5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 1/58

 

1

ITEC 3010 ³Systems Analysis and Design, I´ 

LECTURE 7:LECTURE 7:The ObjectThe Object--Oriented Approach toOriented Approach to

RequirementsRequirements

[ Prof. Peter Khaiter ]

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 2/58

 

2

Lecture OutlineLecture Outline

Unified Modeling Language (UML)Unified Modeling Language (UML)

ObjectObject--Oriented Requirements (OOR )Oriented Requirements (OOR )

System ActivitiesSystem Activities

Use Case DiagramUse Case Diagram

Activity DiagramActivity Diagram

System Sequence DiagramSystem Sequence Diagram State Machine DiagramState Machine Diagram

Integrating ObjectIntegrating Object--Oriented ModelsOriented Models

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 3/58

 

3

OOA considers an IS as a set of objects that work together to carryout the function. OO analysis involves two steps:

(1) Definition the set of objects that will make up the system anddescribing the interactions or communications among the various

objects (these interactions take the form of messages betweenobjects)

(2) Describing the internal processes that go on within each object torespond to messages from other objects, and to initiate messagesto other objects

UML is a notation used in OO modeling

A preliminary version of UML was presented in 1995 In 1997 UML was presented to the Object Management Group

(OMG) as a standard modeling technique OMG (est. 1989) is a consortium of software vendors, developers

and organization with the goal to provide a common architecturalframework for OO applications ± www.omg.org

Unified Modeling Language (UML)Unified Modeling Language (UML)

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 4/58

 

4

ObjectObject--Oriented RequirementsOriented Requirements

(OOR )(OOR )

Object-oriented system requirements are specifiedand documented through process of buildingmodels

Modeling process starts with identification of usecases and problem domain classes (things inusers¶ work environment) 

Business events trigger elementary businessprocesses (EBP) that new system must addressas use cases

Use cases define functional requirements

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 5/58

 

5

OO models (or diagrams) to define systemrequirements are called use case models: Use case diagram shows the various user roles and how they will

use the system. It is an extension of the event table. It is a convenientway to document the function that the system must support. Sequence diagram shows inputs and outputs and sequence of messages between an external actor and the system objects during ause case or scenario. The flow of information between the objects is in form of messages

OO models (or diagrams) to define classes of objectsand their states are called domain models : Domain class diagram (see lecture 5) ± identifies and classifies theobjects that will make up the new system along with their properties(or attributes)

State machine diagram describes the states and behavior of each

object: life of an object in state and transitions

OOR OOR -- ModelsModels

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 6/58

 

6

The System ActivitiesThe System Activities²²

A Use Case/Scenario ViewA Use Case/Scenario View Use case model used to identify and define all

elementary business processes that system mustsupport

Use cases are identified at two levels:Overview  l evel (event table and use case diagram of all theuse cases)

Detai l ed  l evel (for each use case ± use case description,activity diagram, sequence diagram)

Use case ± an activity a system carried out, usually inresponse to a user request

Actor (person, other system, or device that receive servicesfrom the system and who actually interact with thesystem)

Role played by user

Outside automation boundary

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 7/58

7

Techniques for Identif ying UseTechniques for Identif ying Use

Cases (Review from ChapterCases (Review from Chapter 55))  Identify user goals

Each goal at the elementary business process (EBP) levelis a use case

EBP ± task performed by one user in one place and inresponse to business event that adds measurablebusiness value, and leaves system and data in consistentstate

Event decomposition technique (event table)  CR UD analysis technique (create, read/report,

update, delete) to ensure coverage

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 8/58

8

Use Case DiagramUse Case Diagram Graphical UML diagram that summarizes information about

actors and use cases

Simple diagram shows overview of functionalrequirements

Symbols: use case is symbolized by an oval with the nameof the use case inside; stick figure represents an actor (i.e., arole)

Two approaches to use case diagrams

By subsystem

By actor

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 9/58

9

