Slide 6B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with

Slide 6B.1

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

An Introduction toObject-Oriented

Systems Analysis and Design with UML and

the Unified Process

McGraw-Hill, 2004

Stephen R. Schach

[email protected]

Slide 6B.2


CHAPTER 6 — Unit B

THE ANALYSIS WORKFLOW I

Slide 6B.3


Continued from Unit 6A

Slide 6B.4


Fifth Iteration of the Initial Class Diagram (contd)

Slide 6B.5


Dynamic Modeling

Dynamic modeling is the third step in object-oriented analysis

A statechart is constructed that reflects all the operations performed by or to the information system

The operations are determined from the scenarios

Slide 6B.6


The Concept of State

The state of an information system is a particular set of values of the attributes of that system– The state is often represented by a specific screen

Each event causes the system to move from state to state, that is, it causes a transition between states

Example: Microsoft Word– The state is the current screen– An event is to select (say) Font from the Format Menu– The Font screen is then the new state

Slide 6B.7


Initial Dynamic Model: Osbert Oglesby

Initial statechart

Slide 6B.8


Initial Dynamic Model: Osbert Oglesby (contd)

The solid circle (top left) represents the initial state

The white circle with the small black circle inside (top right) represents the final state

States other than the initial and final states are represented by rectangles with rounded corners

The arrows represent transitions from state to state– Example: The arrow from the initial state to the state

labeled Osbert Oglesby Information System Loop

Slide 6B.9



In state Osbert Oglesby Information System Loop, one of five events can occur:– Osbert can choose one of five options: buy a painting, sell

a painting, print a report, update a fashionability coefficient, or quit

These possibilities are indicated by the five events:– buy painting selected– sell painting selected– print report selected– update fashionability selected– quit selected

Slide 6B.10


Initial Dynamic Model: Osbert Oglesby

The initial main menu in the target Osbert Oglesby information system

Slide 6B.11



Suppose that Osbert clicks on Buy a painting in the menu– The event buy painting selected has now occurred– The system moves from its current state, Osbert Oglesby

Information System Loop, to the state Buying a Painting

In Buying a Painting state, Osbert can – Buy a masterpiece, masterwork, or other painting

Slide 6B.12



The Osbert Oglesby information system moves from state to state when an event occurs– In each state, Osbert performs one of the operations

supported by that state

This continues until Osbert clicks on option Quit while the system is in state Oglesby Information System Loop– At this time the information system enters the final state

(represented by the white circle containing the small black circle)

– This terminates execution of the statechart

Slide 6B.13


Dynamic Modeling (contd)

Traditionally there is a dynamic model for each class, rather than for the system as a whole, as in this case study– However, objects in information systems rarely move from

one class to another class

Accordingly, a dynamic model for the information system as a whole is appropriate

Slide 6B.14


Extracting Boundary Classes

It is usually easy to extract boundary classes– Each input screen, output screen, and printed report is

generally modeled by a boundary class

Slide 6B.15


Initial Boundary Classes: Osbert Oglesby

One screen should be adequate for all four Osbert Oglesby use cases:– Buy a Painting– Sell a Painting– Print a Report– Modify a Fashionability Coefficient

Thus there is one initial boundary class– User Interface Class

Slide 6B.16


Initial Boundary Classes: Osbert Oglesby (contd)

Consider again the first iteration of the main menu of the user-interface screen

The five commands correspond precisely to the five events in the statechart

Slide 6B.17



This is a graphical interface, which needs special software

Slide 6B.18



However, a textual interface runs on all computers

Slide 6B.19



There are three reports: – The purchases report– The sales report– The future trends report

Each of these has to be modeled by a separate boundary class because the content of each report is different

Slide 6B.20



There are thus three report boundary classes– Purchases Report Class– Sales Report Class– Future Trends Report Class

Slide 6B.21



There are therefore four boundary classes

Slide 6B.22


Extracting Control Classes

It is also usually easy to extract control classes– Each nontrivial computation is generally modeled by a

control class

Slide 6B.23


