D JEMMI RATHNA

UNIT-1
Introduction to UML: Importance of modeling, principles of modeling, object oriented
modeling, conceptual model of the UML, Architecture, Software Development Life
Cycle.
Structural Modeling: Classes, Relationships, common Mechanisms, and diagrams.
Advanced classes, advanced relationships, Object diagrams: common modeling
techniques.

1.1 Introduction to UML:

UML is a standard language for specifying,
visualizing, constructing, and documenting the
artifacts of software systems.
UML was created by the Object Management Group
(OMG) and UML 1.0 specification draft was
proposed to the OMG in January 1997.
OMG is continuously making efforts to create a
truly industry standard.
• UML stands for Unified Modelling Language.
• UML is different from the other common programming languages such as
C++, Java, COBOL, etc.
• UML is a pictorial language used to make software blueprints.
• UML can be described as a general purpose visual modeling language to
visualize, specify, construct, and document software system.
• Although UML is generally used to model software systems, it is not
limited within this boundary. It is also used to model non-software
systems as well. For example, the process flow in a manufacturing unit,
etc.
• The UML is process independent.
• UML is not a programming language, it is rather a visual language.
• UML diagrams are not only made for developers but also for business
users, common people, and anybody interested to understand the system.

 It helps in designing and characterizing, especially those software systems that

incorporate the concept of Object orientation. It describes the working of both
the software and hardware systems.
 The UML was developed in 1994-95 by Grady Booch, Ivar Jacobson, and James
Rumbaugh at the Rational Software. In 1997, it got adopted as a standard by
the Object Management Group (OMG).
 The UML is a language for
▪ Visualizing
▪ Specifying
▪ Constructing
▪ Documenting
 the artifacts of a software-intensive system.

Visualizing: The UML Is a Language for Visualizing

• Communicating conceptual models to others is

prone to error unless everyone involved speaks the
same language.
• There are things about a software system you can’t
understand unless you build models.

Specifying: UML is a language for Specifying

• Specifying means building models that are precise, unambiguous and complete.

• The UML addresses the specification of all the important analysis, design and
implementation decisions that must be made in developing and deploying a
software system.

Constructing: UML is a language for Constructing

• The UML is not a visual programming language, but its models can be directly
connected to a variety of programming languages, such as JAVA, C++ or Visual
Basic or even to Tables of database.

Documenting: The UML Is a Language for Documenting

• The UML addresses documentation of system architecture, requirements, tests,

project planning, and release management.

1.2 Importance of modeling :

Model: UML is a modeling language

• A model is “a complete description of a system from a particular perspective.”
A model is a simplification of reality.
• A model provides the blueprints of a system.
• Model is important and mandatory.
• A model may be structural, emphasizing the organization of the system, or it
may be behavioral, emphasizing the dynamics of the system.

Why do we model?:

➢ Modeling is a central part of all the activities that lead to the development of
good software.
➢ A model is a simplification at some level of abstraction .
➢ We build models to better understand the systems we are developing:

• To help us visualize
 • To specify structure or behavioral
• To provide template for building system
• To document decisions we have made

➢ Analyse the problem-domain and Design the solution

– simplify reality
– capture requirements
– visualize the system in its entirety
– specify the structure and/or behaviour of the system

• Through Modeling achieves four aims:

o Helps you to visualize a system as you want it to be.
o Permits you to specify the structure or behavior of a system.
o Gives you a template that guides you in constructing a system.
o Documents the decisions you have made.
• You build models of complex systems because you cannot comprehend such a
system in its entirety.
• You build models to better understand the system you are developing.
Less Important More Important

Paper Airplane Fighter

Jet

1.3 principles of modelling:

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

1.4 object oriented modelling:

Traditionally two approaches to modeling a software system

✓ Algorithmically – becomes hard to focus on as the requirements change
✓ Object-oriented – models more closely real world entities

• Object-oriented modeling (OOM) is a common approach to modeling

applications, systems by using the object-oriented paradigm throughout the
entire development life cycles.
• OOM is a main technique heavily used by both OOA and OOD activities in
modern software engineering.
• The Unified Modeling Language (UML) and SysML are the two popular
international standard languages used for object-oriented modeling.

1.5 conceptual model of the UML:

➢ To understand the UML, a conceptual model of the language is need to form

and it requires the three major elements:

• Building blocks of the UML.

• Rules that dictate how these building blocks may be put together.
• Common mechanisms that apply throughout the UML.
1.5.1. UML-Building Blocks:

