UNIT II SOFTWARE DESIGN 9

Design Concepts – Design Model – Software Architecture – Architectural Styles – Architectural Design –
Component-Level Design – User Experience Design – Design for Mobility – Pattern- Based Design.

Design Concepts:

1. Abstraction
2. Architecture
3. Patterns
4. Separation of concerns
5. Modularity
6. Information hiding
7. Functional Independencies
8. Stepwise refinement
9. Refactoring
10. Design Classes

Abstraction
 When you consider a modular solution to any problem, many levels of abstraction can be posed.
 At the highest level of abstraction, a solution is stated in broad terms using the language of the
problem environment (e.g., a user story).
 At lower levels of abstraction, a more detailed description of the solution is provided. Problem-
oriented terminology is coupled with implementation-oriented terminology to state a solution (e.g.,
use case).
 Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly
implemented (e.g., pseudocode).
 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 use for a camera in the
SafeHome system. Use implies a long sequence of procedural steps (e.g., activate the SafeHome
system on a mobile device, log on to the SafeHome system, select a camera to preview, locate the
camera controls on mobile app user interface, 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 camera. Like any data object, the
data abstraction for camera would encompass a set of attributes that describe the camera (e.g.,
camera ID, location, field view, pan angle, zoom). It follows that the procedural abstraction use
would make use of infor- mation contained in the attributes of the data abstraction camera.

Architecture
 Software architecture alludes to “the overall structure of the software and the ways in which that
structure provides conceptual integrity for a system” [Sha15]. \
 Architecture is the structure or organization of program components (modules), the ways in which
these components interact, and the structure of data that are used by the components.
 In a broader sense, however, components can be generalized to represent major system elements and
their interactions.
 One goal of software design is to derive an architectural rendering of a system. This rendering serves
as a framework from which more detailed design activities are conducted.
 A set of architectural patterns enables a software engineer to reuse design- level concepts.
  Several different architectural description languages (ADLs) have been developed to represent these
models [Sha15]. Although many different ADLs have been proposed, the majority provide
mechanisms for describing system components and the ways in which they are connected to one
another.
Patterns
 Brad Appleton defines a design pattern in the following manner:
o “A pattern is a named nugget of insight which conveys the essence of a proven solution
to a recurring prob- lem within a certain context amidst competing concerns” [App00].
 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)
(3) Whether the pattern can serve as a guide for developing a similar, but functionally or
structurally different, pattern.
Separation of Concerns
 Separation of concerns is a design concept [Dij82] 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.
 It follows that the perceived complexity of two problems when they are combined is often greater
than the sum of the perceived complexity when each is taken separately.
 This leads to a divide-and-conquer strategy—it’s easier to solve a complex problem when you break
it into manageable pieces.
 This has important implications for software modularity.Separation of concerns is manifested in
other related design concepts: modularity, functional independence, and refinement. Each will be
discussed in the subsections that follow.

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” [Mye78].
 Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped by
a software engineer.
 Given the same set of requirements, the more modules used in your program means smaller
individual sizes.
 However, as the number of modules grows, the effort (cost) associated with integrating modules with
each other grows.
 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 serious side effects.


Information Hiding
 The concept of modularity leads you to a fundamental question:
“How do I decompose a software solution to obtain the best set of modules?”
 The principle of information hiding [Par72] suggests that modules should be “characterized by design
decisions that (each) hides from all others
 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 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 [Ros75].
 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.

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 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.
 Independence is assessed 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.
 Coupling is an indication of interconnections 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 likely to
propagate errors found in one module to other system modules.

Stepwise Refinement
 Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth [Wir71].
Successively refining levels of procedural detail is a good way to develop an application.
 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 a process of elaboration. That is, the statement describes function or information
conceptually but provides no indication of the internal workings of the function or the internal structure
of the information
 Abstraction and refinement are complementary concepts. Abstraction enables you to specify procedure
and data internally but suppress the need for “outsiders” to have knowledge of low-level details.
Refinement helps you to reveal low-level details as design progresses. Both concepts allow you to create
a complete design model as the design evolves.

Refactoring
 “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 large component that exhibits low cohesion
(i.e., it performs three functions that have only a limited relationship to one another). After
careful consideration, you may decide that the component should be refactored into three
separate components, each of which exhibits high cohesion.
 The result will be software that is easier to integrate, easier to test, and easier to maintain.

Design Classes
 The analysis model defines a set of analysis classes .
 Each of these classes 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 to create a
software infrastructure that supports the business solution.
Arlow and Neustadt [Arl02] suggest that each design class be reviewed to ensure that it is “well-
formed.”
They define four characteristics of a well-formed design class:

 Complete and sufficient. A design class should be the complete encapsulation of all
attributes and methods that can reasonably be expected
 Primitiveness. Methods associated with a design class should be focused on accomplishing
one service for the class. Once the service has been implemented with a method, the class
should not provide another way to accomplish the same thing
 The start and end points of the segment to be drawn. The method
setCoordinates()provides the only means for establishing start and end points for the segment.
 High cohesion. A cohesive design class has a small, focused set of responsibilities and
single-mindedly applies attributes and methods to implement those responsibilities
 Low coupling. Within the design model, it is necessary for design classes to collaborate with
one another. However, collaboration should be kept to an acceptable minimum. If a design
model is highly coupled (all design classes collaborate with all other design classes), the
system is difficult to implement, to test, and to maintain over time.