PROJECT NAME
D4: Design (v0.0)
Advanced Programming Laboratory Course
Turku Centre for Computer Science
Åbo Akademi
Department of Computer Science
AUTHORS
DATE
Copyright © 2001 AUTHORS.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the “D9: Licenses” document entitled “GNU Free Documentation License”.
History
This documentation has evolved as follows:
Original version by AUTHORS, 2001
Abstract
Include here a copy of the requirements abstract.
Include also a short description of the design notation/technique that you use in this document. For instance, if you use UML or some other notation.
Contents
1. System Overview 6
2. Static Design 7
3. Dynamic Design 8
4. Mapping User Interface to Functionality 9
5. Databases 10
1. System Overview
Give in this section a give high-level description of the system, for instance, by giving a component/ package/ module -view to the system. In such a view, explain how the components, packages, and modules interact with each other through interfaces. However, do not explain in detail in this section the internal structure of the components, packages, and modules. You do that in the next section.
Still, remember to describe how the given system overview relates to the use case view given in the requirements. Without this mapping, it is hard to related the rest of this document to the requirements.
2. Static Design
Describe in this section the contents of the components, packages, and modules that form the whole system. Thus, each component, package, and module that you use in the “System Overview” section should have a subsection of its own in this section. You may use class and object diagrams in the description. As this section is supposed to give only a static view to the system, do not describe here which object calls and which methods; that is described in the next section.
If you system contains some databases, remember to describe them here using database class diagrams or entity-relationship diagrams. However, do not describe here in detail what the fields in the databases a supposed to contain; you do that later in section “Databases”.
Note that you might have to write the section “Dynamic Design” below at the same time as you write this section, because they depend on each other. You might even have to iterated writing these two views quite a bit; a change in dynamic design usually reflects in a change in static design and vice versa.
3. Dynamic Design
Describe in this section how the objects in the “Static Design” section interact with each other. You may use interaction diagrams, statecharts, and activity diagrams in the description. You should cover here all the functionality stated in the “Requirements” document. Thus, each functional requirement given in the “Requirements” document should have a subsection of its own in this section. Then, in each subsection, you should describe how the objects participate in realizing a functional requirement.
Note that you might have to write the section “Static Design” above at the same time as you write this section, because they depend on each other.
4. Mapping User Interface to Functionality
Describe in this section how the user interface given in “Requirements” document relates to “Dynamic Design” section above. In “Requirements” document you have already described how the user interface relates to the required functionality. Thus, here it is enough to indicate which method calls are activated when the user presses some button, etc.
In this section you should also consider how invalid user input is processed; what exceptions are raised and how they are handled by the objects given in “Static Design” section above.
5. Databases
Describe here all the databases that you need in the system. Describe the fields and what kind of data the fields may contain. Note that it is NOT enough just to give the names and types of the fields in the database, you should also describe VERBALLY what information is to be stored in the field and why it is there (unless that is somehow too obvious).
Describe here also, in a separate subsection, to what kind of queries the databases should provide answers. In that description you may use SQL, pseudo algorithms, etc.
10