2Object-Oriented Analysis and Design with the Unified Process Detailed Object-Oriented Requirements...

2Object-Oriented Analysis and Design with the Unified Process

Detailed Object-Oriented Requirements Definitions The Object-Oriented approach has a set of Diagrams that together document the user’s needs and define the System Requirements. It may seem complex at first to have so many different types of Diagrams, but as you use them , you will learn to appreciate how they all fit together to produce a complete Specification.

Each Diagram describes a different aspect of the System, so you only focus on one aspect at a time.

Analysts use a collection of Models (Diagrams) based on Use Cases with the Object- Oriented approach.

Four Models are used to describe the System Use Cases from various points of view. This Approach is referred to as “Use Case Driven”

◘ Use Case Diagrams

◘ Use Case Descriptions

◘ Activity Diagrams

◘ System Sequence Diagrams (SSD)


Detailed Object-Oriented Requirements Definitions Each of the Four models are takes each Use Case , one by one, and extend the Requirements in more detail.

Statechart, however is not Use Case Driven but Object Driven.

The Use Case Diagram shows the Various User roles and the way those Users interact with the System. - The Use Case Diagram can be derived directly from the Event Table; Thus a Use Case Diagram is a convenient way to to document the System Events.

Sometimes a single comprehensive Diagram is used to identify all Use cases for an entire System. Sometimes a set of narrower Use Case Diagrams is used.

Each Use Case in the Diagram must be described in detail either by a narrative description of the steps that the User and the System do together

to complete the Use Case. Activity Diagrams can also be used to describe

any business processes done by people in an organization.


Detailed Object-Oriented Requirements Definitions Activity Diagram is a type of workflow Diagram that describes the Users activities and their sequential flows.

Can also be used to describe processes that include both Manual and Automated System Activities.

System Sequence Diagram: Is a Diagram showing the Sequence (SSD) of Messages between an Actor and the System during a Use Case Scenario. SSDs are used to describe the Input and Output s and the sequential order of them. SSDs used in conjunction with Detailed Use Case Descriptions and/or with Activity Diagrams to show processing steps and interactions between the Actor and the System.


Detailed Object-Oriented Requirements Definitions Class Diagrams: Are used to identify the real-world “Things” that determine the structure of the Programming Classes. Constructing a Class Diagram help Analyst identify information about the real-world objects that will be part of the new System.

Statechart Diagram; Is a Diagram showing the Life of an Object in a set of “States” and “Transitions”. Since the Real-world objects are mirrored inside the Computer System, often the Status Conditions of the real Objects are an important piece of information that the Analyst can use to define the Business Rules to be implemented in the Computer System.

Statecharts are also using during the Design to identify various States of the System itself and the allowable events that can be processed. Therefore Statecharts can be considered as an Analysis tool or as a Designer Tool.


Requirements Diagrams With UML Models


A USE CASE / SCENARIO VIEW A Use Case can be defined at an Overview Level or at a Detailed Level. Event table provides an Overview of all Use Cases for a System.

Detailed information abut each Use Case is described with a Use Case Description., an Activity Diagram, and a System Sequence Diagram, or a combination of these Models.

USE CASES AND ACTOR

The Actor is the person or things that actually touches or interacts with the System.An Actor is a role played by people or things. - An Actor is always outside Automation boundary of the System . Eg. A Customer might be a Actor if He/she places the Order directly through the Internet.


THE USE CASE DIAGRAM Use Case Diagram Symbols Stick figure is given a name that characterizes the role

the Actor is playing. An Actor can be Other Systems that interfaces with the System

being developed. In that case the Actor illustrated either with an appropriately named stick figure or with a Rectangle.

◘ E.g. Purchasing Subsystem.

Oval figure is given a name of the Use Case inside. The Connecting Lines between Actor and the Use

Cases indicate which Actor uses (Utilizes) which Use Cases.

Automation Boundary denotes the boundary between the environment , where the Actors resides. And the internal components of the Computer System..


A Simple Use Case with an Actor


A Use Case Diagram of the Order-Entry Subsystem for RMO, Showing a System Boundary


