The ObjectOriented Approach to Requirements

1
The Object-Oriented Approach to Requirements
2
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

3
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

4
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

5
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

6
Requirements Diagrams Traditional and OO Models
7
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

8
Use Case Diagram
9
Use Case Diagram
10
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.

11
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

12
Simple Use Case with an Actor
13
Use Case Diagram with System Boundary
14
Use Case of Customer Support System
15
All Use Cases Including Customer
16
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

17
ltltIncludesgtgt Relationship
18
ltltExtendgtgt 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.

19
Generalization Relationship
20
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

21
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

22
Brief Description of Create New Order Use Case
23
Intermediate Description of the Telephone Order
Scenario for Create New Order
24
Intermediate Description of the Web Order
Scenario for Create New Order
25
Fully Developed Description of Telephone Order
Scenario for Create New Order
26
Fully Developed Description of Web Order
Scenario for Create New Order
27
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

28
Elements of Activity Diagrams
29
Elements of Activity Diagrams
30
Activity Diagram With A Decision Point

• One of the two possible paths will be selected
  for each execution

31
Activity Diagram With Synchronization Bars

• Top synchronization bar is a fork.
• Bottom synchronization bar is a join.

32
Activity Diagram Telephone Order Scenario
33
Activity Diagram Web Order Scenario
34
Activity Diagram With A Decision Point and
Synchronization Bars
35
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

36
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

37
Symbols of a Collaboration Diagram
38
RMO Collaboration Diagram for Look up Item
Availability
39
Sample System Sequence Diagram (SSD)
40
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

41
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

42
Notationtrue/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.

43
Repeating Message
44
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

45
Simplified Activity Diagram of the Telephone
Order Scenario
46
SSD of Simplified Telephone Order Scenario for
Create New Order Use Case
47
SSD of the Web Order Scenario for the Create New
Order Use Case
48
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

49
Example of Domain Model Class Diagram
50
RMO Domain Model Class Diagram
51
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

52
Relationships Between OO Requirements Models
53
Use Case Diagram for Inventory System
54
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)