UML

Unified Modeling LanguageBased on:UML Distilled Martin Fowler

What is UML ?

Modeling language, not a method Mainly graphical notation used to express the design Proposed OMG standard Several techniques:

iterative developmentpatterns : to describe the key ideasclass diagrams : what kind of abstractions were

made interaction diagrams : key behaviors of the systemuse cases : communication with the domain

experts• snapshot of one aspect of your system• sum of all use cases is the external picture of your system

activity diagrams

Development Process

Development Process

Iterative and incremental development processsoftware developed and released in pieces;construction phase consists of many iterations, each of them builds

production quality software , tested and integrated, that satisfies a subset of the requirements;

each iteration contains the usual life cycle phases. Iterations could also take place in the other phases.

Inception Elaboration TransitionConstruction

1 2 3 ...

1. Inception

Can be short or can take monthsvague idea of functional specifications and feasibility studye.g.

we are going to build the next-generation customer support system for our company. We intend to use object-oriented technology to build a more flexible system that is more customer-oriented, specifically , one that will support consolidated customer bills.

Roughly work out the business case for the project.Cost/benefit analysisget a sense of the project’s scopeestimation of the size

In most cases a few days work.

2. Elaboration

Better understanding of the problemWhat are you actually going to build?

How are you going to build it?

What technology are you going to use?

Risk managementRequirements risks: build the right system

Technological risks: experience with the used technology

Skills risks: is the required staff available?

Political risks

Inception Elaboration TransitionConstruction

1 2 3 ...

Requirement Risks Tools for requirement gathering

use cases: basis of communication between sponsors and developers in planning the project

conceptual domain model: the world that the computer system is supporting (functions, vocabulary, … ), high level, no details

analysis model: only in larger projects, to explore the consequences of the external requirements

design model: realization of the information in the domain objects and the behavior in the use cases

• adds classes to actually do the work• provides a reusable architecture for future extensions

Incremental ( no waterfall approach)class diagrams: to capture the business languageactivity diagrams: describing the workflow of the business interaction diagrams

Technological Risks

Build prototypes that try out the pieces of technology you planned to use fast evolving technologyhigh risk in linking the components of a design togetherarchitectural design decisionsspecial attention to distributed systems

RisksWhat happens if a piece of technology doesn’t work ?What if we can’t connect two pieces of the puzzle ?What is the likelihood of something going wrong ?

Used techniquesClass diagrams, package diagrams, deployment diagrams

Skills Risks

Lack of experience and training

Apply immediately by building prototypes

Organize project discussions

Pattern community

http://st-www.cs.uiuc.edu/users/patterns/patterns.html

Baseline Architecture

Result of the Elaboration (±20% of total project time)

List of use cases domain model technology platform

Planning Users: level of priority for each use case Developers: consider architectural risk for each use case Developers: commitment schedule

3. Construction

Construction builds the system in a number of iterationseach iteration is a mini-projectanalysis, design, coding, testing and integration for each use

case assigned to the iteration

testing is a continuous processno code should be written before you know how to test itwrite the test immediatelykeep test code foreverunit tests (white box) and system tests(black box)

Iterations are both incremental and iterative incremental in function iterative in terms of the code base: refactoring (to avoid code

degeneration)

Refactoring

Software entropy

original structure disappears after subsequent modifications

redesign cause short-term pain for longer-term gain

Refactoring

is a term to describe redesign techniques

will not change the functionality of your program

it changes the internal structure to make it better understandable

changes are small steps (rename a method, move a field, …)

Refactoring

Refactoring is made easier by the following steps:

do not refactor and add functionality at the same time

prepare good tests before you start refactoring

keep the steps small

You should refactor when:

if it seems difficult to add new functionality

when you have difficulties in understanding the code

Documentation in Construction

1. One or two pages describing a few classes in class diagrams

2. A few interaction diagrams to show how the classes collaborate

3. Some text to pull the diagrams together

4. State diagram if a class has a complex life cycle

5. Patterns to capture the basic ideas

Patterns

Look at the result of the process They describe common ways of doing things It is much more than a model

it must include the reason why it is the way it is it is a solution to a problempatterns must make the problem clearexplain why it solves the problem explain under what circumstances it solves the problem

Information about patternshttp://st-www.cs.uiuc.edu/users/patterns/patterns.htmlhttp://c2.com/ppr/index.html

4. Transition

Things that should not be done early

e.g. optimization

During transition there is no development to add functionality

There is development to fix bugs

Inception Elaboration TransitionConstruction

1 2 3 ...

Use Case Diagrams

Trading Mgr

Trader

Accountingsystem

SalespersonCapture dealLimits

Exceeded

Capture Deal

Price Deal

Analyze Risk

Set Limits

Valuation

UpdateAccounts

Actor

Use Case

“uses”

“uses”

Example :

“extends”

Class Diagram:Typical example

Order

dateReceivedIs prepaidnumber:stringprice: Money

Dispatch( )Close( )

Customer

NameAddress

CreditRating : string

PersonalCustomer

CreditCard#

CorporateCustomer

contactNamecreditRatingcreditLimit

Remind ( )billForMonth

Order Line

Quantity:intPrice:MoneyIsSatisfied

Employee

Product

* 1

Multiplicity mandatory

Association

Generalization

Class

Constraint1

(If Order.customer.creditRatingis “poor” then Order.isPrepaidmust be true)

*Lineitems

RoleName

Multiplicity:many-valued

0..1 *

Multiplicity:optional

* 1

Salesrep.

{creditRating() ==“poor”}

Interaction: Sequence Diagram

An Order Entry Window

An Order an Order Line A Stock Item

Prepare ( )* Prepare ( )

check ( )

[check=“true”]remove ( )

needs ToReorder ( )

a ReorderItem

a DeliveryItem

New

[check=“true”]new

Object

Message

Iteration

Return

Condition

Self-Delegation

Creation

Object’slifeline

State Diagram Example: An Order

Waiting Delivered

Checking

do/checkitem

Dispatching

do/initiatedelivery

Get next item[not all items checked]

Item received[some items not in stock]

Item re

ceived

[all items availa

ble]

[All items checked &&all items available]

Delivered

start

/get first item

[All items checked &&some items not in stock]

Self transition

Activity

transition

state

event

action

Example of Activity Diagram

Find Beverage

Get can of colaGet cupsAdd waterPut coffee in filter

Put Filter

Turn on machine

Brew coffee

Pour coffeee Drink beverage

Person

[no coffee] [no cola]

[found cola]

^coffeePot.TurnOn

Light goes out

Decisionactivity

Guard

Activity

End

Synchronization bar [found coffee]