<!-- This Source Code Form is subject to the terms of the Mozilla Public
- License, v. 2.0. If a copy of the MPL was not distributed with this
- file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title>Layout High Level design Template</title>
<meta name="author" content="Marc Attinasi (attinasi@netscape.com)">
</head>
<body>
<h1><font color="#cc0000">Gecko Layout High Level Design Document Template</font></h1>
[Use this template to start your high level design. Replace items in square
brackets with the appropriate text for your component, class or system. Keep
in mind that this is just a general template intended for most designs.
Your specific design may require different organization or topics - the
goal is to provide high-level information about the software to the reader.]<br>
<br>
<h1>[Component/Class/System Name] High Level Design</h1>
<br>
<h2>Overview</h2>
[Provide a descriptive overview of the component, class, or system that
you are documenting. Describe what the system is supposed to do, where it
is in the overall system, who the clients are, how it is expected to perform,
and any other information that is important to convey to somebody interested
in understanding what the documented system is all about.]<br>
<br>
<h2>Data Model</h2>
[This section describes the classes or components that make up the data
model for the system being documented. It can include a graphical representation
of the classes and their relationships to each other (derivation, aggregation,
ownership, usership, etc.). No implementation details are to be included
here, but general relationships and inter-relationships should be shown and
briefly described. The reader should be able to understand the players in
the system, and the extent to which those players interact with or are related
to the other players.]<br>
<h4>Class/Component Diagram</h4>
<blockquote>
<div align="Left"><img src="ExampleClassDiagram.jpg" alt="Example Class Diagram" width="324" height="270" title="Example Class Diagram">
<br>
</div>
</blockquote>
<ul>
<li>[Class/<a href="Link%20To%20Component%20A%20Detailed%20Design">
Component A</a>
]: This class is used to...</li>
<li>[Class/<a href="Link%20To%20Component%20B%20Detailed%20Design">
Component B</a>
]: This class works with Class A to...<br>
</li>
</ul>
<br>
<h2>Use Case</h2>
[Use Cases describe interactions between specific instances of the objects
or components described in the Data Model. There will generally be
use cases for each interesting runtime interaction between the objects
in the system. An extremely simple system will have at least one use case
describing the behavior of the simple system in action, but most systems
have many use cases corresponding to the any things that the system does.
The reader should be able to find the use case (or cases) that correspond
to the situation they are interested in understanding, and they should be
able to learn how data flows through the system, what objects are involved,
how object and data life-cycles are managed (e.g. where allocations
ad deallocations occur, and who maintains ownership). This section makes up
the bulk of the document. It touches on implementations and algorithms, but
rather than describing them in detail, it stays high-level and links to the
detailed designs that correspond.]<br>
<h4>[Use Case 1: Component is Created]</h4>
The component is created by a client with...<br>
[Image could go here if it were interesting enough...]<br>
<br>
<h4>[Use Case 2: Component is Destroyed]</h4>
When the client is finished with the instance they created (or were given
ownership of) the destroy it by calling...<br>
<br>
<h4>[Use Case 3: Component is used to find all invalid links on the page]</h4>
Descriptive text of how the component is invoked goes here. The other
components that it uses to carry out its task are shown, and the general
flow of data is documented.<br>
[Picture of the component instance with annotations showing data flow,
ownership, etc. goes here]<br>
<h2>State Transitions</h2>
[Where appropriate, the discrete states of a system should be enumerated
and the transitions between the states defined. Not all systems require
full state transition diagrams, but most systems have at least a handful
of interesting states, and at least a small number of interesting stimuli
that cause transitions from one state to another. Of course, classes
or components that are not stateful have no need for this section.]<br>
<br>
<br>
</body>
</html>