UML is composed of three main building blocks, i.e., things, relationships, and
diagrams. Building blocks generate one complete UML model diagram by rotating
around several different blocks. It plays an essential role in developing UML diagrams.

The basic UML building blocks are enlisted below:

1. Things
2. Relationships
3. Diagrams

• The UML consists of three kinds of building blocks:

a) Things- These are the abstractions that are first-class citizens in a model.
b) Relationships-Tie the above things together.
c) Diagrams-Group interesting collections of things.
1.5.1.1 Things in the UML:

• There are 4 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. You use them
to write well-formed models.

1. Structural Things

➢ Structural things are the nouns of UML models. These are mostly static parts
of a model, representing elements that are either conceptual or physical.
➢ Collectively, the structural things are called classifiers.

There are 7 kinds of Structural things:

1. Class
2. Interface
3. Collaboration
4. Use case
5. Active class
6. Component
7. Node
❖ Class:-
• 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.

❖ 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. An interface
might represent the complete behavior of a
class or component or only a part of that
behavior.
• Interface is represented by a circle as shown
in the following figure. It has a name which is generally written below the
circle.
❖ 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.
• Collaborations have structural, as well as
behavioral, dimensions. A given class or
object might participate in several
collaborations.
• Graphically, a collaboration is rendered as
an ellipse with dashed lines, sometimes including only its name.
❖ Use case:
• A use case is a description of sequences of
actions that a system performs that yield
observable results of value to a particular actor.
• A use case is used to structure the behavioral
things in a model. 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 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.
• Graphically, an active class is rendered as a class
with dark line; it usually includes its name,
attributes, and operations.
❖ Component:
• A component is a physical and replaceable
part of a system that conforms to and provides
the realization of a set of interfaces.

❖ Node:

A physical element that exists at run time.

Behavioral Things

They are the verbs that encompass the dynamic parts of a model. It depicts the
behavior of a system.

▪ There are two types of behavioral things

1. Interaction

2. State machine.

❖ Interaction − Interaction is defined as a behavior that consists of a group of

messages exchanged among elements to accomplish a specific task.
Graphically, a message is rendered as a directed line.

❖ State machine − State machine is useful when the state of an object in its life
cycle is important. It defines the sequence of states an object goes through in
response to events. Events are external factors responsible for state change.
 Graphically, a state is rendered as a rounded rectangle, usually including its
name and its substates

3.Grouping Things
Grouping things can be defined as a mechanism to group elements of a UML model
together. There is only one grouping thing available −
❖ Package − Package is the only one grouping thing
available for gathering structural and behavioral things.

Structural things, behavioral things and even other

grouping things that may be placed in a package.

4.Annotational Things
Annotational things can be defined as a mechanism to capture remarks,
descriptions, and comments of UML model elements.

❖ Note - It is the only one Annotational thing available. A note

is used to render as a rectangle with a dog-eared corner.
❖ Annotational Things are the explanatory parts of the UML
models.

1.5.1.2 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. These
are used to write well-formed models.

1. Dependency: First, a 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.
2. Association : Second, an 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. 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

3. Generalization: Third, a 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

4. Realization : Fourth, a realization is a semantic relationship between classifiers,

wherein one classifier specifies a contract that another classifier guarantees to carry
out. You'll 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.

1.5.1.3 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 paths (relationships).
✓ You draw diagrams to visualize a system from different perspectives, so a
diagram is a projection into a system.
UML includes nine kinds of diagrams:

• Class diagram
• Object diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram
• Activity diagram
 • Statechart diagram
• Component diagram
• Deployment diagram
1.Class 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.

2.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.
3.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.
4.Sequence diagram:
• Both sequence diagrams and Collaboration diagrams are kinds of
interaction diagrams.
• An interaction diagram shows an interaction, consisting of a set of objects
or roles, 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
Collaboration diagram:
• A Collaboration diagram is an interaction diagram that emphasizes the
structural organization of the objects or roles that send and receive
messages.
• Sequence diagrams and Collaboration diagrams represent similar basic
concepts, but each diagram emphasizes a different view of the concepts.
• Sequence diagrams emphasize temporal ordering, and Collaboration
diagrams emphasize the data structure through which messages flow.
Activity diagram:
• An 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.
• They are especially important in modeling the function of a system and
emphasize the flow of control among objects.

Statechart diagram:
• A state diagram shows a state machine, consisting of states, transitions,
events, and activities.
• A state diagrams shows the dynamic view of an object.
• 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

