Content

• Software Design
• Design Principles & Concepts
• Effective Modular Design, Cohesion and Coupling, Architectural design
Software Design
• Software design is the first of three technical activities—design, code generation, and test—that are
required to build and verify the software.

During design we make

decisions that will ultimately
affect the success of software
construction and, as important,
the ease with which software
can be maintained.
Software Design (Cont…)

• The flow of information during software design is illustrated in Figure above.

• Software requirements, manifested by the data, functional, and behavioral models, feed the design task.
Using one of a number of design methods, the design task produces a data design, an architectural design,
an interface design, and a component design.
• The data design transforms the information domain model created during analysis into the data
structures that will be required to implement the software. The data objects and relationships defined in
the entity relationship diagram and the detailed data content depicted in the data dictionary provide the
basis for the data design activity. Part of data design may occur in conjunction with the design of software
architecture. More detailed data design occurs as each software component is designed.
Software Design (Cont…)
• The architectural design defines the relationship between major structural elements of the software, the
“design patterns” that can be used to achieve the requirements that have been defined for the system,
and the constraints that affect the way in which architectural design patterns can be applied. The
architectural design representation—the framework of a computer-based system—can be derived from
the system specification, the analysis model, and the interaction of subsystems defined within the analysis
model.
• The interface design describes how the software communicates within itself, 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 behavior. Therefore, data and control flow diagrams provide much
of the information required for interface design.
• The component-level design transforms structural elements of the software architecture into a
procedural description of software components. Information obtained from the PSPEC, CSPEC, and STD
serve as the basis for component design.
Software Design (Cont…)
• The architectural design defines the relationship between major structural elements of the software, the
“design patterns” that can be used to achieve the requirements that have been defined for the system,
and the constraints that affect the way in which architectural design patterns can be applied. The
architectural design representation—the framework of a computer-based system—can be derived from
the system specification, the analysis model, and the interaction of subsystems defined within the analysis
model.
• The interface design describes how the software communicates within itself, 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 behavior. Therefore, data and control flow diagrams provide much
of the information required for interface design.
• The component-level design transforms structural elements of the software architecture into a
procedural description of software components. Information obtained from the PSPEC, CSPEC, and STD
serve as the basis for component design.
Design Principle
• The design process should not suffer from “tunnel vision.” A good designer should consider alternative
approaches, judging each based on the requirements of the problem, the resources available to do the job.
• The design should be traceable to the analysis model. Because a single element of the design model often
traces to multiple requirements, it is necessary to have a means for tracking how requirements have been
satisfied by the design model.
• The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of
which have likely been encountered before. These patterns should always be chosen as an alternative to
reinvention. Time is short and resources are limited! Design time should be invested in representing truly new
ideas and integrating those patterns that already exist.
• The design should “minimize the intellectual distance” between the software and the problem as it exists in
the real world. That is, the structure of the software design should (whenever possible) mimic the structure of
the problem domain.
• The design should exhibit uniformity and integration. A design is uniform if it appears that one person
developed the entire thing. Rules of style and format should be defined for a design team before design work
begins. A design is integrated if care is taken in defining interfaces between design components.
Design Principle (Cont…)
• The design should be structured to accommodate change. The design concepts discussed in the next
section enable a design to achieve this principle.
• The design should be structured to degrade gently, even when aberrant data, events, or operating
conditions are encountered. Welldesigned software should never “bomb.” It should be designed to
accommodate unusual circumstances, and if it must terminate processing, do so in a graceful manner.
• Design is not coding, coding is not design. Even when detailed procedural designs are created for program
components, the level of abstraction of the design model is higher than source code. The only design
decisions made at the coding level address the small implementation details that enable the procedural
design to be coded.
• The design should be assessed for quality as it is being created, not after the fact. A variety of design
concepts and design measures are available to assist the designer in assessing quality.
Design Concept

• Abstraction
• Refinement
• Modularity
Design Concept (Cont…)

