oo development 5 - analysis

ANALYSISExamining the analysis workflow

5

2

ANALYSIS5

INTRODUCTION1METHODOLOGIES2MODELS AND UML3OBJECT CONCEPTS4

SOFTWARE DESIGN6

http://www.randyconnolly.com/Default.aspx

Our Process3

Reminder of object-oriented development process we are following in this course is that there are four phases: Inception Elaboration Construction Transition

Each phase consists of one or more iterations of the following workflows: Requirements Analysis Design Implementation Test

In this section, we are going to examine the analysis workflow principally in the context of the Elaboration phase.

Analysis Workflow4

In the requirements workflow, use case model and other artifacts (screen prototypes, glossary, etc) are used to build an initial model based on the users’ requirements.

In the analysis workflow, the requirements are analyzed in more detail, so as to begin the description of the internal structure and behavior of the proposed system.

Requirements Model

Use Case Model

Glossary Prototypes

Analysis Model

Use Case Realizations

message()

message2()

Analysis versus Design5

The boundary between analysis and design can be quite vague; they often overlap.

Rules of thumb for analysis modeling: Analysis model is always in the language of the

business Concentrate on capturing the big picture (don’t

get bogged down in details). Focus on the problem domain (business

requirements), not the solution domain (detailed design considerations). e.g., don’t worry about implementation classes such

as database access or user interface classes. Keep the model simple.

Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 101.

Analysis Model6

The aim of the analysis workflow is to produce an analysis model.

This is a logical model that is technology-independent (i.e., unconcerned with how it is to be implemented). It allows developers to focus on the

problems to be solved. Ignoring technology makes it less likely that

old ways of doing things will be carried forward into the design of the new system.

Analysis is Use Case Driven7

The use cases defined in the requirements model are the basis for the entire analysis and design workflows.

Use Case Model

Use Case Realizations

Analysis and Design Models

message()

message2()

Use Case Realizations8

Use cases are realized in subsequent analysis and design.

That is, use-case realizations describe how a use-case is performed ("realized") in terms of interacting objects in the design model (that is, in terms of how objects collaborate). Use case realizations tie together the use cases with

the classes and relationships of the domain model. That is, a use case realization specifies which classes

must be built to implement each use case. Development of use case realizations is the main

goal of analysis; refining these use case realizations is the main goal of design.

Use Caserealizations showhow classescollaborate to realizesystem functionality

PlaceOrder PlaceOrder«realize»

Source: Object-Oriented Analysis with UML (Rational Software Corporation, 2001), p. 3-18.

Use Case Realizations9

Use case realizations consists of the following elements: Analysis class diagrams

Show the analysis classes that interact to realize the use case

Interaction diagrams Show collaborations and interactions between

objects that realize the use case. Use Case refinement

New info may be discovered that requires the original use case to be updated.

Activity diagrams may be used to illustrate scenarios in the use case.

Use case realization is a process of refinement. Take a use case and then model how the

behavior specified in the use case will be realized by collaborations and interactions between instances of domain classes you have identified.

Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 200-1.

Analysis Model10

The two key artifacts are produced in analysis model: Use case realizations

These illustrate how instances of the analysis classes can interact to realize system behavior specified by a use case.

Analysis class diagram Integrates the classes discovered in the use

case realizations into a single diagram that shows methods and attributes uncovered in the realizations.

Analysis Class11

Analysis classes are classes that: Represent a clear and concise abstraction in the

problem domain. i.e., these classes represent the real-world things and

concepts related to the problem the system is being design to solve.

Should map directly onto real-world business concepts.

Should NOT be concerned with design considerations such as performance, patterns, best practices, etc.

Also referred to as domain classes.

Finding Classes12

There is no simple algorithm for finding the right analysis classes.

Yet, there are techniques which can help you discover these classes. They are: Noun/verb analysis CRC analysis

Source: Meyer, Object Oriented Software Construction (Prentice Hall, 1997), p.


Discovering Domain Classes 13

The best source for discovering these basic classes is a high-level (100-300 words) problem statement or system definition. If you don't have this system definition, then

you will have to write one, in conjunction with the client/users.

You can also use other requirements model artifacts as sources of information, in particular: the use case model the glossary of terms.

