Software Design Phase in SDLC

Software design is a phase that comes after the requirement analysis of the software. In
this phase, the requirements of the software are represented in a form that is suitable as
per the customer’s demand, and that can easily be implemented through any coding
language by the software developers.

The software design is like a blueprint of the software. This can be related to the
construction of a building. Before constructing any building, a blueprint of that building
is created and according to that blueprint, further construction is carried out. For a
similar purpose, in the case of software development, we make software design. After
the design phase, the software undergoes the coding and implementation phase. In this
phase, different developers work on different modules. So, for any kind of reference or
any help, they refer to this software design.

While designing any software, we do it mainly in two different phases. They are:

1. Preliminary Design
2. Detailed Design

1) Preliminary Design
In the preliminary design, a rough design of the software is proposed by several
designers according to the customer requirements. In the preliminary design, various
designs of the software are made, accepted, rejected and modified. After reaching a
stage in which the design seems to fulfill all the customer requirements, a set of trained
software designers make the final design of the software.

2) Detailed Design
 The final design that is made at the end of the preliminary design phase is called the
detailed design. After this design is made, no further changes are made in the design of
the software, and the design is sent to the development team for further work.

The design phase of the software is very crucial in the software development process.
This is because if the design of the software is not accurate to fulfill all the requirements
of the user, then the software that will be developed will also look those things because
the software will follow the design only. So, for making good quality software, the
design of the software should also be proper and accurate. So, each design in the
preliminary stage must be evaluated in every manner before being finalized as the
design for the software.

Things developed in the design phase of the

software | Software Engineering
In the design phase, the design of the software is made which represents how the
software would be like when completely developed and launched as a final product. As
there are numerous components in software, the design of every component must be
made, as the developer will refer to the design only while developing that particular
component. The design of the software is made keeping in mind that it can be easily
implemented through a programming language.

In the design phase, we design the following things are for any software:

1. Different modules:
Every module that the software contains or may contain must be designed.
2. Control Flow:
Every module is related to some other module and each module is controlled by some other
module. This control that takes place within the modules must be well defined in the software
design.
3. Data flow:
A software consists of different activities, or pages or segments. Each activity transfers or
receives some data from other activities. This data flow must also resemble the software design
so that the developers can understand it and implement the data flow in the software according
to it.
4. Data structures:
The data structure that the software will be using is represented in the design of the software.
 The data structure followed by each module is represented separately even after these modules
may be following the same data structures.
5. Algorithms (Flow charts):
The algorithms are represented pictorially in the software design through flow charts.
6. User Interfaces:
The interfaces of the software at every phase are also defined in the software design. They are
must to be defined in software design. They resemble how the software would appear to the
user at each state.
7. Interface among different modules:
This defines how and in what manner the different modules of the software are related to each
other. This may be in terms of data control, flow control or may be affected by the action of
some other activity indirectly.

For good quality software to be produced, the software design must also be of good
quality. Now, the matter of concern is how the quality of good software design is
measured? This is done by observing certain factors in software design. These factors
are:

1. Correctness
2. Understandability
3. Efficiency
4. Maintainability

Now, let us define each of them in detail,

1) Correctness
First of all, the design of any software is evaluated for its correctness. The evaluators
check the software for every kind of input and action and observe the results that the
software will produce according to the proposed design. If the results are correct for
every input, the design is accepted and is considered that the software produced
according to this design will function correctly.

2) Understandability
The software design should be understandable so that the developers do not find any
difficulty to understand it. Good software design should be self- explanatory. This is
because there are hundreds and thousands of developers that develop different
modules of the software, and it would be very time consuming to explain each design to
each developer. So, if the design is easy and self- explanatory, it would be easy for the
developers to implement it and build the same software that is represented in the
design.

3) Efficiency
The software design must be efficient. The efficiency of the software can be estimated
from the design phase itself, because if the design is describing software that is not
efficient and useful, then the developed software would also stand on the same level of
efficiency. Hence, for efficient and good quality software to be developed, care must be
taken in the designing phase itself.

4) Maintainability
The software design must be in such a way that modifications can be easily made in it.
This is because every software needs time to time modifications and maintenance. So,
the design of the software must also be able to bear such changes. It should not be the
case that after making some modifications the other features of the software start
misbehaving. Any change made in the software design must not affect the other
available features, and if the features are getting affected, then they must be handled
properly.

