Systems Analysis and Design in a Changing World, Fifth Edition_Chapter 7.ppt

7
Systems Analysis and Design in a
Changing World, Fifth Edition

7
Learning Objectives
 Understand the models and processes of defining
object-oriented requirements
 Develop use case diagrams and activity diagrams
 Develop system sequence diagrams
 Develop state machine diagrams to model object
behavior
 Explain how UML diagrams work together to define
functional requirements for the object-oriented
approach
Systems Analysis and Design in a Changing World, 5th Edition 2

7
Overview
 The objective of requirements definition is
understanding – understanding the users’ needs, the
business processes, and the systems 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

7
Object-Oriented Requirements
 Object-oriented modeling notation is Unified Modeling
Language (UML 2.0)
 UML was accepted by Object Management Group
(OMG) as standard modeling technique
 Purpose of Object Management Group
 Promote theory and practice of object-oriented
technology for development of distributed systems
 Provide common architectural framework for OO

7
Object-Oriented Requirements
(continued)
 Object-oriented system requirements are specified
and documented through process of building models
 Modeling process starts with identification of use
cases and problem domain classes (things in users’
work environment)
 Business events trigger elementary business
processes (EBP) that new system must address as
use cases
 Use cases define functional requirements

7
Object-Oriented Requirements Models
 Use case model – a collection of models to capture
system requirements
 Use case diagram – identify actors and their roles and
how the actor roles utilize the system
 Systems sequence diagrams (SSDs) – define inputs and
outputs and sequence of interactions between user and
system for a use case
 Activity Diagram – Used to document workflow of
business processes within a use case
 Domain model – describes the classes of objects and
their states
 State machine diagrams – describe states of each object

7
Requirements Models—Traditional vs
OO
Figure 7-1

7
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 – an activity a system carried out, usually in
response to a user request
 Actor
 Role played by user
 Outside automation boundary

7
Techniques for Identifying Use Cases
(Review from Chapter 5)
 Identify user goals
 Each goal at the elementary business process (EBP)
level is a use case
 EBP – task performed by one user in one place and in
response to business event that adds measurable
business value, and leaves system and data in
consistent state
 Event decomposition technique (event table)
 CRUD analysis technique (create, read/report,
update, delete) to ensure coverage

7
Use Case Diagram
 Graphical UML diagram that summarizes information
about actors and use cases
 Simple diagram shows overview of functional
requirements
 Can have multiple use case diagrams
 By subsystem
 By actor

7
Simple Use Case with an Actor
Figure 7-2

7
Use Case Diagram with Automation
Boundary and Alternate Actor Notation
Figure 7-3

7
All Use Cases Involving Customer as
Actor
Figure 7-4

7
Use Cases of RMO Order Entry
Subsystem
Figure 7-5 (partial figure)

7
15
Use Case of Customer Support System

7
Use Case of Customer Support System
Order Entry
Subsystem
Order
Fulfillment
Subsystem
Customer
Maintenance
Subsystem
Catalog
Maintenance
Subsystem
Customer
Clerk
Merchandising
Order Clerk
Shipping
Clerk
Management

7
<<Includes>> Relationship
 Documents situation in which 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

7
Example of Order-Entry Subsystem
with <<Includes>> Use Cases
Figure 7-6

7
Developing a Use Case Diagram
 Underlying conditions for describing use cases
 Based on automated system, e.g. users “touch” the
system
 Assume perfect technology condition
 Iterate through these two steps
 Identify actors as roles
 List goals, e.g. use cases, for each actor. A goal is a unit
of work.
 Finalize with a CRUD analysis to ensure completeness

7
Use Case Descriptions
 Use case description – a description of the processing
steps for a use case
 Actor – a person or thing that uses the system.
 Actors have contact with the system
 Scenario or Instance – a particular set of internal steps
that represent a unique path of the use case
 Three types of descriptions
 Brief description
 Intermediate description
 Fully developed description

7
Brief Description
Figure 5-13

7
Intermediate Description
Figure 5-14

7
Fully Developed Description
Figure 5-16

7
“Things” in the Problem Domain
 Define system requirements by understanding
system information that needs to be stored
 Store information about things in the problem domain
that people deal with when they do their work

7
Types of Things
Figure 5-18

7
The Domain Model Class Diagram
 Unified Modeling Language (UML) diagram
 Domain model class diagram
 Models things in the users’ work domain
 Used to define requirements for OO (very similar to
entities in ERD)

7
UML Class Symbol
Figure 5-30

7
Simple Domain Model Class Diagram
Figure 5-31

7
Simple Domain Model Class Diagram
(continued)
 No methods shown in domain model
 Domain classes are not software classes
 Very similar to ERD
 UML and domain model can be used in place of ERD
in traditional approach

7
Multiplicity of Associations
Figure 5-32

7
University Course Enrollment Domain
Model Class Diagram
Figure 5-33

7
Refined Model with Association Class
and Grade Attribute
Figure 5-34

7
More Complex Class Concepts
 Generalization/specialization hierarchies
 General superclasses to specialized subclasses
 Inheritance allows subclasses to share characteristics
