UNIFIED PROCESS What is Object Oriented Analysis? The emphasis is on finding and describing real world the objects or concepts in the problem domain.

UNIFIED PROCESS

What is Object Oriented Analysis?

• The emphasis is on finding and describing real world the objects or concepts in the problem domain.

In the course registration system, some of the concepts include : student , course , enrollment…etc.

The Unified Process

• A standardized approach to analysis and design helps to ensure that all necessary tasks are understood and completed in software development.

• The course, will focus on the Unified Process developed at Rational Software by Ivar Jacobsen, Grady Boch, Jim Rumbaugh, and others.

Applying UML

• UML is just a standard diagramming notation. It is just a tool.

• Knowing UML helps you communicate with others in creating software

NB: Goal of this class:• Learning Object-Oriented Analysis and Design, not

how to draw diagrams.

Why UP?

• Think and Design with Objects• Apply UML• Use Design Patterns• Apply to Agile approaches (XP, scrum)• Incremental requirements analysis• Use cases

Phases in RUP (developed by Rational Corporation)

RUP is divided into four phases:

1. Inception

2. Elaboration

3. Construction

4. Transition

Rational Unified Process

ManagementEnvironment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter.#1

PhasesProcess Workflows

Iterations within phases

Supporting Workflows

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

Most Important Concept in UP

• The critical idea in the Rational Unified Process is

Iterative, Incremental development.

• Iterative Development is successively enlarging

and refining a system through multiple

iterations, using feedback and adaptation.

The Most Important Concept

• Each iteration will include requirements, analysis,

design, and implementation.

• Iterations are timeboxed.

• Incremental : system grows over time

Example: Building a House

• Incremental: Start with a modest house, keep adding rooms and upgrades to it.

• Iterative: On each iteration, the house is re-designed and built a new.

Each iteration involves :• Choosing small subset of requirements.• Quick design, implementation and testing• User quickly see partial system• Rapid , early feedback ( ex: usability tests from

users)• Yes , that´s exactly what I asked for ………….• I try it , what I really want is something slightely different…

• Modify and Adapt understanding of the requirements or design , then involve the user again

Ex: Course registration system !!

Iterations

Iterations

Another approach :Waterfall Model

Requirements

Design

Implementation

Test

All or most of the requirements are defined before development begins

Inception is not Requirement phasee

Chapter 3 and 4Applying UML and Patterns

-Craig Larman

ManagementEnvironment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter.#1

PhasesProcess Workflows

Do you remember this ?

Supporting Workflows

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

time

What needs to be done?

• Describe the initial common vision and business case for this project.

• Exhibiting at least one candidate architecturebased on experience gained from similar systems or in similar problem domains

• Determine if the project is feasible

• Determine if the organization should build or buy the necessary system

• Make a rough estimate of the cost and time .

• Determine if we should go ahead with the project or stop

Inception : Initial short step in the process

Example Questions in Inception

Ask questions such as:– What is the vision and business case for this project?– Feasible?– Buy and/or build?– Buy components and glue them together or from scratch?– Estimate potential risks– Rough estimate of cost: Is it $10K-100K or in the millions?– Should we proceed or stop?

If the answer is YES …..

Feasible ?

Legal feasibilityNo conflicts with legal requirements, e.g. a data processing system must comply with the local Data Protection Acts..

Schedule feasibilitySchedule feasibility is a measure of how reasonable the project timetable is. Given our technical expertise, are the project deadlines reasonable?

Cultural feasibilityImpact on the local and general culture

Resource feasibility

Use Cases• Use cases are stories of how actors use (intercat with)

the system to fulfill his goal.

• Use cases are ‘tasks’ done by the system and has observable value to the actor

• Process sale• Place Order• Loan book

Use Case

Use Case 1

Use caseis a collection of related success and failure scenarios

that describe an actor using a system to support a goal.be text documents, not diagramsUse case modeling is primarily an act of writing text, not

drawing diagrams.There is nothing object-oriented about use cases; Use cases are a key requirements input to classic

OOA/D.be functional or behavioral requirements that indicate

what the system will do.

The purpose of use cases

