MODULE -3

UML
UML is a pictorial language used to make software blueprints. UML can be
described as a general purpose visual modeling language to visualize,
specify, construct, and document software system.Although UML is
generally used to model software systems, it is not limited within this
boundary. It is also used to model non-software systems as well. For
example, the process flow in a manufacturing unit, etc.
There are two broad categories of diagrams and they are again divided into
subcategories −
• Structural Diagrams
• Behavioral Diagrams

Structural Diagrams
The structural diagrams represent the static aspect of the system. These static
aspects represent those parts of a diagram, which forms the main structure and are
therefore stable.
These static parts are represented by classes, interfaces, objects, components, and
nodes. The four structural diagrams are −

• Class diagram
• Object diagram
• Component diagram
• Deployment diagram

Class Diagram

Class diagrams are the most common diagrams used in UML. Class diagram
consists of classes, interfaces, associations, and collaboration. Class diagrams
basically represent the object-oriented view of a system, which is static in nature.
Active class is used in a class diagram to represent the concurrency of the system.
Class diagram represents the object orientation of a system. Hence, it is generally
used for development purpose. This is the most widely used diagram at the time of
system construction.
Class diagram describes the attributes and operations of a
class and also the constraints imposed on the system. The
class diagrams are widely used in the modeling of
objectoriented systems.
Purpose of class diagram
• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.

• Forward and reverse engineering.

Object Diagram

Object diagrams can be described as an instance of class diagram. Thus, these

diagrams are more close to real-life scenarios where we implement a system.
Object diagrams are a set of objects and their relationship is just like class
diagrams. They also represent the static view of the system.
The usage of object diagrams is similar to class diagrams but they are used to
build prototype of a system from a practical perspective.

Component Diagram

Component diagrams represent a set of components and their relationships. These

components consist of classes, interfaces, or collaborations. Component diagrams
represent the implementation view of a system.
During the design phase, software artifacts (classes, interfaces, etc.) of a system
are arranged in different groups depending upon their relationship. Now, these
groups are known as components.
Finally, it can be said component diagrams are used to visualize the
implementation.
Component diagrams are different in terms of nature and
behavior.Component diagrams are used to model the physical
aspects of a system.
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 diagrams can be used to –
•Model the components of a
system.
• Model the database schema.
• Model the executables of an application.
• Model the system's source code.
Deployment Diagram

Deployment diagrams are a set of nodes and their relationships. These nodes are
physical entities where the components are deployed.
Deployment diagrams are used for visualizing the deployment view of a system.
This is generally used by the deployment team.

Symbol and notation of Deployment diagram

The deployment diagram consist of the following notations:

1. A component
2. An artifact
3. An interface
4. A node
Behavioral Diagrams
Any system can have two aspects, static and dynamic. So, a model is considered
as complete when both the aspects are fully covered.
Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic
aspect can be further described as the changing/moving parts of a system.
UML has the following five types of behavioral diagrams −

• Use case diagram

• Sequence diagram
• Collaboration diagram
• Statechart diagram
• Activity diagram

Use Case Diagram

Use case diagrams are a set of use cases, actors, and their
relationships. They represent the use case view of a system.A use
case represents a particular functionality of a system. Hence, use
case diagram is used to describe the relationships among the
functionalities and their internal/external controllers. These
controllers are known as actors.UML is a pictorial language used
to make software blueprints.UML can be described as a general
purpose visual modeling language to visualize, specify, construct,
and document software system.Although UML is generally used to
model software systems, it is not limited within this boundary. It is
also used to model non-software systems as well. For example, the
process flow in a manufacturing unit, etc.

purpose of use-case diagram

• It is 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.
Example of use-case diagram
INTERACTION DIAGRAM

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 UML interaction diagram

• The purpose of interaction diagrams is to visualize the interactive
behavior of the system.
• 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.

Sequence Diagram

A sequence diagram is an interaction diagram. From the name, it is clear that the
diagram deals with some sequences, which are the sequence of messages flowing
from one object to another.
Interaction among the components of a system is very important from
implementation and execution perspective. Sequence diagram is used to visualize
the sequence of calls in a system to perform a specific functionality.

• The sequence diagram has four objects (Customer, Order,

SpecialOrder and NormalOrder).
• The 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.

Collaboration Diagram

Collaboration diagram is another form of interaction diagram. It represents the

structural organization of a system and the messages sent/received. Structural
organization consists of objects and links.
The purpose of collaboration diagram is similar to sequence diagram. However,
the specific purpose of collaboration diagram is to visualize the organization of
objects and their interaction.
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.
A sample diagram of collaboration diagram is shown below.
Statechart Diagram

