Object-Oriented Technology Dr. Koichiro Isshiki Computer Information Department Cal Poly, Pomona krisshiki @csupomona

1. Object-Oriented TechnologyDr. Koichiro IsshikiComputer Information DepartmentCal Poly, Pomonakrisshiki@csupomona.edu Dr. Koichiro Isshiki

2. Outline • Introduction of OO Concepts • Introduction of UML • Using Nouns • Example 1: Electronic Filing Program • Exercise: Computer-Based Gas Station • RDD Approach • Example 2: Electronic Checkbook • Example 3: Elevator Simulation System • Exercise: Coffee Machine Controller Dr. Koichiro Isshiki

3. Introduction of OO Concepts Dr. Koichiro Isshiki

4. Methodology • A process for the organized production of software using a collection of predefined techniques and notational conventions. Early Years Problem Domain Solution Domain (Some Ad-hoc Model) Dr. Koichiro Isshiki

5. Structured Methodology Problem Domain Solution Domain data structure data structure Function 1 Function 2 Function 3 Dr. Koichiro Isshiki

6. OO Methodology Problem Domain Solution Domain MessageMessage Obj 1 Obj 2 Obj 3 Dr. Koichiro Isshiki

7. Procedural vs. OO • Procedural Approach - a program is a collection of procedures and functions read_from_tape (); read_from_file (); write_to_tape (); write_to_file (); • Object-Oriented Approach - a program is a collection of cooperating objects For object tape, define operations read & write For object file, define operations read & write Dr. Koichiro Isshiki

8. Encapsulation - combine data and code e.g. visit to procedural doctor - go to library and get medical books - go to doctor’s office - Doc, here are the books and here are my symptoms - tell me my diagnosis e.g. visit to OO doctor - go to doctor’s office - Doc, here are my symptoms - tell me my diagnosis Dr. Koichiro Isshiki

9. Encapsulation (2) e.g. procedural bread making - get baking pan, mixing bowl, mixer - get flour, yeast, oil - get cookbook - follow directions: pour, mix, knead, raise, knead, raise, bake, time, remove e.g. OO bread making - get flour, yeast, oil - pour into automatic bread maker - turn on Dr. Koichiro Isshiki

10. Traditional System Development • Problems: • Software Projects • Maintenance Cost Escalate • Project Deadlines Slide • Cost Estimate Difficult • Processing • Excessive Transformations • Decreased Productivity Dr. Koichiro Isshiki

11. OO System Development • Iterative rather than sequential • User-centered analysis process • Concepts of objects appear in analysis and is carried through design and implementation • Early & easy prototypes Dr. Koichiro Isshiki

12. Object-Oriented Analysis • A problem domain • A stage in the development cycle in which a real-world problem is examined to understand its requirements without planning the implementation • The process of studying user needs to arrive at a definition of system or software requirements • OOA contains the following activities: • finding the objects • organizing the objects • describing how the objects interact • defining the operations of the objects Dr. Koichiro Isshiki

13. Object-Oriented Design • A solution model • The creation of an abstraction of a software system that is consistent with the requirements specifications and provides a reasonable description for implementation. • A series of decisions on what is most cost-effective implementation • OOD contains the following activities: • building system architecture • providing full definition of classes & user interface • designing algorithms to implement class operations Dr. Koichiro Isshiki

14. OOD Guidelines • Coupling - the “strength” of interdependencies between discrete components in a system. • It’s something to be minimized; e.g. use encapsulation. • For an OO system, we are concerned with the coupling between classes and objects that are not part of a gen-spec or whole-part hierarchy; e.g., we look for ways to minimize the number of messages between objects, as well as the complexity and content of the messages. Dr. Koichiro Isshiki

15. OOD Guidelines (2) • Cohesion - the “strength” of association of elements within a system component (i.e. the degree to which the responsibilities of a single component form a meaningful unit) • An entity, such as a class, an operation, or a module, is coherent if it is organized on a consistent plan and all its parts fit together toward a common goal. • It’s something to be maximized; e.g., a single method should not contain both policy and implementation. Dr. Koichiro Isshiki

16. OOD Guidelines (3) • Reuse • Code reuse • cut, copy, and paste • subroutines and “includes” • binary links • Design reuse • code reuse typically occurs at the bottom levels of a system design hierarchy while design reuse results in whole “branches” of the tree being reused • Specification reuse • eliminate completely the effort involved in designing, coding, and testing an implementation of that specification Dr. Koichiro Isshiki

17. Introduction of UML Dr. Koichiro Isshiki

18. UML • Unified Modeling Language • It unifies the methods of Booch, Rumbaugh, and Jacobson • Model -- an abstraction of something for the purpose of understanding it before building it • architectural models to show customers • airplane models for wind-tunnel tests Dr. Koichiro Isshiki