• Abstraction:
• There are three basic types of abstraction.
• A procedural abstraction is a named sequence of instructions that has a specific and limited function. 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.).
• 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. Like any data object, the data
abstraction for door would encompass a set of attributes that describe the door (e.g., door type, swing
direction, opening mechanism, weight, dimensions). It follows that the procedural abstraction open would
make use of information contained in the attributes of the data abstraction door.
Design Concept (Cont…)

• Abstraction:
• Control abstraction is the third form of abstraction used in software design. Like procedural and data
abstraction, control abstraction implies a program control mechanism without specifying internal details.
An example of a control abstraction is the synchronization semaphore used to coordinate activities in an
operating system.
• Refinement:
• Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth.
• A program is developed by successively refining levels of procedural detail.
• A hierarchy is developed by decomposing a macroscopic statement of function (a procedural abstraction)
in a stepwise fashion until programming language statements are reached.
Design Concept (Cont…)

• Refinement:
• In each step (of the refinement), one or several instructions of the given program are decomposed into
more detailed instructions.
• This successive decomposition or refinement of specifications terminates when all instructions are
expressed in terms of any underlying computer or programming language .
• As tasks are refined, so the data may have to be refined, decomposed, or structured, and it is natural to
refine the program and the data specifications in parallel.
• Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify
procedure and data and yet suppress low-level details. Refinement helps the designer to reveal low-level
details as design progresses. Both concepts aid the designer in creating a complete design model as the
design evolves.
Design Concept (Cont…)
• Modularity:
• Modularity means software is divided into separately named and addressable components, often called
modules, that are integrated to satisfy problem requirements.
• It has been stated that "modularity is the single attribute of software that allows a program to be
intellectually manageable".
• Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped by a
reader. The number of control paths, span of reference, number of variables, and overall complexity
would make understanding close to impossible.
• How to define an appropriate module of a given size?
• Modular decomposability. If a design method provides a systematic mechanism for decomposing the
problem into subproblems, it will reduce the complexity of the overall problem, thereby achieving an
effective modular solution.
Design Concept (Cont…)

• Modularity:
• How to define an appropriate module of a given size?
• Modular composability. If a design method enables existing (reusable) design components to be
assembled into a new system, it will yield a modular solution that does not reinvent the wheel.
• Modular understandability. If a module can be understood as a standalone unit (without reference to
other modules), it will be easier to build and easier to change.
• Modular continuity. If small changes to the system requirements result in changes to individual modules,
rather than system-wide changes, the impact of change-induced side effects will be minimized.
• Modular protection. If an aberrant condition occurs within a module and its effects are constrained within
that module, the impact of error-induced side effects will be minimized.
Effective Modular Design

• Over the years, modularity has become an accepted approach in all engineering disciplines.
• A modular design reduces complexity, facilitates change, and results in easier implementation by
encouraging parallel development of different parts of a system.
• Functional Independence:
• The concept of functional independence is a direct outgrowth of modularity and the concepts of
abstraction and information hiding.
• Functional independence is achieved by developing modules with "single-minded" function and an
"aversion" to excessive interaction with other modules.
• In this, each module addresses a specific sub-function of requirements and has a simple interface when
viewed from other parts of the program structure.
Effective Modular Design (Cont…)

• Functional Independence:
• Software with effective modularity i.e. independent modules, is easier to develop because function may
be compartmentalized and interfaces are simplified.
• Independent modules are easier to maintain (and test) because secondary effects caused by design or
code modification are limited, error propagation is reduced, and reusable modules are possible.
• To summarize, functional independence is a key to good design, and design is the key to software quality.
• Independence is measured using two qualitative criteria: cohesion and coupling.
• Cohesion is a measure of the relative functional strength of a module.
• Coupling is a measure of the relative interdependence among modules.
Effective Modular Design (Cont…)

