Unit IV

Unified Modelling Language (UML)

Object-Oriented Concepts:

• UML can be described as the successor of object-oriented (OO) analysis and design.

• An object contains both data and methods that control the data.

• The data represents the state of the object.

• A class describes an object and they also form a hierarchy to model the real-world system.

• The hierarchy is represented as inheritance and the classes can also be associated in different
ways as per the requirement.

• Objects are the real-world entities that exist around us and the basic concepts such as
abstraction, encapsulation, inheritance, and polymorphism all can be represented using UML.

• UML is powerful used to represent all the concepts that exist in object-oriented analysis and
design.

• UML diagrams are representation of object-oriented concepts only.

• Following are some fundamental concepts of the object-oriented world −

• Objects − Objects represent an entity and the basic building block.

• Class − Class is the blue print of an object.

• Abstraction − Abstraction represents the behavior of an real world entity.

• Encapsulation − Encapsulation is the mechanism of binding the data together and hiding them
from the outside world.

• Inheritance − Inheritance is the mechanism of making new classes from existing ones.

• Polymorphism − It defines the mechanism to exists in different forms

Unified Modeling Language:

• 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 Modeling 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.

• UML is not a programming language but tools can be used to generate code in various languages
using UML diagrams.

• UML has a direct relation with object oriented analysis and design.

• After some standardization, UML has become an OMG standard.

UML View:

• There are five different views that the UML aims to visualize through different modeling
diagrams. These five views are:

1. User's View

2. Structural Views

3. Behavioral Views

4. Environmental View

5. Implementation View

1) User's view

• This contains the diagrams in which the user's part of interaction with the software is defined.

• No internal working of the software is defined in this model.

• The diagrams contained in this view is: Use case Diagram

2) Structural view
 • In the structural view, only the structure of the model is explained.

• This gives an estimate of what the software consists of.

• However, internal working is still not defined in this model.

• The diagram that this view includes are: Class Diagrams, Object Diagrams

3) Behavioral view

• The behavioral view contains the diagrams which explain the behavior of the software.

• These diagrams are: Sequence Diagram, Collaboration Diagram, State chart Diagram, Activity
Diagram

4) Environmental view

• The environmental view contains the diagram which explains the after deployment behavior of
the software model.

• This diagram usually explains the user interactions and software effects on the system.

• The diagrams that the environmental model contain is: Deployment diagram

5) Implementation view

• The implementation view consists of the diagrams which represent the implementation part of
the software.

• This view is related to the developer’s views.

• This is the only view in which the internal workflow of the software is defined.

• The diagram that this view contains is :Component Diagram

Basic Structures and Modeling classes:

• Structural things define the static part of the model. They represent the physical and conceptual
elements. Following are the brief descriptions of the structural things.

• Class − Class represents a set of objects having similar responsibilities.

• Interface − Interface defines a set of operations, which specify the responsibility of a class.
 • Collaboration −Collaboration defines an interaction between elements.

• Use case −Use case represents a set of actions performed by a system for a specific goal.

• Component −Component describes the physical part of a system.

• Node − A node can be defined as a physical element that exists at run time

Basic Structures and Modeling classes:

• A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral
things −

• Interaction − Interaction is defined as a behavior that consists of a group of messages

exchanged among elements to accomplish a specific task.

• 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

 Common Modeling Techniques:

There are three important types of UML modeling.

1. Structural Modeling

• Structural modeling captures the static features of a system.

• They consist of the following −

 Classes diagrams

 Objects diagrams

 Deployment diagrams

 Package diagrams

 Composite structure diagram

• Structural model represents the framework for the system and this framework is the place
where all other components exist.

• Hence, the class diagram, component diagram and deployment diagrams are part of structural
modeling.

• They all represent the elements and the mechanism to assemble them.

• The structural model never describes the dynamic behavior of the system.

• Class diagram is the most widely used structural diagram.

2. Behavioral Modeling

• Behavioral model describes the interaction in the system.

• It represents the interaction among the structural diagrams.

• Behavioral modeling shows the dynamic nature of the system.

• They consist of the following −

 Activity diagrams

 Interaction diagrams
  Use case diagrams

• All the above show the dynamic sequence of flow in a system.

3. Architectural Modeling

• Architectural model represents the overall framework of the system.

• It contains both structural and behavioral elements of the system.

• Architectural model can be defined as the blueprint of the entire system.

• Package diagram comes under architectural modeling.

Relationship:

• Relationship is another most important building block of UML.

• It shows how the elements are associated with each other and this association describes the
functionality of an application.

• There are four kinds of relationships available.

1. Dependency

• Dependency is a relationship between two things in which change in one element also affects
the other.

2. Association

• Association is basically a set of links that connects the elements of a UML model.

