UNIT-IV

SYSTEM DESIGN

The importance of software design is quality for software engineering.

Design is the only way that you can accurately translate (converts)
stakeholder’s requirements into a finished software product or system.
 Design within the Context of Software Engineering
⚫ Software design sits at the technical kernel(center)of software engineering and is
applied regardless of the software process model that is used.
⚫ design is the last software engineering action within the modelling activity and sets
the stage for construction(code generation and testing).

Design Deployment
Commu- Analysis Construction
( installation)
nication modellin (code , test)
(Feedback)
modelling activity

Software Engineering
 THEDESIGN MODEL

Translating(converting) the requirements model (scenario-based, class-based, flow-oriented, and behavioural)

into the design model(data/class design, an architectural design, an interface design, and a component design)
 THE DESIGN MODEL ELEMENTS

Design model has 4 different elements.

1. architectural elements used to derive a complete
structural representation of the software, its subsystems,
and components.
2. Interface design elements used to design external and
internal interfaces and the user interface.
3. Component level elements used to define each of the
program modules (called components) that populate the
architecture.
4. Finally, deployment-level design elements allocate the
architecture that will house the software.
The architectural design
⚫ The architectural design defines the relationship between major structural
elements classes.
⚫ The architectural design representation is the framework of a
computer-based system.
⚫ The architectural design is derived from the requirements model(analysis
model).

The interface design

⚫ The interface design describes how the software communicates with
systems that interoperate with it, and with humans who use it.
⚫ An interface implies a flow of information (e.g., data and/or control) and a
specific type of behaviour.
⚫ Therefore, usage scenarios and behavioural requirement models provide
much of the information required for interface design.
The component-level design
⚫ The component-level design transforms structural elements of the software
architecture into a procedural(algorithm) description of software components.
⚫ Information obtained from the class-based models, flow models, and
behavioural models called requirements models serve as the basis for component
design.

The data/class(database) design

The data/class design transforms(converts) class models into design class realizations
and the requisite data structures required to implement the data/class(database) .
 THE DESIGN PROCESS
⚫ Software design is an iterative process through which stakeholders
requirements are translated(converted) into a “blueprint” or “rough sketch”
for constructing(coding & testing) the software.
Three characteristics called goals of a good design:
• The design must implement all of the explicit requirements contained in the
requirements model(analysis model) , and it must accommodate(accepted)
all of the implicit requirements desired by stakeholders.
• The design must be a readable, understandable guide for those who generate
code and for those who test and subsequently support the software.
• The design should provide a complete picture of the software, addressing the
data, functional, and behavioural domains from an implementation
perspective.
 THE DESIGN PROCESS contd.
consider the following Software Design Quality Guidelines:
1. A design should exhibit an architecture that (1) has been created using recognizable
architectural styles or patterns, (2) is composed of components (e.g.modules, objects,filters)that exhibit good
design characteristics and (3) can be implemented in an evolutionary fashion, thereby facilitating
implementation and testing.
2. A design should be modular. that is, the software should be logically partitioned into elements or
subsystems.
3. A design should contain distinct(different) representations of data, architecture, interfaces, and components.
4. A design should use data structures that are appropriate for the classes to be implemented and are drawn from
recognizable data patterns or styles
5. A design should use components(e.g.modules, objects,filters) that exhibit independent functional
characteristics.
6. A design should use interfaces that reduce the complexity of connections between components(e.g.modules,
objects,filters)and with the external environment.
7. A design should be derived using a repeatable method that is driven by information obtained during software
requirements analysis.
8. A design should be represented using a notation(a series of symbols) that effectively communicates its
meaning.

Software Design Quality Attributes:

Software Desisgn quality attributes that has been given the acronym FURPS—
F:Functionality
U: Usability
R: Reliability
P: Performance
S: Supportability
 DESIGN CONCEPTS
1. Abstraction
2. Architecture
3. Patterns
4. Separation of Concerns
5. Modularity
6. Information Hiding
7. Functional Independence
8. Refinement
9. Aspects
10. Refactoring
 DESIGN CONCEPTS contd.
