The definition and history of creating
the UML
Lection №1
General information about the
discipline
In the autumn semester of 2012-2013 academic year:
 5 lectures;
 6 practical training;
 1 assessment lesson + test;
Rating system of knowledge assessment.
Useful links
 http://sp.susu.ru/ - chair of System
programming
 http://sp.susu.ru/staff/index.html - section
Teacher
 http://ivanovaon.susu.ru/ - Ivanova O.N.
Plan
Literature.
History of the UML.
Principles of object-oriented modeling of
software systems
Literature
1.
2.
3.
4.
5.
6.
7.
Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language:
Users Guide
Rumbaugh J., Jacobson I., Booch G. The Unified Modeling Language
Reference Manual (2nd Edition)
Quatrani T., Palistrant J, Visual Modeling with IBM Rational Sofrware
Architect and UML
Fowler M. UML Distilled: A Brief Guide to the Standard Object
Modeling Language
Arlow, Jim Neustadt UML 2 and the Unified Process: Practical ObjectOriented Analysis and Design
Jacobson I., Booch G., Rumbaugh J. The Unified Software Development
Process
Larman С. Applying UML and patterns
Booch G., Rumbaugh J., Jacobson I. The Unified
Modeling Language: Users Guide
The book contains reference material,
giving an idea of how you can use UML to
solve a variety of problems of modeling.
The book provides a detailed, step-bystep, describes the process of the
development of software systems on the
basis of this language.
Rumbaugh J., Jacobson I., Booch G. The Unified
Modeling Language Reference Manual (2nd Edition)
This book is a complete guide to language UML. It is
primarily intended for developers, system architects,
project managers, engineers-системщикам,
programmers, analysts, customers, and in General all
those who on a sort of activity has to describe, design
and build complex software systems, and also to
examine in their functioning. The book provides a
comprehensive description of concepts and designs,
UML, including their semantics, notation and purpose.
The material is organized in such a way that the book
was easy to use, despite its volume and completeness
of the content. In addition, the authors tried to further
highlight a number of points, a clear interpretation of
which is not in the standards, as well as explain the
rationale for the adoption of those or other decisions in
the course of the development of language UML.
Quatrani T., Palistrant J, Visual Modeling with IBM
Rational Sofrware Architect and UML
The book is devoted to the instrument
of Rational Software Architect and the
version of the UML 2.0. For example, a
particular system the authors are all
the way from setting the task to
implement the system, introducing the
reader and with the possibilities of the
instrument, and with the possibilities of
the new version of the UML. Along the
way, the authors offer a lot of useful
information about the software
development process, useful methods
of modeling and documentation of
design decisions.
Fowler M. UML Distilled: A Brief Guide to the
Standard Object Modeling Language
The third edition of "UML. Framework" covers
UML 2 version, which is significantly different
from all the previous ones. The main
advantage of the book is a concise and
condensed summary of the essence of UML
and features of application of this language in
the modern software development process.
The book describes all the main types of UML
diagrams, told, for what they are and what
notation are applied in their creation and
reading. This class diagrams, sequence,
objects, packages, deployment, use case,
state, activity, composite structures,
components, review the interaction,
communication and time.
Arlow, J. Neustadt UML 2 and the Unified Process:
Practical Object-Oriented Analysis and Design
The book is a practical guide to the complex process of
object-oriented analysis and design using UML 2. It shows
the place of OO analysis and design in the software
development cycle, as it determines Unified process (UP).
The book contains a lot of practical, powerful and
convenient methods of OO analysis and design, ready for
immediate use. You learn the syntax and semantics of
UML 2 and the relevant aspects of the UP. The book gives
a clear and concise overview of UML and UP from the
point of view of the NGO analyst and designer.
Each Chapter starts with a plan in the form of a chart and
ends with a brief overview, ideal for the control of
mastering of the material. The most important information
issued in the form of notes in the frame. Updated edition
contains more real-life examples and a new section
devoted to the object language limitations (OCL).
Jacobson I., Booch G., Rumbaugh J. The Unified
Software Development Process
The book describes the unified process of
creating complex software systems,
including the use of unified modeling
language UML is a standard method of
visualization, development, documentation
and transfer of artifacts of software
systems, - so and all phases of the
preparation and management of the
process.
Larman С. Applying UML and patterns
The book helps to understand the approach of
evolutionary definition of requirements and
case-law, the simulation of the subject area,
the design on the basis of duties, and also the
most important principles of object-oriented
design and multi-tiered architecture. With the
help of this book you will be able to get
acquainted also with the GoF design patterns
and GRASP, iterative methods, flexible
approach to the use of the unified process and
many other topics.
History of the UML
1975-1988: object-oriented modeling
languages, a new genre of object-oriented
programming languages and increasingly
complex applications
1989-1994: increasing of object-oriented
methods (from fewer then 10 to more than
50), “method wars”. Booch, Jacobson's
OOSE, Rumbaugh's OMT, Fusion, ShlaerMellor, and Coad-Yourdon methods.
History of the UML
1995-2003: Grady Booch (Rational
Software Corporation), Ivar Jacobson
(Objectory), and James Rumbaugh
(General Electric) began to adopt ideas
from each other's methods. UML 0.8 … 1
2004-…: UML 2.0.
Principles of object-oriented
modeling of software systems
 Aims of modeling:
 Models help us to visualize a system as it is or as