Cohesion
In general terms, the word cohesion means 'the action or act of forming a united
whole'. According to the definition of Cambridge University, cohesion is defined as "the
state of sticking together, or being in close agreement and working well together".

Now, if we talk about software, the developers and researchers nowadays are trying to
develop software in a component-based approach. In this, the entire software is divided
into different modules. These modules are developed independently and are capable of
performing some specific functionality. Now, for the software to be efficient, these
modules must have high cohesion. What this means is that the same types of
functionalities and behavior must be performed by a single module. Now, as the same
type of functionalities is performed in a united way together in a single module, the
quality of the software will automatically increase, and also the component-based
structure of the software would make it easier for the developers to understand it better
and handle it efficiently in case of error and bugs.
Now, the cohesion of a module is further classified into different classes. This
classification is done based on the level of cohesion that a particular module possesses.
The different classes of cohesion are as follows:

The sequence of the given classification is from high to low in a top-to-down manner.
Now, let us define each of them to understand what they mean:

Functional Cohesion: If a single module aims to perform all the similar types of
functionalities through its different elements, then the module is said to exhibit
functional cohesion.

Sequential Cohesion: In the sequential cohesion, the different elements of a module

form a series, in which the output of one element treats as an input to the other
elements inside the same module. Hence, a sequence inside the module is formed.
Communicational Cohesion: If all the elements of a module are working on the same
data and are accessing that data through the same data structures, then this is called
communicational cohesion.

Procedural Cohesion: If all the elements of a module are a part of the same procedure,
i.e. algorithm, then that particular module is said to possess procedural cohesion.

Temporal Cohesion: In the temporal cohesion, the different elements of a module are
united through the time stamp. All these elements of the module will work in the same
timestamp, and here, the time is handled strictly. The login and shutdown processes are
very good examples of temporal cohesion.

Logical Cohesion: A module is said to exhibit logical cohesion if all its elements perform
the same type of logical operations. For example, if a module is performing the sorting
operation, then all the processes that need to perform sorting in them will be handled
by this module only.

Coupling
In general terms, the term coupling is defined as a thing that joins together two objects.
If we talk about software development, then the term coupling is related to the
connection between two modules, i.e. how tight interaction do the two modules hold
with each other is defined by coupling.

Hence, the term coupling is defined as follows: "“The measure of the degree of the

interdependency of two modules on each other is known as coupling."

It should be noted that a module that has high cohesion and low coupling is
functionally independent.

How can the coupling between two modules be defined?

The interconnection of interdependency between two modules is defined by the

interface between them because any two modules cannot be connected if there exists
no interface between them. Now, the level of coupling that exists among the two
modules is defined by the number of data transfers that take place among them. If any
of the modules (or both) is highly dependent on the data that the other module
provides to it, then we say that the two modules are highly coupled. Else, we say that
the two modules are loosely coupled or the coupling between the modules is low.
Now, the term coupling is further classified into different classes which help us to
quantitatively determine the level of coupling between two modules. The different
classes of coupling are as follows:

The sequence of the given classification is from high to low in a top-to-down manner.
Now, let us define each of them to understand what they mean:

Content Coupling: In the content coupling, the two modules are connected as they
share the same content. What this means is that the content, i.e. the code of both the
modules, has some parts in common which are the functions and methods that are used
by both of the modules. This type of coupling is termed to be the strongest type of
coupling.
Common Coupling: Two modules are said to be commonly coupled if they share the
data using the same data items (i.e. the variables). These data items must be in global
access to both of the modules so that both the modules can be able to access these
data items.

Control Coupling: If the data from the module is responsible for controlling the
activities happening in another module, then these modules are said to be control
coupled. Here, mostly, one or two bits of signal data are passed which controls the
operations happening in some other module. A well-known example of this can be the
set of flags of a module by some other module.

Stamp Coupling: Two modules are said to be stamp coupled if they both use a
composite data item to interact with each other.

Data Coupling: This type of coupling is the weakest one. Two modules are said to be
data coupled if they communicate through some parameters. An example can be of the
parameters that are passed to a function block.

Different types of design strategies in

Software Engineering
As we know that the designing phase is probably the second phase in the software
development lifecycle, which comes after the feasibility testing and requirement analysis
phase. As the name itself defines that in this phase, the software is designed which
reflects how our software must be, what functionalities must it contain, how the user
interface should be, etc. But, it is important to know the strategy that the software
designers follow while developing any software. In this article, we are going to discuss
the same.

