Unit 1

2. Behavioral Things
State Machine
It is a behaviour that specifies the sequences of states an object goes through during
its lifetime is response to events, together with its responses to those events.

A state machine involves a number of other elements, including states, transitions,

events, and activities.

Graphically, a state is rendered as a round edged rectangle, including its name and
its substates.

3. Grouping Things
Grouping things are the organizational parts of UML models.

These are the boxes into which a model can be decomposed.

There is one primary kind of grouping thing, namely, packages.

Package
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. Unlike components (which exist at run time), a package is
purely conceptual (meaning that it exists only at development time).

Graphically, a package is rendered as a tabbed folder, usually including only its

name and, sometimes, its contents.

4. Annotational Things
Annotational things are the explanatory parts of UML models.

Unit 1 1
 These are the comments you may apply to describe, illuminate, and remark
about any element in a model.

There is one primary kind of annotational thing, called a note.

Note
A note is simply a symbol for rendering constraints and 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.

Relationship
There are four kinds of relationships in UML:

1. Dependency

2. Association

3. Generalization

4. Realization

Dependency
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).

It is graphically rendered as a dashed line, possibly directed, and occasionally

including a label.

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

It represents Connection between to or more things.

Graphically, an association is rendered as a solid line, possibly directed,

occasionally including a label, and often containing other adornments, such as
multiplicity and end names.

Multiplicity

A student has one or more Instructors

A Instructor has one or more students

Unit 1 3
 Generalization
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

Realization
A realization is a semantic relationship between classifiers, wherein one class
specifies something that another class will perform.

Relationships in two places: between interfaces and the classes or components

that realize them, and between use cases and the collaborations that realize
them.

It is graphically rendered as a cross between a generalization and a dependency

relationship.

Diagrams in UML

Unit 1 4
 A diagram is the graphical presentation of a set of elements, most often
rendered as a connected graph of vertices (things) and paths (relationships).

You draw diagram to visualize a system from different perspective, so a diagram

is a projection into a system.

UML is linked with object oriented design and analysis. UML makes the use of
elements and forms associations between them to form diagrams. Diagrams in
UML can be broadly classified as:

Structural Diagrams - Capture static aspects or structure of a system.

Structural Diagrams include: Components Diagrams, Object Diagrams, Class
Diagrams and Deployment Diagrams.

Behavior Diagrams - Capture dynamic aspects or behavior of the system.

Behavior diagrams include: Use Case Diagrams, State Diagrams, Activity
Diagrams and Interactive Diagrams.

Rules(Conceptual Model on UML)

The rules of UML specify how the UMLs building blocks come together to
develop diagrams.

The rules enable the users to create well-formed models.

A well-formed model is self-consistent and also consistent with other models.

Common Mechanism
The UML is made simpler by the presence of four common mechanisms that apply
consistently throughout the language.

1. Specifications
Behind every graphical notation in UML there is a precise specification of the details
that element represents.
For example, a class icon is a rectangle and it specifies the name, attributes and
operations of the class.

Unit 1 5
 2. Adornments
The mechanism in UML which allows the users to specify extra information with the
basic notation of an element is the adornments.

In the example, the access specifiers: + (public), # (protected) and - (private)

represent the visibility of the attributes which is extra information over the basic
attribute representation.

3. Common divisions
In UML there is clear division between semantically related elements like:
separation between a class and an object and the separation between an
interface and its implementation.
Here there is one class, named Customer, together with three objects:

: Jan (which is marked explicitly as being a Customer object),

: Customer (an anonymous Customer object)
: Elyse (which in its specification is marked as being a kind of Customer object,
although it's not shown explicitly here).

4. Extensibility mechanism
UMLs extensibility mechanisms allow the user to extend (new
additions) the language in a controlled way. The extensibility
mechanisms in UML are:

Unit 1 6
 a )Stereotypes — Extends the vocabulary of UML. Allows users to
declare new building blocks (icons) or extend the basic notations of
the existing building blocks by stereotyping them using guillemets (<< >>).

b) Tagged Values — Extends the properties of an UML building block.

Allows us to specify extra information in the elements specification.
Represented as text written inside braces and placed under the
element name. The general syntax of a property is:

{ property name = value }

c) Constraints — Extends the semantics of a UMLs building block such as
specifying new rules or modifying existing rules. Represented as text
enclosed in braces and placed adjacent or beside the element name.

Class Diagram

Unit 1 7
 A class is a description of a set of
