Lecture 2.

Introducing the UML

Chapter 2
The Unified Modeling Language User Guide
SECOND EDITION
By Grady Booch, James Rumbaugh, Ivar Jacobson
 What is UML?
• Unified Modeling Language
– OMG Standard, Object Management Group
Based on work from Booch, Rumbaugh, Jacobson
• UML is a modeling language to express and design documents,
software:
– Particularly useful for OO design
– Not a process
– Independent of implementation language
– Version 0.9 released in 1996
– Version 1.1 adopted by OMG in 1997
• Latest Version 2.5.1 (December 2017) - http://www.uml.org/
 Why use UML
• Standardized graphical notation for
– Specifying
– Visualizing
– Constructing and
– Documenting software systems
• Language can be used from general initial design to very specific
detailed design
• Increase understanding/communication of product to customers
and developers
• Support for UML in many software packages today (e.g. Rational)
 The UML is a language for Visualizing
• Some things are best modeled textually; others graphically
• One developer can write a model in the UML, and another developer, or even
another tool, can interpret that model unambiguously

The UML is a language for Specifying

• Specifying means building models that are precise, unambiguous, and complete
• In particular, the UML addresses the specification of all the important analysis,
design, and implementation decisions that must be made in developing and
deploying a software-intensive system.
 The UML is a language for Constructing
• UML is not a visual programming language, but its models can be directly connected
to a variety of programming languages
• It is possible to map from a model in the UML to a programming language such as
Java, C++, or VB, or even to tables in a RDBMS

The UML is a language for Documenting

• The UML addresses the documentation of a system’s architecture and all of its
details
• The UML also provides a language for expressing requirements and for tests
• Finally, the UML provides a language for modeling the activities of project planning
and release management
 Building blocks of the UML
• The vocabulary of the UML encompasses three kinds of
building blocks:
1. Things - abstractions that are first-class citizens in a model
• Structural things
• Behavioral things
• Grouping things
• Annotation things
2. Relationships - tie these things together
3. Diagrams - group interesting collections of things
 Structural things
• Structural things are the nouns of the UML model. These are
the mostly static parts of a model, representing elements that
are either conceptual or physical. There are eight kinds of
structural things.

Behavioral Things
• Behavioral things are the dynamic parts of UML models. These
are the verbs of a model, representing behavior over time and
space. There are three kinds of behavioral things
 Grouping Things
• Grouping things are the organizational parts of UML models. These are the boxes
into which a model can be decomposed.
• There are also variations, such as frameworks, models, and subsystems (kinds of
packages).

Annotational Things
• Annotational things are the explanatory parts of UML models. These are
the comments you may apply to describe, illuminate, and remark about
any element in a model.
 Structural thing - Class
• A class is a description of set of objects that share the same
attributes, operations, relationships, and semantics.
 Structural thing - Interface
• An interface is a collection of operations that specify a service
of a class or component. An interface therefore describes the
externally visible behavior of that element
• <<Stereotype>> - Role
 Structural thing - Collaboration
• A collaboration defines an interaction and is a society of roles
and other elements that work together to provide some
cooperative behavior that’s bigger than the sum of all the
elements
 Structural thing- Use Case
• A Use case is a description of set of sequence of actions that a
system performs that yields an observable result of value to a
particular actor.
 Structural thing- Active Class
• An active class is a class whose objects own one or more
processes or threads and therefore can initiate control activity.
An active class is just like a class except that its objects
represent elements whose behavior is concurrent with other
elements.
 Structural thing- Component
• A component is a physical and replaceable part of a system
that conforms to and provides the realization of a set of
interfaces.
 Structural thing- Artifact
• An artifact is a physical and replaceable part of a system that contains physical
information ("bits").

Structural thing- Node

• A node is a physical element that exists at run time and represents a computational
resource, generally having at least some memory and often, processing capability.
 Behavioral Thing- State Machine
• A state machine is a behavior that specifies the sequences of
states an object or an interaction goes through during its
lifetime in response to events.
 Behavioral Thing- Activity
• An activity is a behavior that specifies the sequence of steps
a computational process performs.
 Behavioral Thing- Interaction
• An interaction is a behavior that comprises a set of messages
exchanged among a set of objects within a particular context
to accomplish a specific purpose.
 Comparison among
Behavioral Things
• Comparison:
– In an interaction, the focus is on the set of objects that interact.
– In a state machine, the focus is on the life cycle of one object at
a time.
– In an activity, the focus is on the flows among steps without
regard to which object performs each step.
• A step of an activity is called an action.
 Grouping Thing- Package
• A package is a general-purpose mechanism for organizing elements into
groups. Structural things, behavioral things, and even other grouping
things can be placed in a package. Unlike components (which exists at
runtime), a package is purely conceptual (meaning that it only exists at
development time).
 Annotational Things - Note
• There is one primary kind of annotational thing, called a note. A note is
simply a symbol for rendering constraints and comments attached to an
element or a collection of elements.
 Relationships in the UML
• There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
 Relationship - Dependency
• A dependency is a semantic relationship between two things in which a change to
one (the independent thing) may effect the semantics of the other thing (the
dependent thing).

Relationship - Association
• An Association is a structural relationship that describes a set of links. A link is a
connection among objects.
 Relationship - Generalization
• A generalization is a specialization/ generalization relationship in which objects of
the specialized element (the child) are substitutable for objects of the generalized
element (the parent). In this way, the child shares the structure and behavior of the
parent.

Relationship - Realization
• A realization is a semantic relationship between classifiers, wherein one classifier
specifies a contract that another classifier guarantees to carry out.
 Diagrams in the UML
• A diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and arcs (relationships). The UML includes 14 such
diagrams.
1. Class diagram (Static Design or Process View)
2. Object diagram (Static Design or Process View)
3. Component diagram (Static Design Implementation View)
4. Composite structure diagram (Hybrid)
5. Use case diagram (Static Use Case View)
6. Sequence diagram (Dynamic Interaction View with Time Ordering)
7. Communication diagram (Dynamic Interaction View with structure)
8. State diagram (Dynamic Behavioral View of object)
9. Activity diagram (Dynamic Process View)
10. Deployment diagram (Static Deployment View)
11. Artifact diagram (Static Implementation view)
12. Package diagram (Static View)
13. Timing diagram (Dynamic view with specific time)
14. Interaction overview diagram (Hybrid)
Modeling a System's Architecture
Evolution of Software Development Methodologies
Software Development Life Cycle – Rational
Unified Process (RUP)
 Software Development Life Cycle
• Inception is the first phase of the process, when the seed idea for the development is brought up to
the point of being at least internally sufficiently well-founded to start the elaboration phase.
• Elaboration is the second phase of the process, when the product requirements and architecture are
defined. In this phase, the requirements are articulated, prioritized, and baselined. A system's
requirements may range from general vision statements to precise evaluation criteria, each
specifying particular functional or nonfunctional behavior and each providing a basis for testing.
• Construction is the third phase of the process, when the software is brought from an executable
architectural baseline to being ready to be transitioned to the user community. Here also, the
system's requirements and especially its evaluation criteria are constantly reexamined against the
business needs of the project, and resources are allocated as appropriate to actively attack risks to
the project.
• Transition is the fourth phase of the process, when the software is delivered to the user community.
Rarely does the software development process end here, for even during this phase, the system is
continuously improved, bugs are eradicated, and features that didn't make an earlier release are
added.
• An iteration is a distinct set of work tasks, with a baselined plan and evaluation criteria that results in
an executable system that can be run, tested, and evaluated.