In general, there are two types of designing strategies that are mainly followed in the
designing phase of any software during its development:

1. Function- oriented design

2. Object- oriented design

Now, let us define each of them in brief and understand the strategies behind each of
them:

1) Function- oriented design

In the function-oriented design, the system is designed according to the functionality it
offers. The system is first widely observed and then each of its functions is observed to
identify the sub-functions that it consists of that are responsible for performing that
particular functionality.

In this type of design, there is a centralized function that consists of various functions.
The software is designed in the same manner.

For example, consider software for the calculator. Its main function is to calculate
various operations and print the result. Now, the sub functionalities that it offers are the
operations modulus, logarithm, square, exponent, etc. Now all these functions further
consist of the fundamental operations like addition, subtraction, etc. Like multiplication
is the result of repeated addition, etc.

In the same way in software, an element may further sub-elements for performing its
inner functions and it may also act as a sub-element for some other module. However
together they are responsible for providing the functionality that the entire software
claims to offer.

2) Object- oriented design

In the object-oriented design approach to design any software, everything is considered
as an object. Now, every object performs some activities and possess some behavior.
This is defined through classes because all the objects that belong to the same class will
exhibit a similar kind of behavior and will also perform similar functionalities. However,
every object will be different from the other object in some manner. Now, this is
determined at the time of object creation when the object is initialized with some values
which provide the object its unique behavior.

The object-oriented design approach is termed better than the function-oriented design
approach as in the object-oriented approach, the real-world entities can easily be
implemented in the computer world. Also, some very basic object behaviors such as
polymorphism, inheritance, abstraction, and encapsulation are implementable through
this approach.
A software model - the importance of a
model in a software
What is a software model?
A software model describes all the important aspects of the software, hiding the rest of
them. In other words, the software model represents only the useful and required
aspects of any software and all the other aspects that are not much important to
showcase are abstracted.

The software model is most of the time confused with software design, but both of
them are two different things. The software design is a detailed representation of the
entire software, but as already mentioned, the software model contains only the
important things.

Also, the software model is created before the requirement analysis phase of the
software while the software design is made after the analysis phase. It can be said that
the software design is probably for the developers so that they can easily understand
each requirement of the user and how it should be implemented inside the software. On
the other hand, the software model is for the people who need to understand the
software but not as deeply as the developers, as they are not meant for the developing
purpose. An example of this can be investors.

Why do we need a software model?

A software model is a very useful tool in software development. Through the software
model, the complexity of the entire software can be analyzed and also the strategy
behind the development of the software can be estimated.

A software model once created is useful in every phase of the software development:
from the ideation phase to the retirement phase. All the other phases that fall in
between these two phases and in which the software model is termed useful are as
follows:

 Analysis phase (of the feasibility and the software requirements)

 Specification phase
 Designing phase
 Visualizing and understanding of the design
 Coding and implementation phase
  Unit Testing phase (Done by the developer)
 Integration phase (bringing all the modules together)
 Sample testing phase (done by the tester)
 And the software model is sometimes used as a reference in the maintenance phase also

Introduction to UML: Unified Modeling

Language
UML, which stands for unified modeling language is a language used for modeling
purposes. When the software design or software model is created, different diagrams
for the software are to be created, like the use case diagrams, activity diagrams, data
flow diagrams, etc. So, to provide ease to the software designers, the UML was created.
This Language already has a set of specified elements that are often used while making
the software models, like rectangles for classes, eclipse for use cases, etc. This set of
elements can be readily used by the system designers without having to, again and
again, specify the shapes for what purpose they are being used for.

It should be noted that though UML is a modeling language, though it follows its

particular syntax like the programming languages, and if this syntax is not followed, then
your model diagram is not considered appropriate and there may be chances that your
model is missing some element or some relation between the elements.

The UML is used to design the software which follows the object-oriented design
strategy. Thus, all the models which are used to represent the object-oriented software
model pictorially, like the activity diagram, use case diagram, class diagram, etc., can all
be represented through this language, i.e. UML.

Salient Features of the Unified Modelling Language (UML)

 UML is not the system design or any model methodology, but it is a modeling language
that can help us make the system design and models.
 The UML is used to pictorially represent the Object-Oriented software models.
 The UML was proposed to validate a standard notation and specific principles to all the
