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).
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.
- Static analysis: formal or semiformal static (non-executable) 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.
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.
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. Here, they are categorized into notations for describing the structural (static) view vs. the behavioral (dynamic) view.
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): programming-like 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).
