Presentation is loading. Please wait.

Presentation is loading. Please wait.

Modeling and the Requirements Discipline

Similar presentations


Presentation on theme: "Modeling and the Requirements Discipline"— Presentation transcript:

1 Modeling and the Requirements Discipline
Chapter 4 -6

2 Activities of the Requirements Discipline
Figure 4-1 Activities of the Requirements Discipline Object-Oriented Analysis and Design with the Unified Process

3 Steps for Requirements Discipline
Gather Detailed Information Define Requirements Prioritize Requirements Develop User Interface Dialogs Evaluate Requirements with Users Object-Oriented Analysis and Design with the Unified Process

4 System Requirements System requirements consist of capabilities and constraints System requirements fall into two categories Functional Nonfunctional Object-Oriented Analysis and Design with the Unified Process

5 Techniques for Information Gathering
Review Existing Reports, Forms & Procedure Descriptions Interviews & Discussions with Users Observe & Document Business Processes Build Prototypes Questionnaires Joint Application Design Sessions Object-Oriented Analysis and Design with the Unified Process

6 A Simple Activity Diagram to Demonstrate a Workflow
Figure 4-14 A Simple Activity Diagram to Demonstrate a Workflow Object-Oriented Analysis and Design with the Unified Process

7 Models and Modeling Purpose Types Logical models specify processes
Mathematical models Descriptive models Graphical models Logical models specify processes Physical models are based on logical models Object-Oriented Analysis and Design with the Unified Process

8 UML Diagrams used for Modeling
Figure 4-5 UML Diagrams used for Modeling Object-Oriented Analysis and Design with the Unified Process

9 Validating the Requirements
Two basic approaches to validating requirements Predictive development Adaptive development (embodied in UP) Alternatives to developing costly prototypes Structured walkthrough Object-Oriented Analysis and Design with the Unified Process

10 Events and Use Cases Use case List users and see what they do
List current functions that the system provides or are needed Event decomposition Object-Oriented Analysis and Design with the Unified Process

11 Events Types of Events Identifying Events External Events
Temporal Events State Events Identifying Events Object-Oriented Analysis and Design with the Unified Process

12 Figure 5-2 Events Affecting a Charge Account Processing System that Lead to Use Cases Object-Oriented Analysis and Design with the Unified Process

13 Figure 5-10 Information about each Event and the Resulting Use Case in an Event Table Object-Oriented Analysis and Design with the Unified Process

14 Problem Domain Classes
OO approach to things in problem domain Identify and understand things in problem domain Object-Oriented Analysis and Design with the Unified Process

15 Figure 5-12 Types of Things
Object-Oriented Analysis and Design with the Unified Process

16 Procedure for Developing an Initial List of Things
List nouns users mention when discussing system Event table as source of potential things Use cases, external agents, triggers, response   Select nouns with questions concerning relevance Further research may be needed Object-Oriented Analysis and Design with the Unified Process

17 Partial List of “Things” Based on Nouns for RMO
Figure 5-13b Partial List of “Things” Based on Nouns for RMO Object-Oriented Analysis and Design with the Unified Process

18 Associations among Things
Analyst document entity associations ( relationships) Associations apply in two directions Multiplicity: the number of associations   The associations between types of things Object-Oriented Analysis and Design with the Unified Process

19 Associations Naturally Occur between Things
Figure 5-14 Associations Naturally Occur between Things Object-Oriented Analysis and Design with the Unified Process

20 Attributes of Things Specific details of things are called attributes
Analyst should identify attributes of things Identifier (key): attribute uniquely identifying thing Compound attribute is a set of related attributes Object-Oriented Analysis and Design with the Unified Process

21 Classes and Objects Domain model class diagram as UML class
Problem domain objects have attributes Software objects encapsulate attributes and behaviors Behavior: action that the object processes itself Software objects communicate with messages Information system is a set of interacting objects Object-Oriented Analysis and Design with the Unified Process

22 Objects Encapsulate Attributes and Methods
Figure 5-17 Objects Encapsulate Attributes and Methods Object-Oriented Analysis and Design with the Unified Process

23 An Expanded Domain Model Class Diagram Showing Attributes
Figure 5-21 An Expanded Domain Model Class Diagram Showing Attributes Object-Oriented Analysis and Design with the Unified Process

24 Hierarchies in Class Diagram Notation
Generalization/specialization notation Classification: means of defining classes of things Whole-part Hierarchy Notation Two types of whole-part hierarchies Multiplicity applies to whole-part relationships Object-Oriented Analysis and Design with the Unified Process