o Uncover and describe all tasks that need doing in a system (of both

human and system actors)

o Give a clear and consistent description of what the system should

do.

o Provide a basis for performing tests that verify the system delivers

the functionality stated.

o To analyse what functionality that need developing for the system

o The use of use cases must mean that the right functional

requirements are made of the IT system (the requirements of the

business!)

Use cases documented in two ways

• Use Case diagramso Give an overview of visible use scenarios in the systemo Describes what actors that interact with the systemo Describes any linkages between use cases

• Verbal descriptiono Describes the content of each use case o Typically uses a pre-defined template

Use Case Formats

Use case can be written in # formats :

– Brief• Terse one-paragraph summary, usually the main success scenario.• During early requirements analysis

– Casual• Informal, multiple paragraphs that cover various scenarios.• During early requirements analysis

– Fully dressed• The most elaborate. All steps and variations are written in detail

and there are supporting sections with preconditions etc. • After many use cases have been identified and written in brief

format (already in inception 10 - 20% of use cases)

Actors - stakeholders Actor: external entity interacts (behavior) with system, such as

a person (identified by role), computer system, or organization; for example, a cashier.

Three kind of Actors - StakeholdersPrimary actor has user goals fulfilled through using services.

(e.g., the cashier). Supporting actor provides a service (e.g., the automated payment

authorization service is an example). Often a computer system, but could be an organization or person (external interfaces)

(e.g. : tax calculation )Offstage actor has an interest in the behavior of the use case, but is

not primary or supporting (e.g., a government tax agency).

How to find Use cases ?

• Recommended procedure:– Choose the system boundary– Find the primary actor– Find the user goals– Define a use case for each

• How?– Ask: what are your goals? (Instead of what do you do?)

How to find Use cases ?Stakeholders Goals Use casePrimary actor

•Cashier•Xxxxx•Xxxxxx•Xxxxxxx•Xxxxxxxx•xxxxxxxxx

To be able to process saleBe able to handle return

Process SaleHandle Return

Supporting actors•Tax calculator•Yyyyyyyy

Offstage actor•Sale tax agency•Zzzzzz

Use case diagramNextGen

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

Handle ReturnsPayment

AuthorizationService

«actor»Tax Calculator

«actor»Accounting

System

alternatenotation fora computersystem actor

Process Rental

«actor»HR System

Cash In

Process Sale

«actor»Sales Activity

System

Manage Security

Analyze Activity

Actor (person)

use case

Actor (system)

What we did so far ?

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

Domain Model

Chapter 9Applying UML and Patterns

-Craig Larman

What is a Domain Model?

• Problem domain : area (scope)of application that needed

to be investigated to solve the problem

• Domain Model : Illustrates meaningful conceptual objects

in problem domain.

• So domain model are conceptual objects of the area of

application to be inestigated

Domain model representation?• A domain model is a visual representation of real world

concepts (real-situation objects ), that could be : idea, thing , event or object…..etc . Business objects - represent things that are manipulated in

the business e.g. Order.Real world objects – things that the business keeps track of

e.g. Contact , book.Events that transpire - e.g. sale, loan and payment.

• Not of software objects• Is part of business Model artifact (document)

33

Domain Model - UML Notation• Illustrated using a set of domain objects (conceptual classes)

with no operations ( no responsibility assigned yet , this will be assigned during design).

How to find these conceptual classes and attributes ?

35

Method1: Noun Phrase Identification

• Identify Nouns and Noun Phrases in textual descriptions of

the domain that could be :

– The fully dressed Use Cases

– The problem definition.

But not strictly a mechanical process. Why ?

– Words may be ambiguous ( such as : System )

– Different phrases may represent the same concepts.

• Main Success Scenario (or Basic Flow):

– 1. Customer arrives at POS checkout with goods and/or services to purchase.

– 2. Cashier starts a new sale.

– 3. Cashier enters item identifier.

– 4. System records sale line item and presents item description, price, and running total.

– Price calculated from a set of price rules.

– Cashier repeats steps 3-4 until indicates done.

– 5. System presents total with taxes calculated.

– 6. Cashier tells Customer the total, and asks for payment.