Noun/verb analysis14

You can use the grammatical inspection technique of circling/highlighting/underling all the noun and noun phrases (compound nouns or adjective+noun) in the text. This is sometimes called noun phrase

identification. You will probably find that:

noun and noun phrases become classes and attributes

verbs and verb phrases become methods and relations

possessive phrases indicate nouns should be attributes rather than classes.

Step 1. Noun Phrase Identification

15

The Portfolio Manager shall be able to roll up portfolios on several levels.

A Trader shall be able to place orders, on behalf of a portfolio, that generate one or more

trades.

A Portfolio Manager shall be able to select a pairoff method in conjunction with placing a

sell order.

The entry of a trade shall generate forecasted cashflows associated with the given trade lot.

The system shall match up actual cashflows with forecasted cashflows.

The system shall automatically generate appropriate postings to the General Ledger.

The system shall allow an Assistant Trader to modify trade data and propagate the results

accordingly.

Source: Doug Rosenberg, Use Case Driven Object Modeling with UML (Addison Wesley, 1999), p. 18

Identify the nouns and noun phrases in this example system definition.

Noun Phrase Identification16

The Portfolio Manager shall be able to roll up portfolios on several levels.

A Trader shall be able to place orders, on behalf of a portfolio, that generate one or

more trades.

A Portfolio Manager shall be able to select a pairoff method in conjunction with placing

a sell order.

The entry of a trade shall generate forecasted cashflows associated with the given trade

lot.

The system shall match up actual cashflows with forecasted cashflows.

The system shall automatically generate appropriate postings to the General Ledger.

The system shall allow an Assistant Trader to modify trade data and propagate the

results accordingly.

Source: Doug Rosenberg, Use Case Driven Object Modeling with UML (Addison Wesley, 1999), p. 18

Identify the nouns and noun phrases in this example system definition.

Step 2. Noun Phrase Consolidation

17

After identifying nouns and noun phrases, make plural terms singular eliminate duplicate terms consolidate synonyms into single term place list in alphabetic order

Noun Phrase Consolidation18

actual cashflow order sell order

Assistant Trader pairoff method system

entry portfolio trade

forecasted cashflow Portfolio Manager trade data

General Ledger posting trade lot

level results Trader

After the consolidating noun phrases

Step 3. Noun Phrase Analysis

19

Now, remove: references to the system itself or to its context nouns which appear out of the scope of the project nouns which are too vague nouns which represent actions.

Actors might be removed from our list of candidate classes, and placed instead on the use case diagrams.actual cashflow order sell order






Analyze the list

Noun Phrase Analysis20

actual cashflow order sell order






actors

actions

out of the scope of the project

too vague

Step 4. Draw Initial Analysis Class Model

21

If you can, draw an initial analysis class model showing just class names, generalizations, associations, and aggregation. At this stage, don't worry especially about multiplicity or

composition, since further analysis is often required to address questions about multiplicity and composition.

The classes in your analysis class model are sometimes referred to as entity classes.

Just as noun phrase analysis helped identify candidate classes, verb phrase analysis can help identify class relationships. The result can be a table showing each candidate

associations with your candidate classes. e.g.,

Student enrolls in CourseProfessor teaches Course

CRC Cards22

Another way of discovering your analysis classes is to use CRC (Class Responsibility Collaboration) cards.

CRC cards are often used within a team to brainstorm the allocation of responsibilities to domain classes as well as for the discovery of relationship for domain classes.

Class Name:

CollaborationsResponsibilities

Responsibilities of a class are listed in this section.

Collaborations with other classes are listed here, together with a brief description of the purpose of the collaboration.

Class name here

CRC Cards23

Class Name Client

Responsibilities Collaborations

Provide client information.

Campaign provides campaign details.

Class Name Campaign


Provide campaign information.

Provide list of adverts.Add a new advert.

Advert provides advert details.Advert constructs new object.

Class Name Advert


Provide advert details.

Construct adverts.

Provide list of campaigns.

Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 193.

Digression on UML Class & Object Notation

24

Customerm_namem_addressm_phone

Customer

m_namem_addressm_phone

getName()getPhone()

Customer Name compartmentAttribute compartment

Operation compartment

f red:Customer