Component diagram:
• A 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. They are important for building large systems from smaller parts.
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. A node typically hosts one or more artifacts.
1.5.2. Rules of the UML :
✓ The UML's building blocks can't simply be thrown together in a random fashion.
✓ 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 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.
 – 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.
– These less-than-well-formed models are unavoidable as the details of a system
unfold and churn during the software development life cycle.
– The rules of the UML encourage youbut do not force youto address the most
important analysis, design, and implementation questions that push such
models to become well-formed over time.
1.5.3 Common Mechanisms
▪ The 4 common mechanisms that apply consistently throughout the language.
1. Specifications
2. Adornments
3. Common Divisions
4. Extensibility mechanisms
1. Specifications:-
➢ The UML is more than just a graphical language. Rather, behind every part of
graphical notation there is a specification that provides a textual statement of
the syntax and semantics of that building block.
➢ For example, behind a class icon is a specification that provides the full set of
attributes, operations and behaviors.
➢ You use the UML’s graphical notation to visualize a system; you use the UML’s
specification to state the system details.
2. 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.
• For example, the notation for a class is intentionally designed to be easy
to draw, because classes are the most common element found in modeling
object-oriented systems.
• The class notation also exposes the most important aspects of a class,
namely its name, attributes, and operations.
  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.
 For example a class, adorned to indicate that it is an abstract class with two
public, one protected, and one private operation.
3.Common Divisions:
In modeling object-oriented systems, the world often gets divided in several ways.
➢ Abstraction vs. manifestation
First, there is the division of class and object. A class is an abstraction; an object
is one concrete manifestation of that abstraction
• Class vs. object
• Most UML building blocks have this kind of class/object distinction.

➢ Interface vs. implementation

Second, there is the separation of interface and implementation.
• An interface declares a contract, and an implementation represents one
concrete realization of that contract.
 • 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.

4.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.
The UML's extensibility mechanisms include:
 Stereotypes
 Tagged values
 Constraints
1.Stereotypes:
 Extend the vocabulary of the UML by creating new model elements derived from
existing ones but that have specific properties suitable for your
domain/problem.
2.Tagged values:-
 Properties for specifying key-value pairs of model elements, where keywords
are attributes.
 Extend the properties of a UML building block, allowing you to create new
information in that elements specification.
3.Constraints:-
 Properties for specifying semantics or conditions that must be maintained as
true for model elements.
 Extend the semantics of a UML building block, allowing you to add new rules,
or modify existing ones.
 Example:- you might want to constrain the EventQueue class so that all
additions are done in order.
1.6 Architecture/ Modeling a System's Architecture:
– Any real world system is used by different users. The users can be developers,
testers, business people, analysts and many more.
– So before designing a system the architecture is made with different
perspectives in mind. T
– he most important part is to visualize the system from different viewer.s
perspective.
– The better we understand the better we make the system.

Architecture is the set of significant decisions about

• The organization of a software system
• The selection of the structural elements and their interfaces by which the
system is composed
• Their behavior, as specified in the collaborations among those elements
• The composition of these structural and behavioral elements into progressively
larger subsystems
 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.
UML plays an important role in defining different perspectives of a system.
These perspectives are:
• Usecase View
• Design View
• Process View
• Implementation View
• Deployment View
The centre is the Use Case view which connects all these four.
✓ A Use case :represents the functionality of the system, it Specify the shape of
the system's architecture. So the other perspectives are connected with use
case.
✓ Design of a system consists of classes, interfaces and collaboration. UML
provides class diagram, object diagram to support this.
• This view primarily supports the functional requirements of the
system, meaning the services that the system should provide to its
end users.
✓ Implementation defines the components assembled together to make a
complete physical system. UML component diagram is used to support
implementation perspective
• This view primarily addresses the configuration management of the
system's releases
✓ Process defines the flow of the system. So the same elements as used in Design
are also used to support this perspective.
• This view primarily addresses the performance, scalability, and
throughput of the system.
✓ Deployment represents the physical nodes of the system that forms the
hardware. UML deployment diagram is used to support this perspective.
• This view primarily addresses the distribution, delivery, and
installation of the parts that make up the physical system.
1.7 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, you 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, testing, 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 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 four phases. A phase is the span of time between two major
milestones of the process.
• 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 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. 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.

1.8 Structural Modeling:

Contents:
1. Classes
2. Relationships
3. Common Mechanisms
4. Diagrams

Structural Modeling:
Structural modeling captures the static features of a system. They consist of the
following −

