Software design

Chapter 9
Design Engineering
CHAPTER OVERVIEW AND COMMENTS

The intent of this chapter is to provide an introduction to the design process and to describe fundamental design concepts that are essential to an understanding of any software design method.  Basic concepts are introduced and a fundamental design model is discussed.  The design model consists of the data design, architectural design, interface design, and component-level design.

The goal of design engineering is to produce a model or representation that exhibits firmness, commodity, and delight.

To accomplish this, a designer must practice diversification and then convergence.

Belady states that “diversification is the acquisition of a repertoire of alternatives, the raw material of design: components, component solutions, and knowledge, all contained in catalogs, textbooks, and the mind.”

Once this diverse set of information is assembled, the designer must pick and choose elements from the repertoire that meet the requirements designed by requirement engineering and the analysis models.

As this occurs, alternatives are considered and rejected, and the design engineer converges on “one particular configuration of components, and thus the creation of the final product.”

9.1 Design within the Context of Software Engineering

Software design is the last software engineering action within the modeling activity and sets the stage for construction (code generation and testing).

The flow of information during software design is illustrated in Figure below.  The analysis model, manifested by scenario-based, class-based, flow-oriented and behavioral elements, feed the design task.

The architectural design defines the relationship between more structural elements of the software, the architectural styles and design patterns that can be used to achieve the requirements defined for the system, and the constraints that affect the way in which the architectural design can be implemented.

The architectural design can be derived from the System Specs, the analysis model, and interaction of subsystems defined within the analysis model.

The interface design describes how the software communicates with systems that interpolate with it, and with humans who use it.  An interface implies a flow of information (data, and or control) and a specific type of behavior.
The component-level design transforms structural elements of the software architecture into a procedural description of software components.

The importance of software design can be stated with a single word – quality.  Design is the place where quality is fostered in software engineering.  Design provides us with representations of software that can be assessed for quality.  Design is the only way that we can accurately translate a customer’s requirements into a finished software product or system.

9.2 Design Process and Design Quality

Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software.

Initially, the blueprint depicts a holistic view of software, i.e. the design is represented at a high-level of abstraction.

Throughout the design process, the quality of the evolving design is assessed with a series of formal technique reviews or design walkthroughs.

Three characteristics serve as a guide for the evaluation of a good design:

• The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.
• 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 behavioral domains from an implementation perspective.

 

Quality Guidelines

In order to evaluate the quality of a design representation, we must establish technical criteria for good design.

• A design should exhibit an architecture that:

(1) Has been created using recognizable architectural styles or patterns,
(2) Is composed of components that exhibit good design characteristics, and
(3) Can be implemented in an evolutionary fashion

• For smaller systems, design can sometimes be developed linearly.
• A design should be modular; that is, the software should be logically partitioned into elements or subsystems
• A design should contain distinct representations of data, architecture, interfaces, and components.
• A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns.
• A design should lead to components that exhibit independent functional characteristics.
• A design should lead to interfaces that reduce the complexity of connections between components and with the external environment.
• A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.
• A design should be represented using a notation that effectively communicates its meaning.

Quality Attributes

Hewlett-Packard developed a set of software quality attributes that has been given the acronym FURPS.  The FURPS quality attributes represent a target for all software design:

• Functionality: is assessed by evaluating the features set and capabilities of the program, the generality of the functions that are delivered, and the security of the overall system.
• Usability: is assessed by considering human factors, overall aesthetics, consistency, and documentation.
• Reliability: is evaluated by measuring the frequency and severity of failure, the accuracy of output results, the mean-time-to-failure, the ability to recover from failure, and the predictability of the program.
• Performance: is measured by processing speed, response time, resource consumption, throughput, and efficiency.
• Supportability: combines the ability to extend the program extensibility, adaptability, serviceability è maintainability.  In addition, testability, compatibility, configurability, etc.

 

9.3 Design Concepts
This section discusses many significant design concepts (abstraction, refinement, modularity, architecture, patterns, refactoring, functional independence, information hiding, and OO design concepts).
9.3.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 we move through different levels of abstraction, we work to create procedural and data abstractions.  A procedural abstraction refers to a sequence of instructions that have a specific and limited function.  An example of a procedural abstraction would be the word open for a door.
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, weight).
9.3.2 Architecture
Software architecture alludes to the “overall structure of the software and the ways in which the structure provides conceptual integrity for a system.”
In its simplest from, architecture is the structure of organization of program components (modules), the manner in which these components interact, and the structure of data that are used by the components.
Te goal of software design is to derive an architectural rendering of a system.  This rendering serves as a framework from which detailed design activities are constructed.
A set of architectural patterns enable a software engineer to reuse design-level concepts.
The architectural design can be represented using one or more of a number of different models. 
Structural models represent architecture as an organized collection of program components. 
Framework models increase the level of design abstraction by attempting to identify repeatable architectural design frameworks that are encountered in similar types of applications.
Dynamic models address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change as a function of external events.
Process models focus on the design of business or technical process that the system must accommodate.
Functional models can be used to represent the functional hierarchy of a system.
Architectural design will be discussed in Chapter 10.

