OBJECT-ORIENTED ANALYSIS

(1)

CHAPTER 13 OBJECT-ORIENTED

ANALYSIS

(2)

Overview

 The analysis workflow

 Extracting the entity classes

 The elevator problem case study

 The test workflow: Object-oriented analysis

 Extracting the boundary and control classes

 The MSG Foundation case study

(3)

Overview (contd)

 The specification document in the Unified Process

 More on actors and use cases

 CASE tools for the object-oriented analysis workflow

 Challenges of the object-oriented analysis workflow

(4)

Object-Oriented Analysis

 OOA is a semiformal analysis technique for the object-oriented paradigm

– There are over 60 equivalent techniques

– Today, the Unified Process is the only viable alternative

 During this workflow

– The classes are extracted

 Remark

– The Unified Process assumes knowledge of class extraction

(5)

13.1 The Analysis Workflow

 The analysis workflow has two aims

– Obtain a deeper understanding of the requirements

– Describe them in a way that will result in a maintainable design and implementation

 There are three types of classes:

– Entity classes

– Boundary classes – Control classes

(6)

UML Notation for These Three Class Types

 Stereotypes (extensions of UML)

Figure 13.1

(7)

13.3 Object-Oriented Analysis: The Elevator Problem Case Study

A product is to be installed to control n elevators in a building with m floors. The problem concerns the logic required to move elevators between floors according to the following constraints:

1. Each elevator has a set of m buttons, one for each floor.

These illuminate when pressed and cause the elevator to visit the corresponding floor. The illumination is canceled when the corresponding floor is visited by the elevator

2. Each floor, except the first and the top floor, has two

buttons, one to request an up-elevator, one to request a down- elevator. These buttons illuminate when pressed. The

illumination is canceled when an elevator visits the floor, then moves in the desired direction

3. If an elevator has no requests, it remains at its current floor with its doors closed

(8)

Use Cases

 For the elevator problem, there are only two possible use cases

– Press an Elevator Button, and

– Press a Floor Button

Figure 13.2

(9)

Scenarios

 A use case provides a generic description of the overall functionality

 A scenario is an instance of a use case

 Sufficient scenarios need to be studied to get a comprehensive insight into the target product being modeled

(10)

13.5 Entity Class Modeling : The Elevator Problem Case Study

 Extract classes and their attributes

– Represent them using a UML diagram

 One alternative: Deduce the classes from use cases and their scenarios

– Possible danger: Often there are many scenarios, and hence

– Too many candidate classes

 Other alternatives:

– CRC cards (if you have domain knowledge) – Noun extraction

(11)

13.5.1 Noun Extraction

 A two-stage process

 Stage 1. Concise problem definition

– Describe the software product in single paragraph – Buttons in elevators and on the floors control the

movement of ⁿ elevators in a building with ^m floors.

Buttons illuminate when pressed to request the elevator to stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed

(12)

Noun Extraction (contd)

 Stage 2. Identify the nouns

– Identify the nouns in the informal strategy

– Buttons in elevators and on the floors control the movement of n elevators in a building with m floors.

Buttons illuminate when pressed to request the elevator to stop at a specific floor; the illumination is canceled

when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed

 Use the nouns as candidate classes

(13)

Noun Extraction (contd)

 Nouns

– button, elevator, floor, movement, building, illumination, request, door – floor, building, door are outside the problem boundary — exclude

– movement, illumination, request are abstract nouns — exclude (they may become attributes)

 Candidate classes:

– Elevator Class and Button Class

 Subclasses:

– Elevator Button Class and Floor Button Class

(14)

First Iteration of Class Diagram

 Problem

– Buttons do not communicate directly with elevators

– We need an additional class: Elevator Controller Class

Figure 13.5

(15)

Second Iteration of Class Diagram

 All relationships are now 1-to-n

– This makes design and

implementation easier

Figure 13.6

(16)

Third Iteration of Class Diagram

Figure 13.10

(17)

Serious Problem with Third Iteration of Class Diagram

 Return to Figure 13.10 (third iteration of class diagram)

 Elevator Controller Class is running everything

 This is an example of a so-called “God class”

– A class that is exposed to too much information, and – has too much control

 This is a well-known antipattern

(18)

Fourth Iteration of Class Diagram

Figure 13.12

(19)