Initial Control Classes: Osbert Oglesby

In the case study there are four computations– Determining the maximum price that Osbert should offer

for a » Masterpiece» Masterwork, or » Other painting

– Determining if there is a new trend in art purchases

Slide 6B.24


Initial Control Classes: Osbert Oglesby

There are thus four initial control classes: – Compute Masterpiece Price Class– Compute Masterwork Price Class– Compute Other Painting Price Class– Compute Future Trends Class

Slide 6B.25


Initial Control Classes: Osbert Oglesby (contd)

Here are the initial control classes

Slide 6B.26


Refining the Use Cases: Osbert Oglesby

The class diagram reflects that the pricing algorithm treats the three types of paintings differently

Accordingly, use case Buy a Painting needs to be refined into three separate use cases– Buy a Masterpiece– Buy a Masterwork– Buy Other Painting

Therefore, the description of the Buy a Painting use case must be split into three separate descriptions

Slide 6B.27


The Produce a Report use case also needs to be refined– The purchases report and the sales report use simple data

extraction— the future trends report involves computation– All three reports use their own boundary classes

Refining the Use Cases: Osbert Oglesby (contd)

Slide 6B.28


For both these reasons, the Produce a Report use case must be refined into three use cases– Produce a Purchases Report– Produce a Sales Report– Produce a Future Trends Report

The description of the use case must be split into three separate descriptions

Refining the Use Cases: Osbert Oglesby (contd)

Slide 6B.29


Third Iteration of the Use-Case Diagram

Slide 6B.30


The description of class extraction is complete

We now therefore return to the Unified Process

Class Extraction (contd)

Slide 6B.31


Use-Case Realization

The process of extending and refining use cases is called use-case realization

Slide 6B.32


Use-Case Realization (contd)

The verb “realize” is used at least 3 different ways:– Understand (“Harvey slowly began to realize that he was

in the wrong classroom”);– Receive (“Ingrid will realize a profit of $45,000 on the stock

transaction”); and– Accomplish (“Janet hopes to realize her dream of starting

a computer company”)

In the phrase “realize a use case,” the word “realize” is used in this last sense– It means to accomplish (or achieve) the use case

Slide 6B.33


Use-Case Realization (contd)

The realization of a specific scenario of a use case is depicted using an interaction diagram– Either a sequence diagram or collaboration diagram

Various versions of the use case Buy a Masterpiece appear in the following slides

Slide 6B.34


Buy a Masterpiece Use Case

Use case diagram

Slide 6B.35


Buy a Masterpiece Use Case (contd)

Description of the use case

Slide 6B.36



Class diagram (classes that enter into the use case)

Slide 6B.37



The four classes that enter into this use case are: – User Interface Class

» This class models the user interface

– Compute Masterpiece Price Class» This class models the computation of the price Osbert should offer

– Masterpiece Class» The computation involves comparing the masterpiece being

considered with the masterpieces that have been previously auctioned

– Auctioned Painting Class » These masterpieces are all instances of Auctioned Painting

Class

Slide 6B.38



The Seller does not interact directly with the information system– Instead, the Seller provides data that Osbert enters into

the information system

This is indicated in the note (the rectangle with the top right-hand corner turned over)– There is a dashed line from the note to the item to which it

refers, the Seller in this case

Slide 6B.39



Scenario (one possible instance of the use case)

Slide 6B.40



A working information system uses objects, not classes– Example: A specific masterpiece is not represented by

Masterpiece Class but rather by an object, a specific instance of Masterpiece Class

Such an object is denoted by : Masterpiece Class

Slide 6B.41



A class diagram shows the classes in the use case and their relationships– It does not show the objects nor the sequence of

messages as they are sent from object to object

Something more is needed

Slide 6B.42



Collaboration diagram (of the realization of the scenario of the use case)

Slide 6B.43



The collaboration diagram shows the objects as well as the messages, numbered in the order in which they are sent in the specific scenario

The direction of the arrow shows the direction in which the information flows

Slide 6B.44


Continued in Unit 6C

Documents

Slide 6B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with