Any real-time system is expected to be reacted by some kind of internal/external

events. These events are responsible for state change of the system.
Statechart diagram is used to represent the event driven state change of a system.
It basically describes the state change of a class, interface, etc.
State chart diagram is used to visualize the reaction of a system by
internal/external factors. 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.AStatechart 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.
Purpose of drawing state chart diagram
• 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.

Activity Diagram

Activity diagram describes the flow of control in a system. It consists of activities

and links. The flow can be sequential, concurrent, or branched.
Activities are nothing but the functions of a system. Numbers of activity diagrams
are prepared to capture the entire flow in a system.
Activity diagrams are used to visualize the flow of controls in a system. This is
prepared to have an idea of how the system will work when executed.
• 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
• 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.

UML package diagram and purpose

• Package diagram, a kind of structural diagram, shows the arrangement and
organization of model elements in middle to large scale project. Package
diagram can show both structure and dependencies between sub-systems or
modules, showing different views of a system.
• Package Diagram can be used to simplify complex class diagrams, it can
group classes into packages.
• A package is a collection of logically related UML elements.
• Packages are depicted as file folders and can be used on any of the UML
diagrams.
The diagram below shows the classes are grouped into packages:
• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.
• One package depends on another if changes in the other could possibly
force changes in the first.
UML diagram organization

Uml model management provides a mechanism for diagram organization that

consists of
1.Package
2.dependency relationship in Package

Package
A package is an organized group of elements. A package may contain structural
things like classes, components, and other packages in it.
Notation − Graphically, a package is represented by a tabbed folder. A package is
generally drawn with only its name. However it may have additional details about
the contents of the package. See the following figures.

Package is the UML mechanism for grouping things. It can be used to:

● group semantically related elements;

● define a “semantic boundary” in the model;
● provide units for parallel working and configuration management;
 ● package is used to provide an encapsulated namespace within which all
names must be unique.

Visibilities of elements inside a package

An element with public visibility are visible to elements outside the package and
they are exported by the package and are represented by pre-pending ‘+’.

An element with private visibility are completely hidden inside the package and
are represented by pre-pending ‘-‘.
Standard package stereotypes

<<framework>> – if the package contains model elements that specify a

reusable architecture. <<modelLibrary>> – if the package contains

elements that are intented to be reused by other packages.

A package define automatically an encapsulated namespace which means within

the package boundary all elements name are unique. A qualified name is the
representation by which an element inside a package is accessed. It is indicated
with the help of ‘::’. foreg:- a class Librarian inside a package users which again
is inside in Library is accessed as Library:: Users:: Librarian

Nested packages

Packages may be nested inside other packages to any depth. Two possible
representations of nested packages are shown in Figure:2. First one is commonly
used.
Package dependencies

A dependency relationship indicates that one package depends in some way on

another. Different dependency are explained below.

«use»– This means that an element in the client uses a public element in the
supplier in some way i.e the client depends on the supplier. If a package
dependency is shown without a stereotype, then «use» should be assumed.
Shown in Figure:3.

Figure:3 Use dependency

«import»– Public elements of the supplier namespace are added as public

elements to the client namespace. Elements in the client can access all public
elements in the supplier using unqualified names. Shown in Figure:4.

Figure:4 import dependency

«access»– Public elements of the supplier namespace are added as private
elements to the client namespace. Elements in the client can access all public
elements in the supplier using unqualified names. Shown in Figure:5.

Figure:5 access dependency

«trace»– «trace» usually represents an historical development of one element into

another more developed version – it is usually a relationship between models
rather than elements.A complete UML model can be represented by a package
with a small triangle in its top right hand corner. Shown in Figure:6.

Figure:6 trace dependency

«merge»– Public elements of the supplier package are merged with elements of
the client package. used only in meta modeling, not used in OO analysis and
design. Shown in Figure:7.

Figure:7 merge dependency

Transitivity

Transitivity means that if there is a relationship between thing A and thing B and a
relationship between thing B and thing C, then there is an implicit relationship
between thing A and thing C. «access» dependency is not transitive and «import»
dependency is transitive. This is illustrated in Figure: 8.
 Figure:8 package-transitivity

UML diagram Extensions

The UML provides a standard language for writing software blueprints, but it is
not possible for one closed language to ever be sufficient to express all possible
nuances of all models across all domains across all time. For this reason, the
UML is opened-ended, making it possible for you to extend the language in
controlled ways.
UML defines three extensibility mechanisms to allow modelers to add extensions
without having to modify the underlying modeling language. These three
mechanisms are:
• Stereotypes
• Constraints
• tagged values

