1 / 24

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.

connor
Download Presentation

Requirements Analysis (Part 1 – Object Modeling)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Requirements Analysis(Part 1 – Object Modeling)

  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. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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)

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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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.

  20. 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

  21. 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

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

  23. 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

  24. 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

More Related