• Cohesion:
• A cohesive module performs a single task within a software procedure, requiring little interaction with
procedures being performed in other parts of a program.
• A cohesive module should (ideally) do just one thing.
• Cohesion represented as a "spectrum." The scale for cohesion is nonlinear. That is, low-end cohesiveness
is much "worse" than middle range, which is nearly as "good" as high-end cohesion.
• A designer need not be concerned with categorizing cohesion in a specific module. Rather, the overall
concept should be understood and low levels of cohesion should be avoided when modules are designed.
• At the low (undesirable) end of the spectrum, we encounter a module that performs a set of tasks that
relate to each other loosely. Such modules are termed coincidentally cohesive.
Effective Modular Design (Cont…)

• Cohesion:
• A module that performs tasks that are related logically (e.g., a module that produces all output regardless
of type) is logically cohesive.
• When a module contains tasks that are related by the fact that all must be executed with the same span of
time, the module exhibits temporal cohesion.
Effective Modular Design (Cont…)

• Coupling:
• Coupling is a measure 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.

Fig: Types of Coupling

Effective Modular Design (Cont…)
• Coupling:
• Figure above provides examples of different types of module coupling.
• Modules a and d are subordinate to different modules. Each is unrelated and therefore no direct coupling
occurs.
• Module c is subordinate to module a and is accessed via a conventional argument list, through which data
are passed.
• As long as a simple argument list is present, low coupling (called data coupling) is exhibited in this portion
of structure.
• A variation of data coupling, called stamp coupling, is found when a portion of a data structure (rather
than simple arguments) is passed via a module interface. This occurs between modules b and a.
Effective Modular Design (Cont…)
• Coupling:
• At moderate levels, coupling is characterized by passage of control between modules.
• Control coupling is very common in most software designs and is shown in Figure above where a “control
flag” (a variable that controls decisions in a subordinate or superordinate module) is passed between
modules d and e.
• Relatively high levels of coupling occur when modules are tied to an environment external to software. For
example, I/O couples a module to specific devices, formats, and communication protocols.
• External coupling is essential, but should be limited to a small number of modules with a structure. High
coupling also occurs when a number of modules reference a global data area. Common coupling, as this
mode is called, is shown in Figure above. Modules c, g, and k each access a data item in a global data area.
• The highest degree of coupling, content coupling, occurs when one module makes use of data or control
information maintained within the boundary of another module. Secondarily, content coupling occurs
when branches are made into the middle of a module. This mode of coupling can and should be avoided.
Effective Modular Design (Cont…)

• Architectural Design:
• The software architecture of a program or computing system is the structure or structures of the system,
which comprise software components, the externally visible properties of those components, and the
relationships among them.
• The architecture is not the operational software. Rather, it is a representation that enables a software
engineer to
• (1) analyze the effectiveness of the design in meeting its stated requirements
• (2) consider architectural alternatives at a stage when making design changes is still relatively easy
• (3) reducing the risks associated with the construction of the software.
Effective Modular Design (Cont…)
• Architectural Design:
• Data centered architectures:
• A data store will reside at the center of this architecture and is accessed frequently by the other components
that update, add, delete or modify the data present within the store.
• The figure illustrates a typical data centered style. The client software access a central repository. Variation
of this approach are used to transform the repository into a blackboard when data related to client or data
of interest for the client change the notifications to client software.
• This data-centered architecture will promote integrability. This means that the existing components can be
changed and new client components can be added to the architecture without the permission or concern of
other clients.
• Data can be passed among clients using blackboard mechanism.
Effective Modular Design (Cont…)
• Architectural Design:
• Data flow architectures:
• This kind of architecture is used when input data to be transformed into output data through a series of
computational manipulative components.
• The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has a set of components
called filters connected by pipes.
• Pipes are used to transmit data from one component to the next.
• Each filter will work independently and is designed to take data input of a certain form and produces data output
to the next filter of a specified form. The filters don’t require any knowledge of the working of neighboring filters.
• If the data flow degenerates into a single line of transforms, then it is termed as batch sequential. This structure
accepts the batch of data and then applies a series of sequential components to transform it.
Effective Modular Design (Cont…)

• Architectural Design:
Call and Return architectures: It is used to create a program that is easy to scale and modify. Many sub-styles
exist within this category. Two of them are explained below.