we want it to be.
 Models permit us to specify the structure or
behavior of a system.
 Models give us a template that guides us in
constructing a system.
 Models document the decisions we have made.
Principles of object-oriented
modeling of software systems
 Basic principles of modeling:
 The choice of what models to create has a profound
influence on how a problem is attacked and how a solution
is shaped.
 Every model may be expressed at different levels of
precision.
 The best models are connected to reality.
 No single model is sufficient. Every nontrivial system is
best approached through a small set of nearly independent
models.
What is UML?
 The Unified Modeling Language (UML) is a standard language
for writing software blueprints. The UML may be used to
visualize, specify, construct, and document the artifacts of a
software intensive system.
 The UML is only a language and so is just one part of a
software development method.
 Three major elements of model:
 the UML's basic building blocks,
 the rules that dictate how those building blocks may be put
together,
 some common mechanisms that apply throughout the UML.
Building Blocks of the UML
Things (entities)
Relationships
Diagrams
Entites
 Entities are the elements of models.
 All UML entities can be divided into:
 structural entities - nouns UML models, such as class, interface,
cooperation, precedent, the active class, component, unit,
 behavioral entities - verbs UML models, such as interaction, activity,
machines; grouping the essence of the package that is used for grouping
semantically related elements of the model in forming a single whole
modules;
 summary entity - note, which can be added to the model to record
specific information, very much like the sticker.
Structural entities
 Structural entities are the nouns of UML
models. These are the mostly static parts of a
model, representing elements that are either
conceptual or physical.
 Class
 Interface
 Collaboration
 Use case
Relationships in UML
Dependency
Association
Generalization
Realization
Type of relationship
UML syntax
Source – Target
Semantics
Dependency
Source element depends on
the target element and
change last may affect the
first.
Association
Description of the set of
relationships between
objects.
Aggregation
The target element is a part
of the source element.
Composition
Strict (more limited) form of
aggregation/
Type of relationship
UML syntax
Source – Target
Semantics
Inclusion
Source element contains the
target element.
Generalization
The source element is a
specialization of a more
generalized the target
element, and can replace
him.
Realization
The original item is
guaranteed to perform the
contract, a certain target
element.
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 diagram is not a model!
 The things or relationships can be deleted from
the chart, or even with all the diagrams, but still
they continue to exist in the model.
Diagrams in the UML
 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Statechart diagram
 Activity diagram
 Component diagram
 Deployment diagram
Class diagrams
 A class diagram shows a set of classes,
interfaces, and collaborations and their
relationships.
 These diagrams are the most common diagram
found in modeling object-oriented systems.
Class diagrams address the static design view of
a system. Class diagrams that include active
classes address the static process view of a
system.
Object diagram
 An object diagram shows a set of objects and
their relationships. Object diagrams represent
static snapshots of instances of the things found
in class diagrams. These diagrams address the
static design view or static process view of a
system as do class diagrams, but from the
perspective of real or prototypical cases.
Use case diagram
 A use case diagram shows a set of use cases and
actors (a special kind of class) and their
relationships. Use case diagrams address the
static use case view of a system. These
diagrams are especially important in organizing
and modeling the behaviors of a system.
Sequence and collaboration
diagrams
 Both sequence diagrams and collaboration diagrams are
kinds of interaction diagrams. An shows an interaction,
consisting of a set of objects and their relationships,
including the messages that may be dispatched among
them. Interaction diagrams address the dynamic view of a
system.
 A sequence diagram is an interaction diagram that
emphasizes the time-ordering of messages; a collaboration
diagram is an interaction diagram that emphasizes the
structural organization of the objects that send and receive
messages. Sequence diagrams and collaboration diagrams
are isomorphic, meaning that you can take one and
transform it into the other.
Statechart diagrams
 A statechart diagram shows a state machine,
consisting of states, transitions, events, and
activities. Statechart diagrams address the
dynamic view of a system. They are especially
important in modeling the behavior of an
interface, class, or collaboration and emphasize
the event-ordered behavior of an object, which
is especially useful in modeling reactive
systems.
Activity diagram
 An activity diagram is a special kind of a
statechart diagram that shows the flow from
activity to activity within a system. Activity
diagrams address the dynamic view of a system.
They are especially important in modeling the
function of a system and emphasize the flow of
control among objects.
Component diagram
 A component diagram shows the organizations
and dependencies among a set of components.
Component diagrams address the static
implementation view of a system. They are
related to class diagrams in that a component
typically maps to one or more classes,
interfaces, or collaborations.
Deployment diagram
 A deployment diagram shows the configuration
of run-time processing nodes and the
components that live on them. Deployment
diagrams address the static deployment view of
an architecture. They are related to component
diagrams in that a node typically encloses one
or more components.