Transcript UML - Vrije Universiteit Brussel

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
Transition
1
2
3
...
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 project’s scope
estimation of the size
In most cases a few days work.
2. Elaboration
Construction
Inception
Elaboration
Transition
1
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 doesn’t work ?
What if we can’t 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
Transition
1
2
3
...
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 :
Update
Accounts
Set Limits
Analyze
Risk
“uses”
“uses”
Trading Mgr
Valuation
Accounting
system
Price Deal
Capture
Deal
Trader
Actor
“extends”
Use Case
Capture deal
Limits
Exceeded
Salesperson
Class Diagram:Typical example
Order
dateReceived
Is prepaid
number:string
price: Money
Multiplicity:
many-valued
1
*
Dispatch( )
Close( )
Constraint
Multiplicity mandatory
Customer
Name
Address
Class
CreditRating
: string
Association
Generalization
1
(If Order.customer.creditRating
is “poor” then Order.isPrepaid
must be true)
Role
Name Line
items *
Order Line
Quantity:int
Price:Money
IsSatisfied
Employee
Sales
rep.
0..1
Multiplicity:
optional
*
1
Product
Corporate
Customer
*
contactName
creditRating
creditLimit
Personal
Customer
CreditCard#
Remind ( )
billForMonth {creditRating()
==“poor”}
Interaction: Sequence Diagram
An Order
Entry Window
An Order
an Order Line
A Stock Item
Prepare ( )
* Prepare ( )
Object
check ( )
Message
Condition
Iteration
[check=“true”]
remove ( )
needs ToReorder ( )
SelfDelegation
Return
New
Object’s
lifeline
a Reorder
Item
[check=“true”]
new
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/initiate
delivery
do/check
item
[All items checked &&
some items not in stock]
event
Activity
Delivered
Item received
[some items not in stock]
transition
Waiting
Self transition
Dispatching
Delivered
state
Example of Activity Diagram
Person
Guard
Find Beverage
Synchronization bar
Put coffee in filter
Decision
activity
[found coffee]
Add water
[no cola]
[no coffee]
Get cups
[found cola]
Get can of cola
Activity
Put Filter
Turn on machine
^coffeePot.TurnOn
Brew coffee
End
Light goes out
Pour coffeee
Drink beverage