Design Descriptions

Software Design Descriptions (SDD)

An SDD is a representation of a software design that is to be used for recording design information, addressing various design concerns, and communicating that information.

SDDs play a pivotal role in the development and maintenance of software system.

• used by acquirers, project managers, quality assurance staff, configuration managers, software designers, programmers, testers, and maintainers.

IEEE 1016 Systems Design - Software Design Descriptions.

This standard specifies requirements on the information content and organization for software design descriptions (SDDs).

The standard specifies that an SDD be organized into a number of design views.

• Establishes a common set of viewpoints for design views.
• Each view addresses a specific set of design concerns of the stakeholders.
• Each design view is prescribed by a design viewpoint.

Standard is intended for use in design situations in which an explicit SDD, as well as well as "reverse engineering" situations where a design description is to be recovered from an existing implementation.

Software Design in Context

SDD can be produced to capture one or more levels of concern

• levels are usually determined by the design methods in use or the life cycle context (e.g. architectural, logical, physical)

SDD is prepared to support the development of a software to solve a problem

• where the problem has been expressed in terms of a set of requirements.

SDD is prepared such that information of interest is captured, organized, presented, etc.

• by identifying and addressing essential design concerns.

Design Concerns

Design concern: An area of interest with respect to a software design.

• names any area of interest in the design, pertaining to its development, implementation, or operation
• arise from specific requirements on the software, or from contextual constraints
• include functionality, reliability, performance, and maintainability

Design Views

SDD is organized using design views, a representation comprised of one or more design elements to address a set of design concerns from a specified design viewpoint

• addresses one or more of the design concerns
• governed by a design viewpoint

Each design viewpoint focuses on a set of the design concerns and introduces a set of descriptive resources called design elements that are used to construct and interpret the design view.

Example: A viewpoint can introduce familiar design elements such as functions, input, and outputs; these elements are used to construct a functional view.

Design Elements

An item occurring in a design view that may be any of the following:

• design entity,
• design relationship,
• design attribute,
• or design constraint.

Design Conceptual Model

A design viewpoint determines the types of design elements to be used in any design views it governs.

Influence on Life Cycle

The SDD influences the content of several major software life cycle work products.

• Software requirements specification.
  • Design decisions, or design constraints discovered during the preparation of the SDD, can lead to requirements changes.
  • Maintaining traceability between requirements and design
• Test documentation.
  • The development of test cases and test procedures can take into consideration the contents of the SDD.

Design Verification

Verification is the determination whether a software work product fulfills specified requirements.

SDD is subject to design verification to ascertain whether the design:

• addresses stakeholders design concerns
• consistent with stated requirements
• implements intended design decisions
• achieves intended qualities
• conforms to an imposed architecture

Its design verification will usually be performed via review, inspection, or analysis (IEEE 1028).

Design Validation

Validation is the determination that the requirements for a specific intended use of a software work product are fulfilled (IEEE 12207).

SDD plays a role in validation by providing (IEEE 1012):

• an overview necessary for understanding the implementation
• the rationale justifying design decisions made
• traceability back to the requirements on the software under design

Design Description Information Content

The required contents of an SDD are as follows:

• Identification of the SDD
• Identified design stakeholders
• Identified design concerns
• Selected design viewpoints, each with type definitions of its allowed design elements and design languages
• Design views
• Design overlays
• Design rationale

SDD Identification

An SDD shall include the following descriptive information:

• Date of issue and status
• Scope
• Issuing organization
• Authorship (responsibility or copyright information)
• References
• Context
• One or more design languages for each design viewpoint used
• Body
• Summary
• Glossary
• Change history

Completeness and Consistency

Each design view in an SDD shall conform to its governing design viewpoint.

An SDD is complete when

• each identified design concern is the topic of at least one design view
• all design attributes have been specified for all of the design entities and relationships in its associated view
• all design constraints have been applied

An SDD is consistent if there are no known conflicts between the design elements of its design views.

Design Viewpoints

For each design view in an SDD, there shall be exactly one design viewpoint governing it.

Each design viewpoint shall be specified by:

• Viewpoint name
• Design concerns that are the topics of the viewpoint
• Design elements, defined by that viewpoint, specifically the types of design entities, attributes, relationships, and introduced constraints

A design viewpoint specification may provide:

• Formal or informal consistency and completeness tests to be applied to the view;
• Evaluation or analysis techniques to be applied to a view; and
• Heuristics, patterns, or other guidelines to assist in construction or synthesis of a view.

Design Element

A design element is any item occurring in a design view.

A design element may be any of the following subcases:

• design entity (key elements of a software design)
• design relationship (relates two or more entities)
• design attribute (names a characteristic of a design element)
• design constraint (a rule imposed by an element on another)

Each design element in the SDD shall have

• name
• type (introduced in exactly one design viewpoint definition)
• any contents

A design element may be used in one or more design views.

Summary of Design Viewpoints

Context Viewpoint

Context viewpoint depicts services provided by a design subject with reference to an explicit context.

Concerns

• identify a design subjects of services and its actors
• establish the system boundary
• delineate the design subject's scope of use and operation.

Elements

• Entities: actors, services (use cases), info flows
• Relationships: receive output and provide input
• Constraints: qualities of service

Languages