of their superclasses

7
A Generalization/Specialization
Class Hierarchy for Motor Vehicles
Figure 5-35

7
A Generalization/Specialization
Class Hierarchy for RMO Orders
Figure 5-36

7
Systems
Analysis and
37
Example of Domain Model Class Diagram

7
Whole-Part Hierarchies
 Whole-part hierarchies – hierarchies that structure
classes by components
 Aggregation – whole-part relationships between and
object and its removable parts
 Parts can exist separately
 Like car and its tires
 Composition – whole-part relationships between and
object and its non-removable parts.
 Parts cannot exist separately
 Like Hand is composed of fingers and thumb

7
Whole-Part Aggregation
Relationships
Figure 5-37

7
RMO
Domain
Model
Class
Diagram
Figure 5-38

7
Activity Diagrams
 Used to document workflow of business process
activities for each use case or scenario
 Standard UML 2.0 diagram as seen in Chapter 4
 Can support any level of use case description; a
supplement to use case descriptions
 Helpful in developing system sequence diagrams

7
Activity Diagram— Telephone Order Scenario
Figure 7-8

7
Activity Diagram— Web Order Scenario
Figure 7-9

7
The System Sequence Diagram
 Interaction diagram – a communication diagram or a
sequence diagram
 System sequence diagram (SSD) is type of UML 2.0
interaction diagram
 Used to model input and output messaging
requirements for a use case or scenario
 Shows sequence of interactions as messages during
flow of activities
 System is shown as one object: a “black box”

7
SSD Notation
 Lifeline or object lifeline is a vertical line under object
or actor to show passage of time for object
 Message is labelled on arrows to show messages
sent to or received by actor or system
 Actor is role interacting with the system with
messages
 Object is the component that interacts with actors
and other objects

7
System Sequence Diagram (SSD)
Notation
Figure 7-10

7
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

7
SSD Messages
 Internal events identified by the flow of objects in a
scenario
 Requests from one actor or object to another to do
some action
 Invoke a particular method

7
Repeating Message
Figure 7-11

7
Developing a System Sequence
Diagram
 Begin with detailed description of use case from fully
developed form or activity diagram
 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

7
Activity Diagram of the Telephone Order Scenario
Figure 7-12

7
Resulting SSD for the Telephone
Order Scenario
Figure 7-13

7
SSD of the Web Order Scenario for the Create New Order Use case
Figure 7-14

7
Identifying Object Behaviour—
The State Machine Diagram
 State machine diagram is UML 2.0 diagram that
models object states and transitions
 Complex problem domain classes can be modelled
 State of an object
 A condition that occurs during its life when it satisfies some
criterion, performs some action, or waits for an event
 Each state has unique name and is a semi permanent
condition or status
 Transition
 The movement of an object from one state to another state

7
Simple State Machine Diagram for a
Printer
Figure 7-15

7
State Machine Terminology
 Pseudo state – the starting point of a state machine,
indicated by a black dot
 Origin state – the original state of an object from which
the transition occurs
 Destination state – the state to which an object moves
after the completion of a transition
 Message event – the trigger for a transition, which causes
the object to leave the origin state
 Guard condition – a true/false test to see whether a
transition can fire
 Action expression – a description of the activities
performed as part of a transition

7
Composite States and Concurrency—
States within a State
Figure 7-16

7
Concurrent Paths for Printer in the On State
Figure 7-17

7
Rules for Developing State Machine Diagram
 Review domain class diagram, select important ones,
and list all state and exit conditions
 Begin building state machine diagram fragments for
each class
 Sequence fragments in correct order and review for
independent and concurrent paths
 Expand each transition with message event, guard-
condition, and action-expression
 Review and test each state machine diagram

7
State machine for Ticket Object

7
States and Exit Transitions for
OrderItem
Figure 7-18

7
Partial State Machine for OrderItem
Figure 7-19

7
Final State Machine for OrderItem
Figure 7-20

7
Order Domain Class for RMO—
States and Exit Transitions
Figure 7-21

7
First-Cut State Machine Diagram for Order
Figure 7-22

7
Second-Cut State Machine Diagram for Order
Figure 7-23

7
Integrating Object-Oriented Models
 Complete use case diagram is needed to understand
total scope of new system
 Domain model class diagrams should also 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

7
Relationships Between OO
Requirements Models
Figure 7-24

7
Summary
 Object-oriented approach has complete set of
diagrams that define system requirements
 Requirements specified using following models
 Domain model class diagram (Chapter 5)
 Use case diagrams (Chapters 7)
 Use case detailed models, either descriptive formats or
activity diagrams (Chapter 5 & 7)
 System sequence diagrams (Chapter 7)
 State machine diagrams (Chapter 7)

Systems Analysis and Design in a Changing World, Fifth Edition_Chapter 7.ppt

More Related Content

Similar to Systems Analysis and Design in a Changing World, Fifth Edition_Chapter 7.ppt (20)

More from mnassar75g (7)

Recently uploaded (20)

Systems Analysis and Design in a Changing World, Fifth Edition_Chapter 7.ppt