19. UML (2) • It is a modeling language, not a method • A method consists of both a modeling language and a process • The modeling language is the notation that methods use to express designs • The process is their advice on what steps to take in doing a design Dr. Koichiro Isshiki

20. UML (3) • Different parts of UML: • Views - show different aspects of the system • Diagrams - graphs that describe the contents in a view • Model elements - represent common oo concepts such as classes, objects, messages, and relationships • General mechanisms - provide extra comments, information, or semantics about a model element Dr. Koichiro Isshiki

21. Views • Use-case view: A view showing the functionality of the system as perceived by external actors. • Logical view: A view showing how the functionality is designed inside the system, in terms of the system’s static structure and dynamic behavior. Dr. Koichiro Isshiki

22. Diagrams • For static parts of a system • class diagram • object diagram • component diagram • deployment diagram • For dynamic parts of a system • use case diagram • sequence diagram • collaboration diagram • state diagram • activity diagram Dr. Koichiro Isshiki

23. Static & Dynamic • All systems have a static structure and dynamic behavior. • Static view represents structural, data aspects of a system. It does not describe the time-dependent behavior of the system. • Dynamic modeling is to demonstrate how the objects interact dynamically at different times during the execution of the system, i.e. how the objects collaborate through communication and how the objects within the system change state during the system’s lifetime. Dr. Koichiro Isshiki

24. Use Case Modeling • Originates from Ivar Jacobson’s methodology (OOSE) • Purposes for use cases: • To provide a complete specification, from the users’ point of view, of how the system will function • To provide a basis for performing system tests that verify the system • Defines actors and use cases • Users are classified as actors in the system. For each actor, specific use cases are played against the system. Collectively the use cases detail everything that the users can do with the system. Dr. Koichiro Isshiki

25. Use Case Modeling (2) • Actor - someone or something that interacts with the system (send or receive messages to and from the system); an actor can be a human being or another system • Finding actors - by answering a number of questions: Who will use the main functionality of the system? Who will need support from the system to do their daily tasks? Who will need to maintain, administrate, and keep the system working? Which hardware devices does the system need to handle? With which other systems does the system need to interact? Who or what has an interest in the results that the system produces? Dr. Koichiro Isshiki

26. Use Case Modeling (3) • Use Case - a set of sequences of actions a system performs that yield an observable result of value to a particular actor • is always initiated by an actor (The actor must directly or indirectly order the system to perform the use case) • provides value to an actor • is complete (not a function call; a use case is not complete until the end value is produced) • Finding use cases - for each of the actors identified, ask: Which functions does the actor require from the system? What does the actor need to do? What input/output does the system need? Where does this I/O come from or go to? Dr. Koichiro Isshiki

27. Use Case Modeling (4) • Example - recycling machine • Two actors: the Customer and the Operator. Brian is the operator of the machine, so he normally acts as the Operator actor. However, sometimes he deposits his own bottles and cans, and then he acts as a Customer. • Use cases: Customers deposit cans and/or bottles. Customers print receipts. Customers collect money. Operators collect cans and/or bottles. Operators replace receipt paper. ……. Dr. Koichiro Isshiki

28. Use Case Diagram Recycling Machine Deposit cans/bottles customer Collect cans/bottles Print receipt Collect money operator Dr. Koichiro Isshiki

29. Finding the Objects • Using nouns (see example 1) • Responsibility driven approach (see example 2,3) • Using the things to be modeled (e.g. identify individual or group things, such as persons, organizations, locations, logs, reports, forms, etc.) • Using decomposition • Using generalization • Reusing an application framework Dr. Koichiro Isshiki

30. Using Decomposition • Patient -> Surgical patient, Referral patient Patient referralPatient name:String ssn:Number surgicalPatient rphys setPhysician() physicianIs() surgery setSurgery() surgeryIs() init() nameIs() SSNis() Dr. Koichiro Isshiki

31. Using Generalization • Surgical patient, Referral patient -> Patient referralPatient name:String ssn:Number surgicalPatient rphys setPhysician() physicianIs() surgery setSurgery() surgeryIs() init() nameIs() SSNis() Dr. Koichiro Isshiki

32. Reusing An Application Framework • The steps of this technique follow: • identify one or more relevant application frameworks in the same application domain • reuse both objects and classes from previously developed frameworks (note that some of the classes may need to be modified to be reused in your specific application) Dr. Koichiro Isshiki

33. Using Nouns Dr. Koichiro Isshiki

34. Example 1: Electronic Filing Program Dr. Koichiro Isshiki

35. The Electronic Filing System • Problem Statement • An electronic filing program (EFP) can be used to store and retrieve text documents. Any document created by a word processor may be stored in the electronic filing system. Documents may be filed along with keywords, authors, and/or a document description or abstract describing the document. Documents filed in the system may also be removed or deleted. Dr. Koichiro Isshiki