Abstraction: It is a process of suppressing the specific details to the external world.
Levels of Abstraction: There are two levels(types) of abstractions.
1.Procedural abstraction 2. Data abstraction
1.A procedural abstraction refers to a sequence of instructions that have a specific
and limited function. The name of a procedural abstraction implies these
functions, but specific details are suppressed. An example of a procedural
abstraction would be the word open for a door. Open implies a long sequence of
procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and
pull door, step away from moving door, etc.)
2.A data abstraction is a named collection of data that describes a data object. In
the context of the procedural abstraction open, we can define a data abstraction
called door. the data abstraction for door would have a set of attributes that
describe the door (e.g., door type, swing direction, opening mechanism, weight,
dimensions).
DESIGN CONCEPTS contd.
⚫ Architecture
⚫ Software architecture refers to “the overall structure of the software and
the ways in which that structure provides conceptual integrity for a
system”.
⚫ Software architecture is the structure or organization of program
components (modules , objects , filters), the manner in which these
components interact, and the structure of data that are used by the
components. however, components can be generalized to represent major
system elements and their interactions.
⚫ One goal of software design is to derive an architectural displaying of a
system.
⚫ A set of architectural patterns enables a software engineer to solve
common design problems.
⚫ A number of different architectural description languages (ADLs) have
been developed to represent these models
DESIGN CONCEPTS contd.
Patterns
⚫ A pattern is a proven solution to a recurring( repeatedly) problem within a
certain context.
⚫ Stated in another way a design pattern describes a design structure that
solves a particular design problem within a specific context in which the
pattern is applied and used.
⚫ The intent of each design pattern is to provide a description that enables a
designer to determine
(1) whether the pattern is applicable to the current work
(2) whether the pattern can be reused (hence, saving design time), and
(3) whether the pattern can serve as a guide for developing a similar, but
functionally or structurally different pattern.
DESIGN CONCEPTS contd.
⚫ Separation of Concerns
⚫ Separation of concerns is a design concept that suggests that any complex
problem can be more easily handled if it is subdivided into pieces that can
each be solved and/or optimized independently. A concern is a feature or
behaviour that is specified as part of the requirements model(analysis
model) for the software. By separating concerns into smaller, and therefore
more manageable pieces, a problem takes less effort and time to solve.

⚫ Separation of concerns is listed in other related design concepts:

modularity, aspects, functional independence, and refinement.
DESIGN CONCEPTS contd.
⚫ Modularity
⚫ Modularity is the most common list of separation of concerns. Software is
divided into separately named and addressable components, sometimes called
modules, that are integrated to satisfy problem requirements.

⚫ Advantages of modularization(modularity):
To modularize a design
1. Software development can be more easily planned.
2. Software increments can be defined and delivered.
3. Software changes can be more easily accommodated.
4. Software testing and debugging can be conducted more efficiently.
5. and long-term software maintenance can be conducted without serious
side effects.
DESIGN CONCEPTS contd.
⚫ Information Hiding
⚫ Hiding implies that effective modularity can be achieved by defining a set
of independent modules that communicate with one another only that
information necessary to achieve software function.
⚫ The purpose of information hiding is to hide the details of data structures
and procedural processing behind a module interface. Knowledge of the
details need not be known by users of the module.
 DESIGN CONCEPTS contd.
⚫ Functional Independence
⚫ The concept of functional independence is a direct outgrowth of separation of concerns ,
modularity, and the concepts of abstraction and information hiding.
⚫ Functional independence is achieved by developing modules with “single minded” function
and little interaction with other modules.
⚫ Software with effective modularity by functionally independent modules have the following
advantages
1.Easier to develop 2.Easier to maintain and test 3.Key to good design, and design is the key to
software quality.
⚫ Functional Independence is evaluated using two qualitative criteria: cohesion and coupling.
⚫ Cohesion is an indication of the relative functional strength of a module. Coupling is an
indication of the relative interdependence among modules.
⚫ Cohesion is a natural extension of the information-hiding.
⚫ A cohesive module performs a single task, requiring little interaction with other components in
other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing.
Although you should always have great efforts to achieve for high cohesion(i.e.,
single-mindedness) However, “schizophrenic” components(modules that perform many
unrelated functions) are to be avoided if a good design is to be achieved.
⚫ Coupling is an indication of interconnection among modules in a software structure. Coupling
depends on the interface complexity between modules, the point at which entry or reference is
made to a module, and what data pass across the interface. Although you should always have
great efforts to achieve for low coupling(little interaction with other components of a
program).
DESIGN CONCEPTS contd.
⚫ Refinement
⚫ Refinement is actually a process of elaboration. You begin with a
statement of function (or description of information) that is defined at a
high level of abstraction. That is, the statement describes function or
information conceptually(logically) but provides no information about the
internal workings of the function or the internal structure of the
information. You then elaborate on the original statement, providing more
and more detail as each successive refinement (elaboration) occurs.
⚫ Abstraction and refinement are complementary concepts. Abstraction
suppresses the specific low level details to external world but Refinement
reveals low-level details as design development. Both concepts allow you
to create a complete design model as the design evolves.
DESIGN CONCEPTS contd.
⚫ Aspects
⚫ The design architecture should support a mechanism for defining an
aspect—a module that enables the concern to be implemented across all
other concerns that it crosscuts.
DESIGN CONCEPTS contd.
⚫ Refactoring
⚫ Refactoring is an important design activity suggested for many agile methods.
⚫ Refactoring is a reorganization technique that simplifies the design (or code) of a
component(e.g. Module , object, filter) without changing its function or behaviour.
⚫ Fowler [Fow00] defines refactoring in the following manner: “Refactoring is the process of
changing a software system in such a way that it does not alter the external behaviour of the
code [design] yet improves its internal structure.”

When software is refactored,

1. The existing design is examined for redundancy.
2. unused design elements.
3. Inefficient or Unnecessary algorithms.
4. Poorly Constructed(coded and tested) or
5. Inappropriate Data Structures used to implement classes or
6. Any other design failure that can be corrected to give a better design.
7. For example, a first design iteration might give a component(e.g. Module , object, filter)
that exhibits low cohesion.
 ARCHITECTURAL
