lOMoARcPSD|24075426

UNIT-2
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. Case Study: Control System: Traffic Management.

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.

1
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

1.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.
2.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.
3.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.
4.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:

2
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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.

1.3.principles of modelling:

UML is basically a modeling language; hence its principles will also be related to
modeling concepts. Here are few basic principal of UML.

First: "The choice of what models to create has a profound influence on how a
problem is attacked and how a solution is shaped"

In other words , choose your models well. The right models will brilliantly illuminate the
most wicked development problems. The wrong models will mislead you, causing you to
focus on irrelevant issues.
Second: " Every model may be expressed at different levels of precision ".

Best approach to a given problem results in a best model. If the problem is complex
mechanized level of approach & if the problem is simple decent approach is followed.

Third: "The best models are connected to reality."

The model built should have strong resemblance with the system.

Fourth: " No single model is sufficient. Every nontrivial system is best approached
through a small set of nearly independent models."

• If you constructing a building, there is no single set of blueprints that reveal all its details.
At the very least, you will need floor plans, elevations , electical plans, heating plans, and
plumbing plans.

1.4.object oriented modelling:

In software , there are several ways to approaches a model. The two most common
ways are
1. Algorithmic perspective
2. Object-Oriented perspective
1. Algorithmic perspective:
3
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

In this approach, the main building blocks of all software is the procedure or function .This
view leads developers to focus on issues of control and decomposition of larger
algorithms into smaller ones.
2.Object-Oriented perspective:
In this approach, the main building blocks of all software is the object or class. Simply
put, an object is a thing. A class is a description of a set of common objects. Every object has
identity, state and behavior.
For example, consider a simple a three-tier -architecture for a billing system, involving a user
interface ,middleware, and a data base. In the user interface, you will find concrete objects, such
as buttons, menus, and dialog boxes. In the database, you will find concrete objects ,such as
tables. In the middle layer ,you will find objects such as transitions and business rules.

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.

4
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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.
5
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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

3.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
6
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

an ellipse with dashed lines, sometimes including only its name.

4.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.
5.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.
6.Component:
• A component is a physical and replaceable part of a system that conforms to and
provides the realization of a set of interfaces.

7.Node:

A physical element that exists at run time.

2. 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.
1.Interaction − Interaction is defined as a behavior that consists of a group of
7
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

messages exchanged among elements to accomplish a specific task.

Graphically, a message is rendered as a directed line.

2.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.
Business rules
Structural things, behavioral things and even other grouping
things that may be placed in a package.
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.

8
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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

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

Generalization

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.2 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).
9
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

 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:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Activity diagram
7. Statechart diagram
8. Component diagram
9. 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.
10
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

• Interaction diagrams address the dynamic view of a system.

• A sequence diagram is an interaction diagram that emphasizes the time-
ordering of messages
5.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.
6.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.
7.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

8.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.
9.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.

11
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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 you but do not force you to 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

12
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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.
1.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
2.Class vs. object
• Most UML building blocks have this kind of class/object distinction.

13
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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

14
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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 Event Queue 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
15
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

• Design View
• Process View
• Implementation View
• Deployment View

The center 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.

16
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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.

17
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

1.8.Basic 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
18
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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.

Name
Window
Origin
Attributes
Size
class
Open( )
Close( ) Operation
Move( )
Display( )

19
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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.

20
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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.

21
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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.

22
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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.

23
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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

24
Downloaded by satya vara vinod Ungarala ([email protected])
 lOMoARcPSD|24075426

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.
25
Downloaded by satya vara vinod Ungarala ([email protected])