9.3.3 Patterns

A design pattern “conveys the essence of a proven design solution to a recurring problem within a certain context amidst computing concerns.”
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, and
3. whether the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern.

9.3.4 Modularity

Software architecture and design patterns embody modularity; that is, software is divided into separately named and addressable components, sometimes called modules that are integrated to satisfy problem requirements.

Monolithic software (large program composed of a single module) cannot be easily grasped by a software engineer.  The number of control paths, span of reference, number of variables, and overall complexity would make understanding close to impossible.

It is the compartmentalization of data and function.  It is easier to solve a complex problem when you break it into manageable pieces. “Divide-and-conquer”

Don’t over-modularize. The simplicity of each small module will be overshadowed by the complexity of integration “Cost”.

9.3.5 Information Hiding

It is about controlled interfaces.  Modules should be specified and design so that information (algorithm and data) contained within a module is inaccessible to other modules that have no need for such information.

Hiding implies that effective modularity can be achieved by defining by a set of independent modules that communicate with one another only that information necessary to achieve software function.

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 procedures are hidden from other parts of the software, inadvertent errors introduced during modifications are less likely to propagate to other location within the software.

9.3.6 Functional Independence

The concept of functional Independence is a direct outgrowth of modularity and the concepts of abstraction and information hiding.

Design software so that each module addresses a specific sub-function of requirements and has a simple interface when viewed from other parts of the program structure.

Functional independence is a key to good design, and design is the key to software quality.
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.

A cohesive module should do just one thing.

Coupling is a qualitative indication of the degree to which a module is connected to other modules and to the outside world “lowest possible”.

9.3.7 Refinement

It is the elaboration of detail for all abstractions.  It is a top down strategy. 
A program is developed by successfully 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.

We begin with a statement of function or data that is defined at a high level of abstraction. 

The statement describes function or information conceptually but provides no information about the internal workings of the function or the internal structure of the data.

Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive refinement (elaboration) occurs.

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.

Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive refinement “elaboration” occurs.

9.3.8 Refactoring

It is a reorganization technique that simplifies the design of a component without changing its function or behavior.  When software is re-factored, the existing design is examined for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed data structures, or any other design failures that can be corrected to yield a better design.

Data Abstraction

 

Procedural Abstraction

 

 

 

“The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a]

• 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. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods
• 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. In essence, the design should have the ability to reuse architectural building blocks.

 

Patterns

Design Pattern Template

Pattern name—describes the essence of the pattern in a short but expressive name
Intent—describes the pattern and what it does
Also-known-as—lists any synonyms for the pattern
Motivation—provides an example of the problem
Applicability—notes specific design situations in which the pattern is applicable
Structure—describes the classes that are required to implement the pattern
Participants—describes the responsibilities of the classes that are required to implement the pattern
Collaborations—describes how the participants collaborate to carry out their responsibilities
Consequences—describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the pattern is implemented
Related patterns—cross-references related design patterns

Modular Design

 

 

Modularity: Trade-offs

What is the "right" number of modules for a specific software design?

 

 

 

 

 

Information Hiding

 

 

 

 

 

 

Why Information Hiding?

• Reduces the likelihood of “side effects”
• Limits the global impact of local design decisions
• Emphasizes communication through controlled interfaces
• Discourages the use of global data
• Leads to encapsulation—an attribute of high quality design
• Results in higher quality software

 

Stepwise Refinement
Functional Independence

 

 

 

 

 

Sizing Modules: Two Views

 

 

 

 

 

 

Refactoring

• Fowler [FOW99] 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 behavior of the code [design] yet improves its internal structure.”
• When software is re-factored, 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.

 

OO Design Concepts

• Entity classes
• Boundary classes
• Controller classes
• Inheritance—all responsibilities of a super-class is immediately inherited by all subclasses
• Messages—stimulate some behavior to occur in the receiving object
• Polymorphism—a characteristic that greatly reduces the effort required to extend the design

 

