Agenda

1. Agenda • Object Modeling Crash Course • Object Analysis • Classification • Identifying Object Relationships, Attributes, and Methods • Class Diagrams

2. Object Modeling Crash Course

3. Basic Object Concepts • Attributes and Methods • Objects vs. Classes • Encapsulation, Inheritance, Polymorphism • Relationships

4. What is an object? • The term object was first formally utilized in the Simula language to simulate some aspect of reality. • An object is an entity. • It knows things (has attributes) • It does things (provides services or has methods)

5. Attributes • Objects know things I am a Fish. I know my date of arrival and expiration. I am an Employee. I know my name, social security number and my address. I am a Car. I know my color, manufacturer, cost, owner and model.

6. Methods • Objects do things I know how to cook myself. I know how to compute my payroll. I know how to stop.

7. What is an object? • Attributes or properties describe object’s state (data) and methods define its behavior. • Object is whatever the information system wants to talk about. • For example, Parts and assemblies might be objects of bill of material application. • Stocks and bonds might be objects of financial investment applications. • In an object-oriented system, everything is an object: numbers, arrays, records, fields, files, forms, an invoice, etc.

8. Two Basic Questions of OO Analysis and Design • When developing an OO information system, two basic questions always arise. • What objects does the application need? • What functionality should those objects have? • Object Analysis

9. Objects and Classes • The role of a class is to define the attributes and methods (the state and behavior) of its instances. • The class car, for example, defines the property color. • Each individual car (object) will have a value for this property, such as "maroon," "yellow" or "white."

10. A Class is an Object Template, or an Object Factory. Boeing Factory(Boeing Class) Boeing Airplane Objects(Boeing Instances)

11. Class Hierarchy • An object-oriented system organizes classes into subclass-super hierarchy. • At the top of the hierarchy are the most general classes and at the bottom are the most specific

12. Class Hierarchy (Cont’d) • A subclass inherits all of the properties and methods (procedures) defined in its superclass.

13. Inheritance • Inheritance is a relationship between classes where one class is the parent class of another (derived) class. • Inheritance allows classes to share and reuse behaviors and attributes. • The real advantage of inheritance is that we can build upon what we already have and, reuse what we already have.

14. Inheritance (Cont’d)

15. Multiple Inheritance • OO systems permit a class to inherit from more than one superclass. • This kind of inheritance is referred to as multiple inheritance.

16. Multiple Inheritance (Cont’d) • For example utility vehicle inherits from Car and Truck classes.

17. Permissible operations Data Messages Private Protocol Public Protocol Encapsulation and Information Hiding • Information hiding is a principle of hiding internal data and procedures of an object. • Reveal as little as possible about its inner workings. • Encapsulation protects the data from corruption.

18. Polymorphism • Polymorphism means that the same operation may behave differently on different classes. • Example: computePayroll

19. Polymorphism – computePayroll • Managers: Receive a regular salary • Office Workers: Receive an hourly wage and are eligible for overtime after 40 hours • Production Workers: Are paid according to a piece rate

20. Associations • The concept of association represents relationships between objects and classes. • For example a pilot can fly planes.

21. Clients and Servers • A special form of association is a client-server relationship. • This relationship can be viewed as one-way interaction: one object (client) requests the service of another object (server).

22. Object Analysis

23. Object Analysis = Classification / Generalization • Classification and Generalization is Difficult • God is Love • Love is blind • Ray Charles is blind • ergo...

24. Identifying Classes • Noun phrase approach. • Common class patterns approach. • Use Case driven approach. • Class Responsibilities Collaboration (CRC) approach.

25. 1. Noun Phrase Approach • Using this method, read through the Use cases, interviews, and requirements specification carefully, looking for noun phrases. • It is safe to scrap the Irrelevant Classes. • Formulate a statement of purpose for each candidate class; if it’s not possible, simply eliminate it.

26. Guidelines For Identifying Classes • Look for nouns and noun phrases in the problem statement. • Some classes are implicit or taken from general knowledge. • All classes must make sense in the application domain. • Avoid computer implementation classes, defer it to the design stage. • Carefully choose and define class names.

27. Guidelines For Refining Classes • Redundant Classes: • Do not keep two classes that express the same information. • If more than one word is being used to describe the same idea, select the one that is the most meaningful in the context of the system. • Adjective Classes: • Does the object represented by the noun behave differently when the adjective is applied to it? • If the use of the adjective signals that the behavior of the object is different, then make a new class. • For example, If Adult Membership and Youth Membership behave differently, than they should be classified as different classes.

28. Guidelines For Refining Classes (Cont’d) • Attribute Classes: • Tentative objects which are used only as values should be defined or restated as attributes and not as a class. • For example the demographics of Membership are not classes but attributes of the Membership class. • Irrelevant Classes: • Each class must have a purpose and every class should be clearly defined and necessary. • If you cannot come up with a statement of purpose, simply eliminate the candidate class.

29. 2. Common Class Patterns Approach • This approach is based on the knowledge-base of the common classes that have been proposed by various researchers.

