Requirements Analysis Modeling Requirements analysis modeling helps - PowerPoint PPT Presentation

Requirements Analysis Modeling Requirements analysis modeling helps transition from elicitation to specification, from stakeholder to engineering view Analysis – the detailed examination of something for explanation or interpretation R. Kuehl/J. Scott Hawker p. 1 R I T Software Engineering

From Requirements to Design and Code Requirements Analysts and  Analysis - a developer’s Developers system/solution perspective Analysis Models of requirements Validation  After requirements (boundary is gray) validation, evaluate the Software analysis model from a Architecture technical design perspective Requirements  Add, refine, start over, etc. Realization Design The requirements model realization is the final answer on what must be done, but not on how to do it R. Kuehl/J. Scott Hawker p. 2 R I T Software Engineering

Use-Case Realization Modeling Use Case Use-Case Realization Sequence Use Class diagrams diagram Cases <<trace>> Use Case Specification Communication diagrams  The external behavior of the use case scenario steps are transformed into an object “design ” of the system  A first step toward architecture design  The use cases are said to be realized in the system design Also known as Robustness Analysis  One possible realization among design (no implementation constraints, options resilient to future changes) R. Kuehl/J. Scott Hawker p. 3 R I T Software Engineering

The Goals of Use-Case Analysis Requirements Perspective  Analyze and validate requirements  Complete, correct, feasible, etc.  Conceive a solution from the available requirements?  The analysis model is transitional, conceptual, it evolves quickly  Explore functional decomposition alternatives  Focus on most important and complex use cases  Think of analysis classes as “ proto-classes ” representing high level abstractions  The result is a very rough first-draft of the system object model R. Kuehl/J. Scott Hawker p. 4 R I T Software Engineering

The Goals of Use-Case Analysis Architecture Perspective  Gain insight into architecture and design requirements  An analysis class encapsulates multiple collaborating design objects  An abstraction of the design model; refined during design  Analysis classes rarely survive into design unchanged  Don’t worry about “formal” documentation and a well-polished model R. Kuehl/J. Scott Hawker p. 5 R I T Software Engineering

Notes  The analysis techniques are based the use of UML notation  This is an introduction – detailed techniques and notation will not be covered (see UML references)  Learning the general use case analysis thought process is more important than any specific technique R. Kuehl/J. Scott Hawker p. 6 R I T Software Engineering

Use-Case Analysis - Steps  Supplement the use case description as necessary  For each use-case  Find classes from use-case behavior  Distribute use-case behavior to classes  Model analysis class interactions in interaction diagrams  For each resulting analysis class  Describe responsibilities and attributes  Describe associations  Unify analysis classes  Review checkpoints R. Kuehl/J. Scott Hawker p. 7 R I T Software Engineering

Class Diagrams R. Kuehl/J. Scott Hawker p. 8 R I T Software Engineering

Class Attributes and Responsibilities <<stereotype>> ClassName  - (Private) Name : Type = InitialValue Attributes represent domain + (Public) Name: Type = InitialValue information # (Protected) Name : Type = InitialValue  Domain attribute types  Use case “Nouns” that did not // PerformAnotherResponsibility become classes  A responsibility is an action an // PerformResponsibility object supports : Client : Supplier  Messages on interaction diagrams define responsibilities Supplier // PerformResponsibility // PerformAnotherResponsibility R. Kuehl/J. Scott Hawker p. 9 R I T Software Engineering

Association Labels  Association names label the association link  Verb phrase with one class the verb subject and the other the verb object  Association roles define the contextual role an object instance plays for its associated object instance  The “face” it presents to its associated object  Acts like an alternative class name <<entity>> <<entity>> <<entity>> departmentHead instructor CourseOffering Professor Department teaches works in <<entity>> Course 0..n (Class object Instances) preRequisites R. Kuehl/J. Scott Hawker p. 10 R I T Software Engineering

Association Multiplicities There can be multiple associations between classes R. Kuehl/J. Scott Hawker p. 11 R I T Software Engineering

The Client Sequence Diagrams classes Supplier PerformResponsibility() Client object Supplier object PerformAnotherResponsibility() Object : Client : Supplier Reflexive message Lifeline (Message to self) 1. PerformResponsibility 1.1. PerformAnotherResponsibility Message Hierarchical message Focus of Control numbering (Activation) Sequence diagrams illustrate how objects interact with each other dynamically R. Kuehl/J. Scott Hawker p. 12 R I T Software Engineering

Communication Diagrams Communication diagrams show the static interactions and links among a set of collaborating objects. Message 1.1. PerformAnotherResponsibility 1. PerformResponsibility : Client : Supplier Client object Link Supplier object Note: The client initiates the behavior and needs it done, the supplier is responsible for carrying out the behavior at the client’s request. R. Kuehl/J. Scott Hawker p. 13 R I T Software Engineering

Stereotypes as Analysis Classes  Separation of concerns - system interface from application logic/control flow from persistent information as specialized class objects (in UML)  Stereotype classes:  Boundary classes: system boundary  Interaction between the system and its actors Boundary  Entity classes: system information and associated behavior Entity  Control classes: system behavior coordination and sequencing Control  Use-case flow of events R. Kuehl/J. Scott Hawker p. 14 R I T Software Engineering

Stereotype Class Collaboration Pattern Use Case <<actor>> External Boundary System Boundary Control Actor Boundary Entity Entity R. Kuehl/J. Scott Hawker p. 15 R I T Software Engineering

Why Stereotype Analysis Classes?  Class stereotypes help  Clarify and separate class roles - encapsulate  Separate things that tend to change independently - modularize  Class stereotypes are conceptually straightforward to begin analysis  Supplement with non stereotype classes in future elaborations as needed  Stereotype classes tend to go away in design Design pattern analogy – model-view-controller R. Kuehl/J. Scott Hawker p. 16 R I T Software Engineering

Requirements Analysis Meta Model Learn the Problem Domain Identify Stakeholders and Users With Stakeholders With Users • User Goals Business User • User Roles Modeling Modeling • Personas • Business Goals, Processes, • User centric and Rules Vision and • Scenarios • System Boundary Scope Task • Activity flow diagrams • Problem Statement Analysis • Task decomposition • Vision & Scope • Model system functions Use Case Software • Actors and associated Modeling Requirements sets of actions Specification • Diagram and descriptions Iterates Architecture • Class Models Use Case and Design • Behavioral models Analysis • Data models (Validation) R. Kuehl/J. Scott Hawker p. 17 R I T Software Engineering