– 7. Customer pays and System handles payment.

36

• 8. System logs completed sale and sends sale and payment information to the external

accounting system (for accounting and commissions) and Inventory system (to update inventory).

• 9. System presents receipt.

• 10. Customer leaves with receipt and goods (if any).

• Extensions (or alternative Flows)

• 7a. Paying by cash:

– 1. Cashier enters the cash amount tendered.

– 2. System presents the balance due, and releases the cash drawer.

– 3. Cashier deposits cash tendered and returns balance in cash to Customer.

– 4. System records the cash payment.37

38

Method2 : By Category List (read p 140-141)

Common Candidates for classes include:

– Descriptions , Roles , Places , Transactions

– Containers , Systems , abstract nouns , Rules

– Organizations, Events, Processes, catalogs , Records , services.

How to find these associations and multiplicities?

Fig. 9.12

SaleRegister Records-current 0..11

association name multiplicity

-"reading direction arrow"-it has no meaning except to indicate direction of reading the association label-often excluded

Association:

Relationship between classes (more precisely, between instances of those

classes)indicating some meaningful and interesting connection

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossaryparameters and

return value details

starting events to design for

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

Fig 10.1 Summary from previous lectures

Fig 10.3 Relationship between SSD and Use case

Chap 11Operation Contracts

Chapter 11Applying UML and Patterns

-Craig Larman

Operation Contract

• Operation contract identifies system state changes when an operation happens.

• Define what each system operation does• An operation is a single event from the system

sequence diagram• A domain model is used to help generate an

operation contract

44

Operation Contract

• When making an operation contract, think of the state of the system before the action and the state of the system after the action.

• The conditions both before and after the action should be described in the operation contract.

• The pre and post conditions describe state, not actions.

45

Sections of an Operation Contract

• Operation: Name of the operation and parameters

• Cross References: Use cases and scenarios this operation can

occur within

• Preconditions: Noteworthy assumptions about the state of the

system or objects in the Domain Model before execution of the

operation.

• Postconditions: This is the most important section. The state of

objects in the Domain Model after completion of the operation

Postconditions: most important • Describe changes in the state of objects in the

domain model after completion of the operation

• what instances were created ?• what associations were formed/broken?• what attributes changed?

• Are not actions to be performed during the operation

Examples of Operation Contracts

From Process Sale Use Case

• Main Success Scenario (or Basic Flow):

– 1. Customer arrives at POS checkout with goods and/or services to purchase.

– 2. Cashier starts a new sale.

– 3. Cashier enters item identifier.

– 4. System records sale line item and presents item description, price, and running total.

– Price calculated from a set of price rules.

– Cashier repeats steps 3-4 until indicates done.

– 5. System presents total with taxes calculated.

– 6. Cashier tells Customer the total, and asks for payment.

– 7. Customer pays and System handles payment.

49

POS Domain Model

Register

ItemStore

Sale

CashPayment

SalesLineItem

CashierCustomer

ProductCatalog

ProductDescription

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

• Operation: makeNewSale()• Cross References:

– Use Case: Process Sale– Scenario: Process Sale

• Preconditions: none• Postconditions

– a sale instance “s” was created (instance creation)– s was associated with the Register (association formed)– attributes of s were initialized

Operation Contract for makeNewSale operation

s :Sale

saleDate = currentDate()saleTim e = currentTime()saleNum = nextSaleNum()isCom plete = false

Regis ter111 1

association was created

s:Sale was created

attributes of s:Sale were initialized

53

Logical architecture using a UML package diagram.

GRASP PATTERN

Creator

Creator principle– Problem: Who creates an A object

– Solution: Assign class B the responsibility to

create an instance of class A if one of these is

true B “contains or aggregate ” A B “records” A B “closely uses” A B “ has the Initializing data for ” A

56

Creator principleB “has the Initializing data for ” A that will be passed to A

when it is created.– Often initiation is done using a constructor with

parameters. e.g. a Payment instance, when created needs to be initialized with the Sale total.– Sale class knows Sale total. Good candidate for

creating Payment is Sale.