models that were being designed. This was done so that a common procedure could be
set for the designing of the software.
 It has specified notations for all the diagrams and elements and also has a defined
structure for each of them. This syntax cannot be violated. This ensures the correctness in
the model diagrams that no element or relation in the model is missing.

Views that can be implemented through the UML Diagram

The UML is used for designing various diagrams, but it is important to note the different
views that can be implemented with the help of the UML. 5 different views can be
visualized through the UML. These five views are as follows:

1. User's Views
2. Structural Views
3. Behavioral Views
4. Environmental View
5. Implementation View

Through these views, 9 different types of diagrams for the software model can be
represented.

There are five different views that the UML aims to visualize through different modeling
diagrams. These five views are:

1. User's View
2. Structural Views
3. Behavioral Views
4. Environmental View
5. Implementation View

Now, these views just provide the thinking methodology and expectations (that people
have formed the software) of different groups of people. However, we still need to
diagrammatically document the system requirements, and this is done through 9
different types of UML diagrams. These diagrams are divided into different categories.
These categories are nothing else but these views that we mentioned earlier.

The different software diagrams according to the views they implement are:

1) User's view
This contains the diagrams in which the user's part of interaction with the software is
defined. No internal working of the software is defined in this model. The diagrams
contained in this view are:

 Use case Diagram

2) Structural view
In the structural view, only the structure of the model is explained. This gives an
estimate of what the software consists of. However, internal working is still not defined
in this model. The diagram that this view includes are:

 Class Diagrams
 Object Diagrams

3) Behavioral view
The behavioral view contains the diagrams which explain the behavior of the software.
These diagrams are:

 Sequence Diagram
 Collaboration Diagram
 State chart Diagram
 Activity Diagram

4) Environmental view
The environmental view contains the diagram which explains the after deployment
behavior of the software model. This diagram usually explains the user interactions and
software effects on the system. The diagrams that the environmental model contain are:

 Deployment diagram

5) Implementation view
The implementation view consists of the diagrams which represent the implementation
part of the software. This view is related to the developer’s views. This is the only view in
which the internal workflow of the software is defined. The diagram that this view
contains is as follows:

 Component Diagram

The following diagram well explains the distribution of these 9 software diagrams
according to the five mentioned views:
The Use Case Model (or the Use case Diagram) is a diagrammatic representation of
the software in which each piece of coherent behavior of the software is represented
through a use case. Each use case represents some activity or interaction that may take
place between different users.

Benefits of the use case diagram

 The use case model very effectively provides an overview of what activities and
use cases take place between the different kinds of users using the software.
 It does not provide the internal working structure of the software. Only the
activities that will be experienced by the user at the front end will be displayed in
this model using the use cases.
 The internal working is kept confidential.

Disadvantages of the use-case model

 The internal structure of the software cannot be estimated to completely form
the use case diagram of the software.
  The algorithm and data structures used, the data flow and the control flow that
takes place within the different fragments of the software cannot be represented
through the use case diagrams.

How to represent the use-case diagram?

The use case Diagram consists of use cases and actors. The use cases are represented
through an eclipse that consists of the name of the use case within it. All the use cases
that the software consists are mentioned in the diagram. Now, the different kinds of
actors or we can say the users that interact with the software are represented through
the stick person images. Each of these stick people represents the class of one kind of
people using the software and do to represent any single individual. For example, if we
consider the software of the library management system, then there will be two actors:
one the library staff that is responsible for issuing the books and the other the students
or the customers who visit the libraries and issues the books.

The following is the use case diagram for the library management system:
 Use-case model for library management system
https://i.pinimg.com/originals/81/80/23/8180236e318f622795bb0a7c824b895a.png

Here, in this use case diagram for the software of the library management system, we
are having two actors: the librarian and the student, and nine use cases representing
different activities and interactions taking place between the actors and the software.
Note: It should be noted that the number of actors and use cases is not fixed. You can
use as many actors and use cases as per your software.

Classes are used to represent the object-oriented models. As we know that in the OOPs
structure, every entity is treated as an object. A class thus can be defined as a collection
of objects that share the common properties and behavior.

The Class diagram of the software consists of all the classes that exist in the software.
In the class diagram, a class is represented via a rectangular box. Each of the classes is
divided into three sections. The topmost section consists of the class name. The second
section consists of the names of all the attributes that the class contains with their data
types. And the third section consists of the methods (or functions) that are defined in
the class. (It must be noted that the section of attributes and methods can be empty,
but the class name cannot.)