MODELLING .
⚫ What Is software?
⚫ Software architecture provides the structure and
organization of software components, their properties,
and the connections between them.
⚫ Software components include program modules and
the various data representations that are manipulated
by the program.
⚫ Therefore, data design is an integral part of the
derivation of the software architecture.
Why Is Software Architecture Important?
Three key reasons that software architecture is important:
• Representations of software architecture are an enabler for
communication between all parties (stakeholders) interested
in the development of a computer based system.

• The architecture highlights early design decisions that will

have a profound impact on all software engineering work
that follows and, as important, on the ultimate success of the
system as an operational entity.

• Architecture “constitutes a relatively small, intellectually

graspable model of how the system is structured and how its
components work together”
ARCHITECTURAL GENRES(category)
The following architectural genres software-based systems:
Artificial intelligence—Systems that simulate or augment human cognition,locomotion, or other
organic processes.
• Commercial and nonprofit—Systems that are fundamental to the operation of a business
enterprise.
• Communications—Systems that provide the infrastructure for transferring and managing data,
for connecting users of that data, or for presenting data at the edge of an
infrastructure.
• Content authoring—Systems that are used to create or manipulate textual or multimedia
artifacts.
Devices—Systems that interact with the physical world to provide some point service for an
individual.
• Entertainment and sports—Systems that manage public events or that provide a large group
entertainment experience.
ARCHITECTURAL GENRES(category)
• Financial—Systems that provide the infrastructure for transferring and
managing money and other securities.
• Games—Systems that provide an entertainment experience for individuals
or groups.
• Government—Systems that support the conduct and operations of a local,
state, federal, global, or other political entity.
• Industrial—Systems that simulate or control physical processes.
• Legal—Systems that support the legal industry.
• Medical—Systems that diagnose or heal or that contribute to medical
research.
• Military—Systems for consultation, communications, command, control,
and intelligence (C4I) as well as offensive and defensive weapons.
• Operating systems—Systems that sit just above hardware to provide basic
software services.
• Platforms—Systems that sit just above operating systems to provide
advanced services.
• Scientific—Systems that are used for scientific research and applications.
• Tools—Systems that are used to develop other systems.
• Transportation—Systems that control water, ground, air, or space vehicles.
• Utilities—Systems that interact with other software to provide some point
service.
 ARCHITECTURAL STYLES
⚫ Data-centered architectures.

A data store (e.g., a file or database) resides at the center of this architecture and is accessed
frequently by other components that update, add, delete, or otherwise modify data within the store.
Client software accesses a central repository.
 ARCHITECTURAL STYLES
⚫ Data-flow architectures.
Data-flow architectures.
This architecture is applied when input data are to be
transformed through a series of computational or manipulative
components into output data.
A pipe-and-filter pattern (Figure 9.2) has a set of components,
called filters, connected by pipes that transmit data from
one component to the next.
Each filter works independently of those components
upstream and downstream, is designed to expect data input
of a certain form, and produces data output (to the next
filter) of a specified form. However, the filter does not require
knowledge of the workings of its neighboring filters.
Call and return architectures.
⚫ This architectural style enables you to achieve a
⚫ program structure that is relatively easy to modify and
scale.
⚫ A number of substyles exist within this category:
⚫ • Main program/subprogram architectures. This classic
program structure decomposes function into a control
hierarchy where a “main” program invokes a number of
program components that in turn may invoke still
other components.
Call and return architectures.
Object-oriented architectures.
⚫ The components of a system encapsulate data and the operations that must be
applied to manipulate the data.
⚫ Communication and coordination between components are accomplished via
message passing.
⚫ Layered architectures. The basic structure of a layered
architecture is illustrated in Figure.
⚫ A number of different layers are defined, each accomplishing
operations that progressively become closer to the machine
instruction set.
⚫ At the outer layer, components service user interface operations. At
the inner layer, components (program modules)perform operating
system interfacing. Intermediate layers provide utility services and
application software functions.
ASSESSING ALTERNATIVE ARCHITECTURAL DESIGNS

⚫ Architectural description language (ADL) provides a

semantics and syntax for describing a software
architecture.
⚫ an ADL should provide the designer with the ability to
decompose architectural components,
⚫ an ADL should compose individual components into
larger architectural blocks, and represent interfaces
(connection mechanisms) between components.
⚫ Once descriptive, language based techniques for
architectural design have been established, it is more
likely that effective assessment methods for
architectures will be established as the design evolves.
 ARCHITECTURAL MAPPING USING DATA FLOW

A mapping technique, called structured design is often

characterized as a
data flow-oriented design method because it provides a
convenient transition from a data flow diagram to software
architecture.
The transition from information flow (represented as a DFD) to
program structure is accomplished as part of a six step
process:
(1) the type of information flow is established,
(2) flow boundaries are indicated,
(3) the DFD is mapped into the program structure,
(4) control hierarchy is defined,
(5) the resultant structure is refined using design
measures and heuristics, and
(6) the architectural description is refined and
elaborated.