2D1363, Mjukvarukonstruktion, 8
poäng
Aktuell kursomgång: period 2-4
06/07
Kursledare: Rand Waltzman
Datorpostadress(er): rand@nada.kth.se
Design
Document (DD) Guidelines
This page contains some general guidelines
for your DD. For details see the Design Document Template.
1. Introduction
The purpose of the design phase of a
project is to define a collection of software components and their interfaces
to establish a framework for developing the software. We will refer to
this framework as the ‘Design’, and it must cover all the
requirements in the RD.
2. Activities
The principal activity of the design
phase is to develop the architectural design of the software and document it in
the DD. This includes:
1.
constructing
the physical model
2.
specifying
the design
2.1 Constructing of the physical model
The developer shall construct a
“physical model” which describes the design of the software, using
implementation terminology. The physical model should be derived from the
logical model, described in the RD. In transforming a logical model to a
physical model, “design decisions” are made in which functions are
allocated to components and their inputs and outputs defined. Design decisions
should also satisfy non-functional requirements, design quality criteria and
implementation technology considerations. Design decisions should be recorded.
Modeling is an iterative process. Each
part of the model needs to be specified and re-specified until a coherent
description of each component is achieved.
2.1.1
Decomposition of the software into components
The software should be decomposed into a
hierarchy of components according to a partitioning method. Examples of
partitioning methods are “functional decomposition” and
“correspondence with real world objects”. There should be distinct
levels within the hierarchy, with each component occupying a well-defined
place.
The method used to decompose the software
into its component parts shall permit a top-down approach. Starting from
the top-level component, the software is decomposed into a hierarchy of
components. The architectural design should specify the upper levels of the
hierarchy, typically the top three or four.
Top-down decomposition is vital for
controlling complexity because it enforces “information hiding” by
demanding that lower-level components behave as “black
boxes”. Only the function and interfaces of a lower-level component
are required for the higher-level design. The information necessary to the
internal workings of a lower-level component can remain hidden.
Top-down decomposition also demands that
each level of the design be described using terms that have an appropriate
degree of “abstraction”
(e.g. the terms “file”, “record”, and
“byte” ought to occur at different levels in the design of a
file-handling system). The use of the right degree of abstraction at each level
assists information hiding.
The bottom-level components in the DD
should be sufficiently independent to allow their detailed design and coding to
proceed in parallel to that of other components, with a minimum of interaction
between programmers
2.1.2 Implementation of
non-functional requirements
The RD contains a number of requirements
in the non-functional category. Examples of these are:
- Performance requirements
- Interface requirements
- Operational requirements
- Resource requirements
- Verification requirements
- Acceptance testing requirements
- Documentation requirements
- Security requirements
- Portability requirements
- Quality requirements
- Reliability requirements
- Maintainability requirements
- Safety requirements
The design of each component should be reviewed
against each of these requirements that are relevant for your project.
While some non-functional requirements may apply to all components in the
system, other non-functional requirements may affect the design of only a few
components.
2.2 Specifying of the design
The design is the fully documented
physical model. This should contain diagrams showing, at each level of
the design, the data flow and control flow between the components. Block
diagrams, showing entities such as tasks and files, may also be used to
describe the design. The diagramming techniques used should be documented
or referenced.
3 Design quality criteria
Designs should be adaptable, efficient
and understandable. Adaptable designs
are easy to modify and maintain. Efficient designs make minimal use of
available resources. Designs must be understandable if they are to be built,
operated and maintained effectively.
Attainment of these goals is assisted by
aiming for simplicity in form and function in every part of the design. There
are a number of metrics that can be used for measuring complexity, (e.g. number
of interfaces per component), and their use should be considered.
Simplicity of function is achieved by
maximizing the “cohesion” of individual components (i.e. the degree
to which the activities internal to the component are related to one another).
Simplicity of form is achieved by:
- minimizing the
“coupling” between components (i.e. the number of distinct
items that are passed between components)
- ensuring that the function a
component performs is appropriate to its level in the hierarchy
- matching the software and data
structures
- maximizing the number of components
that use a given component
- restricting the number of child
components to 7 or less
- removing duplication between
components by making new components.
Designs should
be “modular”, with minimal coupling between components and
maximum cohesion within each component. There is minimal duplication
between components in a modular design.
Components of a modular design are often described as “black
boxes” because they hide internal information from other
components. It is not necessary to know how a black box component works
to know what to\ do with it.
Understandable designs employ terminology
in a consistent way and always use the same solution to the same problem.
Where teams of designers collaborate to produce a design, understandability can
be considerably impaired by permitting unnecessary variety. Designs standards and design reviews all help
to enforce consistency and uniformity.
4 Trade-off between alternative designs
There is no unique design for any
software system. Studies of the different options may be necessary. A number of
criteria will be needed to choose the best option. The criteria depend on the
type of system. For example, in a real-time situation, performance and response
time could be important, whereas in an administrative system stability of the
data base might be more important.
Prototyping may be performed to verify
assumptions in the design or to evaluate alternative design approaches. This is
called “experimental prototyping”. For example, if a program
requires fast access to data stored on disc, then various methods of file
access could be coded and measured. Different access methods could alter the
design approach quite significantly, and prototyping the access method would
become an essential part of the design process.
Only the selected design approach shall be reflected in the DD.
5 Design Document – General Requirements
The Design Document (DD) is the key
document that summarizes your solution. It is the kernel from which the
detailed design grows. The DD shall define the major components of the software
and the interfaces between them. The DD shall define or reference all external
interfaces. The DD shall be an output from the design phase.
The DD shall be complete, covering all
the software requirements described in the RD. To demonstrate this, a
table cross-referencing software requirements to parts of the design shall be
placed in the DD.
The DD shall be consistent.
The DD shall be sufficiently detailed to
allow the project leader to draw up a detailed implementation plan and to control
the overall project during the remaining development phases. A good rule of
thumb is that the DD should be detailed enough to enable the cost of the
remaining development to be estimated to within 10%.
Upp
till Nadas
kurser.
Sidansvarig: <rand@nada.kth.se>
Tekniskt stöd: <webmaster@nada.kth.se>