For example: Consider a class named "books" which has some attributes and methods.
The class diagram for this very class would look something like this:

Here, Books is the name of the class, which has the following attributes: BookId of
integer type, BookCategory of String type, NumberOfBooks of integer type, and has
two methods namely: AddBook() and AlterNumberOfBooks().

Now, the class diagram not only consists of the classes, but these classes also hold
some relation with each other, and this relation is also represented in this diagram.

A class is connected with another class (with whom it holds a relation) using a single
line, and on that line, we represent the cardinality. The cardinality represents the number
of entities that exist in the relation. It may be one to one, one to many, etc. The
cardinality symbols are represented as follows for a class:

Image source: https://wcs.smartdraw.com/class-diagram/img/notes.jpg?bn=1510011152

Example:

Let us consider the example of the library management system. The following is the
class diagram for the same.

It consists of nine classes that are interconnected. The relations and cardinality of each
of them can also be inferred from the class diagram itself.
 Class Diagram for library management System

What is Sequence Diagram?

Sequence Diagram is a "Connection Diagram" that represents a single structure or
storyline executing in a system. It is the second most used UML diagram behind the
class diagram. Sequence Diagram shows what message is to be sent and when.

A sequence diagram is a good way to visualize and ratify various runtime framework.

Sequence diagram
 Basic Sequence Diagram Notation
1. Lifeline: Lifelines are vertical dotted lines that indicate the object's activity over time. Lifeline is a
named element that represents an individual participant in the connection. While parts and
structural properties may have multiplicity, lifelines represent only one interconnected entity.
2. Messages: Messages are nothing but the arrows that represent calls between objects. Half-
arrowed lines are used to represent asynchronous messages. Asynchronous messages are sent
from an object that will not wait for a reply from the receiver before continuing its tasks.
3. Execution Occurrence: Execution boxes present the time an object needs to complete a task.
When an object is busy executing a process or waiting for a reply message, use a thin gray
rectangle placed vertically on its lifeline.
4. Interaction Fragment: It is the named element that represents the most general interaction
segment. Example of Interaction Fragment:
o Occurrence
o Execution

o Interaction use

Types of message in sequence diagram

1. Synchronous Message: It requires a response before the interaction can proceed. It's usually
drawn using a line with a solid arrowhead pointing from one object to another.
2. Asynchronous Message: It does not require a response before the interaction can proceed. It is
usually drawn using an arrow.
3. Reply Message: It is drawn by the dotted arrow moving backward to the original message.
4. Self Message: A message sent to itself and it is represented by the U shaped arrow.
5. Found Message: A message sent from an unknown beneficiary, shown by an arrow from an
endpoint to a lifeline.
6. Lost Message: A message sent to an unknown beneficiary. It's shown by an arrow going from a
lifeline to an endpoint, a filled circle or a cross(x).

Simple E2E Diagram

Image Reference: https://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/interaction-
diagram/

The Activity Diagram

The Activity diagram in the software design models is used to represent the flow of
control among the different activities of the software. In the activity diagram, we
represent different actions through activities. These activities take some input from
some other activity of the system or through the input and output units and produce
some signal outputs that control the workflow of the other activities.

The activities in the activity diagram can be defined as states. Each of these states
performs some internal action that is responsible for performing the required task. Apart
from this, each activity also performs some external activity. This external activity can
either be responsible for triggering or handling some other activities or can be used for
directly producing the required output. Each activity can produce one or more external
transitions. If there is direct workflow form one activity to another activity without any
specific conditional case, then the activity produces only one external transition. If more
than one external transition is produced by the activity, then these transitions are
handled through the conditional statements (like if-else).

Characteristics of the activity diagram of the

software model
 The control flow in every software has to start from some starting point and end at some
termination point. In the activity diagram, the starting point is represented through a
filled circle and the termination point through a filled circle with a double boundary.
Every activity diagram must contain these symbols.
 The activity diagram can also be divided into different categories using the swim lanes.
Each lane represents a single category and all the activities belonging to this category
are represented in this lane.
 The conditional statements can be represented in the activity diagram by placing a
diamond symbol from the line representing the external transition and then splitting this
line according to desired conditions. The condition that each of these divisions follows
can be mentioned on top or beside the line.
 The diamond symbol is also used for conjugating the external transitions from various