If more than one of the above applies, prefer a class B which aggregates or contains A.

57

Creator Pattern in Monoply

58

Problem Who should create a SalesLineItem?

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1

60

Creating a SalesLineItem

: Register : Sale

makeLineItem(quantity)

: SalesLineItemcreate(quantity)

Sale objects are given a responsibility to create SaleLineItem. The responsibility is invoked with a makeLineItem message

Creating a SalesLineItem

62

Why Catalog is reating a Book ?

:Catalog

makeBook(title)

1: create(title):Book

by Creator

Information Expert

Information Expert

Problem : What is a basic principle by which to assign responsibilities to objects?

Solution (advice ) : Assign a responsibility to the information

expert , that is the class with the information necessary to

fulfill the responsibility.

“Objects do things related to the information they have.”

Applying Expert in POS Application

• Start assigning responsibilities by clearly stating the responsibility. Who should be responsible for

knowing the grand total of a sale?

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1

Who should be responsible for knowing/getting the grand total of a sale?

68

Who responsible for knowing the grand total of a sale?

Partial interaction and class diagrams

Sale

time...

getTotal()

:Salet = getTotal

New method

• Add a Sale class to the Design Model.• Express responsibility of knowing the total of a sale

with the method named getTotal.What information do we need to know to

determine the line item subtotal?Sale knows about neighbours

(associations), SaleLineitems who is responsible for knowing its subtotal

SalesLineItem is Expert for Subtotal

Sale

time...

getTotal()

SalesLineItem

quantity

getSubtotal()New method

1 *: st = getSubtotal: Salet = getTotal lineItems[ i ] : SalesLineItem

this notation will imply we are iterating over all elements of a collection

How does the SalesLineItem find out the product price?

SaleLineItem knows about neighbours ( ProductDescription) to get the price.

ProductDescription is Expert for Price

Sale

time...

getTotal()

SalesLineItem

quantity

getSubtotal()

ProductDescription

descriptionpriceitemID

getPrice()New method

:ProductDescription

1.1: p := getPrice()

1 *: st = getSubtotal: Salet = getTotal lineItems[ i ] :SalesLineItem

“Partial” information experts collaborate to fulfill the responsibility.

72

:Library

borrowResource(callNum)

1: r := getResource(callNum): Resource:Catalog

Catalog is an information expert onfinding and returning a resource,based on a call number. It logicallycontains all of them.

by Expert

What class should be responsible forknowing a resource, given a call number?

Another Example

Low Coupling Principle

“Low Coupling” Principle

74

Problem: How to support low dependency, Low change impact, and increased reuse?

Solution: Assign responsibilities so that coupling remains low. Use this principle to evaluate alternatives.

Coupling is a measure of how strongly one class is

• connected to,

• has knowledge of, or

• relies upon other classes.

What is a coupling ?

75

Coupling between classes is dependency of one class

on another class

Common form of coupling from Class A to Class B are:

Class A has an attribute (data member or instance

variable) that refers to a Class B instance, or

Class B itself.

What is a coupling ?

76

Common form of coupling from Class A to Class B are:

Class A has a method which references an

instance of Class B, or Class B itself, by any

means. These typically include a parameter or

local variable of type Class B, or the object

returned from a message being an instance of

Class B.

What is a coupling (continued) ?

77

Common form of coupling from Class A to Class B are:

Class A is a direct or indirect subclass of Class B.

Class B is an interface, and Class A implements

that interface.

Common Forms of Coupling in OO Languages

• Type X has an attribute (data member, instance variable) that refers to type Y or an instance of Y.

• An object of type X calls on services of a type Y object.

• Type X has a method that references an instance of type Y (e.g., parameter, local variable, object returned from a method).

• Type X is a subclass of type Y.• Type X implements the interface Y.

Low Coupling - POS Case Study

• What class should be responsible for creating a Payment instance and associating it with the Sale?– Register?– Sale?

• Creator pattern suggests Register should create the Payment.– A register records a payment in the real world.

What if Register creates Payment

: Register p : Payment

:Sale

makePayment() 1: create()

2: addPayment(p)

• Register is coupled to both Sale and Payment.