25 Rocky Mountain Outfitters Domain Model Class Diagram
Figure 5-31 Rocky Mountain Outfitters Domain Model Class Diagram Object-Oriented Analysis and Design with the Unified Process

26 Requirements Diagrams With UML Models
Figure 6-1 Requirements Diagrams With UML Models Object-Oriented Analysis and Design with the Unified Process

27 The Use Case Diagram Actors Notation for use case diagrams
Automation boundary Includes Ways to identify additional use cases Object-Oriented Analysis and Design with the Unified Process

28 A Simple Use Case with an Actor
Figure 6-2 A Simple Use Case with an Actor Object-Oriented Analysis and Design with the Unified Process

29 Figure 6-3 A Use Case Diagram of the Order-Entry Subsystem for RMO, Showing a System Boundary Object-Oriented Analysis and Design with the Unified Process

30 An Example of the Order-entry Subsystem With «Includes» Use Cases
Figure 6-6 An Example of the Order-entry Subsystem With «Includes» Use Cases Object-Oriented Analysis and Design with the Unified Process

31 Use Case Detailed Descriptions
Use cases have internal complexity Use case descriptions written at (3) levels of detail Brief Intermediate Fully developed Activity Diagram Description Object-Oriented Analysis and Design with the Unified Process

32 Figure 6-10 Fully Developed Description of Telephone Order Scenario for Create New Order Use Case Object-Oriented Analysis and Design with the Unified Process

33 Activity Diagram of the Telephone Order Scenario
Figure 6-12 Activity Diagram of the Telephone Order Scenario Object-Oriented Analysis and Design with the Unified Process

34 Identifying Inputs and Outputs—the System Sequence Diagram
System sequence diagram (SSD) Actor “interacts” with the system via input/output Parts Objects Lifeline Messages Object-Oriented Analysis and Design with the Unified Process

35 Sample System Sequence Diagram
Figure 6-14 Sample System Sequence Diagram Object-Oriented Analysis and Design with the Unified Process

36 Repeating Message (A) Detailed Notation (B) Alternate Notation
Figure 6-15 Repeating Message (A) Detailed Notation (B) Alternate Notation Object-Oriented Analysis and Design with the Unified Process

37 Developing a System Sequence Diagram
Begin with detailed description of use case Fully developed form Activity diagrams (4) step process for turning activity diagram into SSD   [1] Identify the input messages [2] Describe messages from external actor to system [3] Identify/apply special conditions to input messages [4] Identify and add the output return messages  Object-Oriented Analysis and Design with the Unified Process

38 A Simplified Diagram of the Telephone Order Scenario
Figure 6-16 A Simplified Diagram of the Telephone Order Scenario Object-Oriented Analysis and Design with the Unified Process

39 Simple Statechart for a Printer
Figure 6-19 Simple Statechart for a Printer Object-Oriented Analysis and Design with the Unified Process

40 Identifying the Object Behaviorthe Statechart Diagram
Guidelines to help identify states Check naming convention for status conditions Simple states reflect simple conditions such as “On” Complex states labeled with verb phrases Active states usually not labeled with nouns Describe only states of being of the object itself Status conditions reported to management/customers Concurrency Composite States Object-Oriented Analysis and Design with the Unified Process

41 Sample Composite States for the Printer Object
Figure 6-20 Sample Composite States for the Printer Object Object-Oriented Analysis and Design with the Unified Process

42 Concurrent Paths for the Printer in the On State
Figure 6-21 Concurrent Paths for the Printer in the On State Object-Oriented Analysis and Design with the Unified Process

43 Rules for Developing Statecharts
[1] Select the classes that will require statecharts [2] List all the status conditions for each group [3] Specify transitions that cause object to leave the identified state [4] Sequence state-transition combinations in correct order 5] Identify concurrent paths. [6] Look for additional transitions [7] Expand each transition as appropriate [8] Review and test each statechart Object-Oriented Analysis and Design with the Unified Process

44 Second-cut Statechart for Order
Figure 6-27 Second-cut Statechart for Order Object-Oriented Analysis and Design with the Unified Process

45 Integrating Object-Oriented Models
Primary (or source) models Use case diagram Problem domain class diagram CRUD analysis validates model completeness Construction of one model depends on another Models capturing processes of new system Use case diagram and models to lower left Models capturing information about classes Class diagrams and dependencies Object-Oriented Analysis and Design with the Unified Process

46 Relationships among OO Requirements Models
Figure 6-28 Relationships among OO Requirements Models Object-Oriented Analysis and Design with the Unified Process


Download ppt "Modeling and the Requirements Discipline"

Similar presentations


Ads by Google