layout/doc/hld-template.html

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