m_name=Randym_address=123 Any Avem_phone=123-4567

f red:Customer

Objects

«entity»Customer

stereotype

UML Attribute Compartment25

visibility name multiplicity: type=initialValue

optionaloptional mandatory

+ public visibility- private visibility# protected visibility

-m_name-m_address-m_phone: String-m_age:int=0+Children[]#salary+numCustomers

Customer

static attribute

UML Operation Compartment

26

visibility name ( parameterName: parameterType, ...): returnType

optionaloptional mandatory optional

m_namem_addressm_phonenumCustomers

getName()getPhone(): StringsetName(name: String)setPhone(phone: String): voidgetNumCustomers(): int

Customer

Customer()Customer(name: String)

Customer

constructors

Note: at the analysis level, you should not be worried about details like constructors, parameters, data types, etc. These will show up in the design stage.

Reflexive Associations27

A reflexive association is one in which a class has an association with itself. This means that a class has links to other

objects of the same class.

Directory File

1 0..*

-subfolder 0..*

-parent 1

-m_parent[1] : Directory-m_subfolders[0..*] : Directory

Directory

Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 152.

Navigability28

Navigability refers to ability to traverse from object of one class to an object of another class.

Means messages can only be sent in the direction of the arrow.

Order Product

navigable

not navigableThus, a Product object does not contain an Order link, but an Order object does contain a collection of Product links.

*1

Order Product*1 If no arrows, then

the relationship is bidirectional.


Dependency29

A dependency is a relationship between two elements where a change in one, affects the other.

Typically used to indicate that one class uses another, but the usage is not really an association.

Dependencies generated (in class diagrams) by: An operation of class A needs a parameter of class B An operation of class A returns a value of class B An operation of class A uses an object of class B somewhere in

its implementation, but not as an attribute.

+someMethod(in value : B)+otherMethod() : B+doSomething()

A B

