Design
Release Information
Project: |
PROJECT-NAME |
Internal Release Number: |
X.Y.Z |
Attached Worksheets: |
|
Related Documents: |
LINKS-TO-RELEVANT-STANDARDS
LINKS-TO-OTHER-DOCUMENTS
|
Process impact: This design
document describes a system that will satisfy the requirements of the
SRS. Decisions made in creating this design
document are based on those requirements and an understanding of
available technologies and components. Once the design has been
drafted, work on the system implementation and unit testing may
begin.
TODO: Fill in the information above and the sections below.
Consider how the reusable sample text relates to your project or
prompts you to think of new ideas. Add, edit or delete text as
needed for your project. Keep in mind that much of the real detail
of the design will be in the diagrams and the worksheets.
Introduction
- How is this design document organized?
- This main page describes the system design in terms of packages,
classes, relationships, and behavior. Several attached worksheets
address specific aspects of the overall system design, such as user
interface and database design.
- What are the most important facts that a developer should know
about this design?
- This web application has a front-end, business
objects, and a back-end:
- The front-end is organized as a set of servlets, one for each
page on the site.
- The business objects are Java beans that represent users,
products, orders, ratings, and reviews.
- The back-end includes classes for communicating with the
database, payment processing, and our order fulfillment system.
- One key (and perhaps unexpected) concept of the
design is that a transaction is treated as an object rather than an
algorithm. We build several types of detailed transaction objects,
which can then be executed, audited, rolled-back, or related to
other transactions.
- Developers should realize that we started with a
very page-oriented design where each page stood completely on its
own. Now, we have a much lighter-weight presentation layer and a
much more semantically-rich business object layer.
- What are the ranked goals of this design?
-
- Correctness
- Feasibility
- Understandability
- Implementation phase guidance
- Modularity
- Extensibility
- Testability
- Efficiency
UML Structural Design
TODO: Link to a design model and/or design diagrams that describe
your system's structure in detail.
The system's structural design is described in the following UML model:
MODEL-NAME.
The system's structural design is described in the following UML
structural diagrams:
We use the following structural design patterns:
- Observer-Observable:
- Transaction plays Subject. Dashboard plays Observer.
The dash board user interface is updated in real-time by events
that are sent from the Transaction object.
- Abstract-Factory:
- Transaction-Factory plays Factory. Transaction plays Abstract-Product.
Our factory makes one of four types of Transaction objects
depending on the details of the transaction.
- PATTERN-NAME:
- PARTICIPANTS. EXPLANATION-OF-PATTERN-OCCURRENCE.
- PARTICIPANTS. EXPLANATION-OF-PATTERN-OCCURRENCE.
ANY ADDITIONAL NOTES OR COMMENTS
UML Behavioral Design
TODO: Link to a design model and/or design diagrams that describe
your system's behavior in detail.
The system's behavioral design is described in the
following UML model: MODEL-NAME.
The system's behavioral design is described in the following UML
behavioral diagrams:
- State Diagrams
- Sequence Diagrams
- Collaboration Diagrams
We use the following behavioral design patterns:
- PATTERN-NAME:
- PARTICIPANTS. EXPLANATION-OF-PATTERN-OCCURRENCE.
- PARTICIPANTS. EXPLANATION-OF-PATTERN-OCCURRENCE.
ANY ADDITIONAL NOTES OR COMMENTS
UML Design Checklist
TODO: Answer the following questions to help evaluate how well your
design achieves your stated design goals. Consider how the reusable
sample text relates to your project or prompts you to think of new
ideas. If you cannot answer a question positively, that may
indicate an aspect of the design that should be revised.
- Correctness: How do you know that this design is correct?
- We are fairly certain that it is correct because
it is a very standard and familiar design for this type of
application. The only unusual aspects of it are UNUSUAL-ASPECT, and
UNUSUAL-ASPECT. These aspects have been reviewed by EXPERT-NAME.
- This design is very simple, so there is no room
for the design itself to be incorrect.
- This design is based on the design of
EXISTING-SYSTEM, which has worked well in practice. We are testing
the design differences as we go.
- This design is probably correct because each
design detail can be traced back to a specific requirement in the SRS and we feel that we are satisfying each
requirement.
- It is too soon to know if this design is
correct. We will not know until we CODE-or-TEST it.
- Some aspects of this design are probably
incorrect. We can explain what those problems are, review them, and
track them in the issue tracker or risk
management worksheet.
- Feasibility: What indicates that this design can be implemented
and tested with the planned amount of time and effort?
- We have completed the detailed design and we can
simply add up the estimates of the time needed to implement each
design element. The design provides strong testability.
- We have reviewed the design and each aspect of
it seems feasible to implement and test.
- This is an ambitious design that we may not be
able to fully complete in the planned time. The design consists of
a core and several extensions, and we are certain that we can
complete the core well within our schedule constraints.
- This is an innovative design that may not be
feasible. We know that we can built it, we just don't know if it
will have enough DESIRED-QUALITY.
- Understandability: What makes this design understandable?
- It's a very familiar design to any developer who
has experience with TECHNOLOGY-or-LEGACY-SYSTEM.
- It's a very simple design.
- We have carefully documented the design using
UML, design patterns, and textual comments.
- The design itself is not very understandable.
Each developer will need significant time to learn the design before
he/she can reliably make changes.
- Implementation phase guidance: Does the design suggest
reasonable implementation tasks?
- Yes, each class can be implemented fairly
independently. This is possible because we have specified each class
in detail.
- We have left one major component without a
detailed design. We will design the internals of that component as
we implement it. That is one big task that we cannot break down
into smaller tasks until we actually work on it.
- Implementation tasks are not our concern. Some
could be very large. Someone else will have to take responsibility
for that.
- Modularity: How have concerns been separated and addressed in
distinct modules?
- The design emphasizes modularity above other
qualities. Each design decision that could change later is
encapsulated in its own module.
- There is a natural relationship between the
business objects that we used to organize our design into modules,
and the application concerns that could change later. If something
changes, it will likely only affect one or a few business objects.
- We organized the design around the underlying
technology rather than any particular application concerns. If
something must change, we will simply follow through with the change
in as many places as needed, even though that could make us fail to
meet our deadlines.
- We don't know what might change in the future,
so we are assuming that nothing will change.
- Extensibility: How easily can new features be added later?
- We have a core design and a set of plug-ins or
add-ons. We have reviewed the APIs provided to the add-ons and we
are sure that significant new features can be added easily, so long
as they fit our expectations for add-ons.
- At several points in the design, we have
specified interfaces and abstract classes to allow new features to
be added as new concrete subclasses.
- We have not gone out of our way to make the
design extensible. However, it is very understandable and efficient.
Those qualities provide a good foundation for future design
refactoring and extension.
- We are not planning on adding any features
later. We know the complete set of features that will ever be
needed.
- Testability: What makes this system easy to test?
- We have reviewed the design for testability and
we are sure that it provides interfaces that can be used to create
all needed test conditions and evaluate all test results. We have
also made sure that we can use our unit and system test automation
tools.
- We have not gone out of our way to make the
design testable. However, it is very simple and understandable.
Those qualities provide a good foundation for testing.
- Testability is not our concern, someone else
will deal with that.
- Efficiency: Does the system consume an acceptable amount of time,
storage space, bandwidth, and other resources?
- Yes, efficiency is one of our main concerns and
we have designed the system with it in mind. We have done small
experiments to prove the efficiency of certain design choices, and we
have reviewed other choices.
- It is too early to evaluate the design's
efficiency. We will not know until we complete MILESTONE-NAME. If
we must revise the design, we will have enough time to do it
then.
- Efficiency is not our concern, someone else will
deal with that.
- Has the design been communicated to the development
team and other stakeholders?
- Yes, everyone understands. Feedback is
welcome.
- Yes, it is on our project website.
- No, this is a risk that is noted in the risk management worksheet.