What if Sale creates Payment ?

: Register :Sale

:Payment

makePayment() 1: makePayment()

1.1. create()

• Assuming that the Sale must eventually be coupled to knowledge of a Payment, having Sale create the Payment does not increase coupling.

NB : Low Coupling and Creator may suggest different solutions.

Controller Pattern

Controller Pattern

83

UI layer does not contain any business logic

Problem:How to connect UI layer to the business logic layer?

Solution:If a program receive events from external sourcesother than its graphical interface, add an event classto decouple the event source(s) from the objectsthat actually handle the events.

Controller Pattern

What first object beyond the UI layer receives and coordinates (“controls”) a system operation message?

• Solution: Assign the responsibility to a class that represents one of the following options:

Options for Control Responsibility

1. Represents the overall system or a root object. e.g., an object called System or Register Suitable when there are not too many system events or when UI cannot choose between multiple controllers.

2. A controller for each use case e.g. processSaleHandler

Controller choices ?

:RegisterenterItem(id, quantity)

:ProcessSaleHandlerenterItem(id, quantity)

• Register (POS Terminal) is a specialized device with software running on it.

• ProcessSaleHandler represents a receiver of all system events of a use case scenario.

Controllers

What should be Controller for enterItem?

Which class of object should be responsible for receiving this system event message?

It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects.

The controller is a kind of "facade" onto the domain layer from the interface layer.

actionPerformed( actionEvent )

: ???

: Cashier

:SaleJFrame

presses button

enterItem(itemID, qty)

UI Layer

Domain Layer

system operation message

Bad Design

Cashier

:SaleJFrame

actionPerformed( actionEvent )

:Sale1: makeLineItem(itemID, qty)

UI Layer

Domain Layer

It is undesirable for an interfacelayer object such as a window to get involved in deciding how to handle domain processes.

Business logic is embedded in the presentation layer, which is not useful.

SaleJFrame should not send this message.

presses button

Good Design

actionPerformed( actionEvent )

:Register

: Cashier

:SaleJFrame

presses button

1: enterItem(itemID, qty)

:Sale1.1: makeLineItem(itemID, qty)

UI Layer

Domain Layer

system operation message

controller

Controller should delegate the work that needs to be done to other objects.

Use Case Controller

• A use case controller handles system events for a single use case.– Can maintain information about the state of the

use case.– Different controller for each use case.

• Not a domain object, but artificial construct to support the system.

• Use when there are many system events.– Factors handling into separate classes.

Controller

:LibrarianborrowResource(callNum)

:BorrowResourceHandler

borrowResource(callNum)

role controller

use case controller

Controller: Benefits

92

Increased potential for reuse

Ensures that the application logic is not handled in the interface layer.

Thus, the external event raisers are independent of internal event

handlers

Plug & Play interfaces

Since the interface is not bound to the controllers, it can be replaced

or updated without much impact

Verifying the reasoning of the use case

Allows us to verify that the system operations occur in a logical

sequence. For example: makePayment() is not called before

endSale()

High Cohesion

High Cohesion

94

A class with low cohesion does too much unrelated work and are:

• Hard to comprehend• Hard to reuse.• Hard to maintain.• Delicate and constantly

affected by changeCohesion is a measure of how strongly related the responsibilities of an element (classes, subsystems) are.

High Cohesion• Problem

– How to keep complexity manageable?

• Solution – Assign a responsibility so that cohesion remains high

Reduced cohesion of Register(creator pattern)

: Register : Sale

addPayment( p )

p : Paymentcreate()makePayment()

Low cohesion:

Register is taking part of the responsibility for fulfilling “makePayment” operation and many other unrelated responsibility ( 50 system operations all received by Register).then it will become burden with tasks and become incohesive

Better solutionHigher Cohesion and Lower Coupling

: Register : Sale

makePayment()

: Paymentcreate()

makePayment()

Solution:Delegate the payment creation responsibility to “Sale” to support high cohesion

Conclusion

• Like Low Coupling, High Cohesion is a principle to keep in mind during all design decisions

• It is important to evaluate design constantly with respect to GRASP principles, regardless of the design result.

98