UNIT:3 (10

Hours)
Design process: Design concepts, Design Model,
Design Heuristic Architectural Design:
Architectural Mapping using Data Flow Structure
Chart design using DFD. Transform Analysis,
Transaction Analysis: OOD Modeling Using UML,
User Interface Design.
CASE TOOL: Application on Design
Software Design
Software design is a mechanism to transform user requirements
into some suitable form, which helps the programmer in software
coding and implementation.
It deals with representing the client's requirement, as described in
SRS (Software Requirement Specification) document, into a form,
i.e., easily implementable using programming language.
The software design phase is the first step in SDLC (Software Design
Life Cycle), which moves the concentration from the problem domain
to the solution domain.
 In software design, we consider the system to be a set of components or
modules with clearly defined behaviors & boundaries.
The objective of design phase is to take the SRS document as input and
produce the above mentioned document before completion of design
phase.
It is a single step procedure but requires several iterations.
Pre-requisites for software design
Different modules required to implement the design
solution.
Control relationship among the identified modules[ it is
also called as call relationship or invocation relationship
among modules].
 Interface among different modules:- identifies exact data
items exchanged among the modules.
Data structures of individual modules.
Algorithms required to implement the individual modules
Design Activities
Preliminary (or high-level) design:-
Identification of different modules,
The control relationship
Definitions of interfaces among them
Outcome:- program structure/ software architecture
Note:- structure chart (tree-like diagram ) / Jackson diagram /
Warnier-orr diagram to represent the control hierarchy in
high- level design.
Detailed design:-
Data structure
algorithms of different modules
Outcome:- Module specification document
 Objectives of Software Design
Correctness: Software design
should be correct as per
requirement.
Completeness: The design
should have all components like
data structures, modules, and
external interfaces, etc.
Efficiency: Resources should be
used efficiently by the program.
Flexibility: Able to modify on
changing needs.
Consistency: There should not be
any inconsistency in the design.
Maintainability: The design
should be so simple so that it can
be easily maintainable by other
designers.
Software Design Principles
 Software design principles are concerned with providing means to handle
the complexity of the design process effectively.
 Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors
during design.
Problem Partitioning
For software design, the goal is to divide the problem into manageable
pieces.
These pieces cannot be entirely independent of each other as they together
form the system.
 They have to cooperate and communicate to solve the problem. This
communication adds complexity.
Note: As the number of partition increases = Cost of partition and
complexity increases
Benefits of Problem Partitioning
Software is easy to understand
Software becomes simple
Software is easy to test
Software is easy to modify
Software is easy to maintain
Software is easy to expand
Abstraction
An abstraction is a tool that enables a designer to consider a component at an
abstract level without bothering about the internal details of the
implementation. Abstraction can be used for existing element as well as the
component being designed.
Here, there are two common abstraction mechanisms
Functional Abstraction
Data Abstraction
Functional Abstraction
A module is specified by the method it performs.
The details of the algorithm to accomplish the functions are not visible to the
user of the function.
Functional abstraction forms the basis for Function oriented design
approaches.
Data Abstraction
Details of the data elements are not visible to the users of data. Data
Abstraction forms the basis for Object Oriented design approaches.
 Modularity
Single large programs are difficult Advantages of Modularity
to understand and read due to a There are several advantages of
large number of reference variables, Modularity
control paths, global variables, etc. It allows large programs to be written by
several or different people
The desirable properties of a It encourages the creation of commonly
modular system are: used routines to be placed in the library
Each module is a well-defined and used by other programs.
system that can be used with other It simplifies the overlay procedure of
applications. loading a large program into main
Each module has single specified storage.
It provides more checkpoints to measure
objectives.
progress.
Modules can be separately It provides a framework for complete
compiled and saved in the library. testing, more accessible to test
Modules should be easier to use It produced the well designed and more
than to build. readable program.
Disadvantages of Modularity

There are several disadvantages of Modularity

