DESIGN ENGINEERING

DESIGN CONCEPTS
• Design creates a representation or model of the software.
• Unlike the requirements model (that focuses on describing required data,
function, and behavior), the design model provides detail about software
architecture, data structures, interfaces, and components that are necessary to
implement the system.
• Software engineers conduct each of the design tasks.
• This model can be assessed for quality and improved before code is generated.
Design depicts the software in a number of different ways.
• First, the architecture of the system or product must be represented.
• Then, the interfaces that connect the software to end users, to other systems and
devices, and to its own constituent components are modeled.
• Finally, the software components that are used to construct the system are
designed.
DESIGN CONCEPTS
• A set of fundamental software design concepts has evolved over the history of
software engineering. Important software design concepts that span both
traditional and object-oriented software development are discussed below:
1) Abstraction.
• At the highest level of abstraction, a solution is stated in broad terms using the
language of the problem environment.
• At lower levels of abstraction, a more detailed description of the solution is
provided.
• As different levels of abstraction are developed, you work to create both
procedural and data abstractions.
• A procedural abstraction refers to a sequence of instructions that have a specific and
limited function.
• A data abstraction is a named collection of data that describes a data object.
2. Architecture
•Software architecture alludes to “the overall structure of the software and the
ways in which that structure provides conceptual integrity for a system”.
•In its simplest form, architecture is the structure or organization of program
components (modules), the manner in which these components interact, and the
structure of data that are used by the components.
•A set of properties that should be specified as part of an architectural design are:
• Structural properties. This aspect of the architectural design representation
defines the components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with one
another.
• Extra-functional properties. The architectural design description should
address how the design architecture achieves requirements for performance,
capacity, reliability, security, adaptability, and other system characteristics.
• Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of families
of similar systems.
3. Patterns
• A design pattern describes a design structure that solves a particular design
problem within a specific context and amid “forces” that may have an impact on
the manner 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.
4. 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 behavior that is specified as part of the requirements
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 manifested in other related design concepts: modularity,
aspects, functional independence, and refinement.
5. Modularity.
•Modularity is the most common
manifestation of separation of concerns.
•Software is divided into separately named
and addressable components, sometimes
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”.
•You modularize a design (and the resulting
program) so that development can be more
easily planned; software increments can be
defined and delivered; changes can be more
easily accommodated; testing and debugging
can be conducted more efficiently, and long-
term maintenance can be conducted without
6. 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.
• Abstraction helps to define the procedural (or informational) entities that make
up the software. Hiding defines and enforces access constraints to both
procedural detail within a module and any local data structure used by the
module.
• The use of information hiding as a design criterion for modular systems provides
the greatest benefits when modifications are required during testing and later
during software maintenance.
• Because most data and procedural detail are hidden from other parts of the
software, inadvertent errors introduced during modification are less likely to
propagate to other locations within the software.
7. Functional Independence
•Functional independence is achieved by developing modules with “singleminded”
function and an “aversion” to excessive interaction with other modules.
•Stated another way, you should design software so that each module addresses a
specific subset of requirements and has a simple interface when viewed from other
parts of the program structure.
•Software with effective modularity, that is, independent modules, is easier to
develop because function can 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.
• Independence is assessed using two qualitative criteria: cohesion and coupling.
• Cohesion is an indication of the relative functional strength of a module.
• Cohesion is a natural extension of the information-hiding concept.
• A cohesive module performs a single task, requiring little interaction with other
components in other parts of a program.
• A cohesive module should (ideally) do just one thing.
• Although you should always strive for high cohesion (i.e., single-mindedness), it is
often necessary and advisable to have a software component perform multiple
functions. 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 the relative interdependence among modules.
• 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.
• In software design, you should strive for the lowest possible coupling.
• Simple connectivity among modules results in software that is easier to
understand and less prone to a “ripple effect”( caused when errors occur at one
location and propagate throughout a system).
8. Refinement
• A hierarchy is developed by decomposing a macroscopic statement of function (a
procedural abstraction) in a stepwise fashion until programming language
statements are reached.
• 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 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.
9. Refactoring
• Refactoring is a reorganization technique that simplifies the design (or code) of a
component without changing its function or behavior.
• Refactoring is the process of changing a software system in such a way that it
does not alter the external behavior of the code [design] yet improves its internal
structure.
• When software is refactored, the existing design is examined for redundancy,
unused design elements, inefficient or unnecessary algorithms, poorly
constructed or inappropriate data structures, or any other design failure that can
be corrected to yield a better design.
• For example, a first design iteration might yield a component that exhibits low
cohesion (i.e., it performs three functions that have only limited relationship to
one another). After careful consideration, you may decide that the component
should be refactored into three separate components, each exhibiting high
cohesion.
10. Object-Oriented Design Concepts
The object-oriented (OO) paradigm is widely used in modern software engineering.

11. Design Classes

•The requirements model defines a set of analysis classes (Chapter 6). Each
describes some element of the problem domain, focusing on aspects of the
problem that are user visible. The level of abstraction of an analysis class is
relatively high.
•As the design model evolves, you will define a set of design classes that refine the
analysis classes by providing design detail that will enable the classes to be
implemented, and implement a software infrastructure that supports the business
solution.
• Five different types of design classes, each representing a different layer of the
design architecture, can be developed.
1) User interface classes define all abstractions that are necessary for humancomputer
interaction (HCI).
2)Business domain classes are often refinements of the analysis classes defined earlier. The
classes identify the attributes and services (methods) that are required to implement some
element of the business domain.
3)Process classes implement lower-level business abstractions required to fully
manage the business domain classes.
4)Persistent classes represent data stores (e.g., a database) that will persist
beyond the execution of the software.
5)System classes implement software management and control functions that
enable the system to operate and communicate within its computing environment
and with the outside world.
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 you 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, and
(3) reduce the risks associated with the construction of the software.
ARCHITECTURAL STYLES
• The software that is built for computer-based systems also exhibits one of many
architectural styles.
• Each style describes a system category that encompasses:
(1) a set of components (e.g., a database, computational modules) that perform
a function required by a system;
(2) a set of connectors that enable “communication, coordination and
cooperation” among components;
(3) constraints that define how components can be integrated to form the
system;
(4) semantic models that enable a designer to understand the overall properties
of a system by analyzing the known properties of its constituent parts.
A Brief Taxonomy of Architectural Styles
1. 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.
• In some cases the data repository is passive. That is, client software accesses the
data independent of any changes to the data or the actions of other client
software.
• A variation on this approach transforms the repository into a “blackboard”that
sends notifications to client software when data of interest to the client changes.
2.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 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.
• The filter does not require knowledge of the workings of its neighboring filters.
• If the data flow degenerates into a single line of transforms, it is termed batch
sequential.
• This structure accepts a batch of data and then applies a series of sequential
components (filters) to transform it.
3. 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.
• Remote procedure call architectures. The components of a main
program/subprogram architecture are distributed across multiple computers
on a network.
4. 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.
5. Layered architectures.
• 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 perform operating system interfacing.
Intermediate layers provide utility services and application software functions.
• These architectural styles are only a small subset of those available. Once
requirements engineering uncovers the characteristics and constraints of the
system to be built, the architectural style and/or combination of patterns that
best fits those characteristics and constraints can be chosen. In many cases, more
than one pattern might be appropriate and alternative architectural styles can be
designed and evaluated. For example, a layered style (appropriate for most
systems) can be combined with a data-centered architecture in many database
applications.