Chapter 4 -6 Modeling and the Requirements Discipline.

Chapter 4 -6

Modeling and the

Requirements Discipline

2Object-Oriented Analysis and Design with the Unified Process

Figure 4-1Activities of the Requirements Discipline


Steps for Requirements Discipline

Gather Detailed Information

Define Requirements

Prioritize Requirements

Develop User Interface Dialogs

Evaluate Requirements with Users


System Requirements System requirements consist of capabilities and

constraints

System requirements fall into two categories

Functional

Nonfunctional


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


Figure 4-14A Simple Activity Diagram to Demonstrate a Workflow


Models and Modeling Purpose

Types

Mathematical models

Descriptive models

Graphical models

Logical models specify processes

Physical models are based on logical models


Figure 4-5UML Diagrams used for Modeling


Validating the Requirements

Two basic approaches to validating requirements

Predictive development

Adaptive development (embodied in UP)

Alternatives to developing costly prototypes

Structured walkthrough


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


Events Types of Events

External Events

Temporal Events

State Events

Identifying Events


Figure 5-2Events Affecting a Charge Account Processing System that Lead to Use Cases


Figure 5-10Information about each Event and the Resulting Use Case in an Event Table


Problem Domain Classes

Problem domain

OO approach to things in problem domain

Identify and understand things in problem domain


Figure 5-12Types of Things


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


Figure 5-13bPartial List of “Things” Based on Nouns for RMO


Associations among Things

Analyst document entity associations ( relationships)

Associations apply in two directions

Multiplicity: the number of associations

The associations between types of things


Figure 5-14Associations Naturally Occur between Things


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


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


Figure 5-17Objects Encapsulate Attributes and Methods


Figure 5-21An Expanded Domain Model Class Diagram Showing Attributes


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


Figure 5-31Rocky Mountain Outfitters Domain Model Class Diagram


Figure 6-1Requirements Diagrams With UML Models


The Use Case Diagram Actors

Notation for use case diagrams

Automation boundary

Includes

Ways to identify additional use cases


Figure 6-2A Simple Use Case with an Actor


Figure 6-3A Use Case Diagram of the Order-Entry Subsystem for RMO,

Showing a System Boundary


Figure 6-6An Example of the Order-entry Subsystem With «Includes» Use Cases


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


Figure 6-10Fully Developed Description of Telephone Order Scenario for

Create New Order Use Case


Figure 6-12Activity Diagram of the Telephone Order Scenario


Identifying Inputs and Outputs—the System Sequence Diagram

System sequence diagram (SSD)

Actor “interacts” with the system via input/output

Parts

Objects

Lifeline

Messages


Figure 6-14Sample System Sequence Diagram


Figure 6-15Repeating Message (A) Detailed Notation (B) Alternate Notation


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


Figure 6-16A Simplified Diagram of the Telephone Order Scenario


Figure 6-19Simple Statechart for a Printer


Identifying the Object Behaviorthe 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


Figure 6-20Sample Composite States for the Printer Object


Figure 6-21Concurrent Paths for the Printer in the On State


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


Figure 6-27Second-cut Statechart for Order


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


Figure 6-28Relationships among OO Requirements Models

Chapter 4 -6 Modeling and the Requirements Discipline.

Documents

Transcript of Chapter 4 -6 Modeling and the Requirements Discipline.