UNIT – I: Introduction to UML

 The Importance of Modeling:

Modeling is a central part of all the activities that lead up to the deployment of good software.
We build models to communicate the desired structure and behavior of our system. We build models
to visualize and control the system's architecture. We build models to better understand the system
we are building, often exposing opportunities for simplification and reuse. We build models to
manage risk.
A model is a simplification of reality. We build models so that we can better understand the
system we are developing. Through modeling, we achieve four aims. They are:
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.
We build models of complex systems because we cannot comprehend such a System in its entirety.

 Principles of Modeling:
There are four basic principles common to designing any kind of system. They are:
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. The right models will brilliantly illuminate the most wicked development problems, offering
insight that you simply could not gain otherwise; the wrong models will mislead you, causing
you to focus on irrelevant issues.
3. Every model may be expressed at different levels of precision.
4. The best models are connected to reality.
5. No single model is sufficient. Every nontrivial system is best approached through a small set
of nearly independent models.
To understand the architecture of a system, we need several complementary and interlocking
views: a use case view (exposing the requirements of the system), a design view (capturing the
vocabulary of the problem space and the solution space), a process view (modeling the distribution
of the system's processes and threads), an implementation view (addressing the physical realization
of the system), and a deployment view (focusing on system engineering issues). Each of these views
may have structural, as well as behavioral, aspects. Together, these views represent the blueprints of
software.

 Object-Oriented Modeling:
In software, there are several ways to approach a model. The two most common ways are
from an algorithmic perspective and from an object-oriented perspective.
The traditional view of software development takes an algorithmic perspective. In this
approach, the main building block of all software is the procedure or function. This view leads
developers to focus on issues of control and the decomposition of larger algorithms into smaller
ones. As requirements change (and they will) and the system grows (and it will), systems built with
an algorithmic focus turn out to be very hard to maintain.
The contemporary view of software development takes an object-oriented perspective. In
this approach, the main building block of all software systems is the object or class. Simply put, an
object is a thing, generally drawn from the vocabulary of the problem space or the solution space; a
class is a description of a set of common objects. Every object has identity (you can name it or
otherwise distinguish it from other objects), state (there's generally some data associated with it), and
behavior (you can do things to the object, and it can do things to other objects, as well). Object-
oriented development provides the conceptual foundation for assembling systems out of components
using technology such as Java Beans or COM+.
A number of consequences flow from the choice of viewing the world in an object-oriented
fashion: What's the structure of a good object-oriented architecture? What artifacts should the project
create? Who should create them? How should they be measured? Visualizing, specifying,
constructing, and documenting object-oriented systems is exactly the purpose of the Unified
Modeling Language.

 A Conceptual Model of the UML:

To understand the UML, we need to form a conceptual model of the language, and this
requires learning three major elements: the UML's basic building blocks, the rules that dictate how
those building blocks may be put together, and some common mechanisms that apply throughout the
UML.

Building Blocks of the UML:

The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams
Things are the abstractions that are first-class citizens in a model; relationships tie these things
together; diagrams group interesting collections of things.

 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
These things are the basic object-oriented building blocks of the UML. We use them to write
well formed models.

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

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. An interface might
represent the complete behavior of a class or component or only a part of that behavior. An interface
defines a set of operation specifications (that is, their signatures) but never a set of operation
implementations. Graphically, an interface is rendered as a circle together with its name.
 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.
Therefore, collaborations have structural, as well as behavioral, dimensions. Graphically, a
collaboration is rendered as an ellipse with dashed lines, usually including only its name.

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. A use case is used to structure the behavioral things in
a model. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its
name.

The remaining three things active classes, components, and nodes• are all class-like, meaning
they also describe a set of objects that share the same attributes, operations, relationships, and
semantics. However, these three are different enough and are necessary for modeling certain aspects
of an object-oriented system.

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. Graphically, an active class is rendered
just like a class, but with heavy lines, usually including its name, attributes, and operations.

The remaining two elements component, and nodes are also different. They represent
physical things, whereas the previous five things represent conceptual or logical things.

A component is a physical and replaceable part of a system that conforms to and provides
the realization of a set of interfaces. Graphically, a component is rendered as a rectangle with tabs,
usually including only its name.
 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.

II. 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.
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. An interaction involves a
number of other elements, including messages, action sequences (the behavior invoked by a
message), and links (the connection between objects). Graphically, a message is rendered as a
directed line, almost always including the name of its operation.

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. A state
machine involves a number of other elements, including states, transitions (the flow from state to
state), events (things that trigger a transition), and activities (the response to a transition).
Graphically, a state is rendered as a rounded rectangle, usually including its name and its
substates, if any.

III. Grouping Things

Grouping things are the organizational parts of UML models. These are the boxes into
which a model can be decomposed. In all, there is one primary kind of grouping thing, namely,
packages.
A package is a general-purpose mechanism for organizing elements into groups. Structural
things, behavioral things, and even other grouping things may be placed in a package. Unlike
components (which exist at run time), a package is purely conceptual (meaning that it exists only at
development time). Graphically, a package is rendered as a tabbed folder, usually including only
its name and, sometimes, its contents.
IV. 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 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. Graphically, a note is rendered as a rectangle with a dog-eared corner,
together with a textual or graphical comment.

 Relationships in the UML:

There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
These relationships are the basic relational building blocks of the UML. We use them to write
well-formed models.
A dependency is a semantic relationship between two things in which a change to one thing
(the independent thing) may affect the semantics of the other thing (the dependent thing).
Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally
including a label.

An association is a structural relationship that describes a set of links, a link being a

connection among objects. Aggregation is a special kind of association, representing a structural
relationship between a whole and its parts. Graphically, an association is rendered as a solid line,
possibly directed, occasionally including a label, and often containing other adornments, such as
multiplicity and role names.

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).
Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead
pointing to the parent.

