2120 Fitting the UML into Your Development Process

1
2120 Fitting the UML into Your Development
Process

• Paul Gustavson
• Chief Scientist
• SimVentions

Grasping the visual world of UML and howit can
be used in the design of your projects.
2
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
• Dont understand the benefit / payoff
• Dont know how to mold it into their process

myth
myth
3
Survey

• What is your role?
• What are your project goals?
• What are the hurdles you face?

4
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. Whats worse, because
  we didnt 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 wed 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.

5
What If?
Sponsor
Define -gt Design -gt Develop
You're Fired!
Future Funding

6
Our Idea
mp3

• Next Generation JukeBox
• Restaurants
• Satellite Radio
• Internet Radio Phones

7
What it takes

• Policy / Process
• Roles
• Roadmap
• Communication
• Tools, templates and techniques. 
• CapabilityUnderstanding Vision Purpose!

Productivity increases when a team has purpose!
8
UML Process
Blueprint
Corrective Actions

• There is no UML process.
• UML cannot be used effectively without
  application to a process.

Sketch
Borlands Application Lifecycle Management
9
UML Diagrams
Borland Together Edition for Visual Studio
10
(No Transcript)
11
Conceptual Model
 
12
Use Cases

• Used to identify a goal or case of use
• Includes identification of actors and a scenario.
• actors external entities that have behavior
  that interact with the system
• scenario details the sequence of steps and
  events that will be executed to accomplish goal.
• Helps
• direct development of a project
• minimize risk associated with poor requirements
  analysis

• Conceptual Model
• Diagram
• Cockburns Template

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

14
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
15
Use Case Templates (1/2)
 
 Use Case Template for Creating a Play List for
our Jukebox
16
Use Case Templates (2/2)
 
Use Case Template Exceptions and Variations for
Creating a Play List for our Jukebox
17
(No Transcript)
18
The Class Diagram

• Classes are an important aspect of
  object-oriented software. 

19
UML Syntax for Classes

• attributes
• visibility name type defaultValue
• operations
• visibility name(parameters) return_type-express
  ion

20
Conceptual Level Class Diagrams (Part I)
Go to example using Together
21
Conceptual-LevelClass Diagrams (Part II)
Conceptual Level Classes for our Jukebox  
Go to example using Together
22
The Activity Diagram
Jukebox - Customer Activity Diagram
Go to example using Together
23
The Activity Diagramw/ Swim Lanes
Jukebox - Customer Activity Diagram with Swim
Lanes
24
State Diagrams
State Diagram for Creating a Jukebox Play List
Go to example using Together
25
State Diagrams
State Diagram for Creating a Jukebox Play List
26
(No Transcript)
27
Specification-LevelClass Diagrams
Specification Level Classes for our Jukebox
Go to example using Together
28
Class Associations
Jukebox Specification Level Classes and
Associations for Building a Playlist
Go to example using Together
29
Class Associations
Goto example using Together
30
Object Diagram
Jukebox Song Object
31
The Sequence Diagram
Sequence Diagram for Creating a Play list
32
The Communication Diagram (formerly known as
Collaboration Diagram in 1.4)
Collaboration Diagram for the Add Song To Play
List Scenario
33
Packages
Jukebox Package Diagram
34
Component Diagram (example 1)
Component Diagram of Jukebox Payment Mechanism
35
Component Diagram(example 2)
Jukebox Component Playback / Payment Dependency
36
Component Diagram(example 3)
Jukebox Component Playback / Playlist Dependency
37
Deployment Diagram
Jukebox Deployment Diagram  
38
Implementation-LevelClass Diagrams

• Discussion

39
What If?
Sponsor
Define -gt Design -gt Develop
You're Fired!
Future Funding

40
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

41
Conclusion / Recommendations

• Goals best met if they are backed with a plan
• Use UML
• To produce plan lt- 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 -gtSketch Again -gt Blueprint lt- ITERATE

Be prepared to break the rules of the UML at
anytime if helps you communicate better MF --
but dont break away from your process
42
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.

43
Questions?

• Course 2120
• Fitting the UML into Your Development Process
• Please fill out the speaker evaluation
• You can contact me further at pgustavson_at_simvent
  ions.com
• BLOG www.simventions.com/gustavson

44
Addendum Slides
45
Trading Spaces

• Selected FAQs
• What happens when a designer goes over budget?
• What happens when the Donald doesnt like what
  you have done?
• What happens if a project isn't done on time?

46
(No Transcript)
47
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

48
Doesnt 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.

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

50
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
51
UML to ALM Mapping