36. The EFP (2) • Problem Statement (cont’d) • Documents stored using the EFP are indexed to enable rapid retrieval. Users may retrieve or locate documents based on their content, description, author(s), or user-defined keywords. Therefore, the document description, authors, keywords, and/or the actual text document itself may be searched. • A user may specify search criteria, which results in a number of documents being found that meet the specified search criteria. The user may then continue to specify additional search criteria, successively narrowing down the search until the required documents are found. Documents found that meet the user’s search criteria may then be viewed or printed. Dr. Koichiro Isshiki

37. The EFP (3) • Problem Statement (cont’d) • The user is provided with the capability of specifying any “junk” words, which if found in the content of the document will not be searched or indexed - for example, and, or, not, the, if. The user can also specify which alphanumeric characters in the text document will be indexed and searchable (the filing character set), thereby limiting the search and index to only portions of a document(s). Dr. Koichiro Isshiki

38. Identifying Object Classes • Grammatical Inspection - nouns/noun phrases represent candidate objects/classes • Potential Object Classes: abstract, alphanumeric character, author, content, description, document, document description, EFP, electronic filing system, filing character set, index, junk word, keyword, number of documents, portion of the documents, search, search criteria, system, text document, user, user-defined keyword, word processor • By general knowledge • line, word, page Dr. Koichiro Isshiki

39. Identifying Object Classes (2) • Problem Statement • An electronic filing program (EFP) can be used to store and retrieve text documents. Any document created by a word processor may be stored in the electronic filing system. Documents may be filed along with keywords, authors, and/or a document description or abstract describing the document. Documents filed in the system may also be removed or deleted. Dr. Koichiro Isshiki

40. Identifying Object Classes (3) • Problem Statement (cont’d) • Documents stored using the EFP are indexed to enable rapid retrieval. Users may retrieve or locate documents based on their content, description, author(s), or user-defined keywords. Therefore, the document description, authors, keywords, and/or the actual text document itself may be searched. • A user may specify search criteria, which results in a number of documents being found that meet the specified search criteria. The user may then continue to specify additional search criteria, successively narrowing down the search until the required documents are found. Documents found that meet the user’s search criteria may then be viewed or printed. Dr. Koichiro Isshiki

41. Identifying Object Classes (4) • Problem Statement (cont’d) • The user is provided with the capability of specifying any “junk” words, which if found in the content of the document will not be searched or indexed - for example, and, or, not, the, if. The user can also specify which alphanumeric characters in the text document will be indexed and searchable (the filing character set), thereby limiting the search and index to only portions of a document(s). Dr. Koichiro Isshiki

42. Discarding Unnecessary & Incorrect Classes • Redundant Classes - keep the most descriptive object/class name for object classes that express the same information • Irrelevant Classes - classes that have little or nothing to do with the problem domain should be eliminated • Vague Classes - classes should be specific (should not have ill-defined boundaries or be too broad in scope) Dr. Koichiro Isshiki

43. Discarding Unnecessary & Incorrect Classes (2) • Attributes - attributes are properties of object classes and not object classes themselves • Operations - a name describes an operation that is applied to objects should be discarded as a potential object class • Implementation Constructs - anything that has to do with how the problem is solved should not be a part of the analysis model Dr. Koichiro Isshiki

44. Redundant Classes • Document and text document are redundant. Text document is retained because it is more descriptive. Content refers to the document itself and is redundant with text document. • Filing character set and alphanumeric characters are redundant. Filing character set is retained because it’s more descriptive and makes more sense in the application domain. Dr. Koichiro Isshiki

45. Redundant Classes (2) • Description, document description, and abstract are redundant. Abstract is retained because it is a document description and is a familiar term in business and academia. • User-defined keyword and keyword are redundant. All keywords, documents, and authors must be specified by the user in the EFP. Therefore, user-defined is not relevant and keyword will be retained. Dr. Koichiro Isshiki

46. Irrelevant Classes • Word processor is irrelevant since the creation of a document is outside the scope of the EFP software. • Portion of the document and number of documents have nothing to do with the problem and will also be eliminated. • User also has little to do with the problem. All systems have users, and later on we will need to create a user interface. Dr. Koichiro Isshiki

47. Vague Classes • System is too broad in scope. The system is really the EFP, therefore system will be discarded as a potential object class. • EFP and electronic filing system are rather broad in scope. It is the application we are attempting to build, and not an object class in itself. Dr. Koichiro Isshiki

48. Attributes • A search operation requires search criteria in order to perform the search, but beyond that search criteria does not affect the problem. So search criteria should be treated as an attribute of a search operation. Search criteria is discarded as a potential object class. Dr. Koichiro Isshiki

49. Operations • Search involves a sequence of actions to locate one or more documents satisfying some search criteria. Search is discarded as a potential object class. Dr. Koichiro Isshiki

50. Implementation Constructs • Filing character set is an implementation construct. The exact representation of the collection of filing characters is a design issue. Filing character set is renamed filing character. Dr. Koichiro Isshiki