Execution time maybe, but not certainly, longer
Storage size perhaps, but is not certainly, increased
Compilation and loading time may be longer
Inter-module communication problems may be increased
More linkage required, run-time may be longer, more source lines must be
written, and more documentation has to be done

Modular Design

 1. Functional Independence: Functional independence is achieved by

developing functions that perform only one kind of task and do not
excessively interact with other modules. It is measured using two criteria:
Cohesion: It measures the relative function strength of a module.
Coupling: It measures the relative interdependence among modules.
2.  Information hiding: The fundamental of Information hiding suggests
that modules can be characterized by the design decisions that protect from
the others.
Strategy of
Design
A good system design strategy is
to organize the program
modules in such a method that
are easy to develop and latter
too, change.
  Structured design methods
help developers to deal with the
size and complexity of
programs.
 To design a system, there are
two possible approaches:
Top-down Approach
Bottom-up Approach
Features of design
It should be consistent and meaningful names of
various design components.
The design should be modular.
The modules should be arranged neatly in a hierarchy
 The design model is an object model describing the realization of use cases,
and serves as an abstraction of the implementation model and its source
code. The design model is used as essential input to activities in
implementation and test.
Design model elements
Data elements
Data model-Data structure
Data model-Database architecture
Architectural elements
Analysis classes, their relationships, collaborations and
behaviors are transformed into design realizations
Patterns and “styles”
Interface elements:
The user interface (UI)
External interfaces to other systems, devices, networks or other
producers or consumers of information
Internal interfaces between various design components.
Component elements
Deployment elements
Architectural elements
The architectural model is derived from three sources:
information about the application domain for the
software to be built
specific requirements model elements such as data
flow diagrams or analysis classes, their relationships
and collaborations for the problem at hand, and
the availability of architectural patterns and styles
Deployment elements
Data flow diagram(DFD) or Bubble chart
A Data Flow Diagram (DFD) is a traditional visual
representation of the information flows within a system.
A neat and clear DFD can depict the right amount of the
system requirement graphically.
It can be manual, automated, or a combination of both.
It shows how data enters and leaves the system, what changes
the information, and where data is stored.
The objective of a DFD is to show the scope and boundaries of
a system as a whole. It may be used as a communication tool
between a system analyst and any person who plays a part in
the order that acts as a starting point for redesigning a system.
The DFD is also called as a data flow graph or bubble chart.
Types of DFD

Data Flow Diagrams are either Logical or Physical.

Logical DFD - This type of DFD concentrates on the
system process, and flow of data in the system.
For example in a Banking software system, how data is
moved between different entities.
Physical DFD - This type of DFD shows how the data
flow is actually implemented in the system.
 It is more specific and close to the implementation.
Observations about DFDs
The following observations about DFDs are essential:

All names should be unique. This makes it easier to refer to elements in the
DFD.
Remember that DFD is not a flow chart.
Arrows is a flow chart that represents the order of events where as
arrows in DFD represents flowing data.
A DFD does not involve any order of events.
Suppress logical decisions. If we ever have the urge to draw a diamond-shaped
box in a DFD, suppress that urge! A diamond-shaped box is used in flow charts
to represents decision points with multiple exists paths of which the only one is
taken. This implies an ordering of events, which makes no sense in a DFD.
Do not become bogged down with details. Defer error conditions and error
handling until the end of the analysis.
Standard symbols for DFD
Standard
symbols for
DFDs are
derived from
the electric
circuit
diagram
analysis and
are shown in
fig:.
Levels in Data Flow Diagrams (DFD)
In Software engineering DFD(data flow diagram) can
be drawn to represent the system of different levels of
abstraction.
Infact, DFDs may be partitioned into levels that represent
increasing information flow and functional detail.
The DFD may be used to perform a system or software at
any level of abstraction.
Higher level DFDs are partitioned into low levels-hacking
more information and functional elements.
Levels in DFD are numbered 0, 1, 2 or beyond. Here, we
will see primarily three levels in the data flow diagram,
which are: 0-level DFD, 1-level DFD, and 2-level DFD.
0-level DFD
It is also known as fundamental system model, or context
diagram represents the entire software requirement as a
single bubble with input and output data denoted by
incoming and outgoing arrows.
 Then the system is decomposed and described as a DFD