• Any black-box type diagrams: Structured Analysis (IDEF0), UML use cases, etc.

Composition Viewpoint

Composition viewpoint describes the way the design subject is structured into parts and establishes the roles of those parts.

Concerns

• identify the major design constituents of the design subject
• localize and allocate functionality, responsibilities, etc. to these constituents

Elements

• Entities: types of constituents of a system, interfaces, libs, etc.
• Relationships: composition, use, and generalization
• Attributes: a reference to a detailed description via the identification attribute

Languages

• Hierarchical decomposition diagram, UML component diagrams, etc.

Logical Viewpoint

Logical viewpoint elaborates existing and designed types and their implementations as classes and interfaces with their structural static relationships.

Concerns

• choice of abstractions and expression in terms of types
• development and reuse of abstractions and implementations

Elements

• Entities: class, interface, power type, data type, object, etc.
• Relationships: association, generalization, dependency, etc.
• Attributes: name, role name, visibility, etc.
• Constraints: value, relationships exclusivity, navigability, etc.

Languages

• UML class diagrams and UML object diagrams, etc.

Dependency Viewpoint

Dependency viewpoint specifies the relationships of interconnection and access among entities.

Concerns

• assess the impact of requirements or design changes
• isolate entities causing system failures or bottlenecks
• aid in producing the system integration plan

Elements

• Entities: subsystem, component, and module
• Relationships: uses, provides, and requires
• Attributes: name, type, purpose, dependencies, and resources

Languages

• UML component diagrams and UML package diagrams

Information Viewpoint

Information viewpoint is applicable when there is a substantial persistent data content expected with the design subject.

Concerns

• include persistent data structure, content, management strategies, access schemes, and definition of metadata

Elements

• Entities: data items, types and classes, stores, and access
• Relationships: association, uses, implements
• Attributes:: persistence and quality properties

Languages

• IDEF1X, UML class diagrams

Patterns use Viewpoint

Patterns use viewpoint addresses design ideas as collaboration patterns involving abstracted roles and connectors.

Concerns

• reuse at the level of design ideas (design patterns), architectural styles, and framework templates.

Elements

• Entities: collaboration, class, connector, role, framework template, and pattern.
• Relationships: association, collaboration use, and connector
• Attributes: name
• Constraints: collaboration constraints

Languages

• UML composite structure diagram and a combination of the UML class diagram and the UML package diagram

Interface Viewpoint

Interface viewpoint provides information designers, programmers, and testers the means to know how to correctly use the services provided by a design subject.

Concerns

• serves as a binding contract
• provides them with an agreement needed before proceeding with the detailed design of entities

Elements

• Entities: attributes for identification, function, and interface

Languages

• Interface definition languages (IDL), UML component diagram

Structure Viewpoint

Structure viewpoint is used to document the internal constituents and organization of the design subject in terms of like elements.

Concerns

• compositional structure of coarse-grained components
• reuse of fine-grained components

Elements

• Entities: port, connector, interface, part, and class
• Relationships: connected, part of, provided, and required
• Attributes: name, type, purpose, and definition
• Constraints: interface, reusability, and dependency.

Languages

• UML composite structure diagram, UML class diagram, and UML package diagram

Interaction Viewpoint

Interaction viewpoint defines strategies for interaction among entities, regarding why, where, how, and at what level actions occur.

Concerns

• includes evaluating allocation of responsibilities
• discovery or description of interactions in terms of messages among objects
• state transition logic and concurrency

Elements

• classes, methods. states, events, signals, hierarchy, concurrency, timing, and synchronization.

Languages

• UML composite structure diagram, UML interaction diagram

State Dynamics Viewpoint

State dynamics viewpoint addresses design ideas as collaboration patterns involving abstracted roles and connectors.

Concerns

• system dynamics including modes, states, transitions, and reactions to events

Elements

• Entities: event, condition, state, etc.
• Relationships: part-of, internal, effect, entry, exit
• Attributes: name, completion, active, initial, and final
• Constraints: guard conditions, concurrency, synchronization, state invariant, transition constraint, and protocol.

Languages

• UML state machine diagram, state transition table, automata, Petri net

Algorithm Viewpoint

Algorithm viewpoint defines design description of operations, the internal details and logic of each design entity.

Concerns

• provides details needed by programmers in regard to time-space performance and processing logic prior to implementation
• aids in producing unit test plans

Elements

• attribute descriptions for identification, processing, and data for all design entities.

Languages

• Decision tables and flowcharts, program design languages, "pseudo-code", and programming languages may also be used.

Resource Viewpoint

Resource viewpoint models the characteristics and utilization of resources in a design subject.

Concerns

• include resource utilization, resource contention, availability, and performance

Elements

• Entities: resources, usage policies
• Relationships: allocation and uses
• Attributes: identification, resource, performance measures
• Constraints: priorities, locks, resource constraints

Languages

• UML class diagram, UML Object Constraint Language

SDD Template

• Frontispiece
  • Date of issue and status, issuing organization, authorship, change history
• Introduction
  • Purpose, scope, context, summary
• References
• Glossary
• Body
  • Identified stakeholders and design concerns
  • Design viewpoint 1, design view 1
  • ...
  • Design viewpoint n, design view n
  • Design rationale