Introduction to UML

1
Introduction to UML

• Fall 2005 OOPD
• John Anthony

2
What Well Discuss

• What is UML (and a bit of history)
• Why we need UML
• Three UML usage modes
• Some Important Diagrams
• Use Case Diagrams
• Class Diagrams
• Sequence Diagrams
• State Diagrams
• Deployment Diagrams

3
What is UML

• Unified Modeling Language (UML) is a family of
  graphical (and textual) notations that describes
  different aspects of a software system.
• UML helps you specify, visualize, and document
  models of software systems, including their
  structure and design.
• An Open standard controlled by the Object
  Management Group (OMG).

http//www.omg.org/gettingstarted/what_is_uml.htm
http//www.omg.org/
4
History of UML
Pre 1988
1994
Booch (Rational) Rumbaugh (left IBM) begin to
unify under Rational Software Corporation
Rational buys Objectory and aquires Ivar Jacobson
brining the Object Oriented Software Engineering
(OOSE)
Rational releases 0.8 of the Unified Method at
OOPLSA 95
1995
1996
UML .9 and .91 released
OMG gets more involved to ensure CASE tool
interoperability. Need to keep Rational
honest!!!!
Contributors icnlude DEC, HP, i-Logix,
Intellicorp, INBM, ICON Computing, MCI
Systemhouse, Microsoft, Oracle, Rational
Software, Unisys, etc.
1997
UML 1.0 released
1997 - 2003
OMG releases UML versions 1.2, 1.2, 1.3, 1.4, 1.5
2004
OMG releases UML 2.0
5
Goals of UML

• Provide users with a ready-to-use, expressive
  visual modeling language so they can develop and
  exchange meaningful models.
• Provide extensibility and specialization
  mechanisms to extend core concepts.
• Be independent of particular programming
  languages and development processes.
• Provide a formal basis for understanding the
  modeling language.
• Encourage the growth of the OO tools market.
• Support higher-level development concepts such as
  collaborations, frameworks, patterns and
  components.
• Integrate best practices.

6
Why Do We Need UML?
/ Creates a new instance of Athlete.
_at_param name - the name of the athlete /
We need a standard notation for describing the
structure and behavior of a system.
public Athlete(String name ) if(name
null name.equals(""))
this.name this.DEFAULT_NAME
this.name name
7
UML Diagram Types
8
UML Diagram Types (cont)
9
Use Case(s)

• A technique for capturing the functional
  requirements of a system.
• They describe the interaction between the user
  (actor) and the system.
• They help to communicate the scope of a
  development project.
• An actor can be any entity that performs a role
  with a given system
• UML provides guidance on Use Case diagrams but
  not the contents of a Use Case (referred to as a
  Use Case Specification).

10
Scenario
Managers are responsible for creating teams that,
in turn, are responsible for creating various
products. The creation of the team is based on
approval from a product development advisory
committee. Products are often created by
assembling existing components in novel ways.
Each team may be composed of any number of team
members. On occasion, teams may be combined to
form larger teams. The state of a team can be
described as following formed, on hold, active,
and completed. Teams follow a process during
the discovery and creation of a product. The
major steps include Survey, Focus, Investigate,
Transition, Develop.
11
Alternative Behaviors

• What happens if the investigation phase does not
  warrant moving into the transition phase?
• What if the Advisory Committee does not approve
  the creation of a team?

12
Example Use Case Specification

• Form a Team
• Type Main Success Scenario Alternate
• Main Success Scenario
• Manager logs into the Idea Generation system.
• Manager enters a new idea into the Idea
  Generation (the system) application.
• Manager creates a business case and cost benefit
  model to justify the creation of the team.
• Manager enters the proposes team members, start
  date, and estimated completion date into the
  system.
• Manager uploads business case and cost benefit
  model into the system.
• Manager receives appointment to present the new
  idea to the advisory committee.
• Manager adds any additional details that me
  relevant to the new idea.
• Manager receives approval from the advisory
  committee.
• Manager notifies team members and holds a
  kick-off meeting.
• Extensions
• 5a. Manager does not receive approval from
  advisory committee due missing information in
  cost benefit model
• 1. Manager adds missing information to cost
  benefit model (return to MSS step 4).

13
Use Case Diagrams

• Provides a summarized graphical representation of
  a set of Use Case Specifications.
• They reveal the actor(s), the Use Cases, and the
  relationships between them.
• Two types of Use Case relationshipsltltincludegtgt
  - used when a Use Case will invoke another Use
  Case. Analogy method invocationltltextendgtgt -
  used when a Use Case may invoke another Use Case.
  Analogy hardware interrupt inheritance
  represents a specialization of the parent use
  case

14
Example Use Case Diagram
actor
use case
system boundary
15
Class Diagrams

• Provides a structural view of the classes of a
  system, their features, and the
  inter-relationships between the classes
• Probably the most popular UML diagram used to
  convey system structure

16
The Class Icon
class name
attributes
methods
updateStatus( status int) void
type
methodname
variable name
visibility
return type
17
Visibility
18
Associations

• Associations are any type of relationship
  between two classes.
• Composition when something is part of
  something else.
• Aggregation when something contains a
  collection of things that are not part of it.
• Another way to tell them apart if the part
  has the same lifespan as the whole, then its
  composition.
• At the end of the day, the most important goal is
  to model the association. Dont fret about
  Composition vs. Aggregation.

When should you model a relationship as an
attribute vs. an association?
19
Dependency

• There are other types of relationships that are
  not based on composition or aggregation.
• A dependency exists when one class depends on
  behavior of another.

For example, consider the relationship between a
team and a product.
20
Multiplicity

• The multiplicity of a property is an indication
  of how many objects may fill the property.
• 1 only one object can be associated with the
  property
• 0..1 zero or one object may be associated with
  the property
• - any number of objects may be associated with
  the property

21
Generalization

• Depicts the is a relationship.

22
Sequence Diagrams

• Shows the sequence of interactions between
  objects.
• Benefits include
• Validate and flesh out the logic and completeness
  of a particular scenario
• Explore designs by allowing you to visually step
  through the sequence of messages
• Indicates which classes may be highly coupled
  (i.e. receiving many messages)
• Depicts instantiation and length of life of an
  object.
• Major Challenge
• The level of detail is dependent on the intent of
  the diagram (more on this later).

23
Consider the Below Code Sample
From the class Manager

• public void createNewTeam()
• Team aTeam new Team(this.generateUniqueTeamID()
  )
• for(int developerCount0 developerCount lt 3
  developerCount)
• InnovationLabDeveloper developer new
  InnovationLabDeveloper()
• developer.setEmployeeID(new Double(Math.random()
  ).toString())
• aTeam.addTeamMember(developer)
• aTeam.updateStatus(Team.FORMED)
• this.sendNotification()

24
Example Sequence Diagram
25
Types of Interaction Frames
26
(simple) State Diagram
State diagrams are used to describe the behavior
of a system.  State diagrams describe all of the
possible states of an object as events occur. 
Each diagram usually represents objects of a
single class and track the different states of
its objects through the system. 
27
Activity Diagram

• Activity Diagrams support the description of
  business processes and workflows. They can also
  be used to depict a complex sequence of events
  that may not be reflective a functional
  requirement.
• A key feature of Activity diagrams is the ease
  of showing parallelism.

28
Example Activity Diagram
29
Example Activity Diagram (cont)