LECTURE NOTES

What is the UML?

• ―The Unified Modeling Language is a family of graphical notations, backed by a single meta-
model, that help in describing and designing software systems, particularly software systems built
using the object-oriented style.‖
• UML first appeared in 1997
• UML is standardized. Its content is controlled by the Object Management Group (OMG), a
consortium of companies.

• Unified
– UML combined the best from object-oriented software modeling methodologies that
were in existence during the early 1990‘s.
– Grady Booch, James Rumbaugh, and Ivor Jacobson are the primary contributors to UML.
• Modeling
– Used to present a simplified view of reality in order to facilitate the design and
implementation of object-oriented software systems.
– All creative disciplines use some form of modeling as part of the creative process.
– UML is a language for documenting design
– Provides a record of what has been built.
– Useful for bringing new programmers up to speed.

• Language
– UML is primarily a graphical language that follows a precise syntax.
– UML 2 is the most recent version
– UML is standardized. Its content is controlled by the Object Management Group (OMG),
a consortium of companies.

Why We Model

 The importance of modeling

 Four principles of modeling
 Object-oriented modeling

The Importance of Modeling

• A successful software organization is one that consistently deploys quality software that meets
the needs of its users.
• An organization that can develop such software in a timely and predictable fashion, with an
efficient and effective use of resources, both human and material, is one that has a sustainable
business

What, then, is a model? Simply put,

• A model is a simplification of reality.

1
 • A model provides the blueprints of a system.
• A good model includes those elements that have broad effect and omits those minor elements that
are not relevant to the given level of abstraction.

Why do we model? There is one fundamental reason.

We build models so that we can better understand the system we are developing.

Through modeling, we achieve four aims

1. Models help us to visualize a system as it is or as we want it to be.

2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.

Modeling is not just for big systems. Even the software equivalent of a dog house can benefit from
some modeling.
We build models of complex systems because we cannot comprehend such a system in its entirety.

Principles of Modeling

Four principles of modeling:

1. The choice of what models to create has a profound influence on how a problem is attacked and
how a solution is shaped.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.
4. No single model is sufficient. Every nontrivial system is best approached through a small set of
nearly independent models.

Object Oriented Modeling

Two Approaches:

• Traditional Approach
• Objected-Oriented Approach
• TRADITIONAL APPROACH
• Collection of programs or functions.
• A system that is designed for performing certain actions.
• Algorithms + Data Structures = Programs.

An Overview of the UML

The UML is a language for

2
• Visualizing
• Specifying
• Constructing
• Documenting

The UML Is a Language for Documenting

A healthy software organization produces all sorts of artifacts in addition to raw executable code. These
artifacts include (but are not limited to)
• Requirements
• Architecture
• Design
• Source code
• Project plans
• Tests
• Prototypes
• Releases

Where Can the UML Be Used?

The UML is intended primarily for software-intensive systems. It has been used effectively for such
domains as

• Enterprise information systems

• Banking and financial services
• Telecommunications
• Transportation
• Defense/aerospace
• Retail
• Medical electronics
• Scientific
• Distributed Web-based services

A Conceptual Model of the UML

• A conceptual model needs to be formed by an individual to understand UML.

• UML contains three types of building blocks: things, relationships, and diagrams.
• Things
– Structural things
• Classes, interfaces, collaborations, use cases, components, and nodes.
– Behavioral things
• Messages and states.
– Grouping things
• Packages
– Annotational things
• Notes

• Relationships: Dependency, Association, Generalization and Realization.

• Diagrams: class, object, use case, sequence, collaboration, state chart, activity, component
and deployment.

Building Blocks of the UML:

3
The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams

Things in the UML

There are four kinds of things in the UML:

1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things

Structural Things

• Structural things are the nouns of UML models. These are the mostly static parts of a model,
representing elements that are either conceptual or physical. In all, there are seven kinds of
structural things.
• Classes
• Interface
• Cases
• Active Classes
• Components
• Nodes
• Collaborations

Classes:
a class is a description of a set of objects that share the same attributes, operations, relationships, and
semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle,
usually including its name, attributes, and operations

Interfaces
• an interface is a collection of operations that specify a service of a class or component. An
interface rarely stands alone. Rather, it is typically attached to the class or component that realizes
the interface

