Unit 3 :Introdution to UML
Structural Diagrams:
This is a type of diagram that describes the elements of a specification those are Irrespective of time.
These diagrams show the things in a system being modeled.
The structural diagrams are further classified as:
1. Logical diagrams represent the logical structure of the system.
2. Physical diagrams represent the physical structure of the system.
3. Behavioral Diagrams: This is a type of diagram that describes behavioral features of a system or
business process. These diagrams show what should happen in a system. They describe how the objects
interact with each other to create a functioning system.
The behavioral diagrams can be classified as Use Case diagrams, State Machine diagrams and Interaction
diagrams. Interaction diagrams include sequence and collaboration diagrams, whereas state machine
diagrams include state charts and activity diagrams.
To view a system in different perspective, UML included nine different types of diagrams as follows:
1. Class Diagram:
It shows a set of classes, interfaces and collaborations and their relationships. Graphically, a class
diagram is a collection of vertices and arcs. A class diagram addresses the static design view of a system.
2. Object Diagram:
An object diagram shows a set of objects and their relationships at a point in time. Object diagram
represents static snapshots of instances of things found in class diagrams. An object diagram addresses
the static design view of a system.
3.Use Case Diagram:
A use case diagram represents or shows a set of use cases and actors and their relationships. Use case
diagrams address static views of a system.
4. Interaction Diagram:
An interaction diagram shows an interaction of a set of objects and their relationships along with
messages that are shared among them,Interaction diagram address the dynamic view of a system.
5.Collaboration Diagram:
A collaboration diagram is an interaction diagram that focuses on the structural organization of objects
that send and receive messages.
6. State Chart Diagram:
It shows a state machine which includes states, events, transitions and activities. It addresses a dynamic
view of a system.
7.Activity Diagram:
It is a special kind of state chart diagram which shows flow from one activity to another within a system.
Activity diagram addresses dynamic view of a system
8. Component Structure Diagram:
These diagrams explore how objects cooperate to complete a task, document the internal structure of
an object, or graphically describe a design structure or strategy.
9. Deployment Diagrams:
These diagrams show configuration of runtime processing nodes and objects that exist on them.
10. Package Diagrams:
These diagrams describe the high level organization of software packages Package diagrams are used to
divide the model into logical containers, or 'packages' and describe the interactions between them at a
high level
11. Component Diagrams :
Component diagram shows organizations and dependencies among a set of components. Component
diagram addresses static implementation view of a system.
12. Timing Diagrams:
These diagrams combine sequence and state diagrams to provide a view of an object's state over time
and messages which modify that state.
13. Sequence Diagrams:
These diagrams show the time ordering of messages and object lifelines.
A Conceptual model:
A conceptual model in UML can be defined as "a model which is made of concepts and their
relationships".
A conceptual model is the first step before drawing an UML diagram. It helps to understand the entities
in the real world and how they interact with each other.
To model a software intensive system requires learning and understanding three major building blocks.
These building blocks are the part of UML vocabulary.
The building blocks of UML vocabulary:
1. Things/Elements of UML.
2. Relationships.
3. Rules.
Things are the basic elements in a model; while relationship binds these things together, diagrams bind
collection of things.
3.5 THINGS IN UML/ELEMENTS OF UML
Things are the basic building blocks of the UML. We use them to write well-formed models.
Any type of diagram has structure and it also specifies behavior.
In UML, there are four kinds of things i.e. Structural things, Behavioral things, Grouping things and
Annotational things.
3.5.1 Structural Things
Structural things represent a conceptual or physical element. These things are nouns of UML models.
Structural things are the static parts of the model.
(1) Class:
A class is a description of a set of objects that shares the same attributes, operation, relationship and
semantics.
A class implements one or more interfaces.
For example, in Fig. 3.3, a class is represented with a rectangle. The rectangle includes class name,
attributes and operations.
fruit
classname
Taste
attributes
colour
Eat() Show()
operations
Fig. 3.3: Representation of Class
(ii) Interface:
An interface is a collection of operations that specifies a service of a class or component
An interface therefore describes the externally visible behavior of that element.
Interface defines a set of operations which specify the responsibility of a class.
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 sign), but never a set of operation
implementations.
Declaration of interface:
The declaration of an interface looks like a class with the keyword <<interface>> above the name:
attributes are not relevant, except sometimes to show constant.
An interface provided by a class to the outside world is shown as a small circle attached to the class box
by a line.
An interface required by a class from some other class is shown as a small semicircle attached to the
class box by a line, as in Fig. 3.4.
(iii) Collaboration:
Collaboration defines interaction between elements. Collaboration has structural as well as behavioral
dimensions. A given class or object might participate in several collaborations. In Fig. 3.5, collaborations
are displayed as an ellipse with dashed lines. sometimes including only its name.
(iv) Use Case:
Use case represents a set of actions performed by a system for a specific goal.
A use case is a description of sequences of action that a system performs that return 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 collaboration.
Place Order
Graphically, a use case is displayed as an ellipse with solid lines, usually including only its name, as
shown in Fig. 3.6.
Place Order
Fig. 3.6: Representation of Use cases
(v) 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.
(vi) Component:
A component is a modular part of the system design that hides its implementation behind a set of
external interfaces.
Within a system, components sharing the same interfaces can be substituted while preserving the same
logical behavior.
The implementation of a component can be expressed by wiring together parts and connectors. The
parts can include smaller components.
(vii) Artifacts:
The artifacts represent physical things, whereas the previous five things represent conceptual or logical
things.
An artifact is a physical and replaceable part of a system that contains physical information.
In a system, you will face different kinds of deployment artifacts, such as source code files, executable,
script etc.
An artifact typically represents the physical packaging of source or run-time information.
(viii) Node:
A node can be defined as a physical element that exists at run time.
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
3.5.2 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 UML, there are three kinds of behavioral things as given below:
(i) Messages:
Interaction is defined as a behavior that consists of a group of messages exchanged among elements to
accomplish a specific task.
An interaction involves a number of other elements, including messages, actions and connectors.
Graphically, a message is displayed as a directed line, almost always including the name of its operation,
as in Fig. 3.11.
Display
Fig. 3.11: Representation of Messages
(ii) State:
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
The behavior of an individual class or a collaboration of classes may be specified with a state machine.
A state machine involves a number of other elements, including states, transition.
A state is a condition or situation during the life of an object during which it satisfies some condition,
perf some activity, or waits for some event.
(iii) Activity:
It is a behavior that specifies the sequences of steps a computational process performs.
In an interaction, the focus is on the set of objects that interact. In a state machine, the focus is on the
life cycle of one object at a time
In an activity, the focus is on the flows among steps without regard to which object performs each step.
A step of an activity is called an action.
Graphically, an action is displayed as a rounded rectangle with a name indicating its purpose. States and
actions are distinguished by their different contents
3.5.3 Grouping Things
Grouping things are the organizational parts of UML models. These are the boxes into which a model
can be decomposed
Grouping things can be defined as a mechanism to group elements of an UML model together.
(1) Package:
Package is the only one grouping thing available for gathering structural and behavioral things
A package is a general purpose mechanism for organizing the design itself. as opposed to classes which
organize implementation constructs.
Structural things, behavioral things and even other grouping things may be placed in a package.
Graphically, a package is displayed as a tabbed folder, usually including only its name and sometimes its
contents.
3.5.4 Annotational Things
Annotational things are the explanatory parts of UML models.
Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of
UML model elements.
Note is the only one Annotational thing available.
(1) Note:
A note is used to show comments, constraints etc. of an UML element.
A note is simply a symbol for displaying constraints and comments attached to an element or a
collection of elements.
Graphically, a Note is displayed as a rectangle with a dog eared corner together with textual or graphical
comments.
3.6 RELATIONSHIPS IN UML:
Relationship is another most important building block of UML
A relationship is a connection between things. When we model a system, we are supposed to not only
identify the things that form the vocabulary of the system, but we should model how these things are
related to one another.
Relationship shows how elements are associated with each other and this association (linked) describes
the functionality of an application.
There are four kinds of relationships in the UML, Le., Dependency, Association, Generalization and
Realization. These relationships are explained below:
1. Dependency:
Dependency is a semantic relationship. Dependency is a relationship between twe things in which
change in one element also affects the other one.
Dependency states that a change in specification of one thing (independent thing may affect another
thing (depending thing) that uses it, but not the reverse.
Graphically, dependency relationship is represented with a dashed line with an arrow, (See Fig. 3.16).
--------------------
Dependency
Fig. 3.16: Representation of Dependency
For example, in the Fig. 3.17, the FlimClip class is depending on the Channel class. The dependency
relationship is shown using the dashed or dotted line starting from FilmClip class and ending in the
Channel class with an arrow pointing to it.
2 Association:
Association is a structural relationship in which objects are dually dependent.
Association relationship is used when we want to show structural relationship.
Association is basically a set of links that connects elements of an UML model. It also describes how
many objects are taking part in that relationship.
Graphically, association is represented as a solid line. For example, Fig. 3.18 shows linking of objects
Airplane and Passengers.
Types of Association:
There are two types of Association:
1)Aggregation:
It refers to the formation of a particular class as a result of one class being aggregated or built as a
collection.
For example, the class "Library" is made up of one or more books, among other materials.
In aggregation, the contained classes are not strongly dependent on the life cycle of the container.
In the example of Fig. 3.19. Books will remain so even when the Library is dissolved.
To show aggregation graphically in a diagram, draw a line from the parent class to the child class with a
diamond shape near the parent class.
It is very similar to the aggregation relationship, with the only difference being its key purpose of
emphasizing the dependence of the contained class to the life cycle of the container class.
That is, the contained class will be destroyed when the container class is destroyed. For example, House
(parent) and Room (child). Room doesn't exist separate from the House
To describe a composition relationship in an UML diagram, use a directional line connecting the two
classes, with a filled diamond shape (See Fig. 3.20), adjacent to the container class and the directional
arrow to the contained class.
3. Generalization:
A generalization is a relationship between a general thing ie. super class or parent class and a specific
thing Le. subclass or child class. It is similar to the concept of inheritance in OOPs.
Generalization can be defined as "a relationship which connects a specialized element with a
generalized element."
It basically describes inheritance relationships in the world of objects.
It is also known as an "is a" relationship since the child class is a type of the parent class.
Generalization is the ideal type of relationship that is used to showcase reusable elements in the class
diagram. Literally, the child classes "inherit" the common functionality defined in the parent class.
Graphically, generalization relationship is shown as a solid line with a hollow arrowhead pointing
towards the parent as shown in Fig. 3.21.
Generalization
Fig. 3.21: Representation of Generalization
Fig. 3.22 shows an example of generalization.
Fig. 3.22: Example of Generalization
4. Realization:
It is a semantic relationship between classifiers, wherein one classifier specifies a contract that another
classifier guarantees to carry out.
----------------------------------
Fig. 3.23: Representation of Realization
Realization can be defined as 'a relationship in which two elements are connected".
One element describes some responsibility which is not Implemented and the other one implements
them. This relationship exists in the case of interfaces.
Graphically, a realization relationship is displayed as a cross between a generalization and a dependency
relationship
For example. In the Fig 324, printing preferences that are set using the Printer setup interface are being
implemented by the Printer.
Fig. 3.24: Example of Realization
1. Multiplicity:
It is the active logical association when the cardinality of a class in relation to another is being depicted.
It is also called Cardinality
For example, one fleet may include multiple airplanes.
while one commercial airplane may contain zero to many passengers. The notation 0.. in the disgram
means "zero to many",
Fig. 3.25 Example of Multiplicity
3.7 RULES OF 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 syntactic and semantic rules for
1. Names
What can you call things, relationships and diagrams?
2. Scope
The context that gives specific meaning to a name.
3.Visibility:
How can those names be seen and used by others?
4. Integrity:
How things properly and consistently related to one another?
5. Execution:
What does it mean 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
Omitted:Certain elements are hidden to simplify the view
Incomplete:Certain elements may be missing.
Inconsistent:The integrity of the model is not guaranteed.
3.8 UML ARCHITECTURE
Any real-world system is used by different users like developers, testers, business people, analysts and
many more. So before designing a system the architecture made with different perspectives in mind.
The most important part is to visualize the system from a different reviewers perspective. The better we
understand the better we make the system.
UML plays an important role in defining different perspectives of a system. Thes perspectives are
Logical/Design, Implementation, Process and Deployment and Die Case View.
Class, Object Package Composite State Machine
Use Case View Use case, Activity
1. The Use Case View of a system includes the use cases that describe the behavior of the system as
seen by its end users, analysts and testers.
This view does not really specify the organization of a software system. Rather, it exists to specify the
forces that shape the system's architecture.
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 diagrams and activity diagrams.
2. The Logical/Design View of a system includes 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 UMI, 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, state diagrams and activity diagrams. The internal
structure diagram of a class is particularly useful.
3. The Process/Interaction View of a system shows the flow of control among its various parts, including
possible concurrency and synchronization mechanisms This view primarily addresses the performance,
scalability and throughput of the system. With the UML, the static and dynamic features 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
control the system and the messages that flow between them.
4. The Implementation View of a system includes the artifacts 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 files that can be assembled in various ways to produce a running
system. It is also concerned with the mapping from logical classes and components to physical artifacts.
With the UMI, the static aspects of this view are captured in artifact diagrams, the dynamic aspects of
this view are captured in Interaction diagrams, state diagrams and activity diagrams.
5. The Deployment View of a system includes 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
interaction diagrams, state diagrams and activity diagrams.
3.9 ADVANTAGES OF UML
Various advantages of UML are listed below:
1. It is a formal language: Each element has a strongly defined meaning. When we model a system, we
can model with confidence that the designed model is understood by everyone.
2. It is concise: The entire language is made up of simple and straightforward notation.
3. It is comprehensive: it describes all important aspects of a system.
4. It is scalable: Wherever needed, the language is formal enough to handle massive system modeling
projects, but it also scales low to small projects, avoiding overload.
5. It is built on lessons learned: UMI. is the result of best practices in object-oriented communities over
the past few years.
6. It is standard: UML is controlled by an open standard group with active contributions from a world-
wide group of vendors and academics.
7. Mostly used: It is the most useful method of visualization and documenting software system design.
8. It is independent: It uses object-oriented design concepts and it is independent of programming
language.
3.10 Disadvantages of UMI
1. Lack of formality: UML has still no structure and specification for modeling uses Interfaces. UNL does
not define a standard file format.
2. Time: Some developers might find when using UML is the time it takes to manage and maintain UML
diagrams to work property. UML diagrams must be synchronized with the software code, which requires
time to set up and maintain and adds work to a software development project
3. Diagrams can get ever complicated. When creating an UML diagram le conjunction with software
development, the diagram might become even complicated, which can be confusing and frustrating for
developers.
4. Too much importance on design: UNI places much importance on design, which can be problematized
for some developers and companies
5. Synchronizing cede with models is difficult: Using multiple models/diagrams makes it difficult to keep
them consistent with each other and much code has to be added by hand.