objects that share the same attributes,
operations, relationships, and semantics.

Graphically, a class is rendered as a

rectangle, usually including its name,
attributes, and operations in separate,
designated compartments.

The name of the class is the only required

tag in the graphical representation of a
class. It always appears in the top-most
compartment.

Unit 1 8
 An attribute is a named property of a

class that describes the object being modeled.

In the class diagram, attributes appear in

the second compartment just below the

name-compartment.
Attributes are usually listed in the form:
attributeName : Type
A derived attribute is one that can be
computed from other attributes, but
doesn’t actually exist. For example,
a Person’s age can be computed from
his birth date. A derived attribute is
designated by a preceding ‘/’ as in:

/age : Date

Attributes can be:

(+)public

(#)protected
(-)private
( / ) derived

Unit 1 9
 A class diagram in the Unified Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the classes, interfaces,
objects, and their relationships. A class diagram is a graphical representation of a
system's classes, interfaces, and objects, and the relationships between them.
Class diagrams can also show the relationships between classes, such as
inheritance, association, aggregation, and composition. These relationships are
represented by lines connecting the classes, with arrows pointing in the direction of
the relationship.

Example of a Class Diagram

Order System of an application

Unit 1 10
 Object Diagram
An object diagram is a type of UML (Unified Modeling Language) diagram that
shows a snapshot of the instances of the classes in a system, along with their
relationships and attributes. It provides a detailed view of the objects in a system and
their relationships at a specific point in time.

An object diagram is similar to a class diagram, but it shows the actual instances of
the classes and their current state, rather than the class definitions.

Object diagrams can be used to model the static structure of a system, to

understand the relationships between objects, and to verify that the objects in a
system are configured correctly. They are particularly useful for modeling the initial
state of a system, for testing and debugging, and for documenting the system's
design.

Purpose:

To capture the static view of a system at a particular moment.

Forward and reverse engineering.

Object relationships of a system.

Understand object behaviour and their relationships from practical perspective.

Unit 1 11
 Sequence Diagram
A sequence diagram is a type of UML (Unified Modeling Language) diagram that
shows the interactions between objects or components in a system, and the order in
which these interactions occur. It is used to model the dynamic behavior of a system
and to describe the interactions between objects in a system.

In a sequence diagram, the objects or components in a system are represented by

horizontal lines, called lifelines, and the interactions between these objects are
represented by messages, which are shown as arrows connecting the objects. The
messages are sent and received in a specific order, which is shown by the vertical
position of the messages on the diagram. The messages can be synchronous,
meaning that the sender waits for a response before continuing, or asynchronous,
meaning that the sender does not wait for a response.

Sequence diagrams can be used to model the flow of messages between objects,
the order in which the messages are sent and received, and the objects that are
involved in the interactions. They are useful for understanding the interactions
between objects in a system and for identifying potential design issues. They are
also useful for describing the flow of control in a system, and for generating code or
test cases.

Unit 1 12
Unit 1 13
 1. Lifeline: Represented by a vertical dashed line, a lifeline represents an instance
of an object or component in the system.

2. Activation bar: Represented by a vertical bar on a lifeline, an activation bar

indicates the time period during which an object or component is active and
processing a message. The top and bottom of the rectangle are aligned with the
initiation and the completion time respectively.

3. Message: Represented by an arrow connecting lifelines, a message represents

an interaction or communication between objects or components in the system.

4. Synchronous message: Represented by a solid arrow, a synchronous message

is used to indicate that the sender must wait for a response before continuing.

5. Asynchronous message: Represented by a half arrow, an asynchronous

message is used to indicate that the sender does not wait for a response.

6. Return message: Represented by a dotted arrow, a return message is used to

indicate the return of a message from an object or component to the sender.

Unit 1 14
 7. Recursive message: Represented by a message arrow that loops back to the
same object, a recursive message is used to indicate that an object or
component is sending a message to itself.

8. Self message: Represented by a message arrow that loops back to the same
object, a self message is used to indicate that an object or component is sending
a message to itself.

9. Interaction use: Represented by a rectangle with a dashed border, an interaction

use is used to indicate the reuse of a previously defined interaction.

10. Combined fragment: Represented by a rectangle with a label and a operator, a

combined fragment is used to indicate a specific interaction between objects or
components under certain conditions or constraints.

Collaboration Diagram
Collaboration refers to the interaction between objects in a system to achieve a
common goal. Objects in a system send messages to each other, calling methods
and passing data, to coordinate their actions and achieve the desired behavior of the
system. Collaboration between objects allows for the division of a complex problem
into smaller, more manageable parts that can be solved independently, and then
combined to achieve the overall solution.

Objects are able to produce (usable) high-level functionalities by working together.

A collaboration diagram, also known as a communication diagram or interaction

diagram, is a type of UML (Unified Modeling Language) diagram that shows how
objects or components interact with each other. It shows the relationships between
objects and the messages that are exchanged between them.
A collaboration diagram is similar to a sequence diagram, but it focuses on the
relationships between objects rather than the sequence of events. It shows the
objects and the links between them, as well as the messages that are sent between
the objects.
Here are some of the terms used in a collaboration diagram:

Objects: Represented as rectangles with the object name, it's an instance of a

class.

Unit 1 15
 Messages: Represented as arrows pointing from one object to another,
indicating that a message or request is sent from one object to another. The
message is labeled with the name of the operation or method being called.

Activations: Represented as vertical bars on the objects, indicating that an object

is actively processing a message.

Lifeline: Represented as a vertical dashed line, indicating the existence of an

object over a period of time.

Execution Occurrence: Represented as a rectangle on a lifeline, indicating the

period of time during which an object is processing a message.

Found message: Represented as a message originating from an object that

doesn't exist yet.

Lost message: Represented as a message going to an object that doesn't exist

anymore.

Return message: Represented as a message going back to the sender after the
operation is finished.

In a collaboration diagram, a message is represented as an arrow pointing from one

object to another, indicating that a message or request is sent from one object to
another. The message is labeled with the name of the operation or method being
called.
The arrow starts from the sender object and points to the receiving object. The
arrowhead points to the receiving object, and the tail of the arrow is attached to the
sender object. The name of the operation or method being called is written above or
below the arrow.
The message arrow is also accompanied by a activation bar that appears on top of
the object that is processing the message. This activation bar indicates that the
object is actively processing the message. The activation bar appears on the object
at the same time the message is sent and disappears when the message is finished
processing.
It's important to note that, the messages are represented in a chronological order,
one after the other, and it's essential to show the flow of control in the system, so it's
easy to understand the interactions between objects.

Additionally, the collaboration diagram can also show return message, which is
represented as an arrow going back to the sender object after the operation is

Unit 1 16
 finished. This is represented by a dotted arrow going back to the sender object along
with the name of the operation or method being returned.

In a collaboration diagram, polymorphism is represented by showing that an object

can respond to the same message in different ways depending on its type or
implementation. The message arrow is labeled with the name of the operation or
method being called, and the object that receives the message is represented with
its class name or interface name.
For example, a message "draw()" could be sent to multiple objects of different
classes (e.g. "Circle", "Square", "Triangle") which all have a "draw()" operation. Each
class will have its own implementation of the "draw()" operation and will respond to
the message differently.
In the collaboration diagram, the message "draw()" is sent from the sender object to
multiple objects with different class names, each object will process the message
with its own implementation of the "draw()" operation. This is represented by
showing the message arrow pointing to each object with its class name or interface
name.

In a collaboration diagram, iterated messages refer to messages that are sent

multiple times, often in a loop, to achieve a certain behavior. Iterated messages are
used to show that an operation or method is being repeatedly performed on an
object.
In a collaboration diagram, iterated messages are represented by a looped arrow
pointing from the sender object to the receiving object, with the name of the
operation or method being called. The looped arrow indicates that the message is
being sent multiple times.
For example, an object of class "BankAccount" could have an operation
"withdraw(amount: int)" which is used to withdraw money from the account. In the
collaboration diagram, the message "withdraw(100)" is sent from the object "Person"
to "BankAccount" object in a looped arrow, indicating that the operation "withdraw" is
being repeatedly performed multiple times until a certain condition is met.
It's important to note that, iterated messages are useful to model repetitive behavior,
such as loops, and can be used to represent the behavior of a system in a more
accurate and detailed way. It's also important to show the condition that stops the
loop in the diagram, to make it clear when the looped messages stop.

Unit 1 17
 Use Case
A use case is a description of a set of interactions between a system and its actors
(users or other systems) to achieve a specific goal or objective. It is a technique
used in software engineering to capture the requirements of a system and to
describe how the system should behave in different scenarios.
A use case is typically described as a series of steps, called use case scenarios, that
show how the system should respond to different inputs and conditions. Each
scenario begins with a specific goal or objective, and then describes the interactions
between the system and its actors, including the inputs provided by the actors, the
actions taken by the system, and the results or outputs produced by the system.

Use cases are used to model the functional requirements of a system, to understand
the interactions between the system and its actors, and to identify potential design
issues. They are also useful for testing and debugging the system, and for
documenting the system's design.

A use case diagram is a type of UML (Unified Modeling Language) diagram that
shows the interactions between actors and a system, and the goals or objectives
that the actors want to achieve using the system. It is a visual representation of the
use cases and their relationships in a system.
In a use case diagram, actors are represented by stick figures, and the system is
represented by a rectangle. The interactions between actors and the system are
represented by lines connecting the actors and the system, with arrows indicating
the direction of the interaction. The use cases themselves are represented by ovals,
which are labeled with the name of the use case.
Use case diagrams are used to model the high-level functionality of a system and to
understand the interactions between actors and the system. They are useful for
identifying the main goals and objectives of the system, and for understanding the
relationships between the use cases. They can also be used to identify potential
design issues, and to test and debug the system.

Use case diagrams are also useful for communication, as they provide a clear visual
representation of the system's functionality, making it easier for stakeholders and
developers to understand the requirements and design of the system. They are also
useful for documentation, as they provide a clear and concise summary of the
system's functionality.

Unit 1 18
 1. Actor: Represented by a stick figure, an actor represents an external entity that
interacts with the system, such as a user or another system.

2. System: Represented by a rectangle, the system represents the collection of

components or objects that provide the functionality described in the use cases.

3. Use case: Represented by an oval, a use case represents a specific goal or

objective that an actor wants to achieve using the system.

4. Association: Represented by a line connecting an actor and a use case, an

association represents the relationship between an actor and a use case,
indicating that the actor participates in the use case.

5. Include: Represented by a dotted arrow with an open arrowhead pointing from

one use case to another, an include relationship is used to indicate that one use
case includes the functionality of another use case.

Unit 1 19
 6. Extend: Represented by a dotted arrow with an open arrowhead pointing from
one use case to another, an extend relationship is used to indicate that one use
case can be extended by another use case in certain conditions.

7. Generalization: Represented by an arrow pointing from a child use case to a

parent use case, a generalization relationship is used to indicate that the child
use case inherits the functionality of the parent use case.

8. Note: Represented by a note icon, a note is used to add comments or additional

information to a use case diagram.

Activity Diagram
An activity diagram is a type of UML (Unified Modeling Language) diagram that
shows the flow of activities or actions in a system. It is used to model the dynamic
behavior of a system and to describe the flow of control in a system.
In an activity diagram, the flow of activities is represented by a series of connected
shapes, such as rectangles, diamonds, and ovals. Each shape represents a specific
action or decision point in the flow of activities. Transitions between shapes are
represented by arrows, which indicate the flow of control from one action to the next.
It's also important to note that Activity diagrams are closely related to flowcharts, but
activity diagrams are more expressive, as they provide more options to represent
different types of actions, such as parallel and concurrent activities, and also they
include notation for decision points, looping and more.

Unit 1 20
Unit 1 21
 Example:

Unit 1 22
 State Machine Diagram
A state machine diagram, also known as a state diagram or statechart diagram, is a
type of UML (Unified Modeling Language) diagram that shows the states of an object
or a system, the events that cause the object or system to transition between states,
and the actions that are performed as a result of these events. It is used to model
the behavior of an object or a system, and to understand how it responds to different
inputs and conditions.
In a state machine diagram, the states of an object or a system are represented by
circles or rectangles, and the transitions between states are represented by arrows.
Each transition is triggered by a specific event, and is accompanied by a guard
condition, which determines whether the transition can take place.
It's important to note that State machine diagrams are particularly useful for
modeling reactive systems which change their behavior based on events and
internal or external conditions. They are also useful for modeling the behavior of an
object in different states, and to represent the event-condition-action rules that
govern the transition between states.

We use it to model the dynamic behaviour of the system.

Unit 1 23
Unit 1 24
 Example:

Unit 1 25
 Component Diagram

Unit 1 26
Unit 1 27
Unit 1 28
Unit 1 29
 Deployment Diagram
A deployment diagram is a type of UML (Unified Modeling Language) diagram that
shows the physical deployment of software components, hardware components, and
other artifacts on a target platform. It is used to model the physical architecture of a
system and to understand how the system is deployed on the target platform.

They show the structure of the run-time system.

Unit 1 30
Unit 1 31