First Iteration of Statechart for Elevator Subcontroller Class

Figure 13.13

(20)

OOA: Elevator Problem (contd)

 The object-oriented analysis is now fine

 We should rather say:

– The object-oriented analysis is fine for now

 We may need to return to the object-oriented analysis workflow during the object-oriented design workflow

(21)

13.8 Extracting the Boundary and Control Classes

 Each

– Input screen,

– Output screen, and – Report

is modeled by its own boundary class

 Each nontrivial computation is modeled by a control class

(22)

13.9 The Initial Functional Model: MSG Foundation

Figure 13.15

 Recall the seventh iteration of the use-case diagram

(23)

Use Case

Manage a Mortgage

 One possible extended scenario

Figure 13.16

(24)

Use Case

Manage a Mortgage

(contd)

 A second extended scenario

Figure 13.17

(25)

Use Case

Estimate Funds Available for Week

 One possible scenario

Figure 13.18

(26)

Use Case

Produce a Report

 One possible scenario

Figure 13.19

(27)

Use Case

Produce a Report

(contd)

 Another possible scenario

Figure 13.20

(28)

13.10 The Initial Class Diagram: MSG Foundation

 The aim of entity modeling step is to extract the entity classes, determine their interrelationships, and find their attributes

 Usually, the best way to begin this step is to use the two-stage noun extraction method

(29)

Noun Extraction: MSG Foundation

 Stage 1: Describe the information system in a single paragraph

– Weekly reports are to be printed showing how much money is available for mortgages. In addition, lists of investments and mortgages must be printed on

demand.

(30)

Noun Extraction: MSG Foundation (contd)

 Stage 2: Identify the nouns in this paragraph

– Weekly reports are to be printed showing how much money is available for mortgages. In addition, lists of investments and mortgages must be printed on

demand.

 The nouns are report, money, mortgage, list, and

investment

(31)

Noun Extraction: MSG Foundation (contd)

 Nouns report and list are not long lived, so they are unlikely to be entity classes (^report will surely turn out to be a boundary class)

 money is an abstract noun

 This leaves two candidate entity classes

– Mortgage Class and Investment Class

(32)

First Iteration of the Initial Class Diagram

Figure 13.21

(33)

Second Iteration of the Initial Class Diagram

 Operations performed on the two entity classes are likely to be very similar

– Insertions, deletions, and modifications

– All members of both entity classes have to be printed on demand

 Mortgage Class and Investment Class should be subclasses of a superclass called Asset Class

(34)

Second Iteration of Initial Class Diagram (contd)

Figure 13.22

(35)

Back to the Requirements Workflow

 The current five use cases include Manage a Mortgage

and Manage an Investment

 These two can now be combined into a single use case, Manage an Asset

(36)

Eighth Iteration of the Use-Case Diagram

 The new use case is shaded

Figure 13.23

(37)

Initial Class Diagram: MSG Foundation (contd)

 Finally, we add the attributes of each class to the class diagram

– For the MSG Foundation case study, the result is shown on the next slide

 The empty rectangle at the bottom of each box will later be filled with the operations of that class

(38)

Second Iteration of Initial Class Diagram (contd)

Figure 13.24

(39)

Iteration and Incrementation

 The phrase “iterate and increment” also includes the possibility of having to decrement what has been developed to date

– A mistake may have been made, and backtracking is needed

– As a consequence of reorganizing the UML models, one or more artifacts may have become superfluous

(40)

13.11 The Initial Dynamic Model: MSG Foundation

 Dynamic modeling is the third step in extracting the entity classes

 A statechart is constructed that reflects all the

operations performed by or to the software product

 The operations are determined from the scenarios

(41)

Initial Dynamic Model: MSG Foundation (contd)

Figure 13.25

(42)

Initial Dynamic Model: MSG Foundation (contd)

 The statechart reflects the operations of the complete MSG Foundation information system

– The solid circle on the top left represents the initial state, the starting point of the statechart

– The white circle containing the small black circle on the top right represents the final state

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

– The arrows represent possible transitions from state to state

(43)

Initial Dynamic Model: MSG Foundation (contd)

 In state MSG Foundation Information System Loop, one of five events can occur

 An MSG staff member can issue one of five commands:

– estimate funds for the week – manage an asset

– update estimated annual operating expenses – produce a report, or