30. Candidate Classes • Events • These are points in time that must be recorded and remembered. • Things happen, usually to something else, at a given date and time, or as a step in an ordered sequence. • For example order which is an event that must be remembered. • Organization • The organizational units that people belong to. • For example, accounting department might be considered as a potential class.

31. Candidate Classes (II) • People and Person (Roles and Roles Played) • The different roles users play in interacting with the application. • Two Types of People (Coad and Yourdon): • Users of the system • E.g., Operator, Clerk • Those who do not use the system but about whom information is kept. • E.g., Client, Employee • Places • Physical locations, such as buildings, stores, sites or offices that the system must keep information about.

32. Candidate Classes (III) • Tangible Things and Devices • Physical objects, or group of objects, that are tangible, and devices with which the application interacts. • E.g., Cars, ATM • Concepts • Concepts are principles or ideas not tangible but used to organize or keep track of business activities and/or communications. • E.g., Order, LineItem

33. 3. Use Case Driven Approach • Once the system has been described in terms of its scenarios, examine the textual description or steps of each scenario to determine what objects are needed for the scenario to occur. • To identify objects of a system and their behaviors, the lowest level of executable use cases is further analyzed with a sequence and collaboration diagram pair. • By walking through the steps, you can determine what objects are necessary for the scenario to take place.

34. Client ATMMachine BankClient Insert ATM card Request PIN Request PIN number Verify PIN Number Bad PIN Number Bad PIN NumberMessage Eject ATM card Request take card Take card Display main screen Sequence Diagram – Example

35. Collaboration Diagram – Example 2: Enter Kind 5: Process Transaction 4: Enter Amount 13: Terminate Account ATM Machine:Definition Bank Client 1: Request Kind 3: Request Amount 9: Dispense Cash 8: Transaction succeed 10: Request Take Cash 11: Take Cash 12: Request Continuation 14: Print Receipt 6: Withdraw Checking Account 7: Withdraw Successful Checking Account

36. 3. CRC Cards Approach • CRC stands for Class, Responsibilities and Collaborators developed by Cunningham, Wilkerson and Beck. • CRC can be used for identifying classes and their responsibilities. • Process of the CRC Technique Identify Classes Responsibility Iterate Identify Collaboration Assign Responsibility

37. ClassName Responsibilities Collaborators Collaborations • An object can accomplish either a certain responsibility itself, or it may require the assistance of other objects. • If it requires an assistance of other objects, it must collaborate with those objects to fulfill its responsibility. • CRC Cards: • CRC cards are 4" x 6" index cards. All the information for an object is written on a card.

38. Order Check if items in stock OrderLine Determine Price OrderLine Check for valid payment Customer Dispatch to delivery address CRC Cards – Example

39. CRC Cards Process (Cont’d) • CRC starts with only one or two obvious cards. • If the situation calls for a responsibility not already covered by one of the objects: • Add, or • Create a new object to address that responsibility.

40. Object Modeling Issues – Naming Classes • Guidelines • The class should describe a single object, so it should be the singular form of noun. • Use names that the users are comfortable with. • The name of a class should reflect its intrinsic nature. • By the convention, the class name must begin with an upper case letter. • For compound words, capitalize the first letter of each word • E.g., LoanWindow.

41. Object Modeling – Summary • Finding classes is not easy. • The more practice you have, the better you get at identifying classes. • There is no such thing as the “right set of classes.” • Finding classes is an incremental and iterative process. • Unless you are starting with a lot of domain knowledge, you are probably missing more classes than you will eliminate. • Naming a class is also an important activity.

42. Class Diagram

43. Different Perspectives • Class diagrams can be used in a number of ways: • Conceptual – You draw a class diagram of elements under study • Specification – You develop an programming interface • Implementation – You give guidance to an programmer

44. The Class MyClass Attribute1 Attribute2 Method1 Method2(Integer) Method3():String Class Name Attributes Operations Parameter Return Value

45. Associations Multiplicity: required Multiplicity: optional Order Customer * 0..1 1 Navigability Association {if customer.creditRating=0 then isPrepaid must = true} Role Name Constraint Line items * Order Line Multiplicity: many valued

46. Associations • Conceptual perspective • Conceptual relationships between classes • Specification perspective • Class responsibilities • Interfaces • Implementation perspective • Pointers

47. Associations • Each Association: • Involves two classes • Has two roles • Has two multiplicities (one for each role) • 0..1, 0..*, 1, 1..*, * • Can have zero, one, or two navigability indicators – indicates one-way dependency

48. Attributes • Attributes describe a possible state of a class • Similar to Associations • But, • One way navigability (from Class to Attribute) • Usually for single valued simple classes (e.g., strings, dates, integer, double) • Syntax: • visibility name: type = defaultValue

49. Operations • Operations describe possible methods in a class • Syntax: • visibility name (parameter-list): return-type-expression {property-string} • Query vs. Modifier operations • Get Methods • Set Methods

50. Associations: Generalization • Inheritance is also called generalization • Passes the “is a” test Customer Generalization Personal Customer Corporate Customer