CHAPTER 3 SOFTWARE DESIGN Second Part

This is the second part  of the chapter.

4. Software Design Quality Analysis and Evaluation
This section includes a number of quality and evaluation topics that are specifically related to software design. Most are covered in a general manner in the Software Quality KA.

4.1. Quality Attributes
Various attributes are generally considered important for obtaining a software design of good quality—various
“ilities” (maintainability, portability, testability, traceability), various “nesses” (correctness, robustness), including “fitness of purpose.” An interesting distinction is the one between quality attributes discernable at run-time (performance, security, availability, functionality, usability), those not discernable at run-time (modifiability, portability, reusability, integrability, and testability), and those related to the architecture’s intrinsic qualities (conceptual integrity, correctness, and completeness, buildability).

4.2. Quality Analysis and Evaluation Techniques
Various tools and techniques can help ensure a software design’s quality.
- Software design reviews: informal or semiformal, often group-based, techniques to verify and ensure the
quality of design artifacts (for example, architecture reviews, design reviews, and inspections, scenario-based techniques, requirements tracing)
- Static analysis: formal or semiformal static (nonexecutable) analysis that can be used to evaluate a
design (for example, fault-tree analysis or automated cross-checking)
- Simulation and prototyping: dynamic techniques to evaluate a design (for example, performance
simulation or feasibility prototype

4.3. Measures
Measures can be used to assess or to quantitatively estimate various aspects of a software design’s size, structure, or quality. Most measures that have been proposed generally depend on the approach used for producing the design. These measures are classified in two broad categories:
- Function-oriented (structured) design measures: the design’s structure, obtained mostly through functional
decomposition; generally represented as a structure chart (sometimes called a hierarchical diagram) on
which various measures can be computed
- Object-oriented design measures: the design’s overall structure is often represented as a class diagram, on
which various measures can be computed. Measures on the properties of each class’s internal content can also be computed

5. Software Design Notations
Many notations and languages exist to represent software design artifacts. Some are used mainly to describe a
design’s structural organization, others to represent software behavior. Certain notations are used mostly during architectural design and others mainly during detailed design, although some notations can be used in both steps. In addition, some notations are used mostly in the context of specific methods (see the Software Design Strategies and Methods subarea). Here, they are categorized into notations for describing the structural (static) view vs. the behavioral (dynamic) view.

5.1. Structural Descriptions (static view)
The following notations, mostly (but not always) graphical, describe and represent the structural aspects of a software design—that is, they describe the major components and how they are interconnected (static view): - Architecture description languages (ADLs): textual, often formal, languages used to describe a software
architecture in terms of components and connectors Class and object diagrams: used to represent a set of
classes (and objects) and their interrelationships
- Component diagrams: used to represent a set of components (“physical and replaceable part[s] of a
system that [conform] to and [provide] the realization of a set of interfaces”) and their interrelationships
- Class responsibility collaborator cards (CRCs): used to denote the names of components (class), their
responsibilities, and their collaborating components’ names
- Deployment diagrams: used to represent a set of (physical) nodes and their interrelationships, and, thus,
to model the physical aspects of a system
- Entity-relationship diagrams (ERDs): used to represent conceptual models of data stored in information
systems
- Interface description languages (IDLs): programminglike languages used to define the interfaces (names and
types of exported operations) of software components
- Jackson structure diagrams: used to describe the data structures in terms of sequence, selection, and iteration
- Structure charts: used to describe the calling structure of programs (which module calls, and is called by,
which other module)

5.2. Behavioral Descriptions (dynamic view)
The following notations and languages, some graphical and some textual, are used to describe the dynamic behavior of software and components. Many of these notations are useful mostly, but not exclusively, during detailed design.
- Activity diagrams: used to show the control flow from activity (“ongoing non-atomic execution within a state
machine”) to activity
- Collaboration diagrams: used to show the interactions that occur among a group of objects, where the
emphasis is on the objects, their links, and the messages they exchange on these links
- Data flow diagrams (DFDs): used to show data flow among a set of processes
- Decision tables and diagrams: used to represent complex combinations of conditions and actions
- Flowcharts and structured flowcharts: used to represent the flow of control and the associated actions
to be performed
- Sequence diagrams: used to show the interactions among a group of objects, with emphasis on the timeordering of messages
- State transition and statechart diagrams: used to show the control flow from state to state in a state machine
- Formal specification languages: textual languages that use basic notions from mathematics (for example,
logic, set, sequence) to rigorously and abstractly define software component interfaces and behavior, often in
terms of pre- and post-conditions
- Pseudocode and program design languages (PDLs): structured-programming-like languages used to
describe, generally at the detailed design stage, the behavior of a procedure or method

6. Software Design Strategies and Methods
There exist various general strategies to help guide the design process. In contrast with general strategies, methods are more specific in that they generally suggest and provide a set of notations to be used with the method, a description of the process to be used when following the method and a set of guidelines in using
the method. Such methods are useful as a means of transferring knowledge and as a common
framework for teams of software engineers.

6.1. General Strategies
Some often-cited examples of general strategies useful in the design process are divide-and-conquer and stepwise refinement, top-down vs. bottom-up strategies, data abstraction and information hiding, use of heuristics, use of patterns and pattern languages use of an iterative and incremental approach.

6.2. Function-Oriented (Structured) Design
This is one of the classical methods of software design, where decomposition centers on identifying the major
software functions and then elaborating and refining them in a top-down manner. Structured design is generally used after structured analysis, thus producing, among other things, data flow diagrams and associated process descriptions. Researchers have proposed various strategies (for example, transformation analysis, transaction analysis) and heuristics (for example, fan-in/fan-out, scope of effect vs. scope of control) to transform a DFD into a software architecture generally represented as a structure chart.

6.3. Object-Oriented Design
Numerous software design methods based on objects have been proposed. The field has evolved from the early objectbased design of the mid-1980s (noun = object; verb = method; adjective = attribute) through OO design, where inheritance and polymorphism play a key role, to the field of component-based design, where meta-information can be defined and accessed (through reflection, for example). Although OO design’s roots stem from the concept of data abstraction, responsibility-driven design has also been proposed as an alternative approach to OO design.

6.4. Data-Structure-Centered Design
Data-structure-centered design (for example, Jackson, Warnier-Orr) starts from the data structures a program manipulates rather than from the function it performs. The software engineer first describes the input and output data structures (using Jackson’s structure diagrams, for instance) and then develops the program’s control structure based on these data structure diagrams. Various heuristics have been proposed to deal with special cases—for example, when there is a mismatch between the input and output structures.

6.5. Component-Based Design (CBD)
A software component is an independent unit, having welldefined interfaces and dependencies that can be composed and deployed independently. Component-based design addresses issues related to providing, developing, and integrating such components in order to improve reuse.

6.6. Other Methods
Other interesting but less mainstream approaches also exist: formal and rigorous methods and transformational methods.