THE USE CASE DIAGRAM There are two popular ways to Organize Use Case Diagrams to depict different point of view:

Organize Use Cases by Subsystem Organize the Use Cases that involve a Specific Actor

This approach is useful for showing all of the Business Events that are accessible through Internet.

Analyst chooses to draw the Use Case Diagrams based on the needs of the Project Team.


A Use Case Diagram of the Customer Support System (by Subsystem)


« Includes » Relationships «includes» or «uses» Relationship During the Development of a Use Case Diagram it is reasonable

for more than one Use Case to use the services of a Common Subroutine.

Examples: “Create new Order” and “Update Order” Use Cases may need to validate the Customer Account. In that case two Common subroutines may be defined to carry the function of Customer Account Validation, “Validate

Customer Account” and “Look Up Item Availability” .

The Common Subroutine itself becomes additional Use Case.

These Relationship is called as <<includes>> or <<uses>>>

Notation The Relationship between these Use cases is denoted by Connecting Line with arrow.

The Direction of the Arrow indicates which Use Case is Included as apart of the Major Use Cases.


An Example of the Order-entry Subsystem With «Includes» Use Cases


DEVELOPING A USE CASE DIAGRAM Business Modeling helps Analysts understand the Business processes. As a result of Business Modeling Business Events are identified and documented in the Event Table.

Event Table is used to identify the Use Cases. However, the Analysts often need to make some adjustments when building a Use Case Diagram.

- One major Adjustment is that frequently Business Events may be combined into single Use Case. e.g. Adding new Customer and changing Customer information may be done by two different but from the System point of view can be combine into a single Use “Maintain Customer Information”

- Analysts also make adjustment by splitting a single Event into multiple Use Cases. These additional Use Cases can be identified either <<includes>> relationships or when another Use Case is defined from recognizing a common subroutine

Special attention should be paid to Temporal and State Events. Although these Events are not requested by any Actors they must be included in the System Requirements. Therefore, Analyst often connect these business Events to an “Administrator Actor” that might invoke them as a Special Procedure


DEVELOPING A USE CASE DIAGRAM The Process for moving from Business Events to defining Use Cases requires two steps done in iteration:

1. Identify the Actor for each Use Case. (Remember other Systems may also be Actors of a System)

2. Extract the information from the Business Events that describe the System responses to the Business Events. Remember to adjust the Use Cases so that Goals are System tasks such as “Process a Sale”, “Accept Goods Return” etc…

Also remember that you must assume “Perfect Technology”. Be sure that Use Cases are based on Business Events not on Technical Activities such as :Logging on to the System”


USE CASE DESCRIPTIONS The Use Case Diagram helps identify the various processes that Users perform and that the new System must support.

However, careful System Development requires much more detailed level of description or Diagrams. To create a comprehensive, robust System that needs Users’ needs, Analyst must understand all of the derailed internal steps within a single Use Case.

Internally a Use Case includes a whole sequence of steps to complete a Business process and frequently several variations of the Business steps (flows of Activities) exist within a Single Use Case. These different flow of

Activities are called “Scenarios” or “Use Case Instances”.

SCENARIO is a unique set of internal activities within a Use Case and represents a unique path through the Use Case. A Use Case may have many different Scenarios.


USE CASE DESCRIPTIONS (continued) Use Case Descriptions are written at three levels of detail

Brief Description

Intermediate Description

Fully Developed Description

Written Descriptions and Activity Diagrams can be used in any combination depending

on Analyst’s need.

Brief Description

Can be used for very simple Use Cases especially when the System to be developed is also small and well understood application. Simple Use case would normally have a single Scenario and very few (if any) exception Conditions. It is used in conjunction with an Activity Diagram adequately describes a simple Use Case.


Brief Description of Create New Order Use Case


USE CASE DESCRIPTIONS (continued) INTERMEDIATE DESCRIPTION

It extends the Brief Description to include the “Internal Flow of Activities” for the Use Case.

