UML Diagram

Bipin Dhakal
 What is UML?
UML stands for “Unified Modeling Language”

Unified: UML has become a world standard. UML was adopted as a

standard by Object Management Group(OMG).

Modeling: Describing a software system at a high level of abstraction.

Language: Express idea, not a methodology.

UML is a way to visually represent the architecture, design, and
implementation of complex software systems.

It is a industry-standard graphical language for specifying,

visualizing, constructing, and documenting the artifacts of software
systems.

The UML uses mostly graphical notations to express the OO analysis

and design of software projects.

Simplifies the complex process of software design.

 Why we use UML?
Use graphical notation: more clearly than natural language and code.

Help acquire an overall view of a system.

UML is not dependent on any one language or technology.

UML moves us from fragmentation to standardization.

When you’re writing code, there are thousands of lines in an application,

and it’s difficult to keep track of the relationships and hierarchies within a
software system. UML diagrams divide that software system into
components and subcomponents.
 Types of UML Diagrams
Behavioral
Structural : behavioral features of a system / business process
: element of spec. irrespective of time
• Activity
•Class • State machine
• Use case
•Component
• Interaction
•Deployment
•Object
•Composite structure
Interaction
: emphasize object interaction
•Package
• Communication
• Sequence
• Interaction overview
• Timing
 Class Diagram
 Used for describing structure and behavior in the use cases.

 Show the static structure of a system, including classes, their

attributes and behaviors, and the relationships between each class.

 Used for requirement capture, end-user interaction.

 Detailed class diagrams are used for developers.

 Class representation
 Each class is represented by a rectangle subdivided into three
compartments
• Name –at the top
• Attributes –in the middle
• Operations/methods –at the bottom
 Modifiers are used to indicate visibility of attributes and operations.
• ‘+’ is used to denote Public visibility (everyone)
• ‘#’ is used to denote Protected visibility (friends and derived)
• ‘-’ is used to denote Private visibility (no one)
 By default, attributes are hidden and operations are visible.
 Relationship that exists between class
 Inheritance
 Association
 Aggregation
 Composition
 Multiplicity
 Object Diagram
 Object Diagram sometimes referred to as Instance diagrams are very
similar to class diagram. Like class diagrams, they also show the
relationship between objects but they use real-world examples.
 Object is an instance of a class in a particular moment in runtime that
can have its own state and data values.
 They show how a system will look like at a given time. Because there
is data available in the objects, they are used to explain complex
relationships between objects.
 An object diagram focuses on the attributes of a set of objects and
how those objects relate to each other.
 Component Diagram

 A component diagram are used to visualize the organization of

system components and the dependency relationships between them or
say it displays the structural relationship of components of a software
system.
 These are mostly used when working with complex systems with
many components.
 Components communicate with each other using interfaces. The
interfaces are linked using connectors.
 The components can be a software component such as a database or
the interface; or a hardware component such as a circuit, microchip or
devices; or a business unit such as supplier, payroll or shipping.
 Component Diagram Symbol
Rectangle with the component stereo type (the text
1. <<Component>>
<<Component>>). The Component Stereo type is usually used
(Name of Component) above the component name to avoid confusing the shape with
class icon.

Rectangle with the component icon in the top right corner and
2. the name of the Component.
(Name of Component)

Rectangle with the component icon in the component stereo

3. <<Component>> type.
 Provided Interface & Required Interface
 Interface in component diagrams shows how components are wired
together and interacts with each other.
The assembly connector allows linking the components required
interface (represented with semi-circle and a solid line) with provided
interface (represented with a circle and solid line) of another
component.
This shows that the one component is providing the service that other
required.
 Dependencies
 Although we can show more detail about the relationship between
two components using the ball and socket notation (provided interface
and required interface), we can just as well use a dependency arrow to
show the relationship between two components.
 Use Case Diagram
 Use case diagram give a graphic overview of the actors involved in a
system, different functions needed by those actors and how these
different functions interact.
 Used for describing a set of user scenarios.
 Mainly used for capturing user requirements.
 Work like a contract between end user and software developers.
 Use case diagram will specify the events in a system and how those
events flows, however, use case diagram does not describe how these
events are implemented.
 Use Case Diagram (Core Components)
A use case diagram contains four components.
 The boundary/system, which defines the system of interest in
relation to the world around it.
 The actors, usually individuals involved with the system defined
according to their roles.
 The use cases, which are the specific roles played by the actors
within and around the system.
 The relationships between and among the actors and the use cases.
 Use Case Diagram (Core Components)
System/Boundary:
 The system boundary is potentially the entire system. It could be
website, a s/w component, a business process or other thing.
 We represent a system with a rectangle.
 We put the name of the system at the top.
Actors:
 The users(someone or something) that interact with a system/ use our system to
achieve a goal. An actor can be a person, an organization, or an outside system
that interacts with your application or system.
 They must be external objects that produce or consume data.
 We represent actor with stick figure.
 Use Case Diagram (Core Components) Continue…
Use case:
 A set of scenarios that describing an interaction between a user and a
system, including alternatives.
 This is where you really start to describe what your system does.
 It represent an action that accomplishes some sort of task with in the
system.
 They are placed within the rectangle because they are actions that
occurs within the system.
 We represent use case with oval shape.
 Use Case Diagram(core relationship)
1. Association
2. Generalization

Association:
We draw a solid line between the actor and the use case to show their
relationship. This type of relationship is called an association.
 Communication between an actor and a use case.
 Represented by a solid line.
Include:
 An include relationship shows dependency between a base case and an
included use case.
 A dotted line labeled <<include>> beginning at base use case and ending
