author Timothy Nikkel <>
Sat, 10 Apr 2010 13:03:40 -0500
changeset 40679 ae7c766a0fe223f8db9a9561bd61790fead133a8
parent 1 9b2a99adc05e53cd4010de512f50118594756650
child 96742 f4157e8c410708d76703f19e4dfb61859bfe32d8
permissions -rw-r--r--
Bug 553363. Don't allow being in the middle of a flush to prevent the docloader from stopping. r=bzbarsky

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <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 (">
<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. &nbsp;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>
<h1>[Component/Class/System Name] High Level Design</h1>
   [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>
<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>
  <div align="Left"><img src="ExampleClassDiagram.jpg" alt="Example Class Diagram" width="324" height="270" title="Example Class Diagram">
      <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>
  <h2>Use Case</h2>
   [Use Cases describe interactions between specific instances of the objects 
 or components described in the Data Model. &nbsp;There will generally be 
use cases for each &nbsp; 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. 
&nbsp;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 &nbsp;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>
   &nbsp;[Image could go here if it were interesting enough...]<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>
  <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. &nbsp;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. &nbsp; Of course, classes 
or components that are not stateful have no need for this section.]<br>