with multiple bubbles.
Parts of the system represented by each of these bubbles are
then decomposed and documented as more and more
detailed DFDs.
 This process may be repeated at as many levels as necessary
until the program at hand is well understood.
It is essential to preserve the number of inputs and outputs
between levels, this concept is called leveling by DeMacro.
0-level DFD cont……
Thus, if bubble "A" has two inputs x1 and x2 and one output y,
then the expanded DFD, that represents "A" should have exactly
two external inputs and one external output as shown in fig:

The Level-0 DFD, also called context diagram of the result

management system is shown in fig.
As the bubbles are decomposed into less and less abstract
bubbles, the corresponding data flow may also be needed to be
decomposed.
Example (Result Mgt System)
1-level DFD
In 1-level DFD, a
context diagram is
decomposed into
multiple
bubbles/processes.
 In this level, we
highlight the main
objectives of the
system and
breakdown the high-
level process of 0-level
DFD into sub-
processes.
2-level DFD
2-level DFD goes
one step deeper
into parts of 1-level
DFD.
It can be used to
plan or record the
specific/ necessary
detail about the
system’s
functioning.
Assignments
Draw the 2 level DFD for the following:
User account Maintenance.
Login.
Student Information Management.
Subject Information Management.
Students subject choice management.
Marks information Management
Structure Charts
Structure chart is a chart derived from Data Flow
Diagram.
 It represents the system in more detail than DFD. It
breaks down the entire system into lowest functional
modules, describes functions and sub-functions of
each module of the system to a greater detail than
DFD.
Structure chart represents hierarchical structure of
modules.
At each layer a specific task is performed
Symbols used in structure charts
Module - It represents process
or subroutine or task. A control
module branches to more than
one sub-module. Library
Modules are re-usable and
invokable from any module.

Condition - It is represented by
small diamond at the base of
module. It depicts that control
module can select any of sub-
routine based on some
condition.
Symbols used in structure charts cont..
Jump - An arrow is shown
pointing inside the module to
depict that the control will
jump in the middle of the sub-
module.

Loop - A curved arrow

represents loop in the
module. All sub-modules
covered by loop repeat
execution of module.
Symbols used in structure charts cont..
Data flow - A directed
arrow with empty circle at
the end represents data
flow.

Control flow - A directed

arrow with filled circle at
the end represents control
flow.
 Transform Analysis
Transform Analysis identifies the primary functional components
(modules) and the high level inputs and outputs for these
components.
The first step in transform analysis is to divide the DFD into 3 types
of parts:
• Input
• Logical processing
• Output
• The input portion of the DFD includes processes that transform input
data from physical (e.g. character from terminal) to logical forms (e.g.
internal tables, lists, etc.).
• Each input portion is called an afferent branch.
• The output portion of a DFD transforms output data from logical to
physical form. Each output portion is called an efferent branch.
• The remaining portion of a DFD is called the central transform.
In the second step of transform analysis, the structure chart is
derived by drawing functional component for the central
transform, input and output unit.
These are drawn below a root module, which would invoke
these modules.
Identifying the highest level input and output transforms
requires experience and skill.
In the third step of transform analysis, the structure
chart is refined by adding sub-functions required by
each of the high-level functional components.
Many levels of functional components may be added.
This process of breaking functional components into
sub components is called factoring.
Factoring includes adding read and write modules,
error-handling modules, initialization and
termination process, identifying customer modules,
The factoring process is continued until all bubbles in
the DFD are represented in the structure chart.
Example: RMS software

DFD