with an arrows pointing to the include use case.
 Every time the base case is executed, the included use case is executed as
well.
 The base use case requires an included use case in order to be executed.
 When we have an include relationship, we draw a dashed line with an arrow
that points towards the include use case.
Extend:
 An extend relationship has a base use case and an extend use case.
 A dotted line labeled <<extend>> with an arrow toward the base case.
 The extend use case will only happen if certain criteria are met.
 When the base use case is executed, the extended use case will happen
sometimes but not every time.
 Include happens every time but extend happens some times.
Generalization:
 Relationship between one general use case and a special use case (used for defining
special alternatives).
- General Use Case (Parent)
- Specialized Use Case (Child)
 Represented by a line with a triangular arrow head toward the parent use case.
 The child use case is an enhancement of the parent use case.
 Activity Diagram
 An activity diagram is a behavioral diagram i.e. it depicts the
behavior of a system.
 Demonstrate the logic of an algorithm.
 Describe the steps performed in ULM Use Case.
 An activity diagram portrays the control flow from a start point to a
finish point showing the various decision paths that exist while the
activity is being executed.
 Components of Activity Diagram
 Start node:
-Symbolizes the beginning of the process or workflow.
-The start node is represented by a black circle.

 Action/Activity:
- A step in the activity wherein the users or software perform a given task.
- Indicates the activities that makeup a modeled process.
- Actions are symbolized with round-edged rectangles.

 Decision node:
- When we need to make a decision before deciding the flow of control, we use
- Represents a decision and always has a single input
and at least two paths branching out with condition
text to allow user to view options.

 Control/Action flows:
-Refered to as paths and edges.
-They are use to show the direction/control flow from one activity state to
another.

 End node:
-Represents the final step in the activity.
-The end node is represented by an outlined black circle.
 Sequence Diagram
 A sequence diagram is a type of interaction diagram because it
describes how—and in what order—a group of objects works together.
 Sequence Diagrams are interaction diagrams that detail how
operations are carried out.
 Sequence Diagrams are time focus and they show the order of the
interaction visually by using the vertical axis of the diagram to
represent time what messages are sent and when.
 Particularly, this algorithm shows interaction in the order they take
place. Shows the sequence of events.
 Components of Sequence Diagram
 Actor:
-Shows entities that interact with or are external to the system.

 Object Symbol:
-Represents a class or object in UML . The object symbol
demonstrates how an object will behave in the context of the class.

 Activation Box:
-Represents the time needed for an object to complete
a task. The longer the task will take, the longer the
activation box becomes.
 Components of Sequence Diagram Continue…
 Lifeline Symbol:
-Represents the passage of time as it extends downward. The
dashed vertical line shows the sequential events that occurs to
an object during the process. Lifeline may begins with a labeled
rectangle shape or an actor symbol.

 Call Message:
- A message defines a particular communication between lifelines
of an interaction.
- Call message is a kind of message that represents an invocation
of operation of target lifeline.
 Components of Sequence Diagram Continue…
 Self Message:
- Self message is a kind of message that represents the invocation
of message of the same lifeline.
 Entity Relationship Diagram (ERD)
 ERD is a visual representation that illustrates how “entities” such as people,
objects or concepts related to each other within a system.
 They are most often used to design or debug relational databases in the
fields of software engineering, business information systems, education and
research.
 Also known as Entity Relationship Model, used for designing in database.
 It is based on perception of real word that consists of s collection of objects
called entities and of relationship among these objects.
 ER Models use a defined set of symbols such as rectangles, diamonds, ovals
and connecting lines to represent the interconnectedness of entities,
relationships and their attributes.
 Relationship between Entities
The association among several entities is known as relationship. It
defines the relationship between the entities. There are mainly three
types of relationship which can exist between two different entities:

 One to One :
The relationship takes place when a single occurrence of an entity is
related to just one occurrence of a second entity is called one to one
relationship. Example: one member has only one member log and one
member log represent only one member.
 One to Many :
The relationship takes place when a single occurrence of an entity is
related to many occurrences of a second entity is called one to many
relationships. Example: one branch can have many members.

Many to Many:
The relationship takes place when multiple occurrences of an entity are
related to multiple occurrences of a second entity is called many to
many relationships. Example: customers can purchase various products,
and products can be purchased by many customers.
 ER Diagram Symbols
• An Entity Relationship Diagram is composed of different components and each
component in ER diagram is represented using a specific symbol. Some ER
diagram symbols are discussed below:
 Data Flow Diagram (DFD)
 A data flow diagram is a way of representing a flow of data through a
process or a system.
 The DFD also provides information about the outputs and inputs of
each entity and the process itself.
 It is developed during analysis phase.
 Major Symbols of DFD
1. External Entity:
 It supplies data to or receive data from the system.
 Label should be noun phrase.
source - supplies data to
sink - receive data from

2. Process:
 An activity that performs some action on data.
 Label should be verb phrase.
OR
3. Data Flow:
 Depicts the movement of data between component of a DFD.
 Label should be noun phrase.

4. Data Store:
 It is a holding space for information.
 Label should be noun phrase.

OR
 DFD RULES
1. Output can be one or more.
2. Process should have both incoming and outgoing data.

3. The flow of data should not occur between entity, should come from one
entity to process and pass to another entity through process.
4. Flow of data should not occur between entity and the data source, should pass
from process.

5. Flow of data should not occur between data source, should pass from process.

6. Flow of data between two process without incoming and outgoing is not
allowed. Should have incoming to one process and can be outgoing from
another.

7. Can’t be bidirectional.