4
Collaborations:
• A collaboration defines an interaction. These collaborations therefore represent the
implementation of patterns that make up a system. Graphically, a collaboration is rendered as an
ellipse with dashed lines, usually including only its name

Use Cases:
• A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse with
solid lines, usually including only its name

Active Classes:
• An active class is rendered just like a class, but with heavy lines, usually including its name,
attributes, and operations

Components:
• A component typically represents the physical packaging of otherwise logical elements, such as
classes, interfaces, and collaborations. Graphically, a component is rendered as a rectangle with
tabs, usually including only its name.

5
Nodes:
• 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.
• A set of components may reside on a node and may also migrate from node to node. Graphically,
a node is rendered as a cube, usually including only its name.

Behavioral Things:

Behavioral things are the dynamic parts of UML models. These are the verbs of a model, representing
behavior over time and space. In all, there are two primary kinds of behavioral things.

1. Messages
2. States

Messages:
• 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. Graphically, a message is rendered
as a directed line, almost always including the name of its operation.

display

States:

6
 • 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, together with its responses to those events.

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.
Packages:
• A package is a general-purpose mechanism for organizing elements into groups. Graphically, a
package is rendered as a tabbed folder, usually including only its name and, sometimes, its
contents

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.
• There is one primary kind of annotation 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

Dependency is a semantic relationship between two model elements in which a change to one element
(the independent one) may affect the semantics of the other element (the dependent one). Graphically, a
dependency is rendered as a dashed line, possibly directed, and occasionally including a label.

7
Association is a structural relationship among classes that describes a set of links, a link being a
connection among objects that are instances of the classes.
Graphically, an association is rendered as a solid line, possibly directed, occasionally including a label,
and often containing other adornments, such as multiplicity and end names

Generalization is a specialization/generalization relationship in which the specialized element (the child)

builds on the specification of the generalized element (the parent). The child shares the structure and the
behavior of the parent. Graphically, a generalization relationship is rendered as a solid line with a hollow
arrowhead pointing to the parent.

Realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that
another classifier guarantees to carry out. generalization and a dependency relationship.

UML Diagrams

• A diagram is the graphical presentation of a set of elements, most often rendered as a connected
graph of vertices (things) and paths (relationships).
• A diagram represents an elided view of the elements that make up a system.
• In theory, a diagram may contain any combination of things and relationships.
• In practice, a small number of common combinations arise, which are consistent with the five
most useful views that comprise the architecture of a software intensive system

The UML includes Nine kinds of diagrams:

1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram

1. 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.

8
 2. 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.
3. 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.
4. Sequence diagram is an interaction diagram that emphasizes the time-ordering of messages;
5. Collaboration diagram a communication diagram is an interaction diagram that emphasizes the
structural organization of the objects or roles that send and receive messages.
6. Statechart diagram shows a state machine, consisting of states, transitions, events, and activities.
A state diagrams shows the dynamic view of an object.
7. Activity diagram shows the structure of a process or other computation as the flow of control and
data from step to step within the computation. Activity diagrams address the dynamic view of a
system.
8. Component diagram is shows an encapsulated class and its interfaces, ports, and internal structure
consisting of nested components and connectors. Component diagrams address the static design
implementation view of a system.
9. 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

What is Legal UML?

The UML has syntactic and semantic rules for

• Names What you can call things, relationships, and diagrams
• Scope The context that gives specific meaning to a name
• Visibility How those names can be seen and used by others
• Integrity How things properly and consistently relate to one another
• Execution What it means to run or simulate a dynamic model

Architecture

• Architecture refers to the different perspectives from which a complex system can be viewed.
• Visualizing, specifying, constructing, and documenting a software-intensive system demands that
the system be viewed from a number of perspectives.
• The architecture of a software-intensive system is best described by five interlocking views:

– Use case view: system as seen by users, analysts and testers.

– Design view: classes, interfaces and collaborations that make up the system.
– Process view: active classes (threads).
– Implementation view: files that comprise the system.
– Deployment view: nodes on which SW resides.

• Each view is a projection into the organization and structure of the system, focused on a
particular aspect of that system.

9
Each of these five views can stand alone so that different stakeholders can focus on the issues of the
system's architecture that most concern them.

10