• It also describes how many objects are taking part in that relationship.

3. Generalization

• Generalization can be defined as a relationship which connects a specialized element with a

generalized element.

• It basically describes the inheritance relationship in the world of objects.

4. 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 case of interfaces.

Common Mechanisms:

• UML has four common mechanisms −

1. Specifications

2. Adornments

3. Common Divisions

4. Extensibility Mechanisms

1. Specifications

• In UML, behind each graphical notation, there is a textual statement denoting the syntax and
semantics.

• These are the specifications.

• The specifications provide a semantic backplane that contains all the parts of a system and the
relationship among the different paths.

2. Adornments

• Each element in UML has a unique graphical notation.

• Besides, there are notations to represent the important aspects of an element like name, scope,
visibility, etc.

3. Common Divisions

• Object-oriented systems can be divided in many ways.

 • The two common ways of division are

a) Division of classes and objects :

b) A class is an abstraction of a group of similar objects.

c) An object is the concrete instance that has actual existence in the system.

d) Division of Interface and Implementation

e) An interface defines the rules for interaction.

f) Implementation is the concrete realization of the rules defined in the interface.

4. Extensibility Mechanisms

• UML is an open-ended language.

• It is possible to extend the capabilities of UML in a controlled manner to suit the requirements
of a system.

• The extensibility mechanisms are −

 Stereotypes − It extends the vocabulary of the UML, through which new building blocks
can be created out of existing ones.

 Tagged Values − It extends the properties of UML building blocks.

 Constraints − It extends the semantics of UML building blocks

Advanced Structured Modeling:

Classifiers:

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

• In general, the modeling elements that can have instances are called classifiers

• Class, Instance, Component, Node, Use case, Subsystem are classifiers

 • Class: A set of attributes, operations, relationships and semantics

• Use case: Set of a sequence of actions, including variants, that a system performs that yields an
observable result or value to a particular actor

• Datatype: A type whose values have no identity, including primitive built-in types (such as
numbers anti strings), as well as enumeration types (such as Boolean)

• Component: 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 and that represents a computational resource,
generally having at least some memory anti often processing capability

• Subsystem: Grouping of elements of which some constitute a specification of the behavior

offered by the other contained elements

Visibility:

• Public [+]: All outside classifiers that have visibility to the given classifier, can use this feature

