UNIT THREE

 What is softwear design:-

Def:- Software design is the process of envisioning and defining software solutions
to one or more sets of problems.
One of the main components of software design is the software requirements
analysis (SRA).
SRA is a part of the software development process that lists specifications used in
software engineering.
It is about being able to express ideas for your software with other
developers, other teams, and your clients.
Having a well-thought design makes your software easier to implement,
reduces a need for major changes later and saves you from headaches down
the line.
Software design is both a process and a model. The design process is a
sequence of steps that enables the designer to describe all aspects of the
software for building.
Ex:- operation systems, webpages, mobile devices or even the new cloud
computing paradigm.
 Conceptual design and technical design:-
Conceptual Design Technical Design

Conceptual design is an initial/starting A Technical design is a phase in

phase in the process of planning, which the event team writes the
during which the broad outlines of code and describes the minute detail
function and sort of something are of either the whole design or some
coupled. parts of it.

It is written in the customer’s It describes any other thing that

language and designed according to converts the requirements into a
the client’s requirements. solution to the customer’s problem.

It describes that what will happen to It describes the functions or methods

the data in the system. of the system.

It shows the conceptual model i.e, It shows the data flow and the
what should a system look like. structure of the data.

It also includes the process and sub- It includes the functioning and
processes besides the strategies. working of the conceptual design.

It starts when a system requirement It starts after setting the system

comes and the phase looks for a requirements.
potential solution.

At the end of this phase, the solutions At the end of this phase, and after
to the problems are sent for review. analyzing the technical design, the
specification is initiated.

 Modularity :-

Def:- Modularity is the single attribute of software that allows a program to be

intellectually manageable.
Software modularity is measured by how well software is decomposed into smaller
pieces with standardized interfaces.
It enhances design clarity, which in turn eases implementation,
debugging, testing,documenting, and maintenance of software product.
It is analogous to modularity for hardware. We want to create products
by combining reusable chunks of code, so you only implement a feature or
functionality once and then maximize reuse.
Ex:- modularity in design, modularity in production, and modularity in
organization.
Properties :
i. Well defined subsystem
ii. Well defined purpose
iii. Can be separately compiled and stored in a library.
iv. Module can use other modules
v. Module should be easier to use than to build
vi. Simpler from outside than from the inside.d

 Module Coupling:-
Coupling is the measure of the degree of interdependence between modules.
Module coupling means to couple two to more modules with each other
and with the outside world.
It generally represents how the modules are connected with another
module and the outside world. Coupling is related to cohesion

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 of each other and
communicate through data.

Stamp Coupling:
Two modules are stamp coupled if they communicate using
composite data items such as structure, objects, etc. When the module
passes non-global data structure or entire structure to another module,
they are said to be stamp coupled.

Control Coupling:
Control Coupling exists among two modules if data from one
module is used to direct the structure of instruction execution in
another.

External coupling:
External coupling occurs when two modules share an externally
imposed data format, communication protocol, or device interface. This
is basically related to the communication to external tools and devices.

Common coupling:
Common coupling is said to occur when several modules have
access to the same global data. External coupling occurs when two
modules share an externally imposed data format, communication
protocol, or device interface.

Content coupling:
Content coupling is said to occur when one module uses the code of
another module, for instance a branch. This violates information hiding –
a basic software design concept. Common coupling is said to occur
when several modules have access to the same global data.

 Module Cohesion:-
Cohesion is a measure of the degree to which the elements of a module
are functionally related.In computer programming, cohesion defines to the
degree to which the elements of a module belong together. Thus, cohesion
measures the strength of relationships between pieces of functionality within a
given module. For example, in highly cohesive systems, functionality is
strongly related.

Types of cohesion:-

Functional cohesion:
Functional cohesion occurs when elements of a module are
grouped together because they are united for a single, well-defined
purpose. All of the elements in the module work together to fulfill that
purpose. Functional cohesion in a module is ideal and is the highest
type of cohesion.

Sequential cohesion:
Sequential cohesion is when parts of a module are grouped
because the output from one part is the input to another part like an
assembly line (e.g., a function which reads data from a file and
processes the data).

Procedural cohesion:
Procedural cohesion is when parts of a module are grouped
because they always follow a certain sequence of execution (e.g., a
function which checks file permissions and then opens the file).

Temporal Cohesion:
When elements of module are organized such that they are
processed at a similar point in time, it is called temporal cohesion.
Procedural cohesion - When elements of module are grouped together,
which are executed sequentially in order to perform a task, it is called
procedural cohesion.