Structure
chart
Transaction Analysis
A transaction allows the user to perform some meaningful piece of
work.
Transaction analysis is useful while designing transaction
processing programs.
In a transaction-driven system, one of several possible paths
through the DFD is traversed depending upon the input data item.
This is in contrast to a transform centered system which is
characterized by similar processing steps for each data item.
Each different way in which input data is handled is a transaction.
A simple way to identify a transaction is to check the input data.
The number of bubbles on which the input data to the DFD are
incident defines the number of transactions.
However, some transaction may not require any input data. These
transactions can be identified from the experience of solving a
large number of examples.
Transaction Analysis cont…..
For each identified transaction, trace the input data to the
output.
 All the traversed bubbles belong to the transaction.
 These bubbles should be mapped to the same module on the
structure chart.
Module and below this module draw each identified transaction
a module. Every transaction carries a tag, which identifies its
type. Transaction analysis uses this tag to divide the system into
transaction modules and a transaction-center module.
module and below this module draw each identified transaction
a module. Every transaction carries a tag, which identifies its
type. Transaction analysis uses this tag to divide the system into
transaction modules and a transaction-center module.
The structure chart for the supermarket prize scheme software is shown
 OOD Modeling Using UML
The Unified Modeling Language (UML) is a general-purpose, developmental,
modeling language in the field of software engineering that is intended to
provide a standard way to visualize the design of a system.
The goal of UML is to provide a standard notation that can be used by all
object-oriented methods and to select and integrate the best elements of
precursor notations.
Mainly, UML has been used as a general-purpose modeling language in the field
of software engineering.
 However, it has now found its way into the documentation of several business
processes or workflows.
For example, activity diagrams, a type of UML diagram, can be used as a
replacement for flowcharts.
UML is composed of three main building blocks, i.e., things, relationships,
and diagrams.
Which software is used for UML diagrams?
Microsoft Visio:- As one of the MS Office suite applications, Microsoft
Visio is the industry standard diagramming software with which users
can set up a wide range of diagrams, which include UML classes.
UML cont…..
UML is different from the other common programming languages
such as C++, Java, COBOL, etc.
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.
UML is not a programming language but tools can be used to
generate code in various languages using UML diagrams.
UML has a direct relation with object oriented analysis and design.
After some standardization, UML has become an OMG(Object
Management Group) standard.
Conceptual Model of UML
A conceptual model can be defined as a model which is
made of concepts and their relationships. A conceptual
model is the first step before drawing a UML diagram. It
helps to understand the entities in the real world and
how they interact with each other. The conceptual
model of UML can be mastered by learning the
following three major elements −
UML building blocks
Rules to connect the building blocks
Common mechanisms of UML
Conceptual Model of UML

Characteristics of UML
It is a generalized modeling language.
It is different from software programming languages such as
Python, C, C++, etc.
It is a pictorial language which can be used to generate powerful
modeling elements.
It is related to object-oriented designs and analysis.

Five Rules for Better UML Diagrams

to avoid large diagrams with too many items.
avoid any two lines in your diagram crossing each other.
lines in a diagram should go only horizontal or vertical with only
right angles.
parent elements are higher then the child elements in
generalization or realization hierarchies.
diagrams should be nice and clean.
UML Diagrams
UML defines various kinds of diagrams to cover most of the aspects of a system.
There are two broad categories of diagrams and they are again divided into
subcategories −
Structural Diagrams

Class diagram
Object diagram
Component diagram
Deployment diagram

Behavioral Diagrams

Use case diagram

Sequence diagram
Collaboration diagram
State chart diagram
Activity diagram
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.
The purpose of the class diagram can be summarized as −

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.
Constituents of class diagrams

