UNIT - III

DESIGN PROCESS AND DESIGN QUALITY:

It encompasses the set of principles, concepts and practices that lead to the
development of high quality system or product. Design creates a representation or
model of the software. Design model provides details about S/W architecture,
interfaces and components that are necessary to implement the system. Quality is
established during Design. Design should exhibit firmness, Content and design.
Design sits at the kernel of S/W Engineering. Design sets the stage for construction.
DESIGN CONCEPTS:
1. Abstraction
2. Architecture
3. Patterns
4. Modularity
5. Information Hiding
6. Functional Independence
7. Refinement
8. Re-Factoring
9. Design Classes.
1. Abstraction: Abstraction is a fundamental principle in software development
that aims to simplify complex systems or components, making it easier for
developers to understand, use, and manage them. By focusing on the essential
functionality and hiding intricate details, abstraction promotes modularity,
maintainability, and reusability of code.

Levels of abstraction:

Highest level of abstraction: Solution is slated in broad terms using the language
of the problem environment.

Lower levels of abstraction: More detailed description of the solution is provided.

Procedural abstraction: Refers to a sequence of instructions that a specific and

limited function.

Data abstraction: Named collection of data that describe a data object.

2. Architecture: Structural organization of program components (modules) and

their interconnection called Architecture Models such as
a. Structural Models: An organized collection of program components
b. Framework Models: Represents the design in more abstract way
c. Dynamic Models: Represents the behavioural aspects indicating changes as
a function of External events
d. Process Models: Focus on the design of the business or technical process
3. Patterns:
Provides a description to enables a designer to determine the following:
a. Whether the pattern is applicable to the current work
b. Whether the pattern can be reused
c. Whether the pattern can serve as a guide for developing a similar but
functionally or structurally different pattern

4. Modularity:
Divides software into separately named and addressable components,
sometimes called modules. Modules are integrated to satisfy problem
requirements. Consider two problems p1 and p2. If the complexity of p1 is cp1
and of p2 is cp2 then effort to solve p1=ep1 and effort to solve p2=ep2. If
cp1>cp2 then ep1>ep2.

The complexity of two problems when they are combined is often greater than
the sum of the perceived complexity when each is taken separately. Based on
Divide and Conquer strategy. It is easier to solve a complex problem when
broken into sub-modules.

5. Information Hiding:
Information contained within a module is inaccessible to other modules that do
not need such information achieved by defining a set of Independent modules
that communicate with one another only that information necessary to achieve
S/W function provides the greatest benefits when modifications are required
during testing and later. Errors introduced during modification are less likely to
propagate to other location within the S/W.

6. Functional Independence:
It is the direct outgrowth of Modularity of abstraction and information hiding.
It is achieved by developing a module with single minded function and an anti
to excessive interaction with other modules. Easier to develop and have simple
interface. Easier to maintain because secondary effects caused by design or
code modification are limited, error propagation is reduced and reusable
modules are possible. Independence is assessed by two quantitative criteria:

a. Cohesion
b. Coupling

Cohesion: Performs a single task requiring little interaction with other modules.
Coupling: Measure of interconnection among modules. Coupling should be low
and cohesion should be high for good design.

7. Refinement & Refactoring:

Refinement: Process of elaboration from high level abstraction to the lowest
level abstraction. High level abstraction begins with a statement of functions.
Refinement causes the designer to elaborate providing more and more details at
 successive level of abstractions Abstraction and refinement are complementary
concepts.
8. Refactoring: It is an organization technique that simplifies the design of a
component without changing its function or behaviour. It examines for
redundancy, unused design elements and inefficient or unnecessary algorithms.

9. Design Classes:

Class represents a different layer of design architecture. Five types of Design Classes

a. User interface class: Defines all abstractions that are necessary for human
computer interaction
b. Business domain class: Refinement of the analysis classes that identity attributes
And Services to implement some of business domain.
c. Process class: Implements lower level business abstractions required to fully
manage the business domain classes
d. Persistent class: Represent data stores that will persist beyond the execution of
the software
e. System class: Implements management and control functions to operate and
Communicate within the computer environment and with the outside world.

Design Model:
A design model is the means to describe a system's implementation and source
code in a diagrammatic fashion. It has two advantages: simpler representation
and it can be quickly understood. Moving from requirements to design
specifications involves these steps: Architectural. Interface.

The design phase of software development deals with transforming the

customer requirements as described in the SRS documents into a form
implementable using a programming language. The software design process
can be divided into the following three levels or phases of design:

1. Interface Design
2. Architectural Design
3. Detailed Design
 Overall S/w design process:

The architectural design model:

The architectural design elements are derived from:

1. Information about the application domain of the software

2. Analysis model such as dataflow diagrams or analysis classes.
3. Architectural pattern and styles Interface Design Elements Set of
detailed drawings constituting:
4. User interface
5. External interfaces to other systems, devices etc.
6. Internal interfaces between various components