Logical Cohesion: A module is said to be logically cohesive if all the

elements of the module perform a similar operation. For example Error
handling, data input and data output, etc.

Coincident cohesion:Coincidental cohesion exists in modules that

contain instructions that have little or no relationship to one another.
Coincidental cohesion is when parts of a module are grouped
arbitrarily; the only relationship between the parts is that they have
been grouped together.

EXTRA:

 Objectives of modular softwear design:

The purpose of modeling anything is to highlight a set of related
issues to improve understanding. Different kinds of models highlight
different sets of issues. You should choose the model or models that
highlight the issues that are important to the problem you are trying to
solve.
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.
Modular software design is done by breaking the larger code into
smaller sections, think modules, that hold specific functions. Modular
design is shown to improve the design process by allowing better re-
usability, workload handling, and easier debugging processes.

 Design Notations:-
Design notations are largely meant to be used during the process
of design and are used to represent design or design decisions.For a
function oriented design, the design can be represented
Graphically or mathematically by the following:
Data flow diagrams
Data Dictionaries
Structure Charts

Structure Charts:-

 UML : Unified Modelling Language.

Def:- It is a generic developmental modelling language used for
analysis, design and implementation of software systems. The purpose
of UML is to provide a simple and common method to visualise a
software system's inherent architectural properties.
A UML diagram is a diagram based on the UML (Unified Modeling
Language) with the purpose of visually representing a system along
with its main actors, roles, actions, artifacts or classes, in order to
better understand, alter, maintain, or document information about the
system.
A Unified Modeling Language (UML) diagram provides a visual
representation of an aspect of a system. UML diagrams illustrate the
quantifiable aspects of a system that can be described visually, such
as relationships, be

 The meaning of "unified" in UML:

 Unified Modeling language (UML) is a standardized modeling
language enabling developers to specify, visualize, construct and
document artifacts of a software system. Thus, UML makes these
artifacts scalable, secure and robust in execution
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.
It is a graphical language for visualizing, specifying, constructing,
and documenting the artifacts of a software-intensive system.

 Generalization in UML
In UML modeling, a generalization relationship is a relationship in
which one model element (the child) is based on another model
element (the parent). Generalization relationships are used in class,
component, deployment, and use-case diagrams to indicate that the
child receives all of the attributes, operations, and relationships that
are defined in the parent.
To comply with UML semantics, the model elements in a
generalization relationship must be the same type. For example, a
generalization relationship can be used between actors or between
use cases; however, it cannot be used between an actor and a use
case.
You can add generalization relationships to capture attributes,
operations, and relationships in a parent model element and then
reuse them in one or more child model elements. Because the child
model elements in generalizations inherit the attributes, operations,
and relationships of the parent, you must only define for the child the
attributes, operations, or relationships that are distinct from the parent.

 Object modeling using UML

In UML models, objects are model elements that represent
instances of a class or of classes. You can add objects to your model
to represent concrete and prototypical instances. A concrete instance
represents an actual person or thing in the real world.
Unified Modeling Language (UML) is a general purpose modelling
language. The main aim of UML is to define a standard way to
visualize the way a system has been designed. It is quite similar to
blueprints used in other fields of engineering.
 DIAGRAMS IN UML:-

1) USE CASE DIAGRAM: ---- Functionality

Actors and Usecases are the basic elements in usecase

diagram.

Actor is a human being or system

Nouns may be Actor

Verbs are use case of system
Different roles - Actor(Nouns)-----exactly Actor
One usecase to another usecase only dependancy can make the
relationship.Actor to Actor is not possible
Use-case diagrams describe the high-level functions and
scope of a system. These diagrams also identify the interactions
between the system and its actors. The use cases and actors in use-
case diagrams describe what the system does and how the actors use
it, but not how the system operates internally
A use case diagram is a way to summarize details of a system
and the users within that system. It is generally shown as a graphic
depiction of interactions among different elements in a system.
 A use case diagram is used to represent the dynamic behavior of
a system. It encapsulates the system's functionality by
incorporating use cases, actors, and their relationships. It models
the tasks, services, and functions required by a system/subsystem of
an application. It depicts the high-level functionality of a system and
also tells how the user handles a system.
<<include>> relationships: Include relationship is used to include
one use case within the behavior sequence of another use case.
“Exclude" on the other hand is optional use case which extends the
base use case, base use case can run successfully even without
invoking/calling the extending use case.

2. Sequence Diagram:

A single usecase has multiple sequence diagram.