Generalization
Aggregation
Association
Dependencies
Constraints
Points for drawing a class diagram
The name of the class diagram should be meaningful to describe the
aspect of the system.
Each element and their relationships should be identified in advance.
Responsibility (attributes and methods) of each class should be clearly
identified
For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
Use notes whenever required to describe some aspect of the diagram.
At the end of the drawing it should be understandable to the
developer/coder.
Finally, before making the final version, the diagram should be drawn
on plain paper and reworked as many times as possible to make it
correct.
The following diagram is an example of an
Order System of an application.
It describes a particular aspect of the entire
application.
First of all, Order and Customer are identified
as the two elements of the system. They have a
one-to-many relationship because a customer
can have multiple orders.
Order class is an abstract class and it has two
concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.
The two inherited classes have all the
properties as the Order class. In addition, they
have additional functions like dispatch () and
receive ().
The following class diagram has been drawn
considering all the points mentioned above.
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.
The purpose of the object diagram can be summarized as-
Forward and reverse engineering.
Object relationships of a system
Static view of an interaction.
Understand object behaviour and their relationship from practical
perspective
Note:-A single object diagram cannot capture all the necessary instances or rather
cannot specify all the objects of a system.
Solution:-
First, analyze the system and decide which instances have important data and
association.
Second, consider only those instances, which will cover the functionality.
Third, make some optimization as the number of instances are unlimited.
Before drawing an object diagram, the following things should be remembered and
understood clearly −
Object diagrams consist of objects.
The link in object diagram is used to connect objects.
Objects and links are the two elements used to construct an object diagram.
After this, the following things are to be decided before starting the construction of
the diagram −
The object diagram should have a meaningful name to indicate its purpose.
The most important elements are to be identified.
The association among objects should be clarified.
Values of different elements need to be captured to include in the object diagram.
Add proper notes at points where more clarity is required.
Where to Use Object Diagrams?

Object diagrams can be imagined as the snapshot of a running system at a

particular moment. Let us consider an example of a running train
•A particular state which is running.
A particular number of passengers. which will change if the snap is taken in a
different time.
In a nutshell, it can be said that object diagrams are used for −
Making the prototype of a system.
Reverse engineering.
Modeling complex data structures.
Understanding the system from practical perspective.
How to draw an Object Diagram?
1. All the objects present in the system should be examined before start drawing the object diagram.
2. Before creating the object diagram, the relation between the objects must be acknowledged.
3. The association relationship among the entities must be cleared already.
4. To represent the functionality of an object, a proper meaningful name should be assigned.
5. The objects are to be examined to understand its functionality.
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.
Why use 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?

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?
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.
A component diagram for an online shopping
system is given below:
Where to use Component Diagrams?

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.
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.
Note − If the above descriptions and usages are observed
carefully then it is very clear that all the diagrams have some
relationship with one another. Component diagrams are
dependent upon the classes, interfaces, etc. which are part of
class/object diagram. Again, the deployment diagram is
dependent upon the components, which are used to make
component diagrams.
Purpose of Deployment Diagram

Following are the purposes of deployment diagram

enlisted below:

To predict 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?
since it plays a critical role during the administrative
process, it involves the following parameters:
High performance
Scalability
Maintainability
Portability
Easily understandable
NOTE:-One of the essential elements of the deployment
diagram is the nodes and artifacts.
 A deployment diagram for the Apple iTunes
application is given below.
1. The iTunes setup can be downloaded
from the iTunes website, and also it
can be installed on the home
computer.
2. Once the installation and the
registration are done, iTunes
application can easily interconnect
with the Apple iTunes store.
3. Users can purchase and download
music, video, TV serials, etc. and cache
it in the media library.
4. 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.1.
When to use a Deployment Diagram?
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.
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
State chart 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.
Purpose of Use Case Diagrams

It gathers the system's needs.

It depicts the external view of the system.
It recognizes the internal as well as external factors
that influence the system.
It represents the interaction between the actors.
How to draw a Use Case diagram?

Following are some rules that must be followed while

drawing a use case diagram:
A pertinent and meaningful name should be assigned
to the actor or a use case of a system.
The communication of an actor with a use case must
be defined in an understandable way.
Specified notations to be used as and when required.
The most significant interactions should be
represented among the multiple no of interactions
between the use case and actors.
Example of a Use Case Diagram
1.A use
The caseView Itemstheuse
diagram depicting case
Online is website is given below.
Shopping
utilized by the customer who
searches and view products.
2. The Client Register use case
allows the customer to register
itself with the website for
availing gift vouchers, coupons,
or getting a private sale
invitation.
It is to be noted that the
Checkout is an included use
case, which is part of Making
Purchase, and it is not available
by itself.
The View Items use case is utilized by the customer who searches and view
products. The Client Register use case allows the customer to register itself with
the website for availing gift vouchers, coupons, or getting a private sale invitation.
It is to be noted that the Checkout is an included use case, which is part of
Making Purchase, and it is not available by itself.
Important tips for drawing a Use Case diagram