● Remote procedure call architecture: This components is used to present in a main program or sub program
architecture distributed among multiple computers on a network.
● Main program or Subprogram architectures: The main program structure decomposes into number of
subprograms or function into a control hierarchy. Main program contains number of subprograms that can
invoke other components.
Effective Modular Design (Cont…)
• Architectural Design:
● Object Oriented architecture: The components of a system encapsulate data and the operations that must be
applied to manipulate the data. The coordination and communication between the components are established
via the message passing.
● Layered architecture:
a. A number of different layers are defined with each layer performing a well-defined set of operations. Each
layer will do some operations that becomes closer to machine instruction set progressively.
b. At the outer layer, components will receive the user interface operations and at the inner layers,
components will perform the operating system interfacing(communication and coordination with OS)
c. Intermediate layers to utility services and application software functions.
Effective Modular Design (Cont…)
• Architectural Design:
• Layered pattern

• Client-server pattern

• Master-slave pattern

• Pipe-filter pattern

• Broker pattern

• Peer-to-peer pattern

• Event-bus pattern

• Model-view-controller pattern

• Blackboard pattern

• Interpreter pattern
Effective Modular Design (Cont…)
• Architectural Design:
• Layered pattern:
• This pattern can be used to structure programs that can be decomposed into groups of subtasks, each of which is
at a particular level of abstraction. Each layer provides services to the next higher layer.
• Client-server pattern:
• This pattern consists of two parties; a server and multiple clients. The server component will provide services to
multiple client components. Clients request services from the server and the server provides relevant services to
those clients. Furthermore, the server continues to listen to client requests.
• Master-slave pattern:
• This pattern consists of two parties; master and slaves. The master component distributes the work among
identical slave components, and computes a final result from the results which the slaves return.
• Pipe-filter pattern:
• This pattern can be used to structure systems which produce and process a stream of data. Each processing step
is enclosed within a filter component. Data to be processed is passed through pipes. These pipes can be used for
buffering or for synchronization purposes.
Effective Modular Design (Cont…)
• Architectural Design:
• Broker pattern:
• This pattern is used to structure distributed systems with decoupled components. These components can interact
with each other by remote service invocations. A broker component is responsible for the coordination of
communication among components. Servers publish their capabilities (services and characteristics) to a broker.
Clients request a service from the broker, and the broker then redirects the client to a suitable service from its
registry.
• Peer-to-peer pattern:
• In this pattern, individual components are known as peers. Peers may function both as a client, requesting
services from other peers, and as a server, providing services to other peers. A peer may act as a client or as a
server or as both, and it can change its role dynamically with time.
• Event-bus pattern:
• This pattern primarily deals with events and has 4 major components; event source, event listener, channel and
event bus. Sources publish messages to particular channels on an event bus. Listeners subscribe to particular
channels. Listeners are notified of messages that are published to a channel to which they have subscribed
before.
Effective Modular Design (Cont…)

• Architectural Design:
• Model-view-controller pattern:
• This pattern, also known as MVC pattern, divides an interactive application in to 3 parts as,
1. model — contains the core functionality and data
2. view — displays the information to the user (more than one view may be defined)
3. controller — handles the input from the user
• This is done to separate internal representations of information from the ways information is presented to, and
accepted from, the user. It decouples components and allows efficient code reuse.
• Interpreter pattern:
• This pattern is used for designing a component that interprets programs written in a dedicated language. It mainly
specifies how to evaluate lines of programs, known as sentences or expressions written in a particular language. The
basic idea is to have a class for each symbol of the language.
Effective Modular Design (Cont…)

• Architectural Design:
• Blackboard pattern
• This pattern is useful for problems for which no deterministic solution strategies are known. The blackboard
pattern consists of 3 main components.
● blackboard — a structured global memory containing objects from the solution space
● knowledge source — specialized modules with their own representation
● control component — selects, configures and executes modules.
● All the components have access to the blackboard. Components may produce new data objects that are added to the
blackboard. Components look for particular kinds of data on the blackboard, and may find these by pattern matching
with the existing knowledge source.