activities. Most of the time, this type of situation occurs when the activity model
proceeds towards the termination stage.

Features of the Activity model

 This model is prepared in the early stages of software development, i.e. in the analysis
and design phase.
 Internal control flow can be well represented through this model.
 Complex processing activities that involve many elements and components can easily be
represented understandably through this model.
What is Component Diagram?
A Component Diagram breaks down the real system under development into different
heights of working. Every component is reactive for the main aim in the entire system
and only reacts with other particular elements on a need to know basis. The interfaces
on the right are defined as required interfaces, which shows the services the component
wants to carry out its duty.

Basis Concept of Component Diagram

A component represents a modular part of a system of the diagram that encapsulates
its contents and tells whose manifestation is replaceable the states within its
environment of the world. In the UML diagram, a component is drawn as four sides as
breadth and length known as a rectangle with optional compartments stacked straightly
as vertical. A high-level, abstracted view of a component in UML 2 can be modeled as:

1. A rectangle with the component's name

2. A rectangle with the component icon
3. A rectangle with the stereotype text and/or icon

Component Diagram
 Take stock of everything or anything needed or wanted to implement or run the planned
system. For example, for a simple e-commerce system, we will need components or parts
of the component that describe products, orders, objective, server account, and
customer accounts.
 Form a visual or imaginary for each of the components of the system.
 Defines the organization and relationships between components having the parts using
interfaces, ports, and dependencies together to form components.
 Parts of Component Diagram
1. Component:
A component is a logical unit block of the system of the objects, a little large flow abstraction
than classes. It is shown as a length and breadth rectangle with a smaller rectangle in the upside
of right corner or site with tabs or the word written or shows above the name of the component
to help differentiate it from a class.
2. Interface:
An interface (small circle or semi-circle on a stick) differentiate a group of operations required or
something provided by components. A full circle represents an interface provided by the
component and uses for the interface between the two systems. A semi-circle represents a
required interface, like a person's input as the objects of the system.
3. Dependencies:
Draw dependencies among al the components using dashed arrows.
4. Port:
Ports are represented using four equal sites as square along the edge of the system or a
component. A port is used to input the system object into it. A port is often used to help to
expose required and provided and interfaces of a component of the system.

Use of Component Diagram

 Design the components of a system.
 Program the database schema.
 Make the executables of an application.
 Draw the system's source code.

What is Deployment Diagram?

A deployment diagram is a UML diagram type of the system that represents the
execution architecture of the components of a system of the objects, including nodes or
modes such as hardware or software execution environments or worlds, and the
middleware connecting them. Diagram types mostly outline the logical components of a
system. Deployment diagrams are typically or difficultly used to visualize or imagine
the physical hardware and software of a system of the component. Using it you can
understand how the system of the diagram will be physically deployed on the hardware.
 Deployment diagrams help design the hardware topology of a system of component
compared to other UML diagram types from the others which mostly outline the logical
components of a system in the diagram for the use of deploy of the component.

Deployment Diagram Notations

1. Nodes:
A node, represented as 8 faces as the cube, is a physical entity that executes one or more
components, subsystems or executables of the system. A node could be a hardware or software
element of the system.
2. Artifact:
Artifacts are concrete elements that are caused or problemed by a development process.
Examples of artifacts are libraries, archives, configuration files, executable files, deploy files, etc.
3. Communication Association:
This is represented by a solid line between two nodes. It shows the path of communication
between nodes.
4. Devices:
A device is a node that is used to represent a physical computational resource in a system. An
example of a device is an application server.
5. Deployment Specifications:
Deployment specifications is a configuration file, such as a text file or an XML document. It
describes how an artifact is deployed on a node.

Use Deployment Diagram

 What existing systems will the newly added system of the component want to interact or
integrate with?
 How robust does the system need to be redundant for deploy?
 What and who will connect to or interact with the system of the component, and how
will they do it with it and the diagram?
 What middleware, including the operating system and communications approaches and
protocols, will system use this with altogether or not?
 What hardware and software will users directly interact with (PCs, network computers,
browsers, etc.) for deployment?
 How will you monitor the system once deployed for the diagram?
 How secure does the system need to be (needs a firewall, physically secure hardware,
etc.) with deploy?

Deployment Diagram Examples

Deployment Diagram for Online Shopping System
Deployment Diagram for Library Management System
 Images source: http://creately.com/creately-start?tempID=jmk6au3v1