Simple Use Case with an ActorSimple Use Case with an Actor

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 10/58

10

Use Case Diagram withUse Case Diagram withAutomation Boundary andAutomation Boundary and

Alternate Actor NotationAlternate Actor Notation

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 11/58

11

All Use Cases Involving CustomerAll Use Cases Involving Customer

as Actoras Actor

Direct accessto the system

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 12/58

12

A use case diagramof the CSS for RMOorganizes by subsystems

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 13/58

13

Use Cases of RMOUse Cases of RMO Order E ntr y Order E ntr y 

SubsystemSubsystem

A packaged notation is used: a tabbed rectangle that groups similar

component together

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 14/58

14

<<

Includes>> Relationship<<

Includes>> Relationship

Documents situation in which one use caserequires the services of a common subroutine

Another use case is developed for this commonsubroutine

A common use case can be reused by multiple use

cases

E.g., two use cases ³Create new order´ and ³Update order´ may need to validate the customeraccount. A common use case may be defined to

carry out this function

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 15/58

15

Example of OrderExample of Order--Entry Entry Subsystem with <<Includes>>Subsystem with <<Includes>>

Use CasesUse Cases

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 16/58

16

Objective of the use case diagram is to provide an overview of thesystem (including actors and the functions they perform)

± A use case diagram is like a context diagram in the sense of defining the scope of the system

± However, individual use cases appear more like a DFD fragmentin that they identify an individual function that the system must support

Difference with structured techniques

± The use case diagram begins by defining the automationboundary while in DFD this boundary is often not defined until the

entire process has been detailed

± In a DFD an external agent is always the original source ordestination of the information and may not necessarily be the oneinteracting with the system;

± In a use case diagram, an actor is the one who actually 

interacts with the system whether or not that actor is the originalsource of information

Use Case Diagram vs. StructuredUse Case Diagram vs. Structured

TechniquesTechniques

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 17/58

17

Example: in the RMO case, a customer may call an RMO clerkand make an order.

The DFD would identify the external entity as the customer;

the clerk¶s activity would be embedded in a process ³Entercustomer order´.

In the use case diagram, the clerk would be identified as theactor who uses the system to enter or create a customer order

The use case diagram does not indicate data flows, i.e.information flowing into and out of the system is not shown (thisis done with the next level of modeling ± the sequencediagrams)

Important to identify every possible role that will use thesystem.

Use Case Diagram vs. StructuredUse Case Diagram vs. Structured

Techniques (cont¶d)Techniques (cont¶d)

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 18/58

18

Developing a Use Case DiagramDeveloping a Use Case Diagram

Two main approaches to developing a use case diagram:

First approach: start with an event table and analyze each event todetermine:

How the system is used to support the event

The actors who initiate the event

Other use cases that will need to be invoked

Generally, each event will become a use case

Second approach: identifying all the actors who use the system andthe EBPs with the user goal technique Actors must actually contact the system Assume perfect technology condition (no technical activities!) Actors ± are roles played by users (e.g., order clerk, manager) Identify goal for each actor (e.g., ³accept a return´)

Finalize with a CRUD analysis to ensure completeness (every class hassufficient use cases to support its all methods) ± a cross-check!

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 19/58

19

A use case only shows that an actor interacts with the system to carryout a business activity

There may be a whole series of individual steps to accomplish the usecase (these steps are described with a narrative called a f low of  

activities) - steps within a use case A use case may have several alternative internal activities. In theRMO example, for the use case ³Create new order´ there are at leasttwo sequences when:

± A customer creates telephone order through clerk (a clerkinteracts with the system), or

± A customer creates web order (a customer interacts with thesystem)

A particular sequence of activities within a use case is calledscenario. It represents a unique path through the use case

E.g., two possible scenarios for the RMO use case ³Create new order´:in the first instance, the second actor ³Order  c l erk ́ is involved who isactually interfacing with the system

ScenariosScenarios

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 20/58

20

Two scenarios for RMOTwo scenarios for RMO