Component Level Design:

Component design is a type of software design and architecture. The component-

based architecture focuses on breaking the software design into small individual
modules. The component design describes communication, interfaces, algorithms, and
the functionalities of each component regarding the whole software design.

A software component is a software package or service that is modular and

encapsulates a set of related functions or data. Components communicate with each
other via interfaces. Each component provides an interface through which other
components can use it. When a component uses another component's interface, that
interface is called a user interface. Components should be reusable.

Data Design:

It creates a model of data that is represented at a high level of abstraction.

1. It is refined progressively to more implementation-specific

representation for processing by the computer based system
2. Translation of data model into a data base is important task to achieve
business objective of a system.
3. Data design translates data objects defined as a part of the analysis
model into
a. Data structures at the software component level
 b. A possible database architecture at application level
4. It focuses on the representation of data structures that are directly
accessed by one or more software components.
5. The challenge is to store and retrieve the data in such a way that useful
information can be extracted from the database.

Architectural Styles and Patterns:

What is an architectural Style?

a. An architectural style, sometimes called an architectural Pattern.

b. It provides an abstract frame work for a family of Systems.
c. An architectural style improves partitioning and promotes design reuse
by providing solutions to frequently recurring problems.

Architectural Design:
Architectural design is the designing and planning of structures where functionality
and aesthetics are the two key elements of the process. The design must be suitable for
the experience of the user as well as meet the needs of the client and or project
requirements.

The architecture of a system describes its major components, their relationships

(structures), and how they interact with each other. Software architecture and design
includes several contributory factors such as Business strategy, quality attributes,
human dynamics, design, and IT environment.
Conceptual Model of UML:

Conceptual modelling is the process of developing an abstract model or graphical

representation using real-world concepts or ideas. During conceptual modelling,
various assumptions are made regarding how the system functions. Conceptual
models also illustrate the dominant processes in a system and how they are linked.
These processes may include factors known to drive change in the system, or they
may encompass the consequences of change in the factors themselves.

The conceptual data model represents the overall structure of data required to support
the business requirements independent of any software or data storage structure.

Entities represent real-world objects involved in a business. In an online store,

customers, the orders they place, and the items offered for sale are all entities. These
are very similar to a table in a database.
Attributes are the characteristics that describe individual entities. For example, a
customer might be described by their first and last name, account number, and email
address.
Relationships show which entities are connected.
Example: - customers and orders would be connected because customers place
orders.

The UML is a standard representation devised by the developers of widely used

object- oriented analysis and design methods. It has become an effective standard for
object-oriented modelling.
Notations Used:

Object classes are rectangles with the name at the top, attributes in the middle section
and operations in the bottom section.
Relationships between object classes (known as associations) are shown as lines
linking objects.
Inheritance is referred to as generalization and is shown upwards rather than
downwards in a hierarchy.
Example: - Library Class Hierarchy: Multiple inheritance:
Classification of Diagrams in UML:

Basic Structural Modelling:

 Classes and Relationships

 Common Mechanism
 Diagrams
 Class Diagram

Structural model represents the framework for the system and this framework is the
place where all other components exist. Hence, the class diagram, component diagram
and deployment diagrams are part of structural modelling. They all represent the
elements and the mechanism to assemble them.
Class: Description of a set of objects sharing the same attributes, operations and
semantics.
Attributes:
 Named properties of class representing the state of the objects
 It is the extension of Classical Data Structures
 It can include type and default values.
Sequence diagrams:
A sequence diagram is a Unified Modelling 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.
Example Sequence Diagram:

Collaboration Diagrams:
A collaboration diagram, also known as a communication diagram, is an
illustration of the relationships and interactions among software objects in the
Unified Modelling Language (UML).

Following are the components of a Collaboration diagram that are enlisted

below:

Objects: The representation of an object is done by an object symbol with its

name and class underlined, separated by a colon.

In the collaboration diagram, objects are utilized in the following ways:

 The object is represented by specifying their name and class.

 It is not mandatory for every class to appear.
 A class may constitute more than one object.
 In the collaboration diagram, firstly, the object is created, and then its class is
specified.
 To differentiate one object from another object, it is necessary to name them.

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.
It portrays a relationship between the objects through which the messages are sent. It
is represented by a solid line. The link helps an object to connect with or navigate to
another object, such that the message flows are attached to links.

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
labelled arrow, which is placed near a link. The messages are sent from the sender to
the receiver, and the direction must be navigable in that particular direction. The
receiver must understand the message.
USE CASE DIAGRAMS:

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.
There are four main components of a use case diagram are actors, systems,
relationships, and use cases. Actors are any human or external system that interacts
with the system. Systems are the main components of the system being modelled.
Relationships show how the actors and systems interact with each other.
Component Diagram:

A component diagram depicts how the software's components

are organized and interact. This diagram shows the
components of a system at a high level. ATM component
diagram components can be software or hardware.