UML

1. Advanced structural modeling vs basic structural modeling

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 1

 UML

2. Structural modeling vs behavioral modeling

Static vs Dynamic View

Static modeling is used to specify the structure of the objects, classes or components that exist in the problem
domain. These are expressed using class, object or component. While dynamic modeling refers to representing the
object interactions during runtime. It is represented by sequence, activity, collaboration, and state. UML diagrams
represent these two aspects of a system:
 Structural (or Static) view: emphasizes the static structure of the system using objects, attributes, operations
and relationships. It includes class diagrams and composite structure diagrams.
 Behavioral (or Dynamic) view: emphasizes the dynamic behavior of the system by showing collaborations
among objects and changes to the internal states of objects. This view includes sequence diagrams, activity
diagrams, and state machine diagrams.
In UML 2.2 there are 14 types of UML diagrams, which are divided into these two categories:
 7 diagram types represent structural information
 Another 7 represents general UML diagram types for behavioral modeling, including four that represent
different aspects of interactions.
These diagrams can be categorized hierarchically as shown in the following UML diagram map:

Behavioral Diagrams
UML’s five behavioral diagrams are used to visualize, specify, construct, and document the dynamic aspects of a
system. It shows how the system behaves and interacts with itself and other entities (users, other systems). They show
how data moves through the system, how objects communicate with each other, how the passage of time affects the
system, or what events cause the system to change internal states. Since behavior diagrams illustrate the behavior of a
system, they are used extensively to describe the functionality of software systems. As an example, the activity
diagram describes the business and operational step-by-step activities of the components in a system.
In other words, a behavioral diagram shows how the system works ‘in motion’, that is how the system interacts with
external entities and users, how it responds to input or event and what constraints it operates under. There are seven
behavioral diagrams that you can model the dynamics of a system as listed in the Table below:
Behavioral Diagram Brief Description
It is a graphical representations of workflows of stepwise activities and
Activity Diagram
actions with support for choice, iteration and concurrency
It describes a system’s functional requirements in terms of use cases
Use Case Diagram that enable you to relate what you need from a system to how the
system delivers on those needs.
It shows the discrete behavior of a part of a designed system through
State Machine Diagram
finite state transitions.
It shows the sequence of messages exchanged between the objects
Sequence Diagram
needed to carry out the functionality of the scenario.
It shows interactions between objects and/or parts (represented as
Communication Diagram
lifelines) using sequenced messages in a free-form arrangement.

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 2

 UML

Interaction Overview It depicts a control flow with nodes that can contain other interaction
Diagram diagrams.
It shows interactions when the primary purpose of the diagram is to
Timing Diagram reason about time by focusing on conditions changing within and
among lifelines along a linear time axis.

Structural Diagrams
Structure diagrams depict the static structure of the elements in your system. i.e., how one object relates to another. It
shows the things in the system – classes, objects, packages or modules, physical nodes, components, and interfaces.
For example, just as the static aspects of a house encompass the existence and placement of such things as walls,
doors, windows, pipes, wires, and vents. The Seven UML structural diagrams are roughly organized around the major
groups of things you’ll find when modeling a system.
Since structure diagrams represent the structure, they are used extensively in documenting the software architecture
of software systems.
For example, the component diagram describes how a software system is split up into components and shows the
dependencies among these components.
Structural Diagram Brief Description

Composite Structure It shows the internal structure of a classifier, classifier interactions with the
Diagram environment through ports, or behavior of a collaboration.

It shows a set of nodes and their relationships that illustrates the static
Deployment Diagram
deployment view of an architecture.
It groups related UML elements into a collection of logically related UML
Package Diagram
structure.
Profile Diagram

It shows a set of classes, interfaces, and collaborations and their

Class Diagram
relationships, typically, found in modeling object-oriented systems.

It shows a set of objects and their relationships, which is the static

Object Diagram
snapshots of instances of the things found in class diagrams.
It shows a set of components and their relationships that illustrates the static
Component Diagram
implementation view of a system.

3. Difference between Generic class and abstract class

Generics permit classes, structs, interfaces, delegates, and methods to be parameterized by the data types they
store and manipulate. Generic class declaration should be mapped to the UML classifier (class or interface)
with a Template parameter. Additionally, Generics still affect other parts of the program structures such as
Attribute, Operation, Parameter, Parent Class, and Overloading Operators.

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 3

 UML