³Create new order´³Create new order´

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 21/58

21

Activity DiagramsActivity Diagrams

Used to document workflow of business processactivities for each use case or scenario

Standard UML 2.0 diagram as seen in Chapter 4

Can support any level of use case description; asupplement to use case descriptions

Helpful in developing system sequencediagrams

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 22/58

22

Activity Diagram²T el ephone 

Order Scenario

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 23/58

23

Activity Diagram²

W eb Order Scenario

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 24/58

24

Identif ying Inputs and OutputsIdentif ying Inputs and Outputs²²

The System Sequence DiagramThe 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 to/from actorsand internal objects during flow of activities

Emphasis: how the actor interacts with the system byentering input data and receiving output data

Object notation instead of class notation is used to showthat message is sent to an individual object, not the class

System is shown as one object: a ³black box´ 

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 25/58

25

Object and class names in SSDObject and class names in SSD

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 26/58

26

SSD NotationSSD Notation

Lifeline or object lifeline is a vertical dashed lineunder object or actor to show the sequence of messages over time: from top to bottom

Message is labelled on arrows to show messagessent to or received by actor or system, includinginput data: request operation in the destinationobject

Actor is role interacting with the system with

messages Object is the component that interacts with

actors and other objects

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 27/58

27

System Sequence Diagram (SSD) System Sequence Diagram (SSD) NotationNotation

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 28/58

28

SSD NotationSSD Notation

Activation line

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 29/58

29

SSD LifelinesSSD Lifelines

Vertical line under object or actor

Shows passage of time

If vertical line dashed

Creation and destruction of thing is notimportant for scenario

Long narrow rectanglesActivation lifelines emphasize that objectis active only during part of scenario

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 30/58

30

SSD MessagesSSD Messages

Internal events identified by the flow of objects ina scenario

Requests from one actor or object to another to dosome action

Invoke a particular method

Input message ± solid line

Return message ± dashed line

Complete syntax:

* [true/false condition] return-value := message-name(parameter list)

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 31/58

31

SSD for the RMO Look up itemSSD for the RMO Look up item

availabilityavailability

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 32/58

32

RepeatingMessage

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 33/58

33

Developing a System SequenceDeveloping a System SequenceDiagramDiagram

Begin with detailed description of use casefrom fully developed form or activity

diagram Identify input messages

Describe message from external actor tosystem using message notation

Identify and add any special conditionson input message, including iteration andtrue/false conditions

Identify and add output return messages 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 34/58

34

Activity Diagram of the TelephoneActivity Diagram of the Telephone

Order ScenarioOrder Scenario

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 35/58

35

Resulting SSD for the TelephoneResulting SSD for the Telephone

Order ScenarioOrder Scenario

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 36/58

36

SSD of theW eb Order Scenario for

the CreateNew OrderUse case

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 37/58

37

SSD includes objects from the class diagram and act ors from the usecase diagram

The relationship of use caseThe relationship of use casediagram, class diagram anddiagram, class diagram and

sequence diagramssequence diagrams

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 38/58

38

Developing a System Sequence Diagram:Developing a System Sequence Diagram:StepsSteps

1. Identify all the objects and actors that are involved in the

scenario (they are only actors have been identified in the use

case diagram and objects from the classes that are identified

in the class diagram)

2. Based on the flow of activities, identify each message thatwill be required to carry out the scenario along with both

source object (or actor) for the message and the destination

object (or actor)

3. Determine whether each message is always sent or sent only

under certain conditions4. Sequence the messages correctly and attach them to the

appropriate lifelines of actors and objects

5. Add the formal syntax on the messages for conditions,

message names and passed parameters

6. Add response messages and communications

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 39/58

39

A complete

SSD for theRMO usecaseC reate new  order 

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 40/58

40

Just for Fun!Just for Fun!

http://www.visualjokes.com

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 41/58

41

Identif ying Object BehaviourIdentif ying Object Behaviour²²

