Software Engineering unit 4 [R20]
UNIT IV
I)BEHAVIORAL MODELLING:
UML - Interaction
Diagrams
From the term
Interaction, it is clear that the diagram is used to describe some type of
interactions among the different elements in the model. This interaction is a
part of dynamic behavior of the system.
This interactive
behavior is represented in UML by two diagrams known as Sequence
diagram and Collaboration diagram. The basic purpose of
both the diagrams are similar.
Sequence diagram emphasizes on time sequence of
messages and
Collaboration diagram emphasizes on the
structural organization of the objects that send and receive messages.
Purpose of Interaction Diagrams
The purpose of
interaction diagrams is to visualize the interactive behavior of the system.
Visualizing the interaction is a difficult task. Hence, the solution is to use
different types of models to capture the different aspects of the interaction.
Sequence and
collaboration diagrams are used to capture the dynamic nature but from a
different angle.
The purpose of
interaction diagram is −
· To capture the
dynamic behaviour of a system.
· To describe the
message flow in the system.
· To describe the
structural organization of the objects.
· To describe the
interaction among objects.
How to Draw an Interaction Diagram?
The purpose of
interaction diagrams is to capture the dynamic aspect of a system. So to
capture the dynamic aspect, we need to understand what a dynamic aspect is and
how it is visualized. Dynamic aspect can be defined as the snapshot of the
running system at a particular moment
We have two types of
interaction diagrams in UML. One is the sequence diagram and the other is the
collaboration diagram. The sequence diagram captures the time sequence of the
message flow from one object to another and the collaboration diagram describes
the organization of objects in a system taking part in the message flow.
Following things are
to be identified clearly before drawing the interaction diagram
· Objects taking part
in the interaction.
· Message flows among
the objects.
· The sequence in which
the messages are flowing.
· Object organization.
Following are two
interaction diagrams modeling the order management system. The first diagram is
a sequence diagram and the second is a collaboration diagram
The Sequence Diagram
The sequence diagram
has four objects (Customer, Order, SpecialOrder and NormalOrder).
The following diagram
shows the message sequence for SpecialOrder object and the
same can be used in case of NormalOrder object. It is
important to understand the time sequence of message flows. The message flow is
nothing but a method call of an object.
The first call
is sendOrder () which is a method of Order object.
The next call is confirm () which is a method of SpecialOrder object
and the last call is Dispatch () which is a method of SpecialOrder object.
The following diagram mainly describes the method calls from one object to
another, and this is also the actual scenario when the system is running.
The Collaboration Diagram
The second
interaction diagram is the collaboration diagram. It shows the object
organization as seen in the following diagram. In the collaboration diagram,
the method call sequence is indicated by some numbering technique. The number
indicates how the methods are called one after another. We have taken the same
order management system to describe the collaboration diagram.
Method calls are
similar to that of a sequence diagram. However, difference being the sequence
diagram does not describe the object organization, whereas the collaboration
diagram shows the object organization.
To choose between
these two diagrams, emphasis is placed on the type of requirement. If the time
sequence is important, then the sequence diagram is used. If organization is
required, then collaboration diagram is used.
Where to Use Interaction Diagrams?
We have already
discussed that interaction diagrams are used to describe the dynamic nature of
a system.
Now, we will look into the practical scenarios
where these diagrams are used.
·
To understand the practical application,
·
we need to understand the basic nature of sequence and collaboration
diagram.
·
The main purpose of both the diagrams are similar as they are used to
capture the dynamic behavior of a system.
·
However, the specific purpose is more important to clarify and
understand.
Where to use Intraction diagrams:
Sequence diagrams are
used to capture the order of messages flowing from one object to another.
Collaboration diagrams are used to describe
the structural organization of the objects taking part in the interaction.
A single diagram is
not sufficient to describe the dynamic aspect of an entire system, so a set of
diagrams are used to capture it as a whole.
Where to use Intraction Diagrams:
Interaction diagrams
are used when we want to understand the message flow and the structural
organization. Message flow means the sequence of control flow from one object
to another. Structural organization means the visual organization of the
elements in a system.
Interaction diagrams can be used −
· To model the flow of
control by time sequence.
· To model the flow of
control by structural organizations.
· For forward
engineering.
· For reverse
engineering.
Use Case Diagram
To model a system,
the most important aspect is to capture the dynamic behavior. 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. However, this
definition is too generic to describe the purpose, as other four diagrams
(activity, sequence, collaboration, and Statechart) also have the same purpose.
We will look into some specific purpose, which will distinguish it from other
four diagrams.
Use case diagrams are
used to gather the requirements of a system including internal and external
influences. These requirements are mostly design requirements. Hence, when a
system is analyzed to gather its functionalities, use cases are prepared and actors
are identified.
When the initial task
is complete, use case diagrams are modelled to present the outside view.
In brief, the
purposes of use case diagrams can be said to be as follows −
· 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
· 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.
· Give a suitable name
for actors.
· Show relationships
and dependencies clearly in the diagram.
· Do not try to include
all types of relationships, as the main purpose of the diagram is to identify
the requirements.
· 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?
As we have already
discussed there are five diagrams in UML to model the dynamic view of a system.
Now each and every model has some specific purpose to use. Actually these
specific purposes are different angles of a running system.
To understand the
dynamics of a system, we need to use different types of diagrams. Use case
diagram is one of them and its specific purpose is to gather system
requirements and actors.
Use case diagrams
specify the events of a system and their flows. But use case diagram never
describes how they are implemented. Use case diagram can be imagined as a black
box where only the input, output, and the function of the black box is known.
These diagrams are
used at a very high level of design. This high level design is refined again
and again to get a complete and practical picture of the system. A
well-structured use case also describes the pre-condition, post condition, and
exceptions. These extra elements are used to make test cases when performing
the testing.
Although use case is
not a good candidate for forward and reverse engineering, still they are used
in a slightly different way to make forward and reverse engineering. The same
is true for reverse engineering. Use case diagram is used differently to make
it suitable for reverse engineering.
In forward
engineering, use case diagrams are used to make test cases and in reverse
engineering use cases are used to prepare the requirement details from the
existing application.
Use case diagrams can
be used for −
· Requirement analysis
and high level design.
· Model the context of
a system.
· Reverse engineering.
· Forward engineering.
Activity diagram
Activity diagram is another important
diagram in UML to describe the dynamic aspects of the system.
Activity diagram is
basically a flowchart to represent the flow from one activity to another
activity. The activity can be described as an operation of the system.
The control flow is
drawn from one operation to another. This flow can be sequential, branched, or
concurrent.
Activity diagrams
deal with all type of flow control by using different elements such as fork,
join, etc
Purpose of Activity Diagrams
The basic purposes of
activity diagrams is similar to other four diagrams. It captures the dynamic
behavior of the system. Other four diagrams are used to show the message flow
from one object to another but activity diagram is used to show message flow from
one activity to another.
Activity is a
particular operation of the system. Activity diagrams are not only used for
visualizing the dynamic nature of a system, but they are also used to construct
the executable system by using forward and reverse engineering techniques. The
only missing thing in the activity diagram is the message part.
It does not show any
message flow from one activity to another. Activity diagram is sometimes
considered as the flowchart. Although the diagrams look like a flowchart, they
are not. It shows different flows such as parallel, branched, concurrent, and
single.
The purpose of an
activity diagram can be described as −
· Draw the activity
flow of a system.
· Describe the sequence
from one activity to another.
· Describe the
parallel, branched and concurrent flow of the system.
How to Draw an Activity Diagram?
Activity diagrams are
mainly used as a flowchart that consists of activities performed by the system.
Activity diagrams are not exactly flowcharts as they have some additional
capabilities. These additional capabilities include branching, parallel flow, swimlane,
etc.
Before drawing an
activity diagram, we must have a clear understanding about the elements used in
activity diagram.
The main element of
an activity diagram is the activity itself. An activity is a function performed
by the system.
After identifying the
activities, we need to understand how they are associated with constraints and
conditions.
Before drawing an
activity diagram, we should identify the following elements −
· Activities
· Association
· Conditions
· Constraints
Once the
above-mentioned parameters are identified, we need to make a mental layout of
the entire flow. This mental layout is then transformed into an activity
diagram.
Following is an
example of an activity diagram for order management system. In the diagram,
four activities are identified which are associated with conditions. One
important point should be clearly understood that an activity diagram cannot be
exactly matched with the code. The activity diagram is made to understand the
flow of activities and is mainly used by the business users
Following diagram is
drawn with the four main activities −
· Send order by the
customer
· Receipt of the order
· Confirm the order
· Dispatch the order
After receiving the
order request, condition checks are performed to check if it is normal or
special order. After the type of order is identified, dispatch activity is
performed and that is marked as the termination of the process.
Where to Use Activity Diagrams?
The basic usage of
activity diagram is similar to other four UML diagrams. The specific usage is
to model the control flow from one activity to another. This control flow does
not include messages.
Activity diagram is
suitable for modeling the activity flow of the system. An application can have
multiple systems. Activity diagram also captures these systems and describes
the flow from one system to another. This specific usage is not available in other
diagrams. These systems can be database, external queues, or any other system.
We will now look into
the practical applications of the activity diagram. From the above discussion,
it is clear that an activity diagram is drawn from a very high level. So it
gives high level view of a system. This high level view is mainly for business
users or any other person who is not a technical person.
This diagram is used
to model the activities which are nothing but business requirements. The
diagram has more impact on business understanding rather than on implementation
details.
Activity diagram can
be used for −
· Modeling work flow by
using activities.
· Modeling business
requirements.
· High level
understanding of the system's functionalities.
· Investigating
business requirements at a later stage.
Events
and signals
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.
•
A
signal is an event that represents the specification of an asynchronous
stimulus communicated between instances.
kinds of events
•
Signal
Event :A signal event
represents a named object that is dispatched (thrown) asynchronously by one
object and then received (caught) by another.
•
Exceptions
are an example of internal signal.
•
a signal event is an asynchronous event.
•
signal events may have instances,
generalization relationships, attributes and operations. Attributes of a signal
serve as its parameters.
•
A signal event may be sent as the action of a
state transition in a state machine or the sending of a message in an
interaction .
•
signals are modeled as stereotyped classes and
the relationship between an operation and the events by using a dependency
relationship, stereotyped as send
•
•
2.Call
Event :
A call event represents the dispatch of
an operation · a call event is a synchronous event
•
•
3.Time
and Change Events
•
A time event is an
event that represents the passage of time.
•
modeled by using the
keyword ‘after’ followed by some expression that evaluates to a period of time
which can be simple or complex.
•
A change event is an event that represents a
change in state or the satisfaction of some condition.
•
modeled by using the keyword ‘when’ followed
by some Boolean expression
Figure
: Time and Change Events
4.Sending and Receiving Events
•
For
synchronous events (Sending
or Receiving) like call event, the sender and the receiver are in a rendezvous
(the sender dispatches the signal and wait for a response from the receiver)
for the duration of the operation. When an object calls an operation, the
sender dispatches the operation and then waits for the receiver.
•
For
asynchronous events (Sending
or Receiving) like signal event, the sender and receiver do not rendezvous
ie,the sender dispatches the signal but does not wait for a response from the
receiver. When an object sends a signal, the sender dispatches the signal and
then continues along its flow of control, not waiting for any return from the
receiver.
•
Call
events can be modeled as operations on the class of the object.
•
Named
signals can be modeled by naming them in an extra compartment of the class
Figure : Signals and Active Classes
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.
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.
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.
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.
Why State
Machine Diagram?
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. The lifespan of an object remains until the program is
terminated. The object goes from multiple states depending upon the event that
occurs within the object. Each state represents some unique information about
the object.
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.
It represents the state of an
object from the creation of an object until the object is destroyed or
terminated.o write a TEST CASE Software Testing Tutorial
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.
Notation
and Symbol for State Machine Diagram (Statechart Diagram)
Following are the
various notations that are used throughout the state chart diagram. All these
notations, when combined, make up a single diagram.
UML
state diagram notations
Initial state
The initial state
symbol is used to indicate the beginning of a state machine diagram.
Final state
This symbol is used to
indicate the end of a state machine diagram.
Decision box
It contains a
condition. Depending upon the result of an evaluated guard condition, a new
path is taken for program execution.
Transition
A transition is a
change in one state into another state which is occurred because of some event.
A transition causes a change in the state of an object.
State box
It is a specific moment
in the lifespan of an object. It is defined using some condition or a statement
within the classifier body. It is used to represent any static as well as
dynamic situations.
It is denoted using a
rectangle with round corners. The name of a state is written inside the rounded
rectangle.
The name of a state can
also be placed outside the rectangle. This can be done in case of composite or
submachine states. One can either place the name of a state within the
rectangle or outside the rectangle in a tabular box. One cannot perform both at
the same time.
A state can be either
active or inactive. When a state is in the working mode, it is active, as soon
as it stops executing and transits into another state, the previous state
becomes inactive, and the current state becomes active.
Types
of State
Unified Modeling
Language defines three types of states:
- Simple
state
·
They do not have any substrate.
- Composite
state
·
These types of states can have one or more than one substrate.
·
A composite state with two or more substates is called an
orthogonal state.
- Submachine
state
·
These states are semantically equal to the composite states.
·
Unlike the composite state, we can reuse the submachine states.
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.
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.
Example
of State Machine
Following state diagram
example chart represents the user authentication process.
UML state
diagram
There are a total of
two states, and the first state indicates that the OTP has to be entered first.
After that, OTP is checked in the decision box, if it is correct, then only
state transition will occur, and the user will be validated. If OTP is incorrect,
then the transition will not take place, and it will again go back to the
beginning state until the user enters the correct OTP as shown in the above
state machine diagram example.
State
Machine Diagram vs. Flowchart
Following are the key
differences between Statechart Diagram and Flowchart
|
State Machine Diagram |
FlowChart |
|
It represents various states of a
system |
The Flowchart illustrates the
program execution flow. |
|
The state machine has a WAIT
concept, i.e., wait for an action or an event. |
The Flowchart does not deal with
waiting for a concept. |
|
State machines are used for a
live running system. |
Flowchart visualizes branching
sequences of a system. |
|
The state machine is a modeling
diagram. |
A flowchart is a sequence flow or
a DFD diagram. |
|
The state machine can explore
various states of a system. |
Flowchart deal with paths and control flow. |
Processes
and Threads
·
A process is a heavyweight flow that can execute concurrently with other
processes.
·
A thread is a lightweight flow that can execute concurrently with other
threads within the same process.
·
An active object is an object that owns a process or thread and can
initiate control activity.
·
An active class is a class whose instances are active objects.
·
Graphically, an active class is rendered as a rectangle with thick
lines. Processes and threads are rendered as stereotyped active
classes. Figure 1:Active class
Figure 1: Active
Class
Flow
of Control
In a sequential system, there is a single flow of
control. i.e, one thing, and one thing only, can take place at a time.
In a concurrent system, there is multiple
simultaneous flow of control i.e, more than one thing can take place at a time.
Classes
and Events
·
Active classes are just classes which represents an independent flow of
control
·
Active classes share the same properties as all other classes.
·
When an active object is created, the associated flow of control is
started; when the active object is destroyed, the associated flow of control is
terminated
·
two standard stereotypes that apply to
active classes are, <<process>> –
Specifies a heavyweight flow that can execute concurrently with other
processes. (heavyweight means, a thing known to the OS itself and runs in an
independent address space) <<thread>> –
Specifies a lightweight flow that can execute concurrently with other threads
within the same process (lightweight means, known to the OS itself.)
·
All the threads that live in the context of a process are peers of one
another
Communication
·
In a system with both active and passive objects, there are four possible combinations of interaction
·
First, a message may be passed from one
passive object to another
·
Second, a message may be passed from one
active object to another
·
In inter-process communication there
are two possible styles of communication. First, one active
object might synchronously call an operation of another. Second, one active object might asynchronously send a
signal or call an operation of another object
·
a synchronous message is rendered as a full arrow and an asynchronous
message is rendered as a half arrow
·
Figure 2: shows Communication
·
Third, a message may be passed from an
active object to a passive object
·
Fourth, a message may be passed from a
passive object to an active one
Figure 2:
Communication
Advertisements
REPORT THIS AD
Synchronization
·
synchronization means arranging the flow of controls of objects so that
mutual exclusion will be guaranteed.
·
in object-oriented systems these objects are treated as a critical
region
·
Figure 3 Synchronization
·
three approaches are there to
handle synchronization:
·
Sequential – Callers must coordinate
outside the object so that only one flow is in the object at a time
·
Guarded – multiple flow of control is
sequentialized with the help of object’s guarded operations. in effect it
becomes sequential.
·
Concurrent – multiple flow of control
is guaranteed by treating each operation as atomic
·
synchronization are rendered in the operations of active classes with
the help of constraints
Figure 3:
Synchronization
Process
Views
·
The process view of a system encompasses the threads and processes that
form the system’s concurrency and synchronization mechanisms.
·
This view primarily addresses the performance, scalability, and
throughput of the system.
Modeling
Multiple Flows of Control
To model multiple flows of control,
·
· Identify the opportunities for concurrent action and reify each flow
as an active class. Generalize common sets of active objects into an active
class. Be careful not to overengineer the process view of your system by
introducing too much concurrency.
·
· Consider a balanced distribution of responsibilities among these
active classes, then examine the other active and passive classes with which
each collaborates statically. Ensure that each active class is both tightly
cohesive and loosely coupled relative to these neighboring classes and that
each has the right set of attributes, operations, and signals.
·
· Capture these static decisions in class diagrams, explicitly
highlighting each active class.
·
· Consider how each group of classes collaborates with one another
dynamically. Capture those decisions in interaction diagrams. Explicitly show
active objects as the root of such flows. Identify each related sequence by
identifying it with the name of the active object.
·
· Pay close attention to communication among active objects. Apply
synchronous and asynchronous messaging, as appropriate.
·
· Pay close attention to synchronization among these active objects and
the passive objects with which they collaborate. Apply sequential, guarded, or
concurrent operation semantics, as appropriate.
Figure 4 shows part of the process view of a trading system.
Figure 4: Modeling
Flows of Control
Modeling
Interprocess Communication
To model interprocess communication,
·
· Model the multiple flows of control.
·
· Consider which of these active objects represent processes and which
represent threads. Distinguish them using the appropriate stereotype.
·
· Model messaging using asynchronous communication; model remote
procedure calls using synchronous communication.
·
· Informally specify the underlying mechanism for communication by using
notes, or more formally by using collaborations.
Figure 5 shows a distributed reservation system with processes spread
across four nodes.
Figure 5: Modeling
Interprocess Communication
Statechart Diagram
The name of the diagram itself clarifies the
purpose of the diagram and other details. It describes different states of a
component in a system. The states are specific to a component/object of a
system.
A Statechart diagram describes a state machine.
State machine can be defined as a machine which defines different states of an
object and these states are controlled by external or internal events.
Activity diagram, is a special kind of a Statechart
diagram. As Statechart diagram defines the states, it is used to model the
lifetime of an object.
Purpose of Statechart Diagrams
Statechart diagram is one of the five UML diagrams
used to model the dynamic nature of a system. They define different states of
an object during its lifetime and these states are changed by events.
Statechart diagrams are useful to model the reactive systems. Reactive systems
can be defined as a system that responds to external or internal events.
Statechart diagram describes the flow of control
from one state to another state. States are defined as a condition in which an
object exists and it changes when some event is triggered. The most important
purpose of Statechart diagram is to model lifetime of an object from creation
to termination.
Statechart diagrams are also used for forward and
reverse engineering of a system. However, the main purpose is to model the
reactive system.
Following are the main purposes of using Statechart
diagrams −
·
To model the dynamic aspect of a system.
·
To model the life time of a reactive system.
·
To describe different states of an object during its life time.
·
Define a state machine to model the states of an object
How to Draw a Statechart Diagram?
Statechart diagram is used to describe the states
of different objects in its life cycle. Emphasis is placed on the state changes
upon some internal or external events. These states of objects are important to
analyze and implement them accurately.
Statechart diagrams are very important for
describing the states. States can be identified as the condition of objects
when a particular event occurs.
Before drawing a Statechart diagram we should
clarify the following points −
·
Identify the important objects to be analyzed.
·
Identify the states.
·
Identify the events.
Following is an example of a Statechart diagram
where the state of Order object is analysed
The first state is an idle state from where the
process starts. The next states are arrived for events like send request,
confirm request, and dispatch order. These events are responsible for the state
changes of order object.
During the life cycle of an object (here order
object) it goes through the following states and there may be some abnormal
exits. This abnormal exit may occur due to some problem in the system. When the
entire life cycle is complete, it is considered as a complete transaction as
shown in the following figure. The initial and final state of an object is also
shown in the following figure.
Where to Use Statechart Diagrams?
From the above discussion, we can define the
practical applications of a Statechart diagram. Statechart diagrams are used to
model the dynamic aspect of a system like other four diagrams discussed in this
tutorial. However, it has some distinguishing characteristics for modeling the
dynamic nature.
Statechart diagram defines the states of a
component and these state changes are dynamic in nature. Its specific purpose
is to define the state changes triggered by events. Events are internal or
external factors influencing the system.
Statechart diagrams are used to model the states
and also the events operating on the system. When implementing a system, it is
very important to clarify different states of an object during its life time
and Statechart diagrams are used for this purpose. When these states and events
are identified, they are used to model it and these models are used during the
implementation of the system.
If we look into the practical implementation of
Statechart diagram, then it is mainly used to analyze the object states
influenced by events. This analysis is helpful to understand the system
behavior during its execution.
The main usage can be described as −
·
To model the object states of a system.
·
To model the reactive system. Reactive system consists of reactive
objects.
·
To identify the events responsible for state changes.
·
Forward and reverse engineering.
Time and Space
A distributed
system is one in which components may be physically distributed across nodes.
These nodes may represent different processors physically located in the same
box, or they may even represent computers that are located half a world away
from one another.
To
represent the modeling needs of real time and distributed systems, the UML
provides a graphic representation for timing marks, time expressions, timing
constraints, and location.
Figure :Timing Constraints and Location
A timing mark is a
denotation for the time at which an event occurs. Graphically, a timing mark is depicted as a small hash mark
(horizontal line) on the border of a sequence
diagram.
A time expression is an expression that evaluates to an absolute
or relative value of time. A time expression can also be formed using the name
of a message and an indication of a stage in its processing, for
example, request.sendTime or request.receiveTime.
A timing constraint is a semantic
statement about the relative or absolute value of time. Graphically, a timing
constraint is rendered as for any constraint-that is, a string enclosed by
brackets and generally connected to an element by a dependency relationship.
Location is the placement of a component on a node. Location is
an attribute of an object.
Time
Real time
systems are, time-critical systems. Events may happen at regular or irregular
times; the response to an event must happen at predictable absolute times or at
predictable times relative to the event itself.
The
passing of messages represents the dynamic aspect of any system, They are
mainly rendered with the name of an event, such as a signal or a call.
Figure : Time
Location
Distributed
systems, encompass components that are physically scattered among the nodes of
a system. For many systems, components are fixed in place at the time they are
loaded on the system; in other systems, components may migrate from node to
node.
Figure : Location
ii) ARCHITECTURAL MODELLING:
UML Component Diagram
A component diagram is used to break down a large
object-oriented system into the smaller components, so as to make them more
manageable. It models the physical view of a system such as executables, files,
libraries, etc. that resides within the node.
It visualizes the relationships as well as the organization
between the components present in the system. It helps in forming an executable
system. A component is a single unit of the system, which is replaceable and
executable. The implementation details of a component are hidden, and it
necessitates an interface to execute a function. It is like a black box whose
behavior is explained by the provided and required interfaces.
Notation of a Component
Diagram
a) A component
b) A node
b) A node
Purpose of a Component Diagram
Since it is a special kind of a UML
diagram, it holds distinct purposes. It describes all the individual components
that are used to make the functionalities, but not the functionalities of the
system. It visualizes the physical components inside the system. The components
can be a library, packages, files, etc.
The component diagram also describes
the static view of a system, which includes the organization of components at a
particular instant. The collection of component diagrams represents a whole
system.
The main purpose of the component
diagram are enlisted below:
- It envisions each component of a system.
- It constructs the executable by incorporating
forward and reverse engineering.
- It depicts the relationships and organization
of components.
Why use Component Diagram?
The component diagrams have
remarkable importance. It is used to depict the functionality and behavior of
all the components present in the system, unlike other diagrams that are used
to represent the architecture of the system, working of a system, or simply the
system itself.
In UML, the component diagram
portrays the behavior and organization of components at any instant of time.
The system cannot be visualized by any individual component, but it can be by
the collection of components.
Following are some reasons for the
requirement of the component diagram:
- It portrays the components of a system at the
runtime.
- It is helpful in testing a system.
- It envisions the links between several
connections.
When to use a Component Diagram?
It represents various physical
components of a system at runtime. It is helpful in visualizing the structure
and the organization of a system. It describes how individual components can
together form a single system. Following are some reasons, which tells when to
use component diagram:
- To divide a single system into multiple
components according to the functionality.
- To represent the component organization of the
system.
How to Draw a Component Diagram?
The component diagram is helpful in
representing the physical aspects of a system, which are files, executables,
libraries, etc. The main purpose of a component diagram is different from that
of other diagrams. It is utilized in the implementation phase of any
application.
Once the system is designed employing
different UML diagrams, and the artifacts are prepared, the component diagram
is used to get an idea of implementation. It plays an essential role in
implementing applications efficiently.
Following are some artifacts that are
needed to be identified before drawing a component diagram:
- What files are used inside the system?
- What is the application of relevant libraries
and artifacts?
- What is the relationship between the
artifacts?
Following are some points that are
needed to be kept in mind after the artifacts are identified:
- Using a meaningful name to ascertain the
component for which the diagram is about to be drawn.
- Before producing the required tools, a mental
layout is to be made.
- To clarify the important points, notes can be
incorporated.
Example of a Component Diagram
A component diagram for an online
shopping system is given below:
Where to use Component Diagrams?
The component diagram is a special
purpose diagram, which is used to visualize the static implementation view of a
system. It represents the physical components of a system, or we can say it
portrays the organization of the components inside a system. The components,
such as libraries, files, executables, etc. are first needed to be organized
before the implementation.
The component diagram can be used for
the followings:
- To model the components of the system.
- To model the schemas of a database.
- To model the applications of an application.
- To model the system's source code.
UML Deployment
Diagram
The deployment diagram visualizes the physical hardware on which
the software will be deployed. It portrays the static deployment view of a
system. It involves the nodes and their relationships.
It ascertains how software is deployed on the hardware. It maps
the software architecture created in design to the physical system
architecture, where the software will be executed as a node. Since it involves
many nodes, the relationship is shown by utilizing communication paths.
Purpose of Deployment
Diagram
The main purpose of the deployment diagram is to represent how
software is installed on the hardware component. It depicts in what manner a
software interacts with hardware to perform its execution.
Both the deployment diagram and the component diagram are
closely interrelated to each other as they focus on software and hardware
components. The component diagram represents the components of a system,
whereas the deployment diagram describes how they are actually deployed on the
hardware.
The deployment diagram does not focus on the logical components
of the system, but it put its attention on the hardware topology.
Following are the purposes of deployment diagram enlisted below:
- To
envision the hardware topology of the system.
- To
represent the hardware components on which the software components are
installed.
- To
describe the processing of nodes at the runtime.
Symbol and notation of
Deployment diagram
The deployment diagram consist of the following notations:
- A
component
- An
artifact
- An
interface
- A
node
How to draw a Deployment
Diagram?
The deployment diagram portrays the deployment view of the
system. It helps in visualizing the topological view of a system. It
incorporates nodes, which are physical hardware. The nodes are used to execute
the artifacts. The instances of artifacts can be deployed on the instances of
nodes.
Since it plays a critical role during the administrative
process, it involves the following parameters:
- High
performance
- Scalability
- Maintainability
- Portability
- Easily
understandable
One of the essential elements of the deployment diagram is the
nodes and artifacts. So it is necessary to identify all of the nodes and the
relationship between them. It becomes easier to develop a deployment diagram if
all of the nodes, artifacts, and their relationship is already known.
Example of a Deployment
diagram
A deployment diagram for the Apple iTunes application is given
below.
The iTunes setup can be downloaded from the iTunes website, and
also it can be installed on the home computer. Once the installation and the
registration are done, iTunes application can easily interconnect with the
Apple iTunes store. Users can purchase and download music, video, TV serials,
etc. and cache it in the media library.
Devices like Apple iPod Touch and Apple iPhone can update its
own media library from the computer with iTunes with the help of USB or simply
by downloading media directly from the Apple iTunes store using wireless
protocols, for example; Wi-Fi, 3G, or EDGE.
When to use a Deployment
Diagram?
The deployment diagram is mostly employed by network engineers,
system administrators, etc. with the purpose of representing the deployment of
software on the hardware system. It envisions the interaction of the software
with the hardware to accomplish the execution. The selected hardware must be of
good quality so that the software can work more efficiently at a faster rate by
producing accurate results in no time.
The software applications are quite complex these days, as they
are standalone, distributed, web-based, etc. So, it is very necessary to design
efficient software.
Deployment diagrams can be used for the followings:
- To
model the network and hardware topology of a system.
- To
model the distributed networks and systems.
- Implement
forwarding and reverse engineering processes.
- To
model the hardware details for a client/server system.
- For
modeling the embedded system.
Comments
Post a Comment