Requirements Analysis (Part 1 – Object Modeling)

Requirements Analysis(Part 1 – Object Modeling)

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)

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

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

Object Modeling Dynamic Modeling 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

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

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

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

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

Mapping parts of speech to object model components [Abbott, 1983] Part of speech Model component Example Proper noun object Jim Smith Improper noun class Toy, doll Doing verb method Buy, recommend being verb inheritance is-a (kind-of) having verb aggregation has an modal verb constraint must be adjective attribute 3 years old transitive verb method enter intransitive verb method (event) depends on

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)

Example: 2BWatch Objects Button Year ChangeDate Month LCDDisplay Day Entity Objects Control Objects Interface Objects

Naming of Object Types in UML • UML provides several mechanisms to extend the language • UML provides the stereotype mechanism to present new modeling elements <<Boundary>> Button <<Entity>> Year <<Control>> ChangeDate <<Entitity>> Month <<Boundary>> LCDDisplay <<Entity>> Day Entity Objects Control Objects Boundary Objects

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. Button_Boundary Year ChangeDate_ Control Month LCDDisplay_Boundary Day

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

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

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

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

Without qualification File 1 * Directory filename With qualification 1 0…1 Directory filename File Qualifiers • Qualifiers can be used to reduce the multiplicity of an association.

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

Exhaust system TicketMachine ZoneButton 0..2 1 Muffler Tailpipe diameter diameter Aggregation Exhaust system 0..2 1 Muffler Tailpipe diameter diameter • 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) 3

Identifying Attributes • Attributes • Properties of individual objects • Properties • Name • Type • Heuristics • Examine possessive phrases • Represent stored state as an attribute • Describe each attribute

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

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

Requirements Analysis (Part 1 – Object Modeling)