Stereotypes
A stereotype extends the vocabulary of the UML, allowing you to create new
kinds of building
blocks that are derived from existing ones but that are specific to your problem.
They are used for classifying or marking the UML building blocks in order to
introduce new building blocks that speak the language of your domain and that
look like primitive, or basic, model elements.

For example, if you are working in a programming language, such as Java or

C++, you will often want to model exceptions. In these languages, exceptions are
just classes, although they are treated in very special ways. Typically, you only
want to allow them to be thrown and caught, nothing else. You can make
exceptions first-class citizens in your models, meaning that they are treated like
basic building blocks, by marking them with an appropriate stereotype, as for the
class Overflow as shown in the Figure below:

Tagged Values
A tagged value extends the properties of a UML building block, allowing you to
create new information in that element’s specification. They are properties for
specifying keyword-value pairs of model elements, where the keywords are
attributes. They allow you to extend the properties of a UML building block so
that you create new information in the specification of that element. Tagged
Values can be defined for existing model elements, or for individual stereotypes
so that everything with that stereotype has that tagged value. It is important to
mention that a tagged value is not equal to a class attribute. Instead, you can
regard a tagged value as being metadata, since its value applies to the element
itself and not to its instances.
Graphically, a tagged value is rendered as a string enclosed by brackets, which is
placed below the name of another model element. The string consists of a name
(the tag), a separator (the symbol =), and a value (of the tag) as shown in the
Figure below:

You can specify just the value if its meaning is unambiguous, such as when the
value is the name of the enumeration.
 Usage of Tagged Values
One of the most common uses of a tagged value is to specify properties that are
relevant to code generation or configuration management. So, for example, you
can make use of a tagged value in order to specify the programming language to
which you map a particular class, or you can use it to denote the author and the
version of a component.
Constraints
A constraint is an extension of the semantics of a UML element, allowing you to
add new rules or to modify existing ones. They allow you to extend the semantics
of a UML building block by adding new rules or modifying existing ones. A
constraint specifies conditions that must be held true for the model to be well-
formed. This notation can also be used to adorn a model element’s basic notation,
in order to visualize parts of an element’s specification that have no graphical
cue. For example, you can use constraint notation to provide some properties of
associations, such as order and changeability
Graphically, a constraint is rendered as a string enclosed by brackets and placed
near the associated element or connected to that element or elements by
dependency relationships. The example below shows, you might want to specify
that, across a given association, communication is encrypted. Similarly, you
might want to specify that among a set of associations, only one is manifest at a
time.
SOFTWARE DESIGN
Software Design is the process to transform the user requirements into some
suitable form, which helps the programmer in software coding and
implementation. During the software design phase, the design document is
produced, based on the customer requirements as documented in the SRS
document. Hence the aim of this phase is to transform the SRS document into the
design document.
The following items are designed and documented during the design phase:

• Different modules required.

• Control relationships among modules.
• Interface among different modules.
• Data structure among the different modules.
• Algorithms required to implement among the individual modules.
Objectives of Software Design:

1. Correctness:
A good design should be correct i.e. it should correctly implement all the
functionalities of the system.
2. Efficiency:
A good software design should address the resources, time, and cost
optimization issues.
3. Understandability:
A good design should be easily understandable, for which it should be
modular and all the modules are arranged in layers.
4. Completeness:
The design should have all the components like data structures, modules, and
external interfaces, etc.
5. Maintainability:
A good software design should be easily amenable to change whenever a
change request is made from the customer side.
Software Design Concepts:
Concepts are defined as a principal idea or invention that comes into our mind or
in thought to understand something. The software design concept simply means
the idea or principle behind the design. It describes how you plan to solve the
problem of designing software, the logic, or thinking behind how you will design
software. It allows the software engineer to create the model of the system or
software or product that is to be developed or built. The software design concept
provides a supporting and essential structure or model for developing the right
software. There are many concepts of software design and some of them are
given below:
The following points should be considered while designing Software:

1. Abstraction- hide Irrelevant data