9.3.9 Design classes

As the design model evolves, the software team must define a set of design classes that refines the analysis classes and creates a new set of design classes.
Five different classes’ types are shown below:

1. User Interface classes: define all abstractions that are necessary for HCI.
2. Business domain classes: are often refinements of the analysis classes defined earlier.  The classes identify the attributes and services 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 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.

Inheritance (Example)

• Design options:
• The class can be designed and built from scratch. That is, inheritance is not used.
• The class hierarchy can be searched to determine if a class higher in the hierarchy (a super-class) contains most of the required attributes and operations. The new class inherits from the super-class and additions may then be added, as required.
• The class hierarchy can be restructured so that the required attributes and operations can be inherited by the new class.
• Characteristics of an existing class can be overridden and different versions of attributes or operations are implemented for the new class.

 

Messages

 

 

 

 

 

 

 

 

Polymorphism

Conventional approach …

case of graphtype:
                                          if graphtype = linegraph then DrawLineGraph (data);
                                          if graphtype = piechart then DrawPieChart (data);
                                          if graphtype = histogram then DrawHisto (data);
                                          if graphtype = kiviat then DrawKiviat (data);
end case;

All of the graphs become subclasses of a general class called graph. Using a concept called overloading [TAY90], each subclass defines an operation called draw. An object can send a draw message to any one of the objects instantiated from any one of the subclasses. The object receiving the message will invoke its own draw operation to create the appropriate graph.

graphtype draw

9.4 The Design Model

• Data elements
• Data model --> data structures
• Data model --> database architecture
• Architectural elements “similar to the floor plan of a house”
• “You can use an eraser on the drafting table or a sledge hammer on the construction site.”                                               Frank Lloyd Wright
• Application domain
• Analysis classes, their relationships, collaborations and behaviors are transformed into design realizations
• Patterns and “styles”
• Interface elements “The way in which utilities connections come into the house and are distributed among the rooms”
• the user interface (UI)
• external interfaces to other systems, devices, networks or other producers or consumers of information
• internal interfaces between various design components.

 

 

 

 

 

 

 

 

 

 

 

 

• Component elements

 

It is equivalent to a set of detailed drawings and specs for each room in a house.
The component-level design for software fully describes the internal detail of each software component.

• Deployment elements

 

Indicates how software functionally and subsystem terms will be allocated within the physical computing environment that will support the software.

9.5 Pattern-Based Software Design

9.5.1 Describing a Design Pattern

• The best designers in any field have an uncanny ability to see patterns that characterize a problem and corresponding patterns that can be combined to create a solution
• A description of a design pattern may also consider a set of design forces.
• Design forces describe non-functional requirements (e.g., ease of maintainability, portability) associated the software for which the pattern is to be applied.
• Forces define the constraints that may restrict the manner in which the design is to be implemented.
• Design forces describe the environment and conditions that must exist to make the design pattern applicable.
• The pattern characteristics (classes, responsibilities, and collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of problems.
• These attributes represent characteristics of the design that can be searched (via database) so that an appropriate pattern can be found.
• Finally, guidance associated with the use of a design pattern provides an indication of the ramification of design decisions.
• The name of design patterns should be chosen with care.
• One of the key technical problems in software reuse is the inability to find existing patterns when hundreds or thousands of candidate patterns exist.
• The search of the “right” pattern is aided immeasurably by a meaningful pattern name.

 

9.5.2 Using Patterns in Design

Design patterns can be used throughout software design.

Once the analysis model has been developed, the designer can examine a detailed representation of the problem to be solved and the constraints that are imposed by the problem.

The problem description is examined at various levels of abstraction to determine if it is amenable to one or more of the following design patterns:

Architectural patterns: These patterns define the overall structure of the software, indicate the relationships among subsystems and software components, and define the rules for specifying relationships among the elements (classes, packages, components, subsystems) of the architecture.

Design patterns: These patterns address a specific element of the design such as an aggregation of components to solve some design problems, relationships among components, or the mechanisms for effecting component-to-component communication.

Idioms: Sometimes called coding patterns, these language-specific patterns generally implement an algorithmic element of a component, a specific interface protocol, or a mechanism for communication among components.

 

Frameworks

• A framework is not an architectural pattern, but rather a skeleton with a collection of “plug points” (also called hooks and slots) that enable it to be adapted to a specific problem domain.
• Gamma et al note that:
• Design patterns are more abstract than frameworks.
• Design patterns are smaller architectural elements than frameworks
• Design patterns are less specialized than frameworks