UML

Unified Modeling Language

Based 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 development patterns : to describe the key ideas class diagrams : what kind of abstractions were made interaction diagrams : key behaviors of the system use 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 process

software 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.

Construction Inception Elaboration 1 2 3 ... Transition

1. Inception

Can be short or can take months

vague idea of functional specifications and feasibility study e.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 analysis get a sense of the projects scope estimation of the size

In most cases a few days work.

2. Elaboration
Construction Inception Elaboration 1

Transition 2 3 ...

Better understanding of the problem

What are you actually going to build?

How are you going to build it?

What technology are you going to use?

Risk management
Requirements risks: build the right system Technological risks: experience with the used technology Skills risks: is the required staff available? Political risks

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 language activity 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 technology high risk in linking the components of a design together architectural design decisions special attention to distributed systems

Risks
What happens if a piece of technology doesnt work ? What if we cant connect two pieces of the puzzle ? What is the likelihood of something going wrong ?

Used techniques
Class diagrams, package diagrams, deployment diagrams

Skills Risks

Lack of experience and training Apply immediately by building prototypes Organize project discussions Pattern community
http://stwww.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 iterations
each iteration is a mini-project analysis, design, coding, testing and integration for each use case assigned to the iteration

testing is a continuous process

no code should be written before you know how to test it write the test immediately keep test code forever unit 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 problem patterns must make the problem clear explain why it solves the problem explain under what circumstances it solves the problem

Information about patterns

http://st-www.cs.uiuc.edu/users/patterns/patterns.html http://c2.com/ppr/index.html

4. Transition
Construction Inception Elaboration 1 2 3 ... 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

Use Case Diagrams

Example :
Set Limits Update Accounts

Analyze Risk

uses uses Valuation Accounting system

Trading Mgr

Price Deal

Capture Deal Trader Actor extends Capture deal Limits Exceeded Salesperson

Use Case

Class Diagram:Typical example

Multiplicity: Order many-valued dateReceived Is prepaid * number:string price: Money Dispatch( ) Close( ) Association Generalization Multiplicity mandatory 1 Customer Name Address Class

CreditRating : string

Constraint

1
(If Order.customer.creditRating is poor then Order.isPrepaid must be true) Employee

Role Name Line items * Order Line Quantity:int Price:Money IsSatisfied

Sales rep. 0..1

Corporate Customer

Personal Customer CreditCard#

Multiplicity: optional * 1 Product

contactName creditRating creditLimit

Remind ( ) billForMonth {creditRating()

==poor}

Interaction: Sequence Diagram

An Order Entry Window An Order an Order Line A Stock Item

Prepare ( ) * Prepare ( ) Object Message check ( ) Condition

Iteration

[check=true] remove ( )
needs ToReorder ( ) SelfDelegation Return

Objects lifeline [check=true] new

New

a Reorder Item

Creation

a Delivery Item

State Diagram Example: An Order

action start
/get first item Get next item [not all items checked] [All items checked && all items available]

Checking do/check item

Dispatching do/initiate delivery

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

event

Activity
Delivered

Item received [some items not in stock]

transition

Waiting

Delivered

Self transition

state

Example of Activity Diagram

Person Guard Find Beverage
[found coffee] [no coffee] [no cola]

Synchronization bar

Decision activity Get cups

[found cola]

Put coffee in filter

Add water

Get can of cola

Put Filter

Activity

Turn on machine
^coffeePot.TurnOn

Brew coffee
Light goes out

End

Pour coffeee

Drink beverage