Abstraction simply means to hide the details to reduce complexity and
increases efficiency or quality. Different levels of Abstraction are necessary
and must be applied at each stage of the design process so that any error that is
present can be removed to increase the efficiency of the software solution and
to refine the software solution. The solution should be described in broad ways
that cover a wide range of different things at a higher level of abstraction and
a more detailed description of a solution of software should be given at the
lower level of abstraction.
2. Modularity- subdivide the system
Modularity simply means dividing the system or project into smaller parts to
reduce the complexity of the system or project. In the same way, modularity in
design means subdividing a system into smaller parts so that these parts can be
created independently and then use these parts in different systems to perform
different functions. It is necessary to divide the software into components
known as modules because nowadays there are different software available
like Monolithic software that is hard to grasp for software engineers. So,
modularity in design has now become a trend and is also important. If the
system contains fewer components then it would mean the system is complex
 which requires a lot of effort (cost) but if we are able to divide the system into
components then the cost would be small.
3. Architecture- design a structure of something
Architecture simply means a technique to design a structure of something.
Architecture in designing software is a concept that focuses on various
elements and the data of the structure. These components interact with each
other and use the data of the structure in architecture.
4. Refinement- removes impurities
Refinement simply means to refine something to remove any impurities if
present and increase the quality. The refinement concept of software design is
actually a process of developing or presenting the software or system in a
detailed manner that means to elaborate a system or software. Refinement is
very necessary to find out any error if present and then to reduce it.
5. Pattern- a repeated form
The pattern simply means a repeated form or design in which the same shape
is repeated several times to form a pattern. The pattern in the design process
means the repetition of a solution to a common recurring problem within a
certain context.
6. Information Hiding- hide the information
Information hiding simply means to hide the information so that it cannot be
accessed by an unwanted party. In software design, information hiding is
achieved by designing the modules in a manner that the information gathered
or contained in one module is hidden and can’t be accessed by any other
modules.
7. Refactoring- reconstruct something
Refactoring simply means reconstructing something in such a way that it does
not affect the behavior of any other features. Refactoring in software design
means reconstructing the design to reduce complexity and simplify it without
affecting the behavior or its functions. Fowler has defined refactoring as “the
process of changing a software system in a way that it won’t affect the
behavior of the design and improves the internal structure”.
Different levels of Software Design:
There are three different levels of software design. They are:

1. Architectural Design:
The architecture of a system can be viewed as the overall structure of the
system & the way in which structure provides conceptual integrity of the
system. The architectural design identifies the software as a system with many
components interacting with each other. At this level, the designers get the
 idea of the proposed solution domain.

2. Preliminary or high-level design:

Here the problem is decomposed into a set of modules, the control relationship
among various modules identified, and also the interfaces among various
modules are identified. The outcome of this stage is called the program
architecture. Design representation techniques used in this stage are structure
chart and UML.

3. Detailed design:
Once the high-level design is complete, a detailed design is undertaken. In
detailed design, each module is examined carefully to design the data structure
and algorithms. The stage outcome is documented in the form of a module
specification document.

Functional independence

Functional independence occurs where modules (such as a package or class) address a

specific and constrained range of functionality. The modules provide interfaces only to this
functionality. By constraining their functionality, the modules require the help of fewer other
modules to carry out their functionality.

The functional independence of a module can be judged using two

concepts: cohesion and coupling: cohesion is the degree to which a module performs only one
function. coupling is the degree to which a module requires other modules to perform its
function.

Functional independence makes modules easier to develop and test. Changes made to how
they perform their function are less likely to affect the software as a whole.

Functional independence is one of the goals of using information hiding and modularity.

coupling and cohesion

Coupling: Coupling is the measure of the degree of interdependence
between the modules. A good software will have low coupling.
Types of Coupling:

● Data Coupling: If the dependency between the modules is based on the

fact that they communicate by passing only data, then the modules are said
to be data coupled. In data coupling, the components are independent to
each other and communicating through data. Module communications
don’t contain tramp data. Example-customer billing system.

● Stamp Coupling :In stamp coupling, the complete data structure is passed
from one module to another module. Therefore, it involves tramp data. It
may be necessary due to efficiency factors- this choice made by the
insightful designer, not a lazy programmer.

● Control Coupling: If the modules communicate by passing control

information, then they are said to be control coupled. It can be bad if
parameters indicate completely different behavior and good if parameters
allow factoring and reuse of functionality. Example- sort function that takes
comparison function as an argument.

● External Coupling: In external coupling, the modules depend on other

modules, external to the software being developed or to a particular type of
hardware. Ex- protocol, external file, device format, etc.
● Common Coupling: The modules have shared data such as global data
structures.The changes in global data mean tracing back to all modules
which access that data to evaluate the effect of the change. So it has got
 disadvantages like difficulty in reusing modules, reduced ability to control
data accesses and reduced maintainability.

● Content Coupling: In a content coupling, one module can modify the data
of another module or control flow is passed from one module to the other
module. This is the worst form of coupling and should be avoided.

