Transcript Chapter 2

The Object-Oriented
Approach
to Requirements
Overview
• Objective of requirements definition is
understanding user’s 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
2
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
3
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
4
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
5
Requirements Diagrams: Traditional
and OO Models
6
Use Case Diagram
• Graphical models that summarize information about
actors and use cases
• Use case analysis used to identify and define all business
processes that system must support
• System developer
– Looks at system as whole
– Identifies major uses from event table
– Identifies functions to be supported by new system
– Organizes use cases
7
Use Case Diagram
8
Use Case Diagram
9
The System Activities –
A Use Case / Scenario View
• Use Case - single function performed by system
for those who use that function
• Actors
– Role played by user
– Outside automation boundary and organization
– Could be a human, an organization, another
information system, an external device,
or even time.
10
Four Types of Actors
• Primary business actor
– The stakeholder that primarily benefits from the execution of the
use case.
– e.g. the employee receiving the paycheck
• Primary system actor
– The stakeholder that directly interfaces with the system to initiate
or trigger the business or system event.
– e.g. the bank teller entering deposit information
• External server actor
– The stakeholder that responds to a request from the use case.
– e.g. the credit bureau authorizing a credit card charge
• External receiver actor
– The stakeholder that is not the primary actor but receives
something of value from the use case.
– e.g. the warehouse receiving a packing slip
11
Simple Use Case with an Actor
12
Use Case Diagram with System
Boundary
13
Use Case of Customer Support
System
14
All Use Cases Including Customer
15
<<Includes>> 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
16
<<Includes>> Relationship
17
<<Extend>> Relationships
• Extension use case – a use case consisting of
steps extracted from a more complex use case in
order to simplify the original case and thus extend
its functionality.
18
Generalization Relationship
19
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
20
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
21
Brief Description of Create New Order
Use Case
22
Intermediate Description of the Telephone
Order Scenario for Create New Order
23
Intermediate Description of the Web
Order Scenario for Create New Order
24
Fully Developed Description of Telephone
Order Scenario for Create New Order
25
Fully Developed Description of Web
Order Scenario for Create New Order
26
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
27
Elements of Activity Diagrams
28
Elements of Activity Diagrams
29
Activity Diagram With A Decision Point
One of the two possible
paths will be selected for
each execution
30
Activity Diagram With Synchronization
Bars
Top synchronization bar is a
fork.
Bottom synchronization bar
is a join.
31
Activity Diagram: Telephone Order
Scenario
32
Activity Diagram: Web Order Scenario
33
Activity Diagram With A Decision Point and
Synchronization Bars
การตรวจติดตามผล
ห้ องปฏิบัติการ
สานักบริ หารรั บรองห้ องปฏิบัติการ
คณะกรรมการ
กลุ่มทะเบียนและดัชนีฯ
ครบกำหนดตรวจติดตำม
[ไม่]
[ใช่]
ออกหนังสื อแจ้ง
กำรตรวจติดตำม
เตรี ยมกำร
ออกตรวจติดตำมผล
เสนอผลกำรออกตรวจติดตำม
ลดขอบข่ำย
พักกำรใช้
คืนสถำนะ
เพิกถอน
พิจำรณำ
[ไม่เห็นด้วย ]
[ เห็นด้วย ]
แจ้งผลกำรตรวจติดตำม
ปรับปรุ งบัญชี รำยชื่ อ/ข้อมูล
ห้องปฏิบต
ั ิกำร
รับผลกำรพิจำรณำ
34
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
35
Collaboration Diagram
• Provides a quick overview of all objects that
collaborate to support a given scenario
• Uses same symbols as a sequence diagram
• Shows relationships between two objects (links)
• Cannot easily describe concurrent messages or
creation/deletion of objects
36
Symbols of a Collaboration Diagram
37
RMO Collaboration Diagram for
Look up Item Availability
38
Sample System Sequence Diagram
(SSD)
39
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
40
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
41
Notation
*[true/false condition] return-value := message-name
(parameter-list)
• Asterisk (*) indicates repeat or looping of the message.
• Brackets [ ] indicates a true/false condition. It is a test for
that message only. If it evaluates to true, the message is
sent. If it evaluates to false, the message is not sent.
• Message-name is the description of the requested
service. It is omitted on dashed-line return messages,
which only show the return data parameters.
• Parameter-list (with parentheses on initiating messages
and without parentheses on return messages) shows the
data that is passed with the message.
• Return-value on the same line as the message (requires
:=) is used to describe data being returned from the
destination object to the source object in response to the
message.
42
Repeating Message
43
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
44
Simplified Activity Diagram of the
Telephone Order Scenario
45
SSD of Simplified Telephone Order
Scenario for Create New Order Use Case
46
SSD of the Web Order Scenario for
the Create New Order Use Case
47
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
48
Example of Domain Model Class
Diagram
49
RMO Domain Model Class Diagram
50
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
51
Relationships Between OO
Requirements Models
52
Use Case Diagram for Inventory
System
53
Summary
• Object-oriented approach has complete set of
diagrams that together document the user’s 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)
54