1. Using UML, Patterns, and Java Object-Oriented Software Engineering Requirements Analysis (Part 1 – Object Modeling)

2. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2 Requirements Analysis  Formalization of requirements elicited from users  Analysis models  Functional model (use cases)  Analysis object model (class diagrams)  Dynamic model (statechart and sequence diagrams)

3. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 From Use Cases to Objects Level 1 Use Case Level 2 Use Cases Level 3 Use Cases Operations Participating Objects Level 2 Level 1 Level 2 Level 3 Level 3 Level 4 Level 4 Level 3 AB

4. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 From Use Cases to Objects: 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

5. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 Object Models  Analysis Object Model  Classes and objects that describe the application domain  Part of the Requirements Analysis Document (RAD)  Examples: BoardGame, Watch  Solution Object Model  Classes and objects that are used to solve the problem  Part of the Object Design Document (ODD)  Examples: Tree, Hashtable, Widget  During Requirements Analysis, we focus on building the Analysis Object Model

6. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 Object Models and Dynamic Models  Object model  Focuses on individual concepts manipulated by system  Class diagrams represent relationships between classes and objects and properties of those classes and relationships  Dynamic model  Focuses on behavior of the system  Sequence diagrams represent interactions between objects within a single use case  Statecharts represent behavior within a single object

7. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 Analysis Activities  Identifying entity objects  Identifying boundary objects  Identifying control objects  Mapping use cases to objects with sequence diagrams  Modeling interactions among objects with CRC cards  Identifying associations  Identifying aggregates  Identifying attributes  Modeling state-dependent behavior of individual objects  Modeling inheritance relationships between objects  Reviewing the analysis model Object Modeling Dynamic Modeling

8. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 Activities during 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

9. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 Class Identification  Identify the boundaries of the system  Identify the important entities in the system  Class identification is crucial to object-oriented modeling  Basic assumption:  1. We can find the classes for a new software system (Forward Engineering)  2. We can identify the classes in an existing system (Reverse Engineering)  Depending on the purpose of the system different objects might be found  How can we identify the purpose of a system?  Scenarios and use cases

10. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 Pieces of an Object Model  Classes  Associations (Relations)  Generic associations  Canonical associations  Part of- Hierarchy (Aggregation)  Kind of-Hierarchy (Generalization)  Attributes  Detection of attributes  Application specific  Attributes in one system can be classes in another system  Turning attributes to classes  Operations  Detection of operations  Generic operations: Get/Set, General world knowledge, design patterns  Domain operations: Dynamic model, Functional model

11. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 Object vs Class  Object (instance): Exactly one thing  Class: describes a group of objects with similar properties  Object diagram: A graphic notation for modeling objects, classes and their relationships ("associations"):  Class diagram: Template for describing many instances of data. Useful for taxonomies, patters, schemata...  Instance diagram: A particular set of objects relating to each other. Useful for discussing scenarios, test cases and examples

12. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12 Finding Participating Objects in Use Cases  Pick a use case and look at its flow of events  Find terms that developers or users need to clarify in order to understand the flow of events  Look for recurring nouns (e.g., Incident),  Identify real world entities that the system needs to keep track of (e.g., FieldOfficer, Dispatcher, Resource),  Identify real world procedures that the system needs to keep track of (e.g., EmergencyOperationsPlan),  Identify data sources or sinks (e.g., Printer)  Identify interface artifacts (e.g., PoliceStation)  Be prepared that some objects are still missing and need to be found:  Model the flow of events with a sequence diagram  Always use the user’s terms

13. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Mapping parts of speech to object model components [Abbott, 1983] Part of speechModel componentExample Proper nounobjectJim Smith Improper nounclassToy, doll Doing verbmethodBuy, recommend being verbinheritanceis-a (kind-of) having verbaggregationhas an modal verbconstraintmust be adjectiveattribute3 years old transitive verbmethodenter intransitive verbmethod (event)depends on

14. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 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 interface 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 (MVC)

15. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Example: 2BWatch Objects Year Month Day ChangeDate Button LCDDisplay Entity Objects Control ObjectsInterface Objects

16. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 Naming of Object Types in UML  UML provides several mechanisms to extend the language  UML provides the stereotype mechanism to present new modeling elements > Year > Month > Day > ChangeDate > Button > LCDDisplay Entity Objects Control ObjectsBoundary Objects

17. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 Recommended Naming Convention for Object Types  To distinguish the different object types on a syntactical basis, we recommend suffixes:  Objects ending with the “_Boundary” suffix are boundary objects  Objects ending with the “_Control” suffix are control objects  Entity objects do not have any suffix appended to their name. Year Month Day ChangeDate_ Control Button_Boundary LCDDisplay_Boundary

18. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 Example: Flow of events  The customer enters a store with the intention of buying a toy for his child with the age of n.  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.  The customer selects a dangerous toy which is kind of unsuitable for the child.  The store owner recommends a more yellow doll.

19. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19 Identifying Entity Objects  Entity objects  Persistent information tracked by system  Heuristics  Terms that developers or users need to clarify in order to understand the use case  Recurring nouns in the use case  Real-world entities that the system needs to track  Real-world activities that the system needs to track  Data sources or sinks

20. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20 Identifying Boundary Objects  Boundary objects  Interactions between actors and system  Heuristics  Identify user interface controls that the user needs to initiate the use case  Identify forms the user needs to enter data into the system  Identify notices and messages the system needs to respond to the user  Identify actor terminals to refer to the user interface under consideration  Do not model the visual aspects of the user interface  Use end users’ terms

21. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21 Identifying Control Objects  Control objects  Realize use cases, encapsulates the behavior of the use case  Usually not persistent, exists in the lifetime of the use case  Helps clarify the entry and exit conditions of the use case  Heuristics  Identify one control object per use case  Identify one control object per actor in the use case

22. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22 Identifying Associations  Association  A relationship between two or more classes  Properties  Name – describes what the relationship is all about  Role – the function of each class in the association  Multiplicity – number of possible instances  Heuristics  Examine verb phrases  Name associations and roles precisely  Use qualifiers to identify namespaces and keys  Eliminate associations that can be derived from other associations  Worry about multiplicity later  Minimize the number of associations

23. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23 Qualifiers  Qualifiers can be used to reduce the multiplicity of an association. Directory File filename Without qualification 1* With qualification DirectoryFile 0…1 1 filename

24. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24 Identifying Aggregates  Aggregate  An association denoting whole-part relationship  Composition aggregate  Whole and parts cannot exist without each other  Denotes is-part-of relationship  Shared aggregate  Whole and parts can exist independently  Denotes belongs-to relationship  Heuristics  1-to-many relationships could potentially be whole-part relationships

25. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25 Aggregation  An aggregation is a special case of association denoting a “consists of” hierarchy.  The aggregate is the parent class, the components are the children class.  A solid diamond denotes composition, a strong form of aggregation where components cannot exist without the aggregate. (Bill of Material) TicketMachineZoneButton 3 Exhaust system Muffler diameter Tailpipe diameter 1 0..2 Exhaust system Muffler diameter Tailpipe diameter 1 0..2

26. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26 Identifying Attributes  Attributes  Properties of individual objects  Properties  Name  Type  Heuristics  Examine possessive phrases  Represent stored state as an attribute  Describe each attribute

27. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27 Modeling Inheritance Relationships  Generalization  Identification of abstract concepts from lower-level ones  Specialization  Identification of more specific concepts from a high-level one  Heuristics  Look for classes that share similarities  Look for groups of classes that appear to be a taxonomy

28. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28 Another Example  The customer enters the store to buy a toy.  It has to be a toy that his daughter likes and it must cost less than 50 Euro.  He tries a videogame, which uses a data glove and a head-mounted display. He likes it. An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely the boardgame “Monopoly". Flow of events: Is this a good use Case? “Monopoly” is probably a left over from the scenario The use case should terminate with the customer leaving the store Not quite!

29. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29 Grammatical constructUML Component Concrete Person, ThingObject nounclass verbOperation Classifying verbInheritance Possessive VerbAggregation modal VerbConstraint AdjectiveAttribute Intransitive verbOperation (Event) Textual Analysis using Abbot‘s technique Example “Monopoly" “toy" “enters" “is a",“either..or", “kind of…" "Has a ", “consists of" “must be", “less than…" "3 years old" “depends on…."

30. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30 Generation of a class diagram from flow of events  The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a videogame, which uses a data glove and a head-mounted display. He likes it. An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely a boardgame. The customer buy the game and leaves the store type of toy customer depends storeenters Customer ? enter() toydaughter suitable * less than 50 Euro store enter() daughter age toy buy() videogameboardgame toy age videogame daughter boardgame Flow of events: toy price buy() like() buy

31. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31 Avoid Ravioli Models Customer Name CustomerId Account Amount Deposit() Withdraw() GetBalance() CustomerId AccountI d Bank Name Has * * Savings Account Withdraw() Checking Account Withdraw() Mortgage Account Withdraw() Don’t put too many classes into the same package: 7+-2 (or even 5+-2) Don’t put too many classes into the same package: 7+-2 (or even 5+-2)

32. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32 Put Taxonomies on a separate Diagram Savings Account Withdraw() Checking Account Withdraw() Mortgage Account Withdraw() Account Amount Deposit() Withdraw() GetBalance() CustomerId AccountI d

33. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33 A Strategy for Building Object Models  Explicitly schedule meetings for object identification  First just find objects  Then try to differentiate them between entity, interface and control objects  Find associations and their multiplicity  Unusual multiplicities usually lead to new objects or categories  Identify Inheritance: Look for a Taxonomy, Categorize  Identify Aggregation  Allow time for brainstorming, Iterate, iterate

34. Modified from originals of Bruegge & Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34 Managing Analysis  Documenting analysis  Assigning responsibilities  Communicating about analysis  Iterating over the analysis model  Client sign off