UML

1
UML
UML
UML
UML
UML
2
WHAT IS UML?
The Unified Modeling Language (UML) is a modeling
language for specifying, visualizing,
constructing, and documenting the artifacts of a
system-intensive process.
3
WHAT IS UML?

• It was originally conceived by Rational Software
  Corporation and three methodologists in the
  information systems and technology industry,
  Grady Booch, James Rumbaugh, and Ivar Jacobson
  (the Three Amigos).
• Grady Boochs Booch 93 method (from Booch 91)
• James Rumbaughs Object Modeling Technique (OMT)
  -2 (from OMT-1), which was coauthored with Mike
  Blaha, Bill Premerlani, Fred Eddy, and Bill
  Lorensen
• Ivar Jacobsons Object-Oriented Software
  Engineering (OOSE) method
• Wirfs-Brock, Ward, Cunningham, Rubin, Harel,
  Gamma, Vlissides, Helm, Johnson, Meyer, Odell,
  Embley, Coleman, Coad, Yourdon, Schlaer, and
  Mellor.

4
WHAT IS UML?

• These are the commonly use modeling diagrams use
  in UML which each diagram gives a different view
  of a software system
• Use Case Diagram
• Class Diagram
• State Diagram
• Sequence Diagram
• Collaboration Diagram
• Activity Diagram
• Component Diagram
• Deployment Diagram

5
WHAT IS UML?

• The UML models which can be used to abstract the
  system include
• A use case model with all the use cases and their
  relationships to users.
• An analysis model, which has two purposes to
  refine the use cases in more detail and to make
  an initial allocation of the behavior of the
  system to a set of objects that provides the
  behavior.
• A design model that defines a) the static
  structure of the system as subsystems, classes,
  and interfaces and b) the use cases realized as
  collaborations among subsystems, classes and
  interfaces.
• An implementation model, which includes
  components (representing source code) and the
  mapping of the classes to components.
• A deployment model, which defines the physical
  nodes of computers and the mapping of the
  components to those nodes.
• A test model, which describes the test cases that
  verify the use cases.

6
WHAT IS UML?
use case model analysis model
design model mplementation model
Rent video
Rent video
Video Rental System
Video Rental System
Rent video
Video Rental System
Order new videos
Order new videos
Order new videos
Order new videos
Order new videos
Order new videos
Order new videos
Rent video
Order new videos
Rent video
Order new videos
Corporate
Corporate
Corporate
Rent video
Rent video
Rent video
Order new videos
Order new videos
Order new videos
Rent video
Rent video
Rent video
Rent video
Rent video
Rent video
Rent video
Customer
7
Why use UML?

• Because you wish to represent the user
  interaction with the system in a manner than
  communicates with users that you understand the
  system scenarios (business).

System
Video Rental System
Order new videos
Use Case
Corporate
Rent video
Return video
Actor
Customer
8
What are Use Cases?
Use Case Definition The specification of
actions, including variant sequences and error
sequences that a system, subsystem, or class can
perform by interacting with outside actors.
USE CASES describe a sequence of actions
(processes). USE CASES graphically depict
interactions between the system and external
actors. USE CASES identify high level services
(processes, routines, methods). USE CASES specify
behavior. USE CASES may have specialized use
cases as extensions of generalized use cases.
9
Use Cases - The GOOD
Good way to begin defining the system through
scenarios. Test plan can be written from the
users point of view with use cases. Begins
traceability. Has extensions such as
for extending the functionality of a use case
for using one use case within another
and for inner use cases and
for invocation of other use cases.
10
Use Cases - The BAD
Difficult to determine the correct
granularity. Difficult to determine the correct
use case. Knowledge elicitation on use cases can
cause an explosion of use cases. Often too
informal. No techniques for polymorphic
behavior.
11
Use Cases - The UGLY
No semantic soundness. While they are an integral
part of specification of a system, they have only
a small linkage to the other 8 diagrams.
Question Do these use cases aid in the
presentation of a GOOD SRS.
12
Use Cases and an SRS
BAD Correct (maybe) Complete (maybe) Unambiguous
(sometime) Understandable (not always)
GOOD Organized (yes) Modifiable (yes) Traceable
(yes) Design Independent (yes) Annotated (yes)
UGLY Precise (no) Verifiable (no,
dataflows) Consistent (granularity) Concise (no)
13
Why use UML?
2. Because you wish to define the domain
(conceptual) objects or classes of the system so
that domain rules (ex business rules) can be
encapsulated in these domain objects.
ClassName
Video Rental System
Multiplicity
Customer
1..
1..
attributes
rents
CID int name String
authenticateCustomer ()
methods
relationship
14
Class Diagrams
Type of Relationship Diagramming Technique
association generalization realization
(interface) instanceOf refines .