• Classes diagrams
• Objects diagrams
• Component diagram
• Deployment diagrams
• Component diagram
Class diagram is the most widely used structural diagram.
1. Classes:
Terms and Concepts:
A class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics. Graphically, a class is rendered as a
rectangle.
Names
• Every class must have a name that distinguishes it from other classes.
• A name is a textual string. That name alone is known as a simple name;
a qualified name is the class name prefixed by the name of the package
in which that class lives. A class may be drawn showing only its name.
Attributes:
• An attribute is a named property of a class that describes a range of values that
instances of the property may hold.
• A class may have any number of attributes or no attributes at all.
• An attribute represents some property of the thing you are modeling that is
shared by all objects of that class.

Operations
• An operation is the implementation of a service that can be requested from any
object of the class to affect behavior.
• an operation is an abstraction of something you can do to an object that is
shared by all objects of that class.
• A class may have any number of operations or no operations at all.
 Responsibilities

A responsibility is a contract or an obligation of a class. When you create a class, you

are making a statement that all objects of that class have the same kind of state and
the same kind of behavior.

2.Relationships:

Terms and Concepts

• A relationship is a connection among things.
• In object-oriented modeling, the three most important relationships are
dependencies, generalizations, and associations.
• Graphically, a relationship is rendered as a path, with different kinds of
lines used to distinguish the kinds of relationships.

Dependencies:

A dependency is a relationship that states that one thing (for example, class
Window) uses the information and services of another thing (for example, class
Event), but not necessarily the reverse.
Graphically, a dependency is rendered as a dashed directed line, directed to
the thing being depended on.
Choose dependencies when you want to show one thing using another.

Generalizations:

A generalization is a relationship between a general kind of thing (called the

superclass or parent) and a more specific kind of thing (called the subclass or
child). Generalization is sometimes called an "is-a-kind-of" relationship.
Associations:

• An association is a structural relationship that specifies that objects of one

thing are connected to objects of another.
• Given an association connecting two classes, you can relate objects of one
class to objects of the other class.
• An association that connects exactly two classes is called a binary
association..
• Beyond this basic form, there are four adornments that apply to associations.

Name:

An association can have a name, and you use that name to describe the nature
of the relationship. So that there is no ambiguity about its meaning, you can give
a direction to the name by providing a direction triangle that points in the
direction you intend to read the name.
Role:
• When a class participates in an
association, it has a specific role that it
plays in that relationship; a role is just the
face the class at the far end of the
association presents to the class at the
near end of the association.
• You can explicitly name the role a class
plays in an association.
Multiplicity:
• An association represents a structural relationship among objects.
• In many modeling situations, it's important for you to state how many
objects may be connected across an instance of an association.
• This "how many" is called the multiplicity of an association's role.
• It represents a range of integers specifying the possible size of the set
of related objects.

The number of objects must be in the given range. You can show a multiplicity
of exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*). You can
give an integer range (such as 2..5). You can even state an exact number (for
example, 3, which is equivalent to 3..3).

Aggregation:
A plain association between two classes represents a structural relationship
between peers, meaning that both classes are conceptually at the same level, no
one more important than the other.
Sometimes you will want to model a "whole/part" relationship, in which one class
represents a larger thing (the "whole"), which consists of smaller things (the
"parts"). This kind of relationship is called aggregation, which represents a "has-
a" relationship

Composition:-

• Composition is a special form of aggregation within which the parts are

inseparable from the whole.
Modeling Structural Relationships

3.Common Mechanisms:

Terms and Concepts:

 A note is a graphical symbol for rendering constraints or 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.

stereotype is an extension of the vocabulary of the UML, allowing you to

create new kinds of building blocks similar to existing ones but specific to
your problem. Graphically, a stereotype is rendered as a name enclosed by
guillemets (French quotation marks of the form « »), placed above the name
of another element.
 Optionally the stereotyped element may be rendered by using a new icon
associated with that stereotype.
 A tagged value is a property of a stereotype, allowing you to create new
information in an element bearing that stereotype. Graphically, a tagged
value is rendered as a string of the form name = value within a note attached
to the object.
 classes have names, attributes, and operations; associations have names
and two or more ends, each with its own properties; and so on. With
stereotypes, you can add new things to the UML; with tagged values, you can
add new properties to a stereotype.

 A constraint is a textual specification of the semantics of a UML element,

allowing you to add new rules or to modify existing ones. Graphically, a
constraint is rendered as a string enclosed by brackets and placed near the
associated element or connected to that element or elements by dependency
relationships. As an alternative, you can render a constraint in a note.
Other Adornments:
Adornments are textual or graphical items that are added to an element's basic
notation and are used to visualize details from the element's specification