If there are multiple Scenarios for a Use Case , then each internal flow of Activities is described individually. e.g. Create Order Use case has two Scenarios ( Order ClerkCcreatesTelephone

Order , and Customer creates Web Orders)This description resembles a type of writing “Structured English” which can include Sequence , Select (Davison) and Reputation blocks. - Notice that Intimidate Description describes what the User and the System need to carry out the processing for the Scenario.- Each Step is identified with a number to make it easy to read. - Exception Conditions are also documented if they are needed.


Intermediate Description of Telephone Order Scenario for Create New Order Use Case


USE CASE DESCRIPTIONS (continued) FULLY DEDVELOPED DECRIPTION

It is the Most formal Method and preferred method for documenting a Use Case despite the fact that it takes a little more time to define the Internal Flow Of Activities for a Use case.

Creating a Fully Developed Use Case description helps Analyst to get a deep understanding of the Users’ needs. It will also increase the probability of thoroughly understand the Business Processes and the ways the System must support them.

Fully developed Use Case Description Superset of Intermediate and Brief Descriptions Consists of eleven compartments User, Actor, Stakeholder, EBP, and Conditions identified


USE CASE DESCRIPTIONS (continued) FULLY DEDVELOPED DECRIPTION

Precondition states what conditions must be true before a Use Case begins. (What the state of the System must be for the Use Case to beginPostcondition Identifies what must be true upon completion of the Use Case.

Tips for writing Use Case Descriptions:

- Keep Pre- and Post conditions fairly basic. - The Scope of a Use Case begins when the System is at a stable point and ends when it is again stable. This consideration will help you identify the Pre and Postconditions - Assume Perfect Technology such as the System is up and running, User is logged on , the Database connection is active and so forth…

24Object-Oriented Analysis and Design with the Unified ProcessFully Developed Description of Telephone Order Scenario for

Create New Order Use Case


USE CASE DESCRIPTIONS (continued) Activity Diagram is another way to Document a Use Case

Scenario.

- Since an Activity Diagram is an easily understood Diagram, Analysts use it to document the workflows of Business Processes as well as Documenting the flow of Activities for Use Case Scenarios.

An Activity Diagram can be used to support any three levels of Use Case Descriptions. It is similar to Two-column Description - (Actor and System) in the fully Developed Use Case Description.

. The Benefits of creating an Activity diagram is that it is more visual

and so can help both the User and System Developer as they work together to fully document the Use Case.

Activity Diagrams are also helpful in developing System Sequence Diagrams (SSD).

26Object-Oriented Analysis and Design with the Unified ProcessActivity Diagram of the Telephone Order Scenario


SYSTEM SEQUENCE DIAGRAM (SSD) System Sequence Diagram is a type of “Interaction Diagram”. It is used to describe

the flow of information into and out of the Automated System. SSD documents the Inputs and the Outputs and identifies the interaction between

Actors and the System.

SSD NOTATIONS The “Stick” figure represents an Actor The Box labeled as :system is an Object that represents the entire Automated

System ( As opposed to the Class Diagram notation in SSD Object notation is used. Object notation indicates that the box refers to an individual Object and not to the Class of all similar Objects.)

A Rectangle with the name of the Object identified - the colon ( : ) is optional Underneath the Actor and the :system are vertical dashed lines called “LIFELINES” A Lifeline is simply the extension of that Object, throughout the duration of the SSD. The Arrows between the Lifelines represent the Messages that are sent or received. Lifelines indicate the Sequence of the Messages sent and received by the Actor and

Object A Message is Labeled to describe both the message’s purpose and any input data

being sent A Message is a command that has a syntax (Input parameters) Output Message has shown as dashed arrow a slightly format and meaning. An

Optional note can be added to explain output Messages


Sample System Sequence Diagram


SYSTEM SEQUENCE DIAGRAM (SSD)

The same Message may be sent multiple times (i.e Repeated)

(e.g. The message “Add An Item to an Order” may be sent multiple tines )

The Repetition of a Message in a Condition Loop can be represented in two ways:

a) The Message and its return are located inside a larger Rectangle to indicate the Repeating Loop.

b) * [True/False Condition] - Asterisk (*) indicates that Message repeats as long as the True/ False condition evaluates true.

