1. Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 5, Analysis: Object Modeling

2. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Outline  From use cases to objects  Object modeling  Class vs. instance diagrams  Attributes  Operations & methods  Links & associations  Examples of associations  Two special associations  Aggregation  Inheritance

3. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Requirements Elicitation & Analysis Requirements Elicitation Analysis System Design System Specification Analysis Model System Model

4. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 Analysis Model Use Case Diagram:View Class Diagram:View Sequence Diagram:View Statechart Diagram:View Functional: Model Object: Model Dynamic: Model Object: Model

5. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 Why Functional Decomposition is not Enough Scenarios Level 1 Use Cases Level 2 Use Cases Operations Participating Objects Level 2 Level 1 Level 2 Level 3 Level 3 Level 4 Level 4 Level 3 AB

6. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 How do we describe complex systems? (Natural Systems, Social Systems, Artificial Systems) Knowledge Knowledge about Causality (Dynamic Model) Describes our knowledge about the system Knowledge about Functionality (Functional model) Knowledge about Relationships (Object model) Neural Networks DataFlow Diagrams (SA/SD) Scenarios/Use Cases (Jacobsen) Formal Specifications (Liskov) State Diagrams (Harel) Petri Nets(Petri) Inheritance Frames,SemanticNet works (Minsky) Uncertain Knowledge Fuzzy Sets (Zadeh) Data Relationship (E/R Modeling, Chen) Hierarchical Database Model (IMS) Network Database Model (CODASYL) Relational Database Model (Codd) Fuzzy Frames (Graham) Class Diagrams (“E/R + Inheritance”, Rumbaugh) Sequence Diagrams Activity Diagrams

7. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Definition: Object Modeling  Goal: Find the important abstractions  What happens if we find the wrong abstractions?  Iterate until correct!  Steps: Identify  1. Classes  2. Methods  3. Attributes  4. Associations between classes  Order of steps  Goal: get the desired abstractions  Order of steps secondary, only a heuristic  Iteration is important

8. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Links & Associations  Link[association] establishes relationships among objects[classes].  Link: an instance of an association  Association  A bidirectional mapping.  1-to-1, many-to-1, 1-to-many,  An association describes a set of links like a class describes a set of objects.

9. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 1-to-1 & 1-to-many Associations Has-capital 1-to-1 association 1-to-many association City name:String Workorder schedule() StickyNote x: Integer y: Integer z: Integer * Country name:String

10. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Many-to-Many Associations Work on ** MechanicsPlane

11. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Do UML associations have direction?  A association between 2 classes is by default a bi-directional mapping.  Class A can access class B & class B can access class A  Both classes play the agent role. AB To make A a client, & B a server, make the association unidirectional. The arrowhead points to the server Class A ( the “client”) accesses class B (“the server”). B is also called navigable AB accesses Name Direction Name of association Association Direction

12. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Aggregation  Models "part of" hierarchy  Models the breakdown of a product into its components  An association with a diamond indicating the assembly end of the relation.

13. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 weight Automobile serial number year manufacturer model color drive purchase Aggregation Engine horsepower volume on off 3,4,5 Wheel diameter number of bolts 2,4 Door open close Battery amps volts charge discharge * Brakelight on off

14. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Inheritance  Models "kind of" hierarchy  Models commonalities among classes, preserving differences  An arrow with a triangle Cell MuscleCellBloodCellNerveCell StriateSmoothRedWhitePyramidalCortical

15. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Object Types  Model objects  Represent the application domain being modeled  E.g., a region of the complex plane  View objects  Represent a view of the application domain  The 2D colorized view of the region of the complex plane  Control objects  Represent parameters that control either the model itself or the view.  The Model/View/Controller (MVC) is a design pattern that relates but decouples these kinds of objects.  Makes it easy to change 1 aspect w/o affecting the others.

16. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 Example: 2BWatch Objects  UML has several language extension mechanisms  UML provides the stereotype mechanism to present new modeling elements > Year > Month > Day > ChangeDateControl > LCDDisplayBoundary > ButtonBoundary

17. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Roles  A role is a name that uniquely identifies 1 end of an association.  A role appears next to the the class that plays the role.  When do you use role names?  For associations between 2 objects of the same class  To distinguish between 2 associations between the same pair of classes

18. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Example of Role Problem Statement:A person assumes the role of repairperson with respect to another person, who assumes the role of inspector Person * Creates Workorders inspector repairperson * Creates Workorders Person

19. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 Roles in Associations  Client Role  An object that operates on other objects but is never operated on by other objects.  Server Role  An object that never operates on other objects. It only is operated on by other objects.  Agent Role  An object that operates on other objects & is operated on by other objects.  An agent is usually works on behalf of an actor or another agent.

20. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 How do you find classes?  Learn about problem domain: Observe your client  Find participating objects in use cases’ flow of events  Apply design patterns (E.g., discover MVC relationships)  Establish a taxonomy (Inheritance relations)  Nouns are candidates for classes

21. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 Mapping Parts of Speech to Object Model Components Part of speechModel componentExample Proper nounobject Jim Smith Improper nounclass Toy, doll Doing verbmethod Buy, recommend being verbinheritance is-a (kind-of) having verbaggregation has an modal verbconstraint must be adjectiveattribute red

22. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 Heuristics for Identifying Associations  Examine verb phrases.  Name associations & roles precisely.  Omit associations derivable from others  Associations are transitive: Omit association cycles  FieldOfficer writes EmergencyReport  EmergencyReport triggers Incident  FieldOfficer reports Incident (Incident is reported by FieldOfficer)  After associations are stable, document multiplicities

23. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23 Heuristics for Identifying Attributes  Examine possessive phrases.  Represent object’s state as attributes.  Describe each attribute.  Identify attributes only after class structure is stable.

24. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24 Example: Scenario from Problem Statement  Jim Smith enters a store with the intention of buying a toy for his 3 year old child.  Help must be available within less than one minute.  The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy.  Jim selects a dangerous toy which is unsuitable for the child.  The store owner recommends a more yellow doll.

25. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25 Object Modeling in Practice: Class Identification Foo Balance CustomerId Deposit() Withdraw() GetBalance() Class Identification: Name of Class, Attributes and Methods

26. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26 Object Modeling in Practice: Encourage Brainstorming Foo Balance CustomerId Deposit() Withdraw() GetBalance() Account Balance CustomerId Deposit() Withdraw() GetBalance() Naming is important! “Dada” Balance CustomerId Deposit() Withdraw() GetBalance()

27. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27 Object Modeling in Practice Account Balance AccountId Deposit() Withdraw() GetBalance() Customer Name CustomerId Find New Objects Iterate on Names, Attributes & Methods Bank Name

28. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28 Object Modeling in Practice: A Banking System Account Balance AccountId Deposit() Withdraw() GetBalance() Customer Name CustomerId Bank Name Find Associations Has Name the associations Determine their multiplicities *

29. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29 Object Modeling in Practice: Categorize Savings Account Withdraw() Checking Account Withdraw() Mortgage Account Withdraw() Customer Name CustomerId Account Balance AccountId Deposit() Withdraw() GetBalance() Bank Name Has **

30. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30 Object Modeling in Practice: Heuristics  Schedule team meetings to identify objects  Differentiate between model, view, & control objects  Find associations & their multiplicity  Unusual multiplicities usually lead to new objects or categories  Identify Aggregation  Identify Inheritance: Look for a Taxonomy, Categorize  Allow time for brainstorming; iterate!

31. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31 Development Roles Assign individuals to the following roles:  User: application domain expert. May be many different users.  Client: Overall responsibility for system scope based on user requirements.  Analyst: Details use case[s]; identify objects, associations, attributes of the use case. May be many analysts.  Architect: Unifies use case model.  Document editor: Responsible for assembling the RAD.  Configuration manager: Maintains revision history.  Quality & Assurance: Validates the RAD for correctness, completeness, consistency, realism, verifiability, & traceability.

32. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32 A Revision Process Report problem or change request Review proposed change Review actual change Update RAD Design test Unit test, regression test Design change, estimate impact Archive request Update design Update code CLIENTDEVELOPER

33. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33 Summary  Identify objects  Generalize concrete classes  Refine objects with attributes & operations  Identify associations