4.Diagrams:

Terms and Concepts

A system is a collection of subsystems organized to accomplish a purpose and
described by a set of models, possibly from different viewpoints.

A subsystem is a grouping of elements, some of which constitute a specification of

the behavior offered by the other contained elements.

A model is a semantically closed abstraction of a system, meaning that it

represents a complete and self-consistent simplification of reality, created in
order to better understand the system. In the context of architecture,

A view is a projection into the organization and structure of a system's model,

focused on one aspect of that system.
 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 static parts of a system using one of the following diagrams:
1. Class diagram
2. Component diagram
3. Object diagram
4. Deployment diagram

▪ You'll often use five additional diagrams to view the dynamic parts of a
system:
1. Use case diagram
2. Sequence diagram
3. Collaboration diagram
4. State diagram
5. Activity diagram
Structural Diagrams:
• The UML's structural diagrams exist to visualize, specify, construct, and
document the static aspects of a system.
• The UML's structural diagrams are roughly organized around the major
groups of things you'll find when modeling a system.

1.Class diagram Classes, interfaces, and collaborations

2.Component diagram Components

3.Object diagram Objects

4.Deployment diagram Nodes

Behavioral Diagrams:
• The UML's behavioral diagrams are used to visualize, specify, construct, and
document the dynamic aspects of a system.
• The UML's behavioral diagrams are roughly organized around the major
ways you can model the dynamics of a system.

1.Use case diagram Organizes the behaviors of the system

2.Sequence diagram Focuses on the time ordering of messages
3.Collaboration diagram Focuses on the structural organization of
objects that send and receive messages
4.State diagram Focuses on the changing state of a system
driven by events
5.Activity diagram Focuses on the flow of control from
activity to activity
1.9 ADVANCED STRUCTURAL MODELING:
Contents:
1. Advanced Classes
2. Advanced Relationships

1. Advanced Classes:

Terms and Concepts:

A classifier is a mechanism that describes structural and behavioral features.

Classifiers include classes, associations, interfaces, datatypes, signals,
components, nodes, use cases, and subsystems.
Classifiers

When you model, you'll discover abstractions that represent things in the real world
and things in your solution.
✓ The most important kind of classifier in the UML is the class.
✓ A class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics.
✓ Classes are not the only kind of classifier, however. The UML provides a number
of other kinds of classifiers to help you model

Interface A collection of operations that are used to specify a service of a class or a component

Datatype A type whose values are immutable, including primitive built-in types (such as
numbers and strings) as well as enumeration types (such as Boolean)
Association A description of a set of links, each of which relates two or more objects.

Signal The specification of an asynchronous message communicated between instances

Component A modular part of a system that hides its implementation behind a set of external
interfaces
Node A physical element that exists at run time and that represents a computational
resource, generally having at least some memory and often processing capability
Use case A description of a set of a sequence of actions, including variants, that a system
performs that yields an observable result of value to a particular actor
Subsystem A component that represents a major part of a system
Visibility:

One of the design details you can specify for an attribute or operation is visibility. The visibility
of a feature specifies whether it can be used by other classifiers. In the UML, you can specify any
of four levels of visibility.

1. public Any outside classifier with visibility to the given classifier can use the feature; specified
by prepending the symbol +.
2.protected Any descendant of the classifier can use the feature; specified by prepending the symbol
#.
3. private Only the classifier itself can use the feature; specified by prepending the symbol -.
4. package Only classifiers declared in the same package can use the feature; specified by
prepending the symbol ~.
Abstract, Leaf, and Polymorphic Elements:

• You use generalization relationships to model a lattice of classes, with more-

generalized abstractions at the top of the hierarchy and more-specific ones at
the bottom.
• Within these hierarchies, it's common to specify that certain classes are
abstractmeaning that they may not have any direct instances

Multiplicity:

Whenever you use a class, it's reasonable to assume that there may be any
number of instances of that class.

Attributes:

At the most abstract level, when you model a class's structural features (that is, its attributes), you
simply write each attribute's name.
 [visibility] name
[':' type] ['[' multiplicity] ']']
['=' initial-value]
[property-string {',' property-string}]

For example, the following are all legal attribute declarations:

origin Name only

+ origin Visibility and name

origin : Point Name and type

name : String[0..1] Name, type, and multiplicity

origin : Point = (0,0) Name, type, and initial value

id: Integer {readonly} Name and property

Operations:

