Design process SE

Classification of design activities

Software design deals with transforming the client requirements, as described in the SRS
document, into a form that is suitable for implementation in a programming language. A good
software design is achieved through several series of steps.
The software design process can be divided into the following three levels:
1) Architectural Design
2) Preliminary (High-Level) Design
3) Detailed Design

Architectural Design - The architectural design is the highest abstract version of the system. It
identifies the software as a system with many components interacting with each other. At this
level, the designers get the idea of proposed solution domain.

High-level Design- The high-level design breaks the ‘single entity-multiple component’ concept
of architectural design into less-abstracted view of sub-systems and modules and depicts their
interaction with each other. It recognizes modular structure of each sub-system and their relation
and interaction among each other.

Detailed Design- Detailed design deals with the implementation part of what is seen as a system
and its sub-systems in the previous two designs. It is more detailed towards modules and their
implementations. It defines logical structure of each module and their interfaces to communicate
with other modules.

Classification of design methodology

Structured Design
Structured design is an abstraction of problem into several well-organized elements of solution.
It is basically concerned with the solution design. Benefit of structured design is, it gives better
understanding of how the problem is being solved.
Structured design is mostly based on ‘divide and conquer’ strategy where a problem is broken
into several small problems and each small problem is individually solved until the whole
problem is solved. A good structured design has high cohesion and low coupling arrangements.

Function Oriented Design

In function-oriented design, the system is comprised of many smaller sub-systems known as
functions. These functions are capable of performing significant task in the system. Function
oriented design inherits some properties of structured design where divide and conquer
methodology is used.
This design mechanism divides the whole system into smaller functions. These functional
modules can share information among themselves by means of information passing and using
information available globally.
Design process SE

Object Oriented Design

Object oriented design works around the entities and their characteristics instead of functions
involved in the software system. This design strategies focuses on entities and its characteristics.
Let us see the important concepts of Object Oriented Design:
Objects - All entities involved in the solution design are known as objects. For example, person,
banks, company and customers are treated as objects.
Classes - A class is a generalized description of an object. An object is an instance of a class.
Class defines all the attributes, which an object can have and methods, which defines the
functionality of the object.
Encapsulation - the attributes (data variables) and methods (operation on the data) are bundled
together is called encapsulation. Encapsulation also restricts access of the data and methods from
the outside world. This is called information hiding.
Inheritance - OOD allows similar classes to stack up in hierarchical manner where the lower or
sub-classes can import, implement and re-use allowed variables and methods from their
immediate super classes.
Polymorphism - OOD languages provide a mechanism where methods performing similar tasks
but vary in arguments, can be assigned same name.

Cohesion and coupling

The purpose of Design phase in the Software Development Life Cycle is to produce a solution
to a problem given in the SRS(Software Requirement Specification) document.
Coupling and Cohesion are two key concepts in software engineering that are used to measure
the quality of a software system’s design.
Coupling: Coupling is the measure of the degree of interdependence between the modules.
High coupling means that modules are closely connected and changes in one module may
affect other modules. Low coupling means that modules are independent and changes in one
module have little impact on other modules. Good software will have low coupling.
Cohesion: refers to the degree to which elements within a module work together to fulfill a
well-defined purpose. High cohesion means that elements are closely related and focused on a
single purpose, while low cohesion means that elements are loosely related and serve multiple
purposes.
 Both coupling and cohesion are important factors in determining the maintainability
and reliability of a software system.
 Low coupling and high cohesion make a system easier to maintain and improve.
Data modeling concepts
Data modeling is the process of creating a simplified diagram of a software system and the data
elements it contains, using text and symbols to represent the data and how it flows.
Design process SE