Objects and the massages are the basic elements in sequence diagram.
Objects that are represented by lifelines, and the messages that they
exchange over time during the interaction.
The sequence diagram represents the flow of messages in the system
and is also termed as an event diagram. to show the interactions between
objects in the sequential order that those interactions occur. It helps in
envisioning several dynamic scenarios. It portrays the communication
between any two lifelines as a time-ordered sequence of events, such that
these lifelines took part at the run time. In UML, the lifeline is represented by
a vertical bar, whereas the message flow is represented by a vertical dotted
line that extends across the bottom of the page. It incorporates the iterations
as well as branching.
A sequence diagram is a Unified Modeling Language (UML) diagram
that illustrates the sequence of messages between objects in an interaction.
A sequence diagram consists of a group of objects that are represented by
lifelines, and the messages that they exchange over time during the
interaction.

3. Collaboration Diagram/Communication 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.
 The collaboration diagram is used to show the relationship between
the objects in a system. Both the sequence and the collaboration diagrams
represent the same information but differently. Instead of showing the flow
of messages, it depicts the architecture of the object residing in the system
as it is based on object-oriented programming. An object consists of several
features. Multiple objects present in the system are connected to each other.
The collaboration diagram, which is also known as a communication diagram,
is used to portray the object's architecture in the system.

4. Class Diagram:

Class Diagram represents to show or know theThe structure of

purposed system. Class diagram depicts a static view of an application. It
represents the types of objects residing in the system and the relationships
between them. A class consists of its objects, and also it may inherit from
other classes. A class diagram is used to visualize, describe, document various
different aspects of the system, and also construct executable software code.

It shows the attributes, classes, functions, and relationships to give an

overview of the software system. It constitutes class names, attributes, and
functions in a separate compartment that helps in software development.
Since it is a collection of classes, interfaces, associations, collaborations, and
constraints, it is termed as a structural diagram.
 The attributes are written along with its visibility factors, which are
public (+), private (-), protected (#)

5. State Transition Diagram/State Chart Diagram:

The name of the diagram itself clarifies the purpose of the diagram and
other details. It describes different states of a component in a system. The
states are specific to a component/object of a system.
A Statechart diagram describes a state machine. State machine can be
defined as a machine which defines different states of an object and these
states are controlled by external or internal events.
Activity diagram explained in the next chapter, is a special kind of a
Statechart diagram. As Statechart diagram defines the states, it is used to
model the lifetime of an object
Statechart diagram describes the flow of control from one state to
another state. States are defined as a condition in which an object exists and
it changes when some event is triggered. The most important purpose of
Statechart diagram is to model lifetime of an object from creation to
termination.
The objects in sequence diagram is basic for state diagram.
 Start state and stop state ===== this are pseudo state.
Stop state ==== Bulls eye
There is no need to massage for start & stop state
It have only one start state but many stop state

6. Component Diagram: ======= Dependancy

To determine the dependancy between different parts of the

softwear components.
Components are two types:
1) Executable(Runtime)
eg. xyz.exe
2) Non-Executable(Compile Time)
Eg. ABC
Properties:-
Component diagram is always hierchial.
The flow of this diagram should be downwords.
Avoid loops or Bounded region in the component diagram
There are two ends for Dependancy
1) Dependent Component
2) Independent Component
 A component diagram is used to break down a large object-
oriented system into the smaller components, so as to make them
more manageable. It models the physical view of a system such as
executables, files, libraries, etc. that resides within the node.

It visualizes the relationships as well as the organization between the

components present in the system. It helps in forming an executable
system. A component is a single unit of the system, which is
replaceable and executable. The implementation details of a
component are hidden, and it necessitates an interface to execute a
function. It is like a black box whose behavior is explained by the
provided and required interfaces.

7. Deployment Diagram:

Nodes,processor and link between the nodes these are the main
component in deployment diagram.
Here solid line means Link.
Every node should contain name
Every link must technology === Technology is wired or wireless
but name must.
The deployment diagram visualizes the physical hardware on which
the software will be deployed. It portrays the static deployment view of a
system. It involves the nodes and their relationships.

It ascertains how software is deployed on the hardware. It maps the software

architecture created in design to the physical system architecture, where the
software will be executed as a node. Since it involves many nodes, the
relationship is shown by utilizing communication paths.
The main purpose of the deployment diagram is to represent how
software is installed on the hardware component. It depicts in what manner
a software interacts with hardware to perform its execution.

Both the deployment diagram and the component diagram are closely
interrelated to each other as they focus on software and hardware
components. The component diagram represents the components of a
system, whereas the deployment diagram describes how they are actually
deployed on the hardware.