At the most abstract level, when you model a class's behavioral features. you can also specify the
parameters, return type, concurrency semantics, and other properties of each operation.
Collectively, the name of an operation plus its parameters (including its return type, if any) is
called the operation's signature.

[visibility] name ['(' parameter-list ')']

[':' return-type]
[property-string {',' property-string}]

For example, the following are all legal operation declarations:

display Name only

+ display Visibility and name

set(n : Name, s : String) Name and parameters

getID() : Integer Name and return type
restart() {guarded} Name and property

In an operation's signature, you may provide zero or more parameters, each of which follows the
syntax

[direction] name : type [= default-value]

 Direction may be any of the following values:
in An input parameter; may not be modified

out An output parameter; may be modified to communicate information to the caller

inout An input parameter; may be modified to communicate information to the caller

Template Classes:

A template may include slots for classes, objects, and values, and these slots serve as
the template's parameters.

template<class Item, class VType, int Buckets>

class Map {
public:
virtual map(const Item&, const VType&); virtual
Boolean isMappen(const Item&) const;
...

};

You might then instantiate this template to map Customer objects to Order objects. m :

Map<Customer, Order, 3>;

Standard Elements:

All of the UML's extensibility mechanisms apply to classes.

The UML defines four standard stereotypes that apply to classes.
1. metaclass Specifies a classifier whose objects are all classes
2.powertype Specifies a classifier whose objects are classes that are the
children of a given parent class
3.stereotype Specifies that the classifier is a stereotype that may be applied
to other elements
4. utility Specifies a class whose attributes and operations are all static
scoped

2.Advanced Relationships:
Terms and Concepts:
A relationship is a connection among things. In object-oriented modeling, the four
most important relationships are dependencies, generalizations, associations,
 and realizations. Graphically, a relationship is rendered as a path, with different
kinds of lines used to distinguish the different relationships.
Dependencies:
• A dependency is a using relationship, specifying that a change in the
specification of one thing may affect another thing that uses it, but not the
reverse.
• Graphically, a dependency is rendered as a dashed line, directed to the thing
that is depended on. Apply dependencies when you want to show one thing
using another.

 First, there are stereotypes that apply to dependency relationships among

classes and objects in class diagrams.

1. bind Specifies that the source instantiates the target template using the
given actual parameters
2.derive Specifies that the source may be computed from the target
3.permit Specifies that the source is given special visibility into the target
4.instanceOf Specifies that the source object is an instance of the target classifier.
Ordinarily shown using text notation in the form source : Target
5.instantiate Specifies that the source creates instances of the target
6.powertype Specifies that the target is a powertype of the source; a powertype is a
classifier whose objects are the children of a given parent
7. refine Specifies that the source is at a finer degree of
8. use Specifies that the semantics of the source element depends on the
semantics of the public part of the target

 There are two stereotypes that apply to dependency relationships among

packages.

1.import Specifies that the public contents of the target package enter
the public namespace of the source, as if they had been declared
in the source.
2.access Specifies that the public contents of the target package enter
the private namespace of the source. The unqualified names
may be used within the source, but they may not be re-
exported.

 Two stereotypes apply to dependency relationships among use cases:

1.extend Specifies that the target use case extends the behavior of the
source
2.inclue Specifies that the source use case explicitly incorporates the
behavior of another use case at a location specified by the source

 One stereotype you'll encounter in the context of interactions among objects is

1.send Specifies that the source class sends the target event

 Finally, one stereotype that you'll encounter in the context of organizing the
elements of your system into subsystems and models is

1.TRace Specifies that the target is a historical predecessor of the source from an earlier
stage of
development
Generalizations:

• A generalization is a relationship between a general classifier (called the

superclass or parent) and a more specific classifier (called the subclass or
child).
• For example, you might encounter the general class Window with its more
specific subclass, MultiPaneWindow. With a generalization relationship from
the child to the parent, the child (MultiPaneWindow) will inherit all the
structure and behavior of the parent (Window).
• The UML defines one stereotype and four constraints that may be applied to
generalization relationships.
implementation Specifies that the child inherits the implementation
1 of the parent but does not make public nor support
its interfaces thereby violating substitutability

A plain, unadorned generalization relationship is sufficient for most of the

inheritance relationships you'll encounter. However, if you want to specify a shade
of meaning, the UML defines four constraints that may be applied to generalization
relationships:

1. complete Specifies that all children in the generalization have been