A realization is a semantic relationship between classifiers, wherein one classifier specifies a

contract that another classifier guarantees to carry out. We will encounter realization relationships in
two places: between interfaces and the classes or components that realize them, and between use
cases and the collaborations that realize them. Graphically, a realization relationship is rendered as
a cross between a generalization and a dependency relationship.
 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). You draw diagrams to visualize a
system from different perspectives, so a diagram is a projection into a system. UML includes nine
diagrams.
1. Class diagram 6. Statechart diagram
2. Object diagram 7. Activity diagram
3. Use case diagram 8. Component diagram
4. Sequence diagram 9. Deployment diagram
5. Collaboration diagram

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.

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.

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.

Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams.
An interaction diagram 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 we can take one and transform it into the other.

A statechart diagram shows a state machine, consisting of states, transitions, events,

and activities. Statechart diagrams address the dynamic view of a system.

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.

A component diagram shows the organizations and dependencies among a set of

components. Component diagrams address the static implementation view of a system.

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.

Rules of the UML:

Like any language, the UML has a number of rules that specify what a well-formed model
should look like. A well-formed model is one that is semantically self-consistent and in harmony with
all its related models. The UML has semantic rules for
Names: What we 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
Models built during the development of a software-intensive system tend to evolve and may
be viewed by many stakeholders in different ways and at different times. For this reason, it is
common for the development team to not only build models that are well-formed, but also to build
models that are:
Elided: Certain elements are hidden to simplify the view
Incomplete: Certain elements may be missing
Inconsistent: The integrity of the model is not guaranteed.

Common Mechanisms in the UML:

UML is made simpler by the presence of four common mechanisms that apply consistently
throughout the language.
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms.

Specifications:
The UML is more than just a graphical language. We use the UML's graphical notation to
visualize a system; you use the UML's specification to state the system's details. The UML's
specifications provide a semantic backplane that contains all the parts of all the models of a system,
each part related to one another in a consistent fashion.

Adornments:
Most elements in the UML have a unique and direct graphical notation that provides a visual
representation of the most important aspects of the element. A class's specification may include other
details, such as whether it is abstract or the visibility of its attributes and operations. Many of these
details can be rendered as graphical or textual adornments to the class's basic rectangular notation.

Common Divisions:
In modeling object-oriented systems, the world often gets divided in at least a couple of
ways.
First, there is the division of class and object. A class is an abstraction; an object is one
concrete manifestation of that abstraction. In the UML, we can model classes as well as objects.
 In this figure, there is one class, named Customer, together with three objects: Jan (which is marked
explicitly as being a Customer object), :Customer (an anonymous Customer object), and Elyse
(which in its specification is marked as being a kind of Customer object, although it's not shown
explicitly here).
Second, there is the separation of interface and implementation. An interface declares a
contract, and an implementation represents one concrete realization of that contract, responsible for
faithfully carrying out the interface's complete semantics. In the UML, we can model both
interfaces and their implementations.

In this figure, there is one component named spellingwizard.dll that implements two interfaces,
IUnknown and ISpelling.

