Transcript 2120 Fitting the UML into Your Development Process

#2120
2120
Fitting the UML into Your
Development Process
Paul Gustavson
Grasping the visual world of UML and how
it can be used in the design of your projects.
Chief Scientist
SimVentions
#2120
The UML
• Vastly underutilized
• Reasons why people avoid it
– Something new to learn
– Too much time / effort
– Use of RAD IDEs
– Tools are too expensive
– Don’t understand the benefit / payoff
– Don’t know how to mold it into their process
#2120
Survey
• What is your role?
• What are your project goals?
• What are the hurdles you face?
Common Development Issues
3%
9%
21%
43%
24%
Ad Hoc Development
Approach
Inadequate Requirements
/ Design
Improper Scheduling /
Planning
Staffing / Communication
Woes
Funding Problems
#2120
Developer Experiences
“We never had a proper design document, which
meant that we generated a lot of code and art
that we later had to scrap. What’s worse,
because we didn’t have a detailed outline of
what we were trying to build, we had no way to
measure our progress (or lack thereof)
accurately. We only realized that we were in
trouble when it became glaringly obvious. If
we’d been about the design rigorous up front,
we would have known that we were slipping
much sooner.”
– Brian Upton,
“Postmortem: Red Storm's Rainbow Six”
Gamasutra, January 21, 2000.
#2120
What If?
Hi Tech
Innovative
Team B
Team A
Approach
Maximizing
Profit for
the Music
Design
Industry
that
N
appeals to
Y
Consumers
N
Y
Prototype
+ Future Funding
Prototype
Define -> Design -> Develop
Sponsor
#2120
Our Idea
•
Next Generation JukeBox
– Restaurants
– Satellite Radio
– Internet Radio Phones
#2120
What it takes
• Policy / Process
– Roles
– Roadmap
• Communication
• Tools, templates and techniques.
= Capability…Understanding…
Vision… Purpose!
Productivity increases when a team has purpose!
#2120
UML Process
• There is no
UML process.
• UML cannot be
used effectively
without
application to a
process.
•
•
•
•
•
Class
Sequence
Package
State
Deployment
Blueprint
Sketch
•
•
•
•
Use Cases
Class
Activity
State
Borland’s Application Lifecycle Management
#2120
UML Diagrams
Borland® Together® Edition for Visual Studio
#2120
#2120
Conceptual Model
Playlist Support
Payment Support
Playback
Mechanism
•Download Prebuilt
Playlist
•Create Playlist
•Add Songs To Playlist
•Reorder Playlist
•Delete Song from
Playlist
•Calculate Cost
•Check Song
•Display Payment Options
•Payment by Cash
–
Monitor Cash /
Coin Input
–
Return Proper
Change
–
Refund Money
•Payment by Cell Phone
–
Display Phone #
To Dial
•Payment by Credit Card
•Load Song
– Fetch Song from
Local Database
– Fetch Song from
Network
•Play/Stream Song
•Display Visualization /
Song Information
Availability
#2120
Use Cases
Used to identify a goal or ‘case of
use’ for a software program,
system (or simulation).
It includes the identification of
– Actors
• external entities that have
behavior that interacts with
the software program
system,
– Scenario
• details the sequence of
steps and events that will
be executed to accomplish
the stated goal.
#2120
Use Case Diagram
Potential Questions
– “What are these "use case"
things, really?”
– “How do I know if I am doing
them right?”
– “How do I know when I am
done?"
– “How do I link large numbers
of them?”
Use Case Diagram for Creating a Play List for our Jukebox
Go to example using Together®
#2120
Use Case Templates (1/2)
Property
Value
Title
Create Playlist
Goal
Allow the customer to create a playlist
Scope
Playlist Support
Level
Primary Task
Precondition(s)
Access to a song list database must be available
Postcondition(s)
Playlist has been created
Primary Actor 1
Song List Database
Primary Actor 2
Playlist
Primary Actor 3
Customer
Secondary Actor
None
Trigger Event
Customer Chooses to Create a Playlist
Step 1
Customer browses through song list database
Step 2
Customer selects songs to add to play list
Step 3
List of songs in playlist is displayed
Use Case Template for Creating a Play List for our Jukebox
#2120
Use Case Templates (2/2)
Property
Value
Associated Use
Case
Step 1
Customer browses through song list database
None
Exception 1.1
Timeout (Customer waited to long)
None
Exception 1.2
Customer Cancels
None
Step 2
Customer selects songs to add to play list
Add Songs to
Playlist
Step 3
List of songs in playlist is displayed
None
Variation 3.1
Customer chooses to reorder playlist
Reorder Playist
Variation 3.2
Customer chooses to delete songs from
playlist
Delete Song
from Playlist
Use Case Template Exceptions and Variations for
Creating a Play List for our Jukebox
#2120
Conceptual Model
Attributes
Related Use Case Elements
Functional and Behavioral Capabilities
Trigger Events,
Scenario Steps
Objectives / Stakeholder Requirements
Title and Goal
Entities and Objects
Actors
Logic and Algorithms
Scenario Steps
Relationships
Associated
Use Cases
Assumptions
Pre / Post condition
Limitations
Exceptions and Variations
#2120
The Class Diagram
• Classes are an
important aspect of
object-oriented
software.
#2120
UML Syntax for Classes
Symbol
Visibility
+
public
#
protected
-
private
protected internal
internal
attributes
visibility name: type = defaultValue;
operations
visibility name(parameters) : return_type-expression
Conceptual Level –
Class Diagrams (Part I)
Playlist
Playlist
Songlist Database
Song List Database
Go to example using Together®
Song
PaymentSystem
#2120
#2120
Conceptual-Level
Class Diagrams (Part II)
Conceptual Level Classes for our Jukebox
Go to example using Together®
#2120
Jukebox - Customer Activity Diagram
The Activity Diagram
Go to example using Together®
Jukebox - Customer Activity Diagram with Swim Lanes
The Activity Diagram
w/ Swim Lanes
#2120
#2120
State Diagrams
State Diagram for Creating a Jukebox Play List
Go to example using Together®
#2120
State Diagrams
State Diagram for Creating a Jukebox Play List
#2120
#2120
Specification Level Classes for our Jukebox
Specification-Level
Class Diagrams
Go to example using Together®
#2120
Class Associations
Jukebox Specification Level Classes and Associations for Building a Playlist
Go to example using Together®
#2120
Class Associations
Goto example using Together®
#2120
Object Diagram
Jukebox Song Object
Sequence Diagram for Creating a Play list
#2120
The Sequence Diagram
#2120
The Communication Diagram
(formerly known as Collaboration Diagram in 1.4)
Collaboration Diagram for the “Add Song To Play List” Scenario
Jukebox Package Diagram
#2120
Packages
#2120
Component Diagram
(example 1)
Component Diagram of Jukebox Payment Mechanism
#2120
Component Diagram
(example 2)
Jukebox Component Playback / Payment Dependency
#2120
Component Diagram
(example 3)
Jukebox Component Playback / Playlist Dependency
Jukebox Deployment Diagram
#2120
Deployment Diagram
#2120
Implementation-Level
Class Diagrams
Discussion
#2120
What If?
Hi Tech
Innovative
Team B
Team A
Approach
Maximizing
Profit for
the Music
Host
Design
Industry
that
N
appeals to
Y
Consumers
N
Y
Prototype
+ Future Funding
Prototype
Define -> Design -> Develop
Sponsor
#2120
Other Things To Do & Try
•
•
•
•
•
•
•
Dog eared rectangles
Color UML (post-it pastels)
Patterns !
OCL – Object Constraint Language
Use XMI to move between UML tools (1.4)
Version Control Class Diagrams
Take advantage of LiveSource (once you reach
Blueprint)
• Look at MDA
#2120
Conclusion /
Recommendations
• Goals best met if they are backed with a plan
• Use UML
– To produce plan <- design
– To communicate and involve all stakeholders
– To produce useful artifacts
– To reverse engineer / perform code reviews
• Map to ALM process –
– provides foundation for which UML can be applied
• Keep things Iterative and incremental
– Separate interface from Implementation
– Sketch ->Sketch Again -> Blueprint <- ITERATE
“Be prepared to break the rules of the UML at anytime if helps you
communicate better” [MF] -- but don’t break away from your process
#2120
Recommended Reading
•
Martin Fowler, “UML Distilled: Applying the
Standard Object Modeling Language (3rd
Edition)”, Addison-Wesley, 2004.
•
Joseph Schuller, SAMS Teach Yourself UML in
24 Hours (3rd Edition), SAMS, 2004.
•
Grady Booch, Ivar Jacobson, James Rumbaugh,
“The Unified Modeling Language User Guide”,
Addison-Wesley, 1999.
•
Alistair Cockburn, “Writing Effective Use Cases”,
Addison-Wesley, 2001.
#2120
Questions?
Course #2120
Fitting the UML into Your Development Process
Please fill out the speaker evaluation
You can contact me further at …
[email protected]
BLOG: www.simventions.com/gustavson
#2120
Addendum Slides
#2120
Trading Spaces
Selected FAQs
• What happens when a designer
goes over budget?
• What happens when the [Donald
doesn’t] like what you have done?
• What happens if a [project] isn't
done on time?
#2120
#2120
Overcoming the Mental Hurdles
UML simply takes too much time to learn
and use
UML will add an extra burden on the
development effort
Developers would rather code than draw
UML diagrams
Managers may fear the expense of training
Managers may fear the cost of tools
needed to support the job
#2120
Doesn’t UML take time away
from the development phase?
• Assumption made here is that the development
phase is the most important phase.
• The proper use of UML will require more time
during the design stage, but it is at the benefit of
the coding phase.
• How?
– UML helps minimize the issues that typically
crop up during development.
• As a result, there are less defects, better
communication and better direction.
#2120
What is OCL?
Object Constraint Language (OCL)
Notational language for analysis and design of software
systems.
Subset of UML
Allows software developers to write constraints and
queries over object models.
These constraints are particularly useful, as they allow a
developer to create a highly specific set of rules that
govern the aspects of an individual object.
As many software projects today require unique and
complex rules that are written specifically for business
models, OCL is becoming an integral facet of object
development.
#2120
What is OCL?
Object Constraint Language
Used to describe expressions and constraints
on object models
– expression - an indication or
specification of a value.
– constraint - a restriction on one or
more values of (part of) a model /
system.
Expressions
Constraints
–invariant – a condition that
must always be met
–precondition - a restriction
that must be true at the
moment that the operation is
going to be executed.
–postcondition - a restriction
that must be true at the
moment that the operation has
just ended its execution.
–guard - must be true before a
state transition fires.
http://www.klasse.nl/ocl/ocl-introduction.html