specified in the model (although some may be elided in the
diagram) and that no additional children are permitted
2.incomplete Specifies that not all children in the generalization have been
specified (even if some are elided) and that additional children are
permitted
3. disjoint Specifies that objects of the parent may have no more than one
of the children as a type. For example, class Person can be
specialized into disjoint classes Man and Woman.
4.overlapping Specifies that objects of the parent may have more than one of
the children as a type. For example, class Vehicle can be
specialized into overlapping subclasses LandVehicle and
WaterVehicle (an amphibious vehicle is both).

Association:
• An association is a structural relationship, specifying that objects of one thing
are connected to objects of another.
• We use associations when you want to show structural relationships.
• There are four basic adornments that apply to an association:
✓ a name,
✓ the role at each end of the association,
✓ the multiplicity at each end of the association,
✓ and aggregation.
• For advanced uses, there are a number of other properties you can use to model
subtle details, such as
✓ Navigation
✓ Vision
✓ Qualification
✓ various flavors of aggregation.
 Navigation:
• unadorned association between two classes, such as Book and Library, it's
possible to navigate from objects of one kind to objects of the other kind. Unless
otherwise specified, navigation across an association is bidirectional.
• However, there are some circumstances in which you'll want to limit navigation
to just one direction.

Navigation
Visibility:
• Given an association between two classes, objects of one class can see and
navigate to objects of the other, unless otherwise restricted by an explicit
statement of navigation.
• However, there are circumstances in which you'll want to limit the visibility
across that association relative to objects outside the association.
• In the UML, you can specify three levels of visibility for an association end, just
as you can for a class's features by appending a visibility symbol to a role name
the visibility of a role is public.
• Private visibility indicates that objects at that end are not accessible to any
objects outside the association.
• Protected visibility indicates that objects at that end are not accessible to
any objects outside the association, except for children of the other end.

Visibility

Qualification:
In the context of an association, one of the most common modeling idioms
you'll encounter is the problem of lookup. Given an object at one end of an association,
how do you identify an object or set of objects at the other end?
In the UML, you'd model this idiom using a qualifier, which is an association
attribute whose values partition the set of objects related to an object across an
association.
You render a qualifier as a small rectangle attached to the end of an
association, placing the attributes in the rectangle

Qualification

Interface Specifier:
An interface is a collection of operations that are used to specify a service of a
class or a component
Collectively, the interfaces realized by a class represent a complete
specification of the behavior of that class.
 However, in the context of an association with another target class, a source
class may choose to present only part of its face to the world

a Person class may realize many interfaces: IManager, IEmployee, IOfficer, and
so on
you can model the relationship between a supervisor and her workers with a
one-to- many
association, explicitly labeling the roles of this association as supervisor and
worker
• In the context of this association, a Person in the role of supervisor presents
only the IManager face to the worker; a Person in the role of worker presents
only the IEmployee face to the supervisor. As the figure shows, you can
explicitly show the type of role using the syntax rolename : iname, where iname
is some interface of the other classifier.

Composition:

• Simple aggregation is entirely conceptual and does nothing more than

distinguish a "whole" from a "part."
• Composition is a form of aggregation, with strong ownership and coincident
lifetime as part of the whole.
• Parts with non-fixed multiplicity may be created after the composite itself, but
once created they live and
• die with it. Such parts can also be explicitly removed before the death of the
composite.
• This means that, in a composite aggregation, an object may be a part of only
one composite at a time.
• In addition, in a composite aggregation, the whole is responsible for the disposition
of its parts, which means that the composite must manage the creation and
destruction of its parts.

Association Classes:
• In an association between two classes, the association itself might have properties.
• An association class can be seen as an association that also has class properties,
or as a class that also has
• association properties.
• We render an association class as a class symbol attached by a dashed line
to an association

Association Classes
 Constraints:
• UML defines five constraints that may be applied to association relationships.

Specifies that the relationship is not manifest but, rather, is

1 implicit only
conceptual
Specifies that the set of objects at one end of an association are
2 ordered in an
explicit order
3 changeable Links between objects may be added, removed, and changed
freely
New links may be added from an object on the opposite end of
4 addOnly the
association
A link, once added from an object on the opposite end of the
5 frozen association, may not be modified or deleted

implicit

• if you have an association between two base classes, you can specify
that same association between two children of those base classes
• you can specify that the objects at one end of an association (with a multiplicity
greater than one) are ordered or unordered.

ordered
• For example, in a User/Password association, the Passwords associated with the
User might be kept in a least-recently used order, and would be marked as ordered.
• Finally, there is one constraint for managing related sets of associations:

1 xor Specifies that, over a set of associations, exactly one is manfest for each
associated object

Realization