A data model can be thought of as a flowchart that illustrates data entities, their attributes and the
relationships between entities.
The process of data modeling typically involves several steps, including requirements gathering,
conceptual design, logical design, physical design, and implementation.
Data modeling examples:
1. ER (Entity-Relationship) Model: Here, an entity is a real-world object; for instance, an
employee is an entity in an employee database. An attribute is a property with value, and entity
sets share attributes of identical value. Finally, there is the relationship between entities.
2. Hierarchical Model : This data model arranges the data in the form of a tree with one root, to
which other data is connected. The hierarchy begins with the root and extends like a tree. This
model effectively explains several real-time relationships with a single one-to-many relationship
between two different kinds of data.
3. Network Model: This model enables many-to-many relationships among the connected
nodes. The data is arranged in a graph-like structure, and here ‘child’ nodes can have multiple
‘parent’ nodes. The parent nodes are known as owners, and the child nodes are called members.
4. Relational Model: This popular data model example arranges the data into tables. The tables
have columns and rows, each representing an attribute present in the entity. It makes
relationships between data points easy to identify.
Types of Data Modeling
There are three main types of data models that organizations use.
1. Conceptual Model
It is a visual representation of database concepts and the relationships between them identifying
the high-level user view of data. Rather than the details of the database itself, it focuses on
establishing entities, characteristics of an entity, and relationships between them.
2. Logical Model
This model further defines the structure of the data entities and their relationships. Usually, a
logical data model is used for a specific project since the purpose is to develop a technical map
of rules and data structures.
3. Physical Model
This is a framework defining how data is physically stored in a database. It is used for database-
specific modeling where the columns include exact types and attributes. A physical model
designs the internal schema. The purpose is the actual implementation of the database.

Data model consists of following fundamental elements:

Data objects
The data object is actually a location of storage that contains a collection of attributes that act
as characteristic, quality, or descriptor of the object. A vehicle is a data object which can be
defined or described with the help of a set of attributes or data.
 External entities such as a printer, user, speakers, keyboard, etc.
 Things such as reports, displays, signals.
Design process SE

Data attributes
Attributes define the properties of a data object. The attribute is a quality or characteristic that
defines a person, group, or data objects. An attribute can have a single or multiple values as per
our needs.
Relationship(ER diagram)
The relationship represents the relation between different data objects and describes
association among entities. Relationships are of three types: one-to-many, many-to-many, and
many-to-one.
For example, toy and shopkeeper are two objects that share the following relationship:
 The Shopkeeper order toys.

Cardinality and modality

Cardinality and Modality are the two data modeling concepts used for understanding the
information domain of the problem.
BASIS FOR
CARDINALITY MODALITY
COMPARISON
Basic Maximum number of associations Minimum number of row
between the table rows. associations.
Types One-to-one, one-to-many, many-to- Nullable and not nullable.
many.

Lets say for example, we have two data objects A and B with attributes a1,a2,a3..............an and
b1.b2,b3........ respectively. They are related to each other by relation R

This information is not sufficient. We must also know how many elements of A are related to
how many elements of B by relation R. This concept is called cardinality. There may be some
cases when a defined relationship is not mandatory. This concept is called as modality.
Design process SE

Cardinality: Cardinality is the specification of number of occurrences of one object that can be
related to number of occurrences of another object. It generally defines the maximum number of
objects that can participate in a relationship. On the basis of cardinality a relationship can be one
to one (1:1) one to one (1: M) many to many (M-M).

Modality: Modality of a relationship is represented by 1 if it is mandatory 0 if it is not

mandatory. In simple words, it describes whether a relationship between two or more entities is
even required or not.

Data flow diagram

Design process SE

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.
Primitive symbols of DFD

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.

Data Flow: A curved line shows the flow of data into or out of a process or data store.

Data Store: A set of parallel lines shows a place for the collection of data items. A data store
indicates that the data is stored which can be used at a later stage or by the other processes in a
different order. The data store can have an element or group of elements.

Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or sink
of system outputs.
Design process SE
Design process SE

Develop DFD model of system

Levels in Data Flow Diagrams (DFD)

DFDs may be partitioned into levels that represent increasing information flow and functional
detail. 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.

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 subprocesses.
Design process SE

2-levelDFD:
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.