layout/doc/hld-template.html

   1 <!-- This Source Code Form is subject to the terms of the Mozilla Public
   2    - License, v. 2.0. If a copy of the MPL was not distributed with this
   3    - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
   4
   5 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
   6 <html>
   7 <head>
   8
   9   <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  10   <title>Layout High Level design Template</title>
  11
  12   <meta name="author" content="Marc Attinasi (attinasi@netscape.com)">
  13 </head>
  14   <body>
  15
  16 <h1><font color="#cc0000">Gecko Layout High Level Design Document Template</font></h1>
  17    [Use this template to start your high level design. Replace items in square
  18  brackets with the appropriate text for your component, class or system. &nbsp;Keep
  19  in mind that this is just a general template intended for most designs.
  20 Your  specific design may require different organization or topics - the
  21 goal is  to provide high-level information about the software to the reader.]<br>
  22   <br>
  23
  24 <h1>[Component/Class/System Name] High Level Design</h1>
  25   <br>
  26
  27 <h2>Overview</h2>
  28    [Provide a descriptive overview of the component, class, or system that
  29  you are documenting. Describe what the system is supposed to do, where it
  30  is in the overall system, who the clients are, how it is expected to perform,
  31  and any other information that is important to convey to somebody interested
  32  in understanding what the documented system is all about.]<br>
  33   <br>
  34
  35 <h2>Data Model</h2>
  36    [This section describes the classes or components that make up the data
  37  model for the system being documented. It can include a graphical representation
  38  of the classes and their relationships to each other (derivation, aggregation,
  39  ownership, usership, etc.). No implementation details are to be included
  40 here, but general relationships and inter-relationships should be shown and
  41 briefly described. The reader should be able to understand the players in
  42 the system, and the extent to which those players interact with or are related
  43 to the other players.]<br>
  44
  45 <h4>Class/Component Diagram</h4>
  46
  47 <blockquote>
  48   <div align="Left"><img src="ExampleClassDiagram.jpg" alt="Example Class Diagram" width="324" height="270" title="Example Class Diagram">
  49     <br>
  50     </div>
  51     </blockquote>
  52
  53   <ul>
  54       <li>[Class/<a href="Link%20To%20Component%20A%20Detailed%20Design">
  55 Component  A</a>
  56    ]: This class is used to...</li>
  57       <li>[Class/<a href="Link%20To%20Component%20B%20Detailed%20Design">
  58 Component  B</a>
  59    ]: This class works with Class A to...<br>
  60       </li>
  61
  62   </ul>
  63     <br>
  64
  65   <h2>Use Case</h2>
  66    [Use Cases describe interactions between specific instances of the objects
  67  or components described in the Data Model. &nbsp;There will generally be
  68 use cases for each &nbsp; interesting runtime interaction between the objects
  69  in the system. An extremely simple system will have at least one use case
  70  describing the behavior of the simple system in action, but most systems
  71 have many use cases corresponding to the any things that the system does.
  72 &nbsp;The reader should be able to find the use case (or cases) that correspond
  73 to the situation they are interested in understanding, and they should be
  74 able to learn how data flows through the system, what objects are involved,
  75 how &nbsp;object and data life-cycles are managed (e.g. where allocations
  76 ad deallocations occur, and who maintains ownership). This section makes up
  77 the bulk of the document. It touches on implementations and algorithms, but
  78 rather than describing them in detail, it stays high-level and links to the
  79 detailed designs that correspond.]<br>
  80
  81   <h4>[Use Case 1: Component is Created]</h4>
  82    The component is created by a client with...<br>
  83    &nbsp;[Image could go here if it were interesting enough...]<br>
  84     <br>
  85
  86   <h4>[Use Case 2: Component is Destroyed]</h4>
  87    When the client is finished with the instance they created (or were given
  88  ownership of) the destroy it by calling...<br>
  89     <br>
  90
  91   <h4>[Use Case 3: Component is used to find all invalid links on the page]</h4>
  92    Descriptive text of how the component is invoked goes here. The other
  93 components  that it uses to carry out its task are shown, and the general
  94 flow of data  is documented.<br>
  95    [Picture of the component instance with annotations showing data flow,
  96 ownership,  etc. goes here]<br>
  97
  98   <h2>State Transitions</h2>
  99    [Where appropriate, the discrete states of a system should be enumerated
 100  and the transitions between the states defined. &nbsp;Not all systems require
 101  full state transition diagrams, but most systems have at least a handful
 102 of interesting states, and at least a small number of interesting stimuli
 103 that cause transitions from one state to another. &nbsp; Of course, classes
 104 or components that are not stateful have no need for this section.]<br>
 105     <br>
 106     <br>
 107
 108   </body>
 109   </html>