1. Realization is sufficiently different from dependency, generalization, and

association relationships that it is treated as a separate kind of relationship.
2. A realizationis a semantic relationship between classifiers in which one
classifier specifies a contract that another classifier guarantees to carry out.
3. Graphically, a realization is rendered as a dashed directed line with a large
open arrowhead pointing to the classifier that specifies the contract.
4. You'll use realization in two circumstances: in the context of interfaces and
in the context of collaborations
5. Most of the time, you'll use realization to specify the relationship between an
interface and the class or component that provides an operation or service for it
6. You'll also use realization to specify the relationship between a use case and
the collaboration that realizes that use case

Realization of an Interface
 Realization of a Use Case

Common Modeling Techniques:

Modeling Webs of Relationships
• Don't begin in isolation. Apply use cases and scenarios to drive your discovery
of the relationships.
• start by modeling the structural relationships that are present.
• Next, identify opportunities for generalization/specialization relationships; use
multiple inheritance sparingly.
• Only after completing the preceding steps should you look for dependencies;
• For each kind of relationship, start with its basic form and apply advanced
features only as absolutely necessary.
• Remember that it is both undesirable and unnecessary to model all relationships
among a set of abstractions in a single diagram or view.
• Rather, build up your system's relationships by considering different views on
the system. Highlight interesting sets of relationships in individual diagrams.

1.10 OBJECT DIAGRAMS:

• Object diagrams model the instances of things contained in class diagrams. An

object diagram shows a set of objects and their relationships at a point in time.
• We use object diagrams to model the static design view or static process view
of a system. This involves modeling a snapshot of the system at a moment in
time and rendering a set of objects, their state, and their relationships.
• Object diagrams are not only important for visualizing, specifying, and
documenting structural models, but also for constructing the static aspects of
systems through forward and reverse engineering.
• An object diagram covers a set of instances of the things found in a class
diagram. An object diagram,
• therefore, expresses the static part of an interaction, consisting of the objects
that collaborate but without any of the messages passed among them. In both
cases, an object diagram freezes a moment in time.
 An object diagram is a diagram that shows a set of objects and their relationships at
a point in time. Graphically, an object diagram is a collection of vertices and arcs.
Common Properties
An object diagram is a special kind of diagram and shares the same common
properties as all other diagrams that is, a name and graphical contents that are a
projection into a model.
What distinguishes an object diagram from all other kinds of diagrams is its particular
content.
Contents
Object diagrams commonly contain
• Objects
• Links
Like all other diagrams, object diagrams may contain notes and constraints.

1.11 COMMON MODELING TECHNIQUES:

Modeling Object Structures

• When you construct a class diagram, a component diagram, or a deployment
diagram, what we are doing is capturing a set of abstractions that are interesting
to you as a group and, in that context, exposing their semantics and their
relationships to other abstractions in the group.
• If class A has a one-to-many association to class B, then for one instance of A
there might be five instances of B; for another instance of A there might be only
one instance of B. Furthermore, at a given moment in time, that instance of A,
along with the related instances of B, will each have certain values for their
attributes and state machines.
To model an object structure:
Identify the mechanism you'd like to model. A mechanism represents some function
or behavior of the part of the system you are modeling that results from the
interaction of a society of classes, interfaces, and other things.
• Create a collaboration to describe a mechanism.
• For each mechanism, identify the classes, interfaces, and other elements that
participate in this collaboration; identify the relationships among these things as
well.
• Consider one scenario that walks through this mechanism. Freeze that
scenario at a moment in time, and render each object that participates in the
mechanism.
• Expose the state and attribute values of each such object, as necessary, to
understand the scenario.
• Similarly, expose the links among these objects, representing instances of
associations among them.

Figure : Modeling Object Structures

1.12 FORWARD AND REVERSE ENGINEERING:

 Forward engineering is the creation of code from a model.

 Reverse engineering is the creation of a model from code.
To reverse engineer an object diagram

• Chose the target you want to reverse engineer. Typically, you'll set your context
inside an operation or relative to an instance of one particular class.
• Using a tool or simply walking through a scenario, stop execution at a certain
moment in time.
• Identify the set of interesting objects that collaborate in that context and render
them in an object diagram.
• As necessary to understand their semantics, expose these object's states.
• As necessary to understand their semantics, identify the links that exist
among these objects.
• If your diagram ends up overly complicated, prune it by eliminating objects that
are not germane to the questions about the scenario you need answered. If your
diagram is too simplistic, expand the neighbors of certain interesting objects and
expose each object's state more deeply.