1. A simple and complete use case diagram should be articulated.

2. A use case diagram should represent the most significant interaction among the
multiple interactions.
3. At least one module of a system should be represented by the use case diagram.
4. If the use case diagram is large and more complex, then it should be drawn more
generalized.
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.
UML Sequence Diagram for Book Renewal Scenario
Purpose of a Sequence Diagram
To model high-level interaction among active objects within a
system.
To model interaction among objects inside a collaboration
realizing a use case.
It either models generic interactions or some certain
instances of interaction.
Benefits of a Sequence Diagram
It explores the real-time application.
It depicts the message flow between the different objects.
It has easy maintenance.
It is easy to generate.
Implement both forward and reverse engineering.
It can easily update as per the new change in the system.
The drawback of a Sequence Diagram

In the case of too many lifelines, the sequence diagram

can get more complex.
The incorrect result may be produced, if the order of
the flow of messages changes.
Since each sequence needs distinct notations for its
representation, it may make the diagram more
complex.
The type of sequence is decided by the type of
message.
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.
Notations of a Collaboration Diagram
Objects: The representation of an object is done by an object
symbol with its name and class underlined, separated by a
colon.
Actors: In the collaboration diagram, the actor plays the
main role as it invokes the interaction. Each actor has its
respective role and name. In this, one actor initiates the use
case.
Links: The link is an instance of association, which
associates the objects and actors.
Messages: It is a communication between objects which
carries information and includes a sequence number, so that
the activity may take place. It is represented by a labeled
arrow, which is placed near a link.
Components of collaboration diagram
Example of a Collaboration Diagram:
renew book use case
Benefits of a Collaboration Diagram

The collaboration diagram is also known as Communication Diagram.

It mainly puts emphasis on the structural aspect of an interaction diagram, i.e., how lifelines are connected.
The syntax of a collaboration diagram is similar to the sequence diagram; just the difference is that the
lifeline does not consist of tails.
The messages transmitted over sequencing is represented by numbering each individual message.
The collaboration diagram is semantically weak in comparison to the sequence diagram.
The special case of a collaboration diagram is the object diagram.
It focuses on the elements and not the message flow, like sequence diagrams.
Since the collaboration diagrams are not that expensive, the sequence diagram can be directly converted to
the collaboration diagram.
There may be a chance of losing some amount of information while implementing a collaboration diagram
with respect to the sequence diagram.

The drawback of a Collaboration Diagram

Multiple objects residing in the system can make a complex collaboration diagram, as it becomes quite
hard to explore the objects.
It is a time-consuming diagram.
After the program terminates, the object is destroyed.
As the object state changes momentarily, it becomes difficult to keep an eye on every single that has
occurred inside the object of a system.
State chart 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.
State chart 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.
Notation of a State chart Diagram
Initial state: It defines the initial state (beginning) of
a system, and it is represented by a black filled circle.
Final state: It represents the final state (end) of a
system. It is denoted by a filled circle present within a
circle.
Decision box: It is of diamond shape that represents
the decisions to be made on the basis of an evaluated
guard.
Transition: A change of control from one state to
another due to the occurrence of some event is termed
as a transition. It is represented by an arrow labeled
with an event due to which the change has ensued.
State box: It depicts the conditions or circumstances
of a particular object of a class at a specific point of
time. A rectangle with round corners is used to
represent the state box.
Types of State
The UML consist of three states:
Simple state: It does not constitute any substructure.
Composite state: It consists of nested states (sub states),
such that it does not contain more than one initial state
and one final state. It can be nested to any level.
Submachine state: The submachine state is
semantically identical to the composite state, but it can be
reused.
State chart diagram for an order object
How to Draw a State chart Diagram?

A unique and understandable name should be assigned to the