A UML abstract class is a class without any instances. It represents a common class for other
derived subclasses. An abstract class can contain abstract and also non-abstract attributes and
operations. A class that is not abstract cannot have any abstract fields (attributes, operations).

E.g. a class for Shape can be marked as abstract. It cannot be instantiated because we do not know
what kind of shape it represents. It is a base (super) class for other shape classes (e.g. Ellipse,
Rectangle)

4. Difference between object and actors

Actor initiates, shuts and even provides input to the system but does not sit inside the software system to perform any
task of the System. System works independently of actor.

Objects can simulate real world actors but still depend upon human actors for start-up, exit and input directly or
indirectly.

5. Deployment diagram and component diagram

Component Diagram
When modeling large object-oriented systems, it is necessary to break down the system into manageable
subsystems. UML component diagrams are used for modeling large systems into smaller subsystems which
can be easily managed.
A component is a replaceable and executable piece of a system whose implementation details are hidden. A
component provides the set of interfaces that a component realizes or implements. Components also require
interfaces to carry out a function.
So, component diagrams are used for,

 To represent the components of any system at runtime.

 It helps during testing of a system.
 It visualizes the connection between various components.
The purpose of the component diagram can be summarized as

 Visualize the components of a system.

 Construct executables by using forward and reverse engineering.
 Describe the organization and relationships of the components.

Component Diagram

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 4

 UML

Basic Component Diagram Symbols and Notations

Component
A component is a logical unit block of the system, a slightly higher abstraction than classes. It is represented as a rectang le with a smaller
rectangle in the upper right corner with tabs or the word written above the name of the component to help distinguish it from a class.

Interface

An interface (small circle or semi-circle on a stick) describes a group of operations used (required) or created (provided) by components. A
full circle represents an interface created or provided by the component. A semi-circle represents a required interface, like a person's input.

Dependencies

Draw dependencies among components using dashed arrows.

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 5

 UML

Port

Ports are represented using a square along the edge of the system or a component. A port is often used to help expose required and
provided interfaces of a component.

Deployment diagram
Deployment diagrams are used to visualize the topology of the physical components of a system, where the software components are
deployed.
Deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams consist of nodes and their
relationships
Purpose of Deployment Diagrams

 They show the structure of the run-time system

 They capture the hardware that will be used to implement the system and the links between different items of hardware.
 They model physical hardware elements and the communication paths between them
 They can be used to plan the architecture of a system.
 They are also useful for Document the deployment of software components or nodes

6. State machines and state chart diagram

What is a State Machine Diagram?

State Diagram are used to capture the behavior of a software system. UML State machine diagrams can be used to
model the behavior of a class, a subsystem, a package, or even an entire system. It is also called a Statechart or State
Transition diagram.

When to use a State Machine Diagram?

State diagrams are used to implement real-life working models and object-oriented systems in depth. These diagrams
are used to compare the dynamic and static nature of a system by capturing the dynamic behavior of a system.

Statechart diagrams are used to capture the changes in various entities of the system from start to end. They are used to
analyze how an event can trigger change within multiple states of a system.

State char diagrams are used:

1. To model objects of a system.

2. To model and implement interactive systems.
3. To display events that trigger changes within the states.

There are a total of two types of state machine diagram in UML:

1. Behavioral State Machine Diagram

 It captures the behavior of an entity present in the system.

 It is used to represent the specific implementation of an element.
 The behavior of a system can be modelled using behavioral state machine diagram in OOAD.

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 6

 UML

2. Protocol State Machine Diagram

 These diagrams are used to capture the behavior of a protocol.

 It represents how the state of protocol changes concerning the event. It also represents corresponding changes in
the system.
 They do not represent the specific implementation of an element.

What is a Statechart Diagram?

Statechart diagrams provide us an efficient way to model the interactions or communication that occur within the
external entities and a system. These diagrams are used to model the event-based system. A state of an object is
controlled with the help of an event. Statechart diagrams are used to describe various states of an entity within the
application system.

How to draw a Statechart diagram?

Statechart diagrams are used to describe the various state that an object passes through. A transition between
one state into another state occurs because of some triggered event. To draw a state diagram in UML, one
must identify all the possible states of any particular entity.

The purpose of these UML diagrams is to represent states of a system. States plays a vital role in state
transition diagrams. All the essential object, states, and the events that cause changes within the states must be
analyzed first before implementing the diagram.