The True / False Condition is used for Control of the Loop as well as to determine as to whether a Message is sent or not.


SYSTEM SEQUENCE DIAGRAM (SSD)

THE COMPLETE NOTATION FOR A MESSAGE

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

Note: Any part of the message may be omitted

• Indicates repeat or Looping of the Message

• Brackets [ ] indicates true / false Condition.

• Message-name is the description of the requested service. It is omitted on the dashed-line return messages. Which only show the Return Data Parameter.

• Parameter-list (with parentheses on input Messages and without parenthesis on Return Messages) shows what data are passed with the Message

• Return-value on the same line as the Message requires Assignment Operator (: =) which is used to describe Data being returned from the destination Object to the source Object in response to the message.


Repeating Message (A) Detailed Notation (B) Alternate Notation


DEVELOPING A SYSTEM SEQUENCE DIAGRAM Begin with Detailed Description of the Use Case either Fully

Developed form or as with Activity Diagrams One Advantage of using Activity Diagrams is that it is easy to identify

when an Input or Output occurs. Input an Output occurs whenever an arrow in an Activity Diagram goes from an External Actor to the Computer System.

FOUR Step Process for turning Activity Diagram into SSD

[1] Identify the Input Messages

[2] Describe messages from External Actor to System

[3] Identify / apply special Conditions to Input Messages

[4] Identify and add the Output Return Messages


DEVELOPING A SYSTEM SEQUENCE DIAGRAM 1. Identify the Input Messages

At each location where the workflow crosses the Automation boundary, Input data are required therefore a Message is needed.

2. Describ Messages from External Actor to System