Cohesion: Cohesion is a measure of the degree to which the elements of the

module are functionally related. It is the degree to which all elements directed
towards performing a single task are contained in the component. Basically,
cohesion is the internal glue that keeps the module together. A good software
design will have high cohesion.

Types of Cohesion:

● Functional Cohesion: Every essential element for a single computation is

contained in the component. A functional cohesion performs the task and
functions. It is an ideal situation.

● Sequential Cohesion: An element outputs some data that becomes the

input for other element, i.e., data flow between the parts. It occurs naturally
in functional programming languages.

● Communicational Cohesion: Two elements operate on the same input

data or contribute towards the same output data. Example- update record int
the database and send it to the printer.
 ● Procedural Cohesion: Elements of procedural cohesion ensure the order
of execution. Actions are still weakly connected and unlikely to be
reusable. Ex- calculate student GPA, print student record, calculate
cumulative GPA, print cumulative GPA.
● Temporal Cohesion: The elements are related by their timing involved. A
module connected with temporal cohesion all the tasks must be executed in
the same time-span. This cohesion contains the code for initializing all the
parts of the system. Lots of different activities occur, all at init time.

● Logical Cohesion: The elements are logically related and not functionally.
Ex- A component reads inputs from tape, disk, and network. All the code
for these functions is in the same component. Operations are related, but
the functions are significantly different.

● Coincidental Cohesion: The elements are not related(unrelated). The

elements have no conceptual relationship other than location in source
code. It is accidental and the worst form of cohesion. Ex- print next line
and reverse the characters of a string in a single component.

Object-Oriented Design

In the object-oriented design method, the system is viewed as a collection of objects

(i.e., entities). The state is distributed among the objects, and each object handles its
state data. For example, in a Library Automation Software, each library
representative may be a separate object with its data and functions to operate on
these data. The tasks defined for one purpose cannot refer or change data of other
objects. Objects have their internal data which represent their state. Similar objects
create a class. In other words, each object is a member of some class. Classes may
inherit features from the superclass.

The different terms related to object design are:

1. Objects: All entities involved in the solution design are known as objects. For
example, person, banks, company, and users are considered as objects. Every
entity has some attributes associated with it and has some methods to perform
on the attributes.
2. Classes: A class is a generalized description of an object. An object is an
instance of a class. A class defines all the attributes, which an object can have
and methods, which represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist of
the integrity of the target object, the name of the requested operation, and any
other action needed to perform the function. Messages are often implemented
as procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using
abstraction. Abstraction is the removal of the irrelevant and the amplification
of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept.
The data and operations are linked to a single unit. Encapsulation not only
bundles essential information of an object together but also restricts access to
the data and methods from the outside world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner
where the lower or sub-classes can import, implement, and re-use allowed
variables and functions from their immediate superclasses.This property of
OOD is called an inheritance. This makes it easier to define a specific class
and to create generalized classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned the same
name. This is known as polymorphism, which allows a single interface is
performing functions for different types. Depending upon how the service is
invoked, the respective portion of the code gets executed.

Software design model

Following are the types of design models:

1. Data design
● The data design element produced a model of data that represent a high level

of abstraction.

● This model is then more refined into more implementation specific

representation which is processed by the computer based system. ● The

structure of data is the most important part of the software design.

2. Architectural design
● The architecture design elements provides us overall view of the system. ●

The architectural design element is generally represented as a set of

interconnected subsystem that are derived from analysis packages in the

requirement model.
The architecture model is derived from following sources:● The
information about the application domain to built the software.
● Requirement model elements like data flow diagram or analysis classes,

relationship and collaboration between them.

● The architectural style and pattern as per availability.

3. Interface design
● The interface design elements for software represents the information

flow within it and out of the system.

● They communicate between the components defined as part of

architecture.

Following are the important elements of the interface design:1.

The user interface
2. The external interface to the other systems, networks
etc.3. The internal interface between various components.

4. Component level diagram

● The component level design for software is similar to the set of detailed

specification of each room in a house.

● The component level design for the software completely describes the

internal details of the each software component.

● The processing of data structure occurs in a component and an interface

which allows all the component operations.

● In a context of object-oriented software engineering, a component shown in a

UML diagram.

● The UML diagram is used to represent the processing logic.

5. Deployment level design

● The deployment level design element shows the software functionality

and subsystem that allocated in the physical computing environment which

support the software.

● Following figure shows three computing environment as shown. These are

the personal computer, the CPI server and the Control panel.