SEA Side

Software Engineering Annotations

• Annotation 3:
UML
• One hour presentation to inform you of new
techniques and practices in software

 
development.
              • Professor Sara Stoecklin
• Director of Software Engineering- Panama City
• Florida State University – Computer Science
• [email protected]
• [email protected]
• 850-522-2091
• 850-522-2023 Ex 182
 L UM
UM L

LUML M L
UM
U
The Unified Modeling Language (UML)
is a modeling language for specifying,
visualizing, constructing, and
documenting the artifacts of a system-
intensive process.
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 Booch’s Booch ’93 method (from Booch ’91)
•James Rumbaugh’s Object Modeling Technique (OMT) -2 (from OMT-1),
which was coauthored with Mike Blaha, Bill Premerlani, Fred Eddy, and
Bill Lorensen
•Ivar Jacobson’s 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.
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
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.
use case model analysis model design model mplementation model
Rent video Rent video
Video Rental System Video Rental System Video Rental System Video Rental System Rent video
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
Corpo Order new videos Corpo Corpo
Corpo
rate rate rate rate
Rent video Rent video Rent video Rent video
Rent video Rent videoOrder new videos Rent videoOrder new videos Rent videoOrder new videos

Rent video Rent video

Rent video Rent video
Cus
Custo Cer
mer (I
)D

CustoCus Cus
mer Cer Cus Cer Cus
Cus (I Cer (I Cer Cus
Cus Cus Cer Cus )D (ICus )DCus (I Cer
Cus Cer Cus Cer Cus (I Cer Cer
)D Cus Cer )D (I
Cer (I Cer Cus (I Cer )D (I Cus (I Cer (I )D
Cus (I )D Cus (I Cer )D (I )D Cer Cus )D (I )D
Cer )D Cus Cer Cus )D (ICus )D (I Cer )D Cus
(I Cer (I Cer Cer
)D Cus )DCus (I Cus Cer Cus
)D Cus (I )D (I Cus (I Cer Cer )DCus Cer Cus (I CusCer
Cer )D )D Cer Cus )D (I Cus (I Cer (I Cer )D Cer I( Cus
(I (I Cer )D Cer )D (I )D (I Cus (I )D Cer
)D Cus )D (I Cus (I Cus )D )D Cer )D (I
Cer )D Cer Cus )D Cer Cus (I )D
(I (I Cer (I CusCer )D
)D )D (I )D er
C (I Cus
)D Cus (I )D Cer
Cer )D (I
(I )D
)D
 Why use UML?
1. 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

Customer Actor
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.
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:
<<extends>> for extending the functionality of a use case
<<uses>> for using one use case within another and
<<includes>> for inner use cases and
<<calls>> for invocation of other use cases.
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.
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.
GOOD BAD UGLY
Organized (yes) Correct (maybe) Precise (no)
Modifiable (yes) Complete (maybe) Verifiable (no, dataflows)
Traceable (yes) Unambiguous (sometime) Consistent (granularity)
Design Independent (yes) Understandable (not always) Concise (no)
Annotated (yes)
 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 Cassette
1..* 1..*
CID: int
name: String
rents cassetteID: int
cassetteVolumeNo: int
attributes
authenticateCustomer () rentMovie()

relationship methods
Type of Relationship Diagramming Technique
association
generalization
realization (interface)
instanceOf <<instanceOf>>

<<refines>>
refines
…….
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.
Deceptive in correctness.
Requires a network of classes.
Can be confused with ERD.
Is RADICALLY different in each phase.
Is difficult to maintain manually.
NOT semantically sound.
Resembles semantically sound ERD, NOT sound.
Integration between use cases and class diagrams requires
yet another diagram.
 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()
rentCassette(CID)
checkIfRentable(CID)
Classes

method calls
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.
Can become very complex without adding value.
Can consume time without adding value.
Automatically generated ones help in maintenance.
Looks FAR more correct than is actually.
Correctness is always questionable.
Completeness is always questionable.
GOOD BAD UGLY
Organized (yes) Understandable (not always) Precise (no)
Modifiable (yes) Verifiable (somewhat) Concise (no)
Traceable (yes) Correct (not sure)
Design Independent (yes?) Unambiguous (sometime)
Annotated (yes) Consistent (somewhat)
Complete (no)
 Why use UML?
4. Because you wish to identify the states of the variables and
classes within the software domain.
available
rent

rented
state return

overdue
activities payAR

Checked
transitions
Helps to identify methods
Drives out scenario definitions better.
Most valuable in real-time systems.
Formal Correctness is available in State Diagrams but
UML did not include most of this formality.
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.
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.
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.
UML is NOT semantically sound.
UML diagrams are NOT specific to a particular abstraction
(conceptual, design, implementation).
UML diagrams ARE NOT integrated.
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.
Don’t just require it.
Don’t expect to keep it up manually.
Do choose IDEs that integrate UML with tools.
 
1..

a.Rational Rose. market leader, expensive, not aesthetically pleasing diagrams.

b.Embarcadero Describe. Interoperability with Java , presentable diagrams, $$
c.ILogix Rhapsody. Inexpensive, free version, geared toward embedded systems
d.Visio inexpensive general-purpose drawing tool.
e.SmartDraw cheapest but solid drawing tool
f.Dia free, runs under Linux, clunky diagrams, metadata in XML
g.Kivio beautiful diagrams
h.JAVision
i.VAJ
j.Café
k.Borland