Extensibility Mechanisms
The UML provides a standard language for writing software blueprints, but it is not possible
for one closed language to ever be sufficient to express all possible nuances of all models across all
domains across all time. For this reason, the UML is opened-ended, making it possible for us to
extend the language in controlled ways. The UML's extensibility mechanisms include Stereotypes,
Tagged values, Constraints

A stereotype extends the vocabulary of the UML, allowing you to create new kinds of
building blocks that are derived from existing ones but that are specific to your problem.

A tagged value extends the properties of a UML building block, allowing us to create new
information in that element's specification.
A constraint extends the semantics of a UML building block, allowing you to add new rules
or modify existing ones.

 Architecture:
Architecture is the set of significant decisions about
1. The organization of a software system
2. The selection of the structural elements and their interfaces by which the system is
composed
3. Their behavior, as specified in the collaborations among those elements
4. The composition of these structural and behavioral elements into progressively
larger Subsystems
5. The architectural style that guides this organization: the static and dynamic elements
and their interfaces, their collaborations, and their composition.
Software architecture is not only concerned with structure and behavior, but also with usage,
functionality, performance, resilience, reuse, comprehensibility, economic and technology
constraints and trade-offs, and aesthetic concerns. The architecture of a software-intensive system
can best be described by five interlocking views. Each view is a projection into the organization and
structure of the system, focused on a particular aspect of that system.

The use case view of a system encompasses the use cases that describe the behavior of the
system as seen by its end users, analysts, and testers. With the UML, the static aspects of this view
are captured in use case diagrams; the dynamic aspects of this view are captured in interaction
diagrams, state chart diagrams, and activity diagrams.

The design view of a system encompasses the classes, interfaces, and collaborations that
form the vocabulary of the problem and its solution. This view primarily supports the functional
requirements of the system, meaning the services that the system should provide to its end users.
With the UML, the static aspects of this view are captured in class diagrams and object diagrams; the
dynamic aspects of this view are captured in interaction diagrams, statechart
diagrams, and activity diagrams.

The process view of a system encompasses the threads and processes that form the system's
concurrency and synchronization mechanisms. This view primarily addresses the performance,
scalability, and throughput of the system. With the UML, the static and dynamic aspects of this view
are captured in the same kinds of diagrams as for the design view, but with a focus on the
active classes that represent these threads and processes.

The implementation view of a system encompasses the components and files that are used to
assemble and release the physical system. This view primarily addresses the configuration
management of the system's releases, made up of somewhat independent components and files that
can be assembled in various ways to produce a running system. With the UML, the static aspects of
this view are captured in component diagrams; the dynamic aspects of this view are
captured in interaction diagrams, statechart diagrams, and activity diagrams.

The deployment view of a system encompasses the nodes that form the system's hardware
topology on which the system executes. This view primarily addresses the distribution, delivery, and
installation of the parts that make up the physical system. With the UML, the static aspects of this
view are captured in deployment diagrams; the dynamic aspects of this view are captured in
interaction diagrams, statechart diagrams, and activity diagrams.
These five views also interact with one another nodes in the deployment view hold
components in the implementation view that, in turn, represent the physical realization of classes,
interfaces, collaborations, and active classes from
the design and process views.
 Software Development Life Cycle:
The UML is largely process-independent, meaning that it is not tied to any particular
software development life cycle. However, to get the most benefit from the UML, we should
consider a process that is Use case driven, Architecture-centric, Iterative and incremental.

Use case driven means that use cases are used as a primary artifact for establishing the
desired behavior of the system, for verifying and validating the system's architecture, for testing, and
for communicating among the stakeholders of the project.
Architecture-centric means that a system's architecture is used as a primary artifact for
conceptualizing, constructing, managing, and evolving the system under development.
An iterative process is one that involves managing a stream of executable releases. An is one
that involves the continuous integration of the system's architecture to produce these releases, with
each new release embodying incremental improvements over the other. Together, an iterative and
incremental process is risk-driven, meaning that each new release is focused on
attacking and reducing the most significant risks to the success of the project.
This use case driven, architecture-centric, and iterative/incremental process can be broken
into phases. A phase is the span of time between two major milestones of the process, when a
welldefined set of objectives are met, artifacts are completed, and decisions are made whether to
move into the next phase. There are four phases in the software development life cycle: inception,
elaboration, construction, and transition.

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 warrant entering into the
elaboration phase.
Elaboration is the second phase of the process, when the product vision and its architecture
are defined. In this phase, the system's requirements are articulated, prioritized, and baselined.
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.
Transition is the fourth phase of the process, when the software is turned into the hands of
the user community.