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 How do we describe complex systems (Natural Systems, Social Systems, Artificial Systems)? Epistemology 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

3. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Definition: Object Modeling  Main goal: Find the important abstractions  What happens if we find the wrong abstractions?  Iterate and correct the model  Steps during object modeling  1. Class identification  Based on the fundamental assumption that we can find abstractions  2. Find the attributes  3. Find the methods  4. Find the associations between classes  Order of steps  Goal: get the desired abstractions  Order of steps secondary, only a heuristic  Iteration is important

4. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 Class Identification  Identify the important entities in the system  Class identification is crucial to object-oriented modeling

5. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 Pieces of an Object Model  Classes  Associations (Relations)  Part of- Hierarchy (Aggregation)  Kind of-Hierarchy (Generalization)  Attributes  Methods  Generic methods: General world knowledge  Domain Methods: Dynamic model, Functional model

6. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Operation, Signature or Method? What when?  Operation: A function or transformation applied to objects in a class. All objects in a class share the same operations (Analysis Phase)  Signature: Number & types of arguments, type of result value. All methods of a class have the same signature (Object Design Phase)  Method: Implementation of an operation for a class (Implementation Phase)  Polymorphic operation: The same operation applies to many different classes. Workorder File_name: String Size_in_bytes: integer Last_update: date Stickies: array[max] print() delete() open() close() write() read()

7. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Associations  Relationships among classes:  Basically a bidirectional mapping.  One-to-one, many-to-one, one-to-many,  An association describes a set of links like a class describes a set of objects.

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

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

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

11. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Aggregation  Models "part of" hierarchy  Useful for modeling the breakdown of a product into its component parts (sometimes called bills of materials (BOM) by manufacturers)  UML notation: Like an association but with a small diamond indicating the assembly end of the relationship.

12. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 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

13. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Inheritance  Models "kind of" hierarchy  Powerful notation for sharing similarities among classes while preserving their differences  UML Notation: An arrow with a triangle Cell MuscleCellBloodCellNerveCell StriateSmoothRedWhitePyramidalCortical

14. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Other Associations  Uses:  A subsystem uses another subsystem (System Design)  Contains:  Sometimes called “spatial aggregation” ... contains...  Example: A UML package contains another UML package  Parent/child relationship: ... is father of... ... is mother of...  Seniority: ... is older than... ... is more experienced than...

15. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Roles  A role name is the name that uniquely identifies one end of an association.  A role name is written next to the association line near the class that plays the role.  When do you use role names?  Necessary for associations between two objects of the same class  Also useful to distinguish between two associations between the same pair of classes  When do you not use role names?  If there is only a single association between a pair of distinct classes, the names of the classes serve as good role names

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

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

18. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Roles in Associations  Client Role:  An object that can operate upon other objects but that is never operated upon by other objects.  Server Role:  An object that never operates upon other objects. It is only operated upon by other objects.  Agent Role:  An object that can both operate upon other objects and be operated upon by other objects. An agent is usually created to do some work on behalf of an actor or another agent.

19. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 Qualification  The qualifier improves the information about the multiplicity of the association between the classes.  It is used for reducing 1-to-many multiplicity to 1-1 multiplicity With qualification: A directory has many files, each with a unique name Without qualification: A directory has many files. A file belongs only to one directory. DirectoryFile filename Directory File filename 1* 0..1 1

20. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 Example Problem Statement:A stock exchange lists many companies. However, a stock exchange lists only one company with a given ticker symbol.A company may be listed on many stock exchanges, possibly with different ticker symbols. Find company with ticker symbol AAPL. StockExchange Company tickerSym ** lists

21. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 Use of Qualification reduces multiplicity StockExchangeCompany tickerSym 0..1 1 StockExchange Company tickerSym **

22. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 Object Types  Entity Objects  Represent the persistent information tracked by the system (Application domain objects, “Business objects”)  Boundary Objects  Represent the interaction between the user and the system  Control Objects:  Represent the control tasks performed by the system  Having three types of objects leads to models that are more resilient to change.  The boundary of a system changes more likely than the control  The control of the system change more likely than the application domain  Object types originated in Smalltalk:  Model, View, Controller (MV)

23. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23 Object Modeling in Practice Account Balance Deposit() Withdraw() GetBalance() Customer Name Bank Name

24. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24 Object Modeling in Practice: A Banking System Account Balance Deposit() Withdraw() GetBalance() Customer Name Bank Name Has *

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

26. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26 Dynamic Modeling with UML  Diagrams for dynamic modeling  Interaction diagrams describe the dynamic behavior between objects  Statecharts describe the dynamic behavior of a single object  Interaction diagrams  Sequence Diagram:  Dynamic behavior of a set of objects arranged in time sequence.  Good for real-time specifications and complex scenarios  Collaboration Diagram :  Shows the relationship among objects. Does not show time  State Charts:  A state machine that describes the response of an object of a given class to the receipt of outside stimuli (Events).  Activity Diagram:  Special type of statechart where all states are action states

27. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27 Dynamic Modeling  Definition of dynamic model:  A collection of multiple state chart diagrams, one state chart diagram for each class with important dynamic behavior.  Purpose:  Detect and supply methods for the object model  How do we do this?  Start with use case or scenario  Model interaction between objects => sequence diagram  Model dynamic behavior of single objects => statechart diagram

28. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28 Sequence Diagram  From the flow of events in the use case or scenario proceed to the sequence diagram  A sequence diagram is a graphical description of objects participating in a use case or scenario using a DAG notation  Relation to object identification:  Objects/classes have already been identified during object modeling  Objects are identified as a result of dynamic modeling  Heuristic:  An event always has a sender and a receiver. Find them for each event => These are the objects participating in the use case

29. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29 An Example  Flow of events in a “Get SeatPosition” use case : 1. Establish connection between smart card and onboard computer 2. Establish connection between onboard computer and sensor for seat 3. Get current seat position and store on smart card  Which are the objects?

30. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30 Sequence Diagram for “Get SeatPosition” Smart Card Onboard Computer Seat Establish Connection Accept Connection Get SeatPosition “500,575,300” 1. Establish connection between smart card and onboard computer 2. Establish connection between onboard computer and sensor for seat 3. Get current seat position and store on smart card

31. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31 Heuristics for Sequence Diagrams  Layout:  1st column: Should correspond to the actor who initiated the use case  2nd column: Should be a boundary object  3rd column: Should be the control object that manages the rest of the use case  Creation:  Control objects are created at the initiation of a use case  Boundary objects are created by control objects  Access:  Entity objects are accessed by control and boundary objects,  Entity objects should never call boundary or control objects: This makes it easier to share entity objects across use cases and makes entity objects resilient against technology-induced changes in boundary objects.

32. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32 UML Statechart Diagram Notation State2 State1 Event1(attr) [condition]/action entry /action exit/action  Notation based on work by Harel  Added are a few object-oriented modifications  A UML statechart diagram can be mapped into a finite state machine do/Activity Also: internal transition and deferred events Event trigger With parameters Guard condition

33. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33 Statechart Diagrams  Graph whose nodes are states and whose directed arcs are transitions labeled by event names.  Distinguish between two types of operations:  Activity: Operation that takes time to complete  associated with states  Action: Instantaneous operation  associated with events  associated with states (reduces drawing complexity): Entry, Exit, Internal Action  A statechart diagram relates events and states for one class  An object model with a set of objects has a set of state diagrams

34. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34 State  An abstraction of the attribute of a class  State is the aggregation of several attributes a class  Basically an equivalence class of all those attribute values and links that do no need to be distinguished as far as the control structure of the system is concerned  Example: State of a bank  A bank is either solvent or insolvent  State has duration

35. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35 Example of a StateChart Diagram Idle Collect Money coins_in(amount) / add to balance do: test item and compute change do: make change do: dispense item [change=0] [change>0] [item empty] [select(item)] [change<0] coins_in(amount) / set balance cancel / refund coins

36. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36 Nested State Diagram  Activities in states are composite items denoting other lower- level state diagrams  A lower-level state diagram corresponds to a sequency of lower-level states and events that are invisible in the higher- level diagram.  Sets of substates in a nested state diagram denoting a superstate are enclosed by a large rounded box, also called contour.

37. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37 Example of a Nested Statechart Diagram Superstate Idle Collect Money coins_in(amount) / add to balance do: test item and compute change do: make change do: dispense item [change=0] [change>0] [item empty] [select(item)] [change<0] coins_in(amount) / set balance cancel / refund coins

38. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 38 Expanding activity “do:dispense item” do: move arm to row do: move arm to column do: push item off shelf Arm ready ‘Dispense item’ as an atomic activity: ‘Dispense item’ as a composite activity: do: dispense item [change=0] Arm ready

39. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 39 State Chart Diagram vs Sequence Diagram  State chart diagrams help to identify:  Changes to objects over time  Sequence diagrams help to identify  The temporal relationship of between objects over time  Sequence of operations as a response to one ore more events

40. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 40 Summary: Requirements Analysis  1. What are the transformations?  Create scenarios and use case diagrams  Talk to client, observe, get historical records, do thought experiments  2. What is the structure of the system?  Create class diagrams  Identify objects. What are the associations between them? What is their multiplicity?  What are the attributes of the objects?  What operations are defined on the objects?  3. What is its control structure?  Create sequence diagrams  Identify senders and receivers  Show sequence of events exchanged between objects. Identify event dependencies and event concurrency.  Create state diagrams  Only for the dynamically interesting objects. Dynamic Modeling Functional Modeling Object Modeling

41. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 41 Analysis: UML Activity Diagram

42. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 42 Consistency, Completeness, Ambiguities  Consistency  Identification of crossed “wires” between classes  Naming of classes, attributes, methods  Completeness:  Identification of dangling associations (associations pointing to nowhere)  Identification of double- defined classes  Identification of missing classes (referred to by one subsystem but not defined anywhere)  Ambiguities  Misspelling of names  Classes with the same name but different meanings

43. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 43 Requirements Analysis Document Template 1.Introduction 2.Current system 3.Proposed system 3.1Overview 3.2Functional requirements 3.3Nonfunctional requirements 3.4Constraints (“Pseudo requirements”) 3.5System models 3.5.1 Scenarios 3.5.2 Use case model 3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams 3.5.4 Dynamic models 3.5.5 User interfae 4. Glossary

44. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 44 Section 3.5 System Model 3.5.1 Scenarios - As-is scenarios, visionary scenarios 3.5.2 Use case model - Actors and use cases 3.5.3 Object model - Data dictionary - Class diagrams (classes, associations, attributes and operations) 3.5.4 Dynamic model - State diagrams for classes with significant dynamic behavior - Sequence diagrams for collaborating objects (protocol) 3.5.5 User Interface - Navigational Paths, Screen mockups

45. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 45 Section 3.3 Nonfunctional Requirements 3.3.1 User interface and human factors 3.3.2 Documentation 3.3.3 Hardware considerations 3.3.4 Performance characteristics 3.3.5 Error handling and extreme conditions 3.3.6 System interfacing 3.3.7 Quality issues 3.3.8 System modifications 3.3.9 Physical environment 3.3.10 Security issues 3.3.11 Resources and management issues

46. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 46 Nonfunctional Requirements: Trigger Questions 3.3.1 User interface and human factors  What type of user will be using the system?  Will more than one type of user be using the system?  What sort of training will be required for each type of user?  Is it particularly important that the system be easy to learn?  Is it particularly important that users be protected from making errors?  What sort of input/output devices for the human interface are available, and what are their characteristics? 3.3.2 Documentation  What kind of documentation is required?  What audience is to be addressed by each document? 3.3.3 Hardware considerations  What hardware is the proposed system to be used on?  What are the characteristics of the target hardware, including memory size and auxiliary storage space?

47. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 47 Nonfunctional Requirements (continued) 3.3.4 Performance characteristics  Are there any speed, throughput, or response time constraints on the system?  Are there size or capacity constraints on the data to be processed by the system? 3.3.5 Error handling and extreme conditions  How should the system respond to input errors?  How should the system respond to extreme conditions? 3.3.6 System interfacing  Is input coming from systems outside the proposed system?  Is output going to systems outside the proposed system?  Are there restrictions on the format or medium that must be used for input or output?

48. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 48 Nonfunctional Requirements, ctd  3.3.7 Quality issues  What are the requirements for reliability?  Must the system trap faults?  Is there a maximum acceptable time for restarting the system after a failure?  What is the acceptable system downtime per 24-hour period?  Is it important that the system be portable (able to move to different hardware or operating system environments)?  3.3.8 System Modifications  What parts of the system are likely candidates for later modification?  What sorts of modifications are expected?  3.3.9 Physical Environment  Where will the target equipment operate?  Will the target equipment be in one or several locations?  Will the environmental conditions in any way be out of the ordinary (for example, unusual temperatures, vibrations, magnetic fields,...)?

49. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 49 Nonfunctional Requirements, ctd  3.3.10 Security Issues  Must access to any data or the system itself be controlled?  Is physical security an issue?  3.3.11 Resources and Management Issues  How often will the system be backed up?  Who will be responsible for the back up?  Who is responsible for system installation?  Who will be responsible for system maintenance?

50. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 50 Pseudo Requirements (Constraints)  Pseudo requirement:  Any client restriction on the solution domain  Examples:  The target platform must be an IBM/360  The implementation language must be COBOL  The documentation standard X must be used  A dataglove must be used  ActiveX must be used  The system must interface to a papertape reader

51. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 51 Project Agreement  The project agreement represents the acceptance of the analysis model (as documented by the requirements analysis document) by the client.  The client and the developers converge on a single idea and agree about the functions and features that the system will have. In addition, they agree on:  a list of priorities  a revision process  a list of criteria that will be used to accept or reject the system  a schedule, and a budget

52. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 52 Prioritizing requirements  High priority (“Core requirements”)  Must be addressed during analysis, design, and implementation.  A high-priority feature must be demonstrated successfully during client acceptance.  Medium priority (“Optional requirements”)  Must be addressed during analysis and design.  Usually implemented and demonstrated in the second iteration of the system development.  Low priority (“Fancy requirements”)  Must be addressed during analysis (“very visionary scenarios”).  Illustrates how the system is going to be used in the future if not yet available technology enablers are