void doSomething() { ... B myB = new B(); // use myB in some way ...}


Scenarios30

The process of realization often begins by looking at use case scenarios.

A scenario is an instance of a use case. It is one flow through a use case It is some combination of basic and alternate

flows. "this happened, then this, then this …"

Some people even write scenarios first, then write the use cases.

Written scenarios can also be a way of documenting test behaviors for the testing phase.

Scenarios31

Ways of describing (not realizing) scenarios: using textual descriptions using activity diagrams

Activity Diagram32

Scenarios can be graphically described by using an activity diagram. These diagrams are the UML equivalent of a flow

chart. They visually capture the step-by-step flow of a

typical use case description. Are also used in business process modeling

This is a preliminary requirements step in some methodologies. It is used to help the analysts better understand how a business operates.

Not as useful for illustrating message communication between objects (we will use interaction diagrams for that).

Activity Diagrams33

This diagram shows: action states, which represent the

execution of a step within the flow of a use case.

Transitions between those action states decisions for which guard conditions are

defined forks, where flow of control is split into two

or more concurrent flows joins, where separate flows are joined.

34

Select Course

Check Schedule

Check Pre-requisites

Assign toCourse

ResolveConflicts

Update Schedule

[student added to the course]

[checks failed][checks completed]

initial state

action state

fork

join

guard expression

http://www.randyconnolly.com/Default.aspx

Exercise35

Draw the activity diagram for the following use case scenario:Use Case: Place OrderStep 1. Enter the order (includes getting info

about order and payment method from customer)

Step 2. Authorize the purchase (requires verification that the requirement funds can be obtained from customer using the specified payment method).

Step 3. Allocate the order items from the inventory.

Step 4. Ship the order.Source: Charles Richter, Designing Flexible Object-Oriented Systems with UML (Macmillan, 1999), p. 27.

Exercise36

Enter Order

Authorize Purchase Allocate Order Items Ship Order

[pending]

[declined]

[approved]

[aborted]

This activity diagram is a refinement of the use case

Enter Order

Authorize Purchase Allocate Order Items Ship Order

[pending]

[declined]

[approved]

[aborted]

Place Order

«trace»

Exercise37

Draw the activity diagram for the following use case scenario:Use Case: Cancel Order ItemStep 1. Update that order item (check to see if the

item is still pending, and if so, change its status to cancelled.

Step 2. Credit the customer's account for that item.Step 3. Release the inventory request for that item.Note: Steps two and three can happen in either

order (or concurrently).

Exercise38

Update Order Item Credit Account

Release Inventory

[pending]

Cancel OrderItem

[not pending]

Interaction Diagrams39

Interaction diagrams are a graphical representation of how objects communicate with one another in a scenario. Static diagrams such as the class diagram and the

use case diagram contain no dynamic or temporal information.

It can be quite difficult proceeding from initial static class model to designing and implementing behaviors necessary for an application. Interaction diagrams help with this task.

Interaction diagrams are a vital part of realizing a use case (along with the class diagram). They model the collaborations and interactions

between the objects that realize a use case.


Two types Collaboration diagrams

Emphasize structural relationships between objects.

Sequence diagrams Emphasize the time-ordered sequence of

messages sent between objects. Both diagrams are two different

representations of the same thing (i.e., the object interactions). Thus a collaboration diagram can be converted

to a sequence diagram, and vice-versa.


In these diagrams, focus is on communication between objects, not classes.

fredStudent fred : Student : Student

class objects

Messages42

How do objects communicate? By sending messages (i.e., invoking a method).

A message is thus a communication between two objects (or within one) what results in some activity. This activity usually involves one or more actions.

Actions are executable statements that change values of the attributes of an object or return a value.

Are calls to an object's methods or properties We will make use of two actions:

Call Return

Source: Kendall Scott, UML Explained (Addison-Wesley, 2001), p. 59-62.

UML Actions: Call and Return

43

Object1 : Customer Object2 : Order

action name()

other action call()

call action notation

return action notation

Object1 : Customer

Object2 : Order

action name()

action name()

: Customer : Order

return value

Call and Return Example44

: Order : Shipper

shipping cost

calcShippingCost()

lookupCost()

: Order : Shipper

return(15.50)

calcShippingCost("BC", 30)

lookupZone("BC")

Sequence Diagram45

A sequence diagram focuses on the time ordering of the messages.

Objects appear along the top margin, with each object having a lifeline, with an optional flow of control on the rectangle.

Sequence Diagram Example46

: Customer

clickLogin()

:Home Page :Login Page

displayLogin()

enterUserID()

:UserAccount

validateLogin()

login okay

displayLoginOkay()

lifeline

Focus of control

Collaboration Diagram47

A collaboration diagram is spatially oriented with an emphasis on the relationships between objects.

Similar to sequence diagram, except no lifeline and focus of control.

Collaboration Diagram Example

48

: Customer

:Home Page

:Login Page

1: clickLogin()

:UserAccount

2: displayLogin()

3: enterUserID()

4: validateLogin()

5: displayLoginOk()

Collaboration vs Sequence Diagrams

49

Collaboration Diagrams Shows relationships and interactions Better for visualizing all of the effects on a

given object Easier to use/draw for brainstorming

Sequence Diagrams Explicitly shows time ordering of messages Better for visualizing overall flow in real-

time systems and complex scenarios.

Analysis Class Model50

This is the final artifact of the analysis. This is a revised class diagram that includes

all the responsibilities (operations) and attributes for all classes discovered via the use case realizations. You interaction diagrams indicate via the

messages what should be the operations and attributes you need to add to your classes.

Remember that this is an iterative and incremental process. The class diagram and the interaction diagrams

will be modified repeatedly and in tandem as you work your work through the analysis.

Analysis in Context51

« » « »

« » « »

refined by

implemented by

Design Model Implementation Model

message()

message2()

realized by

message()

message2()

Analysis Model

Analysis in the big picture52

Recall that in the Unified Software Development Process, there are four phases; in each phase there is a analysis workflow.

What is produced during the analysis workflow varies from phase to phase. Nonetheless, most of the analysis will occur in

the elaboration phase.Inception Elaboration Construction Transition

1 2 3 4 5 6 7 8

Requirements

Analysis

Design

Implementation

Test

Analysis in the phases53

Inception Phase CRC sessions, noun phrase analysis to

create domain model Elaboration Phase

Use case realizations Analysis class model

Construction Phase Additional use case realizations for any

newly discovered use cases.

oo development 5 - analysis

Technology