What is an Object Diagram?

An object is a real-world problem entity whose activities are defined by the classes. The
Object is a specimen of a particular moment in runtime, plus objects and data ethics or
values. A steady UML object diagram is an example of a class diagram; it shows a snap
of the detailed state of a system at a point in time, thus an object diagram circumscribe
objects and their relationships at a point in time. It may examine a special case of a class
diagram or a communication diagram.

Notation of the Object Diagram

The Motive of Object Diagram

 1. It is used to represent the occurrence of the class. You might create a class diagram to
present the structure and then create a set of objectives.
2. It is used to understand the activity or working of an object.

In summary, the relation between the instantiated class and the defined class is been
shown by the Object diagram. The best way to exemplify what an object diagram looks
like is to show the object diagram generated from a similar class diagram.

Object Diagram Notation

1. Name: Every object is represented like a rectangle, that offers the name from the object and its
class emphasize as well as divided with a colon.
2. Attributes: Similar to classes, you can list object characteristics inside a separate section.
However, unlike classes, object credit should have values given to them.
3. Links: Links tells to be an example associated with the relationship. You can draw a link while
using the lines utilized in class diagrams.

Steps for drawing Object diagram

A communication diagram called collaboration in the previous version of UML without
comment is known as an object diagram. An object diagram must be a valid
actualization of a fixed class diagram. This can be used as a fast regularity check. To do
this we can develop an object diagram by using the following steps:

 Recognize the mechanism you'd like to draw. An apparatus constitute some functions or
behaviors of the part of the system you are modeling.
 Show the state and accredit values of each such object, as necessary, to understand the
scene.

Instance specification
Each object and link on an object diagram is presented by a current quality. This can
show an object's classifier e.g. an abstract or concrete class and instance name, as well
as attributes and other structural features using slots. Each part corresponds to a single
meaning or feature and may include a value for that state.

The name on an instance specification optionally shows an instance name, separator,

and not compulsory one or more classifier names separated by commas.

Object diagram example

 Image source: https://cloud.smartdraw.com/editor.aspx?templateId=680993af-b8b1-48a9-8fce-
3f57a65eb834&noro=1&nsu=1

What is State Chart Diagram?

A state machine of the states of objects defined by State Chart Diagram. The state
machine can be called a machine that tells different states of an object and these states
are controlled by internal or external events. A state chart diagram is a kind of diagram
used in CS and a similar field to tell us about the nature of the system. The Special kind
of a diagram is the Statechart diagram is known as Activity Diagram. It is used to the
model of the states of objects of the time of life of an object so it is known as the
Statechart diagram. It shows the various states as for transition for everything in the
diagram.
Basic of State Chart Diagram
1. It is one of the important UML diagrams used to model the spirited nature of a system.
2. The important aim of a diagram is to creation to termination from the states of objects.
3. These are also used for ahead and opposite engineering of a system. The main aim is to
model the responsible system.
4. They describe different types of states of an object during its time of life and these states
are updated by events and places where it used.
5. The main purposes of using Statechart diagrams are follows,
o Design the dynamic aspect of a system.
o During its lifelong time defines the states of an object.
o Model the time of a responsible system in states.
o Tell a state product to design the states of an object.

Types of State Chart Diagram

1) First one is Behavioral state chart diagram

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

 It is used to shows the represent the particular types of implementation of a state of
object.
 The behavior of a system of objects can be shaped the diagram using this diagram.

2) Second one is Protocol state chart diagram

 These state chart diagrams are used to capture or click the behavior or nature of a
system of the objects used in the diagram.
 It shows how the state of objects of protocol updates concerning the event in the place.
It also represents corresponding changes in the system of the states of objects in the
diagram.
 They don't represent the particular or simple implementation of an element of the states
of the objects of the diagram.

Where to operate State Chart Diagram

 To represent the states of a system.
 Ahead and just opposite engineering.
 To represent the reactive system and responsible system consists of reactive states.
 To recognize the events responsible for updates of the system.

State Chart Diagram

These are very useful for defines the states. States can be guessed as the condition of
objects when an event takes place.

Before drawing a diagram we should know the following parts,

 Recognize the important objects to be analyzed

 Recognize the states
 Recognize the events

Simple ATM Diagram

Image source: https://www.researchgate.net/figure/Statechart-Diagram-of-ATM_fig3_220299153