• Protected [#]: All descendants of the classifier can use the feature

• Private [-]: The classifier alone can use the feature

 • Scope:

• The owner scope of a feature specifies whether the feature appears in each instance of the
classifier or whether there is just a single instance of feature for all instances of the classifier.

• Instance: Each instance holds its own value

• Classifier: Just one value for all instances (static)

• Multiplicity:

The number of instances a class may have is called multiplicity

Dependency:

• Specifying a change in the specification of one thing may affect another thing, but not
necessarily the reverse

• Graphically rendered as a dashed line

• There are eight stereotypes that apply to dependency relationships among classes and objects
in class diagrams

• Bind: The source instantiates the target template

• Derive:The source may be computed from target

• Friend:The source is given special visibility into target

• instanceOf :Source object is an instance of the target classifier

• Instantiate:Source object creates instance of the target

• Powertype :Target is a powertype of the source
• Refine:Source is at a finer degree of abstraction than target
• Use:The semantics of the source element depends on the semantics of the public part of the
target

Advanced Relationship:
Two stereotypes that apply to dependency relationships among packages

• Access - Source package is granted the right to reference the elements of the target package

• Import - A kind of access, but only public content

Two stereotypes that apply to dependency relationships among use case

• Extend - Target use case extends the behavior of source

• Include - Source use case explicitly incorporates the behavior of another use case at a location
specified by the source

Three stereotypes when modeling interactions among objects

• Become - Target is the same object of source at later time

• Call - Source operation invokes the target operation

In the context of state machine

• Send - Source operation sends the target event

• In the context of organizing the elements of your system into subsystem and model

• Trace - Target is a historical ancestor of the source (model relationship among elements in
different models)

Generalization

• A generalization is a relationship between a general thing and a more specific kind of that thing

• In multiple Inheritance one class may have more than one parent

• Complete: Means that all children in the generalization have been indicated in the model and
that no additional children are permitted

• Incomplete: Means that all children of the generalization may not have been included and new
ones can be added later

• Disjoint: Depicts that objects of the parent do not overlap, i.e., they belong to only one child
class

• Overlapping: Indicates that objects of the parent may have more than one of the children as a
type
• Association

• Advanced adornments: Navigation, Qualification, Various flavors of aggregation

• Navigation: Adorning an association with an arrowhead pointing to the direction of traversal

• Visibility: Objects at that end are not accessible to any objects outside the association

• Qualification: This is an attribute whose values partition the set of objects related to an object
across an association.
 • Composition: A form of an aggregation with strong ownership and coincident lifetime of the
parts by the whole

Constraints:

• Implicit: The relationship is not obvious and may be conceptual

• Ordered: The set of objects at one end of an association are in a piece of order

• Changeable: The links among the objects may be altered

• AddOnly: New links may be included from an object on the opposite end of the association

• Frozen: An existing link may not be deleted or modified

• XOR: Over a set of relationships, exactly one is apparent for each associated object

Realization

• A realization is a semantic relationship between classifiers in which one classifier specifies a

contract that another classifier guarantees to carry out
--Used in two circumstances

• In the context of interfaces

• In the context of collaborations

• --Graphically rendered as dashed directed line with a large open arrowhead

Interface, Types and Roles:

• An Interface is a collection of operations that are used to specify a service of a class or a

component.

• Graphically, an interface is represented as a circle

• A type is a stereotype of a class used to specify a domain of objects, together with the
operations (but not the methods) applicable to the object.

• To distinguish a type from an interface or a class, prepend a ‘T’ to every type.

• Stereotype type is used to formally model the semantics of an abstraction and its conformance
to a specific interface.

• A role is the behavior of an entity participating in a particular context.

• A role is the face that an abstraction presents to the world

Class Diagram:

• Class diagram is a static diagram.

• It represents the static view of an application.

• Class diagram is not only used for visualizing, describing, and documenting different aspects of a
system but also for constructing executable code of the software application.

• Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system.

• The class diagrams are widely used in the modeling of object oriented systems because they are
the only UML diagrams, which can be mapped directly with object-oriented languages.

• Class diagram shows a collection of classes, interfaces, associations, collaborations, and

constraints. It is also known as a structural diagram.

Purpose of Class Diagrams

 • Analysis and design of the static view of an application.

• Describe responsibilities of a system.

• Base for component and deployment diagrams.

The following diagram is an example of an Order System of an application

• First of all, Order and Customer are identified as the two elements of the system. They have a
one-to-many relationship because a customer can have multiple orders.

• Order class is an abstract class and it has two concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.

• The two inherited classes have all the properties as the Order class. In addition, they have
additional functions like dispatch () and receive ().

Where to Use Class Diagrams?

• Describing the static view of the system.

• Showing the collaboration among the elements of the static view.

• Describing the functionalities performed by the system.

• Construction of software applications using object oriented languages.

Object Diagram:
 • Object diagrams are derived from class diagrams so object diagrams are dependent upon class
diagrams.

• Object diagrams represent an instance of a class diagram.

• The basic concepts are similar for class diagrams and object diagrams.

• Object diagrams also represent the static view of a system but this static view is a snapshot of
the system at a particular moment.

• Object diagrams are used to render a set of objects and their relationships as an instance.

Purpose of Object Diagrams

• Object relationships of a system

• Static view of an interaction.

• Understand object behaviour and their relationship from practical perspective

How to Draw an Object Diagram?

• First, analyze the system and decide which instances have important data and association.

• Second, consider only those instances, which will cover the functionality.

• Third, make some optimization as the number of instances are unlimited.

• Before drawing an object diagram, the following things should be remembered and
understood clearly −

• Object diagrams consist of objects.

• The link in object diagram is used to connect objects.

• Objects and links are the two elements used to construct an object diagram.

• After this, the following things are to be decided before starting the construction of the
diagram −

• The object diagram should have a meaningful name to indicate its purpose.

• The most important elements are to be identified.

• The association among objects should be clarified.

• Values of different elements need to be captured to include in the object diagram.

• Add proper notes at points where more clarity is required.

 • The following diagram is an example of an object diagram. It represents the Order management
system which we have discussed in the chapter Class Diagram. The following diagram is an
instance of the system at a particular time of purchase. It has the following objects.

• Customer

• Order

• SpecialOrder

• NormalOrder

• Now the customer object (C) is associated with three order objects (O1, O2, and O3). These
order objects are associated with special order and normal order objects (S1, S2, and N1). The
customer has the following three orders with different numbers (12, 32 and 40) for the
particular time considered.

• The customer can increase the number of orders in future and in that scenario the object
diagram will reflect that. If order, special order, and normal order objects are observed then you
will find that they have some values.

• For orders, the values are 12, 32, and 40 which implies that the objects have these values for a
particular moment (here the particular time when the purchase is made is considered as the
moment) when the instance is captured

• The same is true for special order and normal order objects which have number of orders as 20,
30, and 60. If a different time of purchase is considered, then these values will change
accordingly.

• The following object diagram has been drawn considering all the points mentioned above

Where to Use Object Diagrams?

• Making the prototype of a system.

 • Reverse engineering.

• Modeling complex data structures.

• Understanding the system from practical perspective.

Component diagram:

• Component diagrams are different in terms of nature and behavior.

• Component diagrams are used to model the physical aspects of a system.

• Now the question is, what are these physical aspects? Physical aspects are the elements such as
executables, libraries, files, documents, etc. which reside in a node.

• Component diagrams are used to visualize the organization and relationships among
components in a system.

• These diagrams are also used to make executable systems.

• Component diagrams can also be described as a static implementation view of a system. Static
implementation represents the organization of the components at a particular moment.

• A single component diagram cannot represent the entire system but a collection of diagrams is
used to represent the whole.

Purpose of Component Diagrams

• Visualize the components of a system.

• Construct executables by using forward and reverse engineering.

• Describe the organization and relationships of the components.

How to Draw a Component Diagram?

• Component diagrams are used to describe the physical artifacts of a system. This artifact
includes files, executables, libraries, etc

• The purpose of this diagram is different. Component diagrams are used during the
implementation phase of an application. However, it is prepared well in advance to visualize the
implementation details.

• Initially, the system is designed using different UML diagrams and then when the artifacts are
ready, component diagrams are used to get an idea of the implementation.
• This diagram is very important as without it the application cannot be implemented efficiently. A
well-prepared component diagram is also important for other aspects such as application
performance, maintenance, etc.

• Before drawing a component diagram, the following artifacts are to be identified clearly −

• Files used in the system.

• Libraries and other artifacts relevant to the application.

• Relationships among the artifacts. Following is a component diagram for order management
system. Here, the artifacts are files. The diagram shows the files in the application and their
relationships. In actual, the component diagram also contains dlls, libraries, folders, etc.

• In the following diagram, four files are identified and their relationships are produced.
Component diagram cannot be matched directly with other UML diagrams discussed so far as it
is drawn for completely different purpose.

• The following component diagram has been drawn considering all the points mentioned
above

• After identifying the artifacts, the following points need to be kept in mind.

• Use a meaningful name to identify the component for which the diagram is to be drawn.

• Prepare a mental layout before producing the using tools.

• Use notes for clarifying important points.

Where to Use Component Diagrams?

• Model the components of a system.

 • Model the database schema.

• Model the executables of an application.

• Model the system's source code.

Use case Diagram:

• Dynamic behavior means the behavior of the system when it is running/operating.

• Only static behavior is not sufficient to model a system rather dynamic behavior is more
important than static behavior.

• In UML, there are five diagrams available to model the dynamic nature and use case diagram is
one of them.

• Now as we have to discuss that the use case diagram is dynamic in nature, there should be
some internal or external factors for making the interaction.

• These internal and external agents are known as actors.

• Use case diagrams consists of actors, use cases and their relationships. The diagram is used to
model the system/subsystem of an application.

• A single use case diagram captures a particular functionality of a system.

• Hence to model the entire system, a number of use case diagrams are used.

Purpose of Use Case Diagrams

• The purpose of use case diagram is to capture the dynamic aspect of a system.

• Used to gather the requirements of a system.

• Used to get an outside view of a system.

• Identify the external and internal factors influencing the system.

• Show the interaction among the requirements are actors.

How to Draw a Use Case Diagram?

• Use case diagrams are considered for high level requirement analysis of a system.

• When the requirements of a system are analyzed, the functionalities are captured in use cases.

• We can say that use cases are nothing but the system functionalities written in an organized
manner.
• The second thing which is relevant to use cases are the actors.

• Actors can be defined as something that interacts with the system.

• Actors can be a human user, some internal applications, or may be some external applications.

• When we are planning to draw a use case diagram, we should have the following items
identified.

Functionalities to be represented as use case

Actors

Relationships among the use cases and actors.

• Use case diagrams are drawn to capture the functional requirements of a system. After
identifying the above items, we have to use the following guidelines to draw an efficient use
case diagram

1. The name of a use case is very important. The name should be chosen in such a way so that it can
identify the functionalities performed.

2. Give a suitable name for actors.

3. Show relationships and dependencies clearly in the diagram.

4. Do not try to include all types of relationships, as the main purpose of the diagram is to identify
the requirements.

5. Use notes whenever required to clarify some important points.

• Following is a sample use case diagram representing the order management system.
• Hence, if we look into the diagram then we will find three use cases (Order, SpecialOrder, and
NormalOrder) and one actor which is the customer.

• The SpecialOrder and NormalOrder use cases are extended from Order use case. Hence, they
have extended relationship. Another important point is to identify the system boundary, which
is shown in the picture. The actor Customer lies outside the system as it is an external user of
the system.

• Where to Use a Use Case Diagram?

• Requirement analysis and high level design.

• Model the context of a system.

• Reverse engineering.

• Forward engineering.