Name the Messages to reflect the services that the Actor is requesting of the System. (eg. startOrder, addItem etc

The other information required is the Parameter List for each Message. The important principle for identifying Data parameters is to base the List on the attributes on the Class Diagram.

Looking at the Attributes with an understanding of what the System needs to do will help you find the right Attributes.

3. Identify / Apply special Conditions to Input Messages Including Iterations and True / False conditions

4. Identify and Add the Output Return Messages


A Simplified Diagram of the Telephone Order Scenario


An SSD of Simplified Telephone Order Scenario for the Create New Order Use Case


THE STATECHART DIAGRAM Statechart Diagram describes the collection of States of each Objects.

Statechart shows the ‘Behavior’ or ‘Life of an Object’ in “States” and “Transitions”.

Status Condition is a Condition during and Object Life when it satisfy some criterion, performs some Action, or waits for an Event.

Transition is the movement of an object from one State to another State.

State of each Object are an important piece of information that an Analyst can use to help define the ‘Business Rules’ to be implemented in a Computer System.

Statechart Can be developed for any Problem Domain Classes that have Complex “Behaviors” or “Status Condition” that need to be tracked by the System.

Not all Problem Domain Classes require Statechart.

◘ A Statechart is not necessary for a Class that does not have Status Condition to Control Processing .


THE STATECHART DIAGRAM Statechart Diagram Symbols

Ovals represent “Status of Object”

Arrows represent “Transitions”

Pseudostate (Black dot) denotes start of Statechart flow


Simple Statechart for a Printer


STATECHART DIAGRAM State of an object is a Condition that occurs during its

Life when it satisfies some criterion, performs some Action or waits for an Event.

States are Semi-permanent conditions. Transitions interrupt them and cause them to end.

Transition is the movement of an Object from one State to another State. Transition is like a trigger that fires or an event that occurs.

Origin State is the original State of an Object from which a Transition occurs.

Destination State is the State to which an Object moves during a Transition.

Message Event is the Trigger for a Transition which causes an Object to leave its original State.


STATECHART DIAGRAM Transition Label consists of three components:-

transition-name (parameters) [guard-condition] / action-expression Transition-name is the name of a “Message Event” that triggers the Transition and causes the

Object to leave the Origin state.

» Message Names and Transition Names almost use the same Syntax

» Transitions are caused by Messages coming to the Object

Parameters comes directly from the Message Parameters.

Guard-condition is the qualifier or test on the Transition and it is simply a “True / False” condition that must be satisfied before Transition can fire.

» Sometimes a Transaction has only Guard-Condition and no Triggering Event; in that case the Trigger is constantly firing and whenever the Guard-Condition becomesTrue the Transition occurs.

Action-expression is a Procedural Expression that executes when the Transition fires. It describes the Action to be performed.

Any of the three components (i.e transaction-name, guard-condition, or action-expression) may be empty.

If either the Transition-name or Guard-condition is empty then it automatically evaluates to ‘True” . Either of them may be complex with AND an OR connectives.


Statechart DiagramGuidelines to help identify Object States There are two ways to identify the Valid States

Check Naming convention for Status Conditions. A State may have a name of a simple Condition such as such as

“On” or “In repair” A Complex States labeled with Gerunds or Verb phrases

◘ Example: “Being shipped” ◘ Active States usually not labeled with Nouns. (If you use a noun to

name a State‘ you have an incorrect idea about the States of Object Classes.)

– Rethink your Analysis and describe only States of being of the Object itself

Think about Status Conditions that may need to be reported to Management or Customers (e.g. “Shipped”)


Nested States And Concurrency The BVehavior of Objects in the real world is more complex than simply being

in one State at a time. The condition of an Object being in more than one State at a time is called

‘Concurrency’[ or ‘oncurrent States’

The Two ways to represent Concurrent States

1. Show Concurrency with a Synchronization Bar and Concurrent Paths. (Path is a sequential set connected States and Transitions)

2. Show Concurrency with States Nested inside other, higher-level States. (Nest low-level States inside Higher-level States)

Higher-level states also called “Composite States”

A Composite State represents a Higher Level of abstraction and can contain multiple Levels and Transitions (Nested States and Transitions.) To show Composite States we draw Lower- Level Statecharts within the Higher-

Level State.


Sample Composite States for the Printer ObjectWhen the Printer enters the “ON” State , it automatically begins at the nested black dot and moves to the “IDLE” State. So the Printer is both in the “On” State and the “Idle” State When Print Message is received the Printer makes the transition to the “Working” State but also remains in “On State.”. The Lower compartment contains “action-expression” - (Load: and Print Sheets) while printer is in Working State.


Nested States And Concurrency Object Behavior is frequently more complex than simpleNested States.

An Object may have entire set of States and Transitions (Multiple Paths – that are actively concurrent) To document Concurrent Behavior of a single Object we draw Composite State with the Lower portion divided into multiple compartments , one for each concurrent Path of Behavior.

Example: A Printer that has an Input Bin to hold paper also cycles between two States in its work cycle of “Idle” and “Working” States.

– If we describe one Path as the States of Input Paper Try and the other path as the States of the Printing mechanism (Idle and Working )

– In first Path (Input Paper try ) will have States of : “Empty”, “Full” and “ Low”.-In the Second Path will have States of “Idle” and “Working”.

These two paths are independent. The movement between States in one compartment is completely independent of movement between States in the other compartment.


Nested States And Concurrency Object Behavior is frequently more complex than simple Nested States. An Object may have entire set of States and Transitions

(Multiple Paths – that are active concurrently) To document Concurrent Behavior of a single Object we draw Composite State with the lower portion divided into multiple

compartments , one for each concurrent Path of Behavior.

Concurrent Paths for the Printer in the On State


Rules for Developing Statecharts The primary challenge in building a Statechart is to identify the

right “States” for the Object.

The other major problem is to identify and handle “Composite States” with Nested Threads. (Due to Lack of experience!)

Remember to consider “Exception Conditions” especially when you see the word “Verify” and “Check” .

Normally there will be Transitions out of States that Verify something (one for Accept and one for Reject}

The best solution is to remember that developing Statechart is an iterative behavior, more so than developing any other type of UML Diagram. (Analysts seldom get a Statechart right the first time! Thus, you should draw it and refine it again and again.


Rules for Developing Statecharts The following Rules can help to develop Statecharts for Classes in the Problem Domain

[1] Review Class Diagram and Select the Classes that will require Statecharts (Include those Classes that have various Status Conditions important to track in the System

[2] Make a List all the Status Conditions for each Object group Think the Life Cycle of an Object! How does it come into existence in the System, when and how it is modified or deleted from the System. Does it have Active / Inactive States ., Waiting States etc.

[3] Begin building Statechart fragments by identifying the “Transitions” that cause an object to leave the identified State. (e.g. If an Order is in the State of “Ready to be Shipped”, a Transition such as ‘beginShipping’ will cause the Order to leave the State.

[4] Sequence State-transition” combinations in correct Order and Aggregate these combinations into large fragments. As fragments aggregated into Larger Paths begin to look for a natural Life Cycle for the Object.

Continue to build longer Paths in the Statechart by combining the Fragments.


Rules for Developing Statecharts (continued)[5] Review the Paths and look for independent, Concurrent Paths.

The two States may be on independent Path; one can change without affecting the other. Alternatively, one State may be a Composite state, so that the two States should be Nested, one inside the other.

- One way to identify a candidate for a Composite State is to determine if it is concurrent with several other States, and the other States depend on the Origin State.

[6] Look for additional Transitions One method to identify the additional Transitions is to take every paired combination of States and ask whether there is a valid Transition between the States. Test them in both directions.

[7] appropriate Expand each Transition with Message Event, Guard Condition and Action-expression.Include with each State appropriate “Action-expression” Much of it have been done as the Statechart fragments were being built Statechart.

[8] Review and test each Statechart.

Test Statechart by “Desk-checking” and review them by doing the followings:

a) Make sure your States are really States of the Object in the Class. Ensure that the name truly describes States of being of the Object b) Follow the Object Life Cycle from its coming to existence to its being deleted from the system.. Be sure that possible combinations are covered and that the paths are accurate.c) Be sure to cover all Exception Conditions as well as the normally expected flow of Behaviors.d) Check again for Concurrent Behavior (Multiple Paths) and the possibility of Nested Paths.


DEVELOPING RMO STATECHARTS Review the Domain Class Diagram Select Classes with Status Conditions that need to be tracked Candidate Classes : Order, OrderItem, InventoryItem,

Shipment, Customer

Choose Order and OrderItem as an example

Continue Developing Statechart according to Eight rules

Identify possible Status Conditions of interest

“Ready to be shipped”

“On back order”

“Shipped”


States and Exit Transitions for Orderitem


Final Statechart for OrderitemAction-expressions are added to the transitions to indicate any special action. It is indicated by the Object or on the Object. (Place Purchase Order)


States and Exit Transitions for Order


Second-cut Statechart for Order


Developing the Order State Chart Benefits of developing a Statechart for an Object:

It helps to capture and clarifies Business Rules

It also help Analysts gain a true understanding of System Requirements


Integrating Object-Oriented Models Developing and integrating Models are critical to ensure that Analyst understands the Business Requirements.

You should note that the development of detailed Diagram s is critical to gaining a through understanding of the User Requirements.

The Primary (or source) Models are:

Use Case Diagram ◘ Use Case Descriptions◘ Activity Diagrams◘ System Sequence |Diagram

Problem Domain Class Diagram◘ System Sequence Diagram◘ Statechart Diagrams

You must make sure that the Use Case Diagram and the Domain Class Diagram is designed as completely as possible..

CRUD Analysis validates Model is performed between the Class Diagram and Use Case Diagrams to ensure that the Use Case Diagram and the Problem Domain Class Diagram are as complete as possible.

The detailed Use Case Descriptions or Activity Diagrams are internal documentation of the Use Case and must completely support the Use Case Diagrams. Internal descriptions such as Pre-and postconditions are also important for development of System Sequence Diagrams.

So the Detailed Use Case Descriptions, Activity Diagrams and System Sequence Diagrams must be all consistent with regards to the steps of a particular Use Case.


Relationships among OO Requirements Models

2Object-Oriented Analysis and Design with the Unified Process Detailed Object-Oriented Requirements...

Documents

Transcript of 2Object-Oriented Analysis and Design with the Unified Process Detailed Object-Oriented Requirements...