The State Machine Diagram (SMD)The State Machine Diagram (SMD) SSDs give external view of object behaviour ± messages

passed around but do not show, what an object does when itgets a message

There is a need to specify internal logic  for each object,

i.e., a description of the actions that the objects performthemselves

State machine diagram is UML a 2.0 diagram that modelsobject internal behaviour, states and transitions

Complex problem domain classes can be modeled

Each object is an instance of a class, and comes intoexistence in some manner

During its existence it is ³in´ certain states and makestransitions from state to state

These states and the changes an object makes from state tostate are shown in SMD (two main symbols: state and

transitions)

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 42/58

42

Identif ying Object BehaviourIdentif ying Object Behaviour²²

The State Machine DiagramThe State Machine Diagram State of an object

A condition that occurs during its life when it satisfies somecriterion, performs some action, or waits for an event

Each state has unique name (e.g., ³on´, ³working´, ³loadingequipment´, etc .) and is a semipermanent condition or status(because external events can interrupt them)

Action is an activity performed by an object in a particular state A state is represented by a rectangle with rounded corners (with

the name of the state inside)

Any actions that must be performed during the period of the stateare placed below the state name in the rectangle

Transition - movement of an object from one state toanother state

Considered to be short in duration and cannot be interruptedOnce started, a transition runs to completion by taking the

object to the new state (called destination state)

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 43/58

43

Simple SMD for a PrinterSimple SMD for a Printer

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 44/58

44

State Machine TerminologyState Machine Terminology

Pseudostate ± 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 objectmoves 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 activitiesperformed as part of a transition

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 45/58

45

Composite States andComposite States andConcurrencyConcurrency²²States within aStates within a

StateState

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 46/58

46

Concurrent Paths for Printer in theConcurrent Paths for Printer in the

On StateOn State

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 47/58

47Relationships among OO models

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 48/58

48

State Machine Diagram and SSDState Machine Diagram and SSD

Each column is labelled with the name of a class (the columns

identify all of the classes in the system); each row is for one sequencediagram; the Xs in the cells show which classes are involved in whichsequence diagram).

An SMD for a class is based on the entire column for that class

Every cell with X provides information about the messages to and

from the class

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 49/58

49

Rules for Developing State MachineRules for Developing State Machine

DiagramDiagram Review domain class diagram, select important

ones, and list all state and exit conditions

Begin building state machine diagram fragmentsfor each class

Sequence fragments in correct order and reviewfor independent and concurrent paths

Expand each transition with message event,

guard-condition, and action-expression Review and test each state machine diagram

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 50/58

50

States and Exit Transitions forStates and Exit Transitions for

OrderItemOrderItem

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 51/58

51

Partial State Machine forPartial State Machine for

OrderItemOrderItem

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 52/58

52

Final State Machine for OrderItemFinal State Machine for OrderItem

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 53/58

53

Order Domain Class for RMOOrder Domain Class for RMO²²

States andEx

it TransitionsStates andEx

it Transitions

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 54/58

54

FirstFirst--Cut State Machine DiagramCut State Machine Diagram

for Orderfor Order

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 55/58

55

SecondSecond--Cut State MachineCut State Machine

Diagram for OrderDiagram for Order

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 56/58

56

Integrating ObjectIntegrating Object--OrientedOriented

ModelsModels 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, construct use casedescriptions, activity diagrams, and systemsequence diagrams for use cases in iteration

Development of a new diagram often helps refineand correct previous diagrams

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 57/58

57

Relationships Between OORelationships Between OO

Requirements ModelsRequirements Models

 

5/12/2018 Lecture3010-71 - slidepdf.com

http://slidepdf.com/reader/full/lecture3010-71 58/58

58

ReadingsReadings

Today¶s lecture: Chapter 7 ± ³The Object-

Oriented Approach to Requirements´ 

For next lecture: Chapter 8 ± ³Evaluating

Alternatives for Requirements,Environments, and Implementation´