1. Unified Modeling Language
UML
Unified Modeling Language
Based on:UML Distilled
Martin Fowler

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

4. Development Process

5. 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.
Inception
Elaboration
Transition
Construction

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

7. 2. Elaboration Better understanding of the problem Risk management
Inception
Elaboration
Transition
Construction
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

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

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

10. Skills Risks Lack of experience and training
Apply immediately by building prototypes
Organize project discussions
Pattern community

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

12. 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)

13. Refactoring Software entropy Refactoring
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, …)

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

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

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

17. 4. Transition Things that should not be done early
Inception
Elaboration
Transition
Construction
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

19. Use Case Diagrams Example : Set Limits Update Accounts Analyze Risk
“uses”
Accounting
system
Valuation
“uses”
Price Deal
Trading Mgr
Capture
Deal
Trader
Actor
“extends”
Capture deal
Limits
Exceeded
Salesperson
Use Case

20. Class Diagram:Typical example
Multiplicity:
many-valued
Order
Customer
Multiplicity mandatory
dateReceived
Is prepaid
number:string
price: Money
Name
Address
Class * 1
Dispatch( )
Close( )
CreditRating
: string
Association
Generalization 1
Constraint
(If Order.customer.creditRating
is “poor” then Order.isPrepaid
must be true)
Corporate
Customer
Personal
Customer
Role
Name
Sales
rep.
Line
items
Employee * *
contactName
creditRating
creditLimit
CreditCard#
Order Line
Multiplicity:
optional
Quantity:int
Price:Money
IsSatisfied
Remind ( )
billForMonth
{creditRating()
==“poor”}
Product *

21. Interaction: Sequence Diagram
An Order
Entry Window
An Order
an Order Line
A Stock Item
Prepare ( )
* Prepare ( )
Object
check ( )
Message
Condition
[check=“true”]
remove ( )
Iteration
needs ToReorder ( )
Self-
Delegation
Return
New
a Reorder
Item
Object’s
lifeline
[check=“true”]
new
a Delivery
Item
Creation

22. 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
event
[All items checked &&
some items not in stock]
Activity
Delivered
[all items available]
Item received
Item received
[some items not in stock]
Waiting
transition
Delivered
Self transition
state

23. Example of Activity Diagram
Guard
Person
Find Beverage
[no coffee]
[no cola]
Synchronization bar
[found coffee]
Decision
activity
[found cola]
Put coffee in filter
Add water
Get cups
Get can of cola
Activity
Put Filter
Turn on machine
^coffeePot.TurnOn
Brew coffee
End
Light goes out
Pour coffeee
Drink beverage