15
Class Diagrams - The GOOD
Good way to begin defining the system through
abstractions with attributes, business rules,
methods. Good way to document conceptual
objects. Allows depiction of relationships
between objects. Allows modeling of
inheritance. Is integrated with some other
diagrams. Has potential for soundness. Acts as a
communication tool regarding the system. Serves
as an abstraction for complex systems.
16
Class Diagrams - The BAD
Deceptive in correctness. Requires a network of
classes. Can be confused with ERD. Is RADICALLY
different in each phase. Is difficult to maintain
manually.
17
Class Diagrams - The UGLY
NOT semantically sound. Resembles semantically
sound ERD, NOT sound. Integration between use
cases and class diagrams requires yet another
diagram.
18
Why use UML?
3. Because you wish to define the use case
scenarios to show how the classes/objects
interact in the scenario.
Customer
Rental
Cassette
validateCustomer()
Classes
rentCassette(CID)
checkIfRentable(CID)
method calls
19
Sequence Diagrams - The GOOD
Good method of discussing a use case with another
developer. God way to document which classes go
with which use case. Helps to identify methods
not yet discovered and sometimes classes. Acts as
a high level specification for programmers. Helps
new OO programmers to see class interaction
problems.
20
Sequence Diagrams - The BAD
Can become very complex without adding value. Can
consume time without adding value. Automatically
generated ones help in maintenance.
21
Sequence Diagrams - The UGLY
Looks FAR more correct than is actually. Correctne
ss is always questionable. Completeness is always
questionable.
22
Sequence Diagrams and the SRS/SDS
BAD Understandable (not always) Verifiable
(somewhat)
GOOD Organized (yes) Modifiable (yes) Traceable
(yes) Design Independent (yes?) Annotated (yes)
UGLY Precise (no) Concise (no) Correct (not
sure) Unambiguous (sometime) Consistent
(somewhat) Complete (no)
23
Why use UML?
4. Because you wish to identify the states of
the variables and classes within the software
domain.
available rent
rented return
state
overdue payAR
activities
Checked
transitions
24
State Diagrams - The GOOD
Helps to identify methods Drives out scenario
definitions better. Most valuable in real-time
systems.
25
State Diagrams - The BAD/UGLY
Formal Correctness is available in State Diagrams
but UML did not include most of this formality.
26
The GOOD
UML notation provides a variety of diagrams for
different purposes, like dynamic or static system
views. UML is powerful and feature-rich. UML is
suitable for representing workflow management
systems. UML is the established (generally
accepted) notational standard in the software
community. UML can be used on a general level,
where implementation details are suppressed. UML
diagram semantics are defined clearly.
27
The GOOD
UML is graphic taking advantage of a picture is
worth 1000 words. UML enables is a use-case
driven, architecture-centric. UML is extensible.
UML is implementation independent. UML is
process independent. UML supports abstractions.
UML is scaleable. UML is widely applicable and
usable.
28
The BAD
UML is a often complicated notation. UML contains
imprecise elements. UML is overwhelmingly
complex. UML is full of added extensions to
correct problems, these are not consistent or
well known. 37 things wrong with UML
(inconsistencies, wrong modeling, ) UML notation
is perhaps too rich to be intuitive and
user-friendly.
29
The UGLY
UML is NOT semantically sound. UML diagrams are
NOT specific to a particular abstraction
(conceptual, design, implementation). UML
diagrams ARE NOT integrated.
30
Recomendations
UML should be used to AID in software
development. Use it to incrementally document
items that are unclear. Use it to develop code
in teams to define classes, use cases. Use it to
communicate with users. Use it as a
discussion/review deliverable. Dont just
require it. Dont expect to keep it up
manually. Do choose IDEs that integrate UML with
tools.
31
Tools

•  
• .
• Rational Rose. market leader, expensive, not
  aesthetically pleasing diagrams.
• Embarcadero Describe. Interoperability with Java
  , presentable diagrams,
• ILogix Rhapsody. Inexpensive, free version,
  geared toward embedded systems
• Visio inexpensive general-purpose drawing tool.
• SmartDraw cheapest but solid drawing tool
• Dia free, runs under Linux, clunky diagrams,
  metadata in XML
• Kivio beautiful diagrams
• JAVision
• VAJ
• Café
• Borland
•  
•