Chapter 7: The ObjectOriented Approach to Requirements

1
Chapter 7 The Object-Oriented Approach to
Requirements

• Systems Analysis and Design in a Changing World,
  3rd Edition

2
Learning Objectives

• Develop use case diagrams
• Write use case and scenario descriptions
• Develop activity diagrams and system sequence
  diagrams
• Refine and enhance the domain model class diagram
• Explain how UML diagrams work together to define
  functional requirements for the object-oriented
  approach

3
Overview

• Objective of requirements definition is
  understanding users needs, business processes,
  and system to support business processes
• Understand and define requirements for a new
  system using object-oriented analysis models and
  techniques
• Line between object-oriented analysis and
  object-oriented design is somewhat fuzzy
• Iterative approach to development
• Models built in analysis are refined during design

4
The Unified Modeling Language and the Object
Management Group

• Object-oriented modeling notation is Unified
  Modeling Language (UML)
• UML was presented to Object Management Group
  (OMG) as standard modeling technique
• Purpose of Object Management Group
• Promote theory and practice of object technology
  for development of distributed systems
• Provide common architectural framework for OO

5
Object-Oriented Requirements

• Object-oriented system requirements are specified
  and documented through process of building models
• Systems development process starts with
  identification of events and things
• Events are business processes that new system
  must address
• Things are problem domain objects involved in
  business process

6
Object-Oriented Approach Models

• Class diagram definition of system components
• Use case diagrams and use case descriptions
  show user roles and how they use the system
• Systems sequence diagrams (SSDs) define inputs
  and outputs and sequence of interactions between
  user and system for a use case
• Statechart diagrams describe states of each
  object
• Activity diagrams describe user activities

7
Requirements Diagrams Traditional and OO Models
8
The System Activities A Use Case / Scenario
View

• Use case analysis used to identify and define all
  business processes that system must support
• Use Case - single function performed by system
  for those who use that function
• Actors
• Role played by user
• Outside automation boundary and organization

9
Use Case Diagram

• Graphical models that summarize information about
  actors and use cases
• System developer
• Looks at system as whole
• Identifies major uses from event table
• Identifies functions to be supported by new
  system
• Organizes use cases

10
Simple Use Case with an Actor
11
Use Case Diagram with System Boundary
12
Use Case of Customer Support System
13
All Use Cases Including Customer
14
ltltIncludesgtgt Relationships

• Documents situation where one use case requires
  the services of a common subroutine
• Another use case is developed for this common
  subroutine
• A common use case can be reused by multiple use
  cases

15
Example of Order-Entry Subsystem with
ltltIncludesgtgt Use Cases
16
Developing a Use Case Diagram

• Starting points for use case development
• Use event table
• Identify all actors of the system
• Identify functions actors perform with system
• Develop flow of activities to identify various
  scenarios
• Common internal use cases can be identified and
  separated into different use cases

17
CRUD analysis

• CRUD Create, Read/Report, Update, Delete
• Information Engineering (IE) technique to
  identify event table events or develop use case
  diagram
• Compares identified use cases with domain model
  class diagram
• Every class in class diagram must have use cases
  to support creating, reading, reporting,
  updating, and deleting object instances
• Confirms system integration requirements

18
Use Case Detailed Descriptions

• Scenario, or use case instance, details sequence
  of activities within use case
• Shows actor interacting with computer system
  step-by-step to carry out business activity
• May have several scenarios for single use case
• Analysts prefer to write narrative descriptions
  of use cases instead of building activity
  diagrams
• Three levels brief, intermediate, and fully
  developed description

19
Brief Description of Create New Order Use Case
20
Intermediate Description of the Telephone Order
Scenario for Create New Order
21
Intermediate Description of the Web Order
Scenario for Create New Order
22
Fully Developed Description of Telephone Order
Scenario for Create New Order
23
Fully Developed Description of Web Order
Scenario for Create New Order
24
Activity Diagrams

• Used to document work flow of business process
  activities for each use case scenario
• Standard UML diagram
• Can support any level of use case description
• Helpful in developing system sequence diagrams

25
Activity Diagram Telephone Order Scenario
26
Activity Diagram Web Order Scenario
27
Identifying Inputs and Outputs The System
Sequence Diagram

• Collaboration diagram
• Emphasizes objects that interact together to
  support a use case diagram
• May be used alone or with sequence diagram
• System sequence diagram
• Shows sequence of interactions between objects
  and flow of events in a single use case
• Focuses on message details
• Used more frequently in industry

28
Sample System Sequence Diagram (SSD)
29
SSD Notation

• Actor represented by stick figure person (or
  role) that interacts with system by entering
  input data and receiving output data
• Object notation is rectangle with name of object
  underlined shows individual object and not
  class of all similar objects
• Lifeline is vertical line under object or actor
  to show passage of time for object
• Messages use arrows to show messages sent or
  received by actor or system

30
SSD Lifelines

• Vertical line under object or actor
• Shows passage of time
• If vertical line dashed
• Creation and destruction of thing is not
  important for scenario
• Long narrow rectangles
• Activation lifelines emphasize that object is
  active only during part of scenario

31
SSD Messages

• Internal events identified by the flow of objects
  within a scenario
• Requests from one actor or object to another to
  do some action
• Invokes a particular method

32
Repeating Message
33
Developing a System Sequence Diagram

• Begin with detailed description of use case from
  fully developed form or activity diagrams
• Identify input messages
• Describe message from external actor to system
  using message notation
• Identify and add any special conditions on input
  message, including iteration and true/false
  conditions
• Identify and add output return messages

34
Simplified Activity Diagram of the Telephone
Order Scenario
35
SSD of Simplified Telephone Order Scenario for
Create New Order Use Case
36
SSD of the Web Order Scenario for the Create New
Order Use Case
37
Problem Domain Modeling The Domain Model Class
Diagram

• Class diagram is focal point of object-oriented
  development
• Provides definition of system components
• Contains important class structural information
  for implementation with object-oriented
  programming
• Provides conceptual data model to describe
  classes for database definition
• Consists of problem domain classes and
  implementation classes

38
Example of Domain Model Class Diagram
39
RMO Domain Model Class Diagram
40
Integrating Object-Oriented Models

• Complete use case diagram is needed to understand
  total scope of new system
• Domain model class diagrams also should be as
  complete as possible for entire system
• With iterative approach, only construct use case
  descriptions, activity diagrams, and system
  sequence diagrams for use cases in iteration
• Development of a new diagram often helps refine
  and correct previous diagrams

41
Relationships Between OO Requirements Models
42
Use Case Diagram for Inventory System
43
Summary

• Object-oriented approach has complete set of
  diagrams that together document the users need
  and define system requirements
• Requirements specified using following models
• Domain model class diagrams
• Use case diagrams
• Use case detailed model, either descriptive
  format or activity diagram
• System sequence diagrams (SSDs)