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
• 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
• The UML is more than just a bunch of graphical symbols
• 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.
 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 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
 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.
 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.
 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 Things
• Grouping things are the organizational parts of UML models.
These are the boxes into which a model can be decomposed.
There is one primary kind of grouping thing, namely, packages.
• There are also variations, such as frameworks, models, and
subsystems (kinds of packages).
 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
• 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.
• 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.