– quit

(44)

Initial Dynamic Model: MSG Foundation (contd)

 These possibilities are indicated by the five events

– estimate funds for the week selected – manage an asset selected

– update estimated annual operating expenses selected – produce a report selected, and

– quit selected

 An event causes a transition between states

(45)

Initial Dynamic Model: MSG Foundation (contd)

 An MSG staff member selects an option by clicking on the menu

 This graphical user interface (GUI) requires special software

Figure 13.26

(46)

Initial Dynamic Model: MSG Foundation (contd)

 Equivalent textual user interface that can run on any computer

Figure 13.27

(47)

Third Iteration of the Initial Class Diagram: MSG Foundation

 MSG

Application Class has other

attributes as well

– Attributes that do not appertain to the assets

Figure 13.28

(48)

Third Iteration of the Initial Class Diagram: MSG Foundation

Figure 13.29

 The class diagram redrawn to show the prototypes

(49)

13.15 Use-Case Realization: The MSG Foundation Case Study

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

(50)

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

(51)

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

 Consider use case Estimate Funds Available for Week

 We have previously seen

– The use case

– The description of the use case

(52)

13.15.1 Estimate Funds Available for Week Use Case

 Use-case diagram

Figure 13.32

(53)

Estimate Funds Available for Week Use Case (contd)

 Description of use case

Figure 13.33

(54)

 Class diagram (classes that enter into the use case)

Figure 13.34

(55)

 The six classes that enter into this use case are:

– User Interface Class

» This class models the user interface

– Estimate Funds for Week Class

» This control class models the computation of the estimate of the funds that are available to fund mortgages during that week

– Mortgage Class

» This class models the estimated grants and payments for the week

(56)

– Investment Class

» This class models the estimated return on investments for the week

– MSG Application Class

» This class models the estimated return on investments for the week

– Estimated Funds Report Class

» This class models the printing of the report

(57)

 Scenario (one possible instance of the use case)

Figure 13.35

(58)

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

Figure 13.36

(59)

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

(60)

 No client will approve the specification document without understanding it

 Accordingly, a written description of the

collaboration diagram is needed, the flow of events

(61)

 The flow of events of the collaboration diagram of the realization of the scenario of the use case

Figure 13.37

(62)

 Sequence diagram

equivalent to the collaboration

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

Figure 13.38

(63)

Interaction Diagrams

 The strength of a sequence diagram is that it shows the flow of messages and their order unambiguously

– When transfer of information is the focus of attention, a sequence diagram is superior to a collaboration diagram

 A collaboration diagram is similar to a class diagram

– When the developers are concentrating on the classes, a collaboration diagram is more useful than the

equivalent sequence diagram

(64)

13.16 Incrementing the Class Diagram: The MSG Foundation

 In the course of realizing the various use cases

– Interrelationships between classes become apparent

 Accordingly, we now combine the realization class diagrams

(65)

Combining the Realization Class Diagrams

Figure 13.62

(66)

Fourth Iteration of the Class Diagram

 Fifth iteration + realization class diagram

Figure 13.63

(67)

13.18 The Specification Document in the Unified Process

 The Unified Process is use-case driven

– The use cases and the artifacts derived from them replace the traditional textual specification document

 The client must be shown each use case and associated artifacts, both diagrammatic and textual

– These UML diagrams convey to the client more information more accurately than the traditional specification document

– The set of UML diagrams can also play the same

contractual role as the traditional specification document

(68)

13.20 CASE Tools for the Object-Oriented Analysis Workflow

 Diagrams play a major role in object-oriented analysis

 Diagrams often change

– We need a diagramming tool – Many tools go further

 All modern tools support UML

– Commercial examples

» IBM Rational Rose

» Together

– Open-source example

» ArgoUML

(69)

13.21 Challenges of the Object-Oriented Analysis Workflow

 Do not cross the boundary into object-oriented design

 Do not allocate methods to classes yet

– Reallocating methods to classes during stepwise refinement is wasted effort

(70)

13.22 Metrics for the Object-Oriented Analysis Workflow

 As with the other core workflows

– It is essential to measure the five fundamental metrics:

size, cost, duration, effort, and quality

– It is essential to keep accurate fault statistics

 A measure of size of the object-oriented analysis

– Number of pages of UML diagrams