Design

Release Information

Project:	PROJECT-NAME
Internal Release Number:	X.Y.Z
Attached Worksheets:	Design > Architecture Design > Source organization and build system Design > User interface Design > Persistence Design > Security
Related Documents:	SRS > Use case suite SRS > Feature set Glossary 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?

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:

PACKAGE OVERVIEW DIAGRAM
PACKAGE-NAME
- CLASS-DIAGRAM-NAME
- CLASS-DIAGRAM-NAME
PACKAGE-NAME
- CLASS-DIAGRAM-NAME
PACKAGE-NAME
- CLASS-DIAGRAM-NAME

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
- STATE-DIAGRAM-NAME
- STATE-DIAGRAM-NAME
Sequence Diagrams
- SEQUENCE-DIAGRAM-NAME
- SEQUENCE-DIAGRAM-NAME
Collaboration Diagrams
- COLLABORATION-DIAGRAM-NAME
- COLLABORATION-DIAGRAM-NAME

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.

TODO: Check for words of wisdom for additional advice on this template.

Company Proprietary