state transition that describes the behavior of the system.
Out of multiple objects, only the essential objects are
implemented.
A proper name should be given to the events and the transitions.
When to use a State chart Diagram?

For modeling the object states of a system.

For modeling the reactive system as it consists of reactive objects.
For pinpointing the events responsible for state transitions.
For implementing forward and reverse engineering.
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.
Note − Dynamic nature of a system is very difficult to capture. UML has
provided features to capture the dynamics of a system from different
angles. Sequence diagrams and collaboration diagrams are isomorphic,
hence they can be converted from one another without losing any
information. This is also true for Statechart and activity diagram.
Activity diagram for student admission procedure at IIT
How to draw an Activity Diagram?

A meaningful name should be given to each and every activity.

Identify all of the constraints.
Acknowledge the activity associations.

When to use an Activity Diagram?

To graphically model the workflow in an easier and understandable way.

To model the execution flow among several activities.
To model comprehensive information of a function or an algorithm
employed within the system.
To model the business process and its workflow.
To envision the dynamic aspect of a system.
To generate the top-level flowcharts for representing the workflow of an
application.
To represent a high-level view of a distributed or an object-oriented system.
Assignments
Draw the following diagrams for supermarket prize
scheme and Tic –Toc-Toe Game:-
Use case
Sequence
Class diagram
Activity diagram
State chart diagram
Interaction diagrams
User Interface Design
User interface is the front-end application view to which user interacts
in order to use the software.
User interface is part of software and is designed such a way that it is
expected to provide the user insight of the software.
UI can be graphical, text-based, audio-video based, depending upon the
underlying hardware and software combination. UI can be hardware or
software or a combination of both.
The software becomes more popular if its user interface is:
Attractive
Simple to use
Responsive in short time
Clear to understand
Consistent on all interfacing screens
UI is broadly divided into two categories:
Command Line Interface
Graphical User Interface
Command Line Interface (CLI)
A text-based command line interface can have the
following elements:
Command Prompt - It is text-based notifier that is
mostly shows the context in which the user is working. It
is generated by the software system.
Cursor - It is a small horizontal line or a vertical bar of the
height of line, to represent position of character while
typing. Cursor is mostly found in blinking state. It moves
as the user writes or deletes something.
Command - A command is an executable instruction. It
may have one or more parameters. Output on command
execution is shown inline on the screen. When output is
produced, command prompt is displayed on the next line.
Graphical User Interface
Graphical User Interface provides the user graphical means to interact with the
system.
GUI can be combination of both hardware and software. Using GUI, user
interprets the software.
GUI Elements
GUI provides a set of components to interact with software or hardware.
Every graphical component provides a way to work with the system.

A GUI system has

following elements such
as:
Window
Tabs
Menu
Icon
Cursor
 Application specific GUI components
 A GUI of an application contains one
or more of the listed GUI elements:
 Application Window
 Dialogue Box
 Text-Box
 Buttons
 Radio-button
 Check-box
 List-box

Other impressive GUI

components are:
•Sliders
•Combo-box
•Data-grid
•Drop-down list
User Interface Design Activities
 There are a number of activities
performed for designing user interface.
 GUI Requirement Gathering - The
designers may like to have list of all
functional and non-functional
requirements of GUI .
 User Analysis - The designer studies
who is going to use the software GUI.
 Task Analysis - Designers have to
analyze what task is to be done by the
software solution. Here in GUI, it does
not matter how it will be done.
 GUI Design & implementation -
Testing - GUI testing can be done in
Designers after having information
various ways. Organization can have in-
about requirements, tasks and user
house inspection, direct involvement of
environment, design the GUI and
implements into code and embed the users and release of beta version are few of
GUI with working or dummy software them. Testing may include usability,
in the background. compatibility, user acceptance etc.
User Interface Golden rules
Strive for consistency
Enable frequent users to use short-cuts
Offer informative feedback
Design dialog to yield closure
Offer simple error handling
Permit easy reversal of actions –
Support internal locus of control
Reduce short-term memory load