<!-- 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>