Following rules must be considered while drawing a state chart diagram:

1. The name of a state transition must be unique.

2. The name of a state must be easily understandable and describe the behavior of a state.
3. If there are multiple objects, then only essential objects should be implemented.
4. Proper names for each transition and an event must be given.

Main Differences
Statechart diagram is used to capture the dynamic aspect of a system.

State machine diagrams are used to represent the behavior of an application. An object goes through various states
during its lifespan.

Statechart diagrams are used to design interactive systems that respond to either internal or external event. Statechart
diagram in UML visualizes the flow of execution from one state to another state of an object.

The primary purpose of a statechart diagram is to model interactive systems and define each and every state of an
object. Statechart diagrams are designed to capture the dynamic behavior of an application system. These diagrams are
used to represent various states of a system and entities within the system.

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 7

 UML

7. Signal and event.

Events

An event is the specification of a significant occurrence that has a location in time and space.
 Anything that happens is modeled as an event in UML.
 In the context of state machines, an event is an occurrence of a stimulus that can trigger a state transition
 four kinds of events – signals, calls, the passing of time, and a change in state.
 Events may be external or internal and asynchronous or synchronous.
Asynchronous events are events that can happen at arbitrary times eg:- signal, the passing of time, and a
change of state.
Synchronous events, represents the invocation of an operation eg:- Calls
External events are those that pass between the system and its actors.
Internal events are those that pass among the objects that live inside the system

Signal

A signal is a named object that is sent asynchronously by one object and then received by another. Exceptions are the
famous examples for signals. A signal may be sent as the action of a state in a state machine or as a message in an
interaction. The execution of an operation can also send signals.

In UML, we model the relationship between an operation and the events using a dependency stereotyped with “send”,
which indicates that an operation sends a particular signal.

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 8

 UML

8. Scenario vs use case

1. A scenario is a situation in which more than one actor is involved in performing a specific task. A
use case is the description of the scenario which involves describing the functionality of the scenario.
2. The scenario is the instance of the use case whereas the use case is the external entity such as an
actor or system.
3. The scenario doesn't contain entry or exit points but the use case has this for describing the
conditions within the range.

Construction of scenario and use case-

1. The scenario used during the requirement analysis. This can be used as a tool for describing the use
of specific requirements.
2. The use cases are constructed for modeling the requirements which are proposed in the scenario.
The use case provides more descriptions of the requirements.

Example-

1. Scenario-
Consider a university that requires an application for an online exam. The scenario describes the use of an
online exam, an individual such as a student, and the equipment such as a system.
The scenario for this application is-
 Authentication of the student
 The URL for the student which is an exam URL
 List of options in the exam for the student.
 List of questions for the students.
 Log-off information of the student.

2. Use cases-
Consider the online exam system. The use case is the online exam. The actor is a student and the system is
server.
The flow of the events-

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 9

 UML

 The student connects to the server

 The student selects the exam.
 The student submits the exam
 The student log off the system.

Entry condition-
 The system verifies the student login information
Exit condition-
 Successful log off the system

9. Active, passive and transient object in sequence diagram.

Objects in UML

UML preserves a similar distinction between classes and objects, and they are represented in the same way;
UML classes contain broad descriptions, and UML objects contain specific values that represent instances of
those descriptions. Formally speaking, therefore, an "active object" in UML is any instance of an "active
class," and similarly a "passive object" is an instance of a "passive class"—in a theoretical sense, you could
consider these terms to be essentially interchangeable.

Active Objects

In UML, active classes, and therefore active objects, exist in their own thread of operations and have their
own address space. If execution, or code activity, is thought of in terms of flow, active objects can start or
control that flow. Active objects, in other words, are sequential and do something: modify variables, change
program behavior, and so on. In UML, active classes and objects are distinguished by having a thicker border
than passive objects.

Passive Objects

Passive objects in UML do not generally have the ability to modify or begin the flow of execution, because
they must wait for another object to call them. Instead, passive objects are generally used to store information,
and in many cases this information may be shared between multiple other objects. This may allow passive
objects to be accessed concurrently, not sequentially. To make sure that the data contained inside has a high
integrity, UML allows for passive objects to insist that they be accessed sequentially; if two threads attempt to
call the same sequential passive object, that object can delay the second thread until the first has finished with
it.

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 10

 UML

by: Tuhin Subhra Panda [BCA 6th SEMESTER] Page 11