1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/layout/doc/hld-template.html Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,109 @@
1.4 +<!-- This Source Code Form is subject to the terms of the Mozilla Public
1.5 + - License, v. 2.0. If a copy of the MPL was not distributed with this
1.6 + - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
1.7 +
1.8 +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
1.9 +<html>
1.10 +<head>
1.11 +
1.12 + <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
1.13 + <title>Layout High Level design Template</title>
1.14 +
1.15 + <meta name="author" content="Marc Attinasi (attinasi@netscape.com)">
1.16 +</head>
1.17 + <body>
1.18 +
1.19 +<h1><font color="#cc0000">Gecko Layout High Level Design Document Template</font></h1>
1.20 + [Use this template to start your high level design. Replace items in square
1.21 + brackets with the appropriate text for your component, class or system. Keep
1.22 + in mind that this is just a general template intended for most designs.
1.23 +Your specific design may require different organization or topics - the
1.24 +goal is to provide high-level information about the software to the reader.]<br>
1.25 + <br>
1.26 +
1.27 +<h1>[Component/Class/System Name] High Level Design</h1>
1.28 + <br>
1.29 +
1.30 +<h2>Overview</h2>
1.31 + [Provide a descriptive overview of the component, class, or system that
1.32 + you are documenting. Describe what the system is supposed to do, where it
1.33 + is in the overall system, who the clients are, how it is expected to perform,
1.34 + and any other information that is important to convey to somebody interested
1.35 + in understanding what the documented system is all about.]<br>
1.36 + <br>
1.37 +
1.38 +<h2>Data Model</h2>
1.39 + [This section describes the classes or components that make up the data
1.40 + model for the system being documented. It can include a graphical representation
1.41 + of the classes and their relationships to each other (derivation, aggregation,
1.42 + ownership, usership, etc.). No implementation details are to be included
1.43 +here, but general relationships and inter-relationships should be shown and
1.44 +briefly described. The reader should be able to understand the players in
1.45 +the system, and the extent to which those players interact with or are related
1.46 +to the other players.]<br>
1.47 +
1.48 +<h4>Class/Component Diagram</h4>
1.49 +
1.50 +<blockquote>
1.51 + <div align="Left"><img src="ExampleClassDiagram.jpg" alt="Example Class Diagram" width="324" height="270" title="Example Class Diagram">
1.52 + <br>
1.53 + </div>
1.54 + </blockquote>
1.55 +
1.56 + <ul>
1.57 + <li>[Class/<a href="Link%20To%20Component%20A%20Detailed%20Design">
1.58 +Component A</a>
1.59 + ]: This class is used to...</li>
1.60 + <li>[Class/<a href="Link%20To%20Component%20B%20Detailed%20Design">
1.61 +Component B</a>
1.62 + ]: This class works with Class A to...<br>
1.63 + </li>
1.64 +
1.65 + </ul>
1.66 + <br>
1.67 +
1.68 + <h2>Use Case</h2>
1.69 + [Use Cases describe interactions between specific instances of the objects
1.70 + or components described in the Data Model. There will generally be
1.71 +use cases for each interesting runtime interaction between the objects
1.72 + in the system. An extremely simple system will have at least one use case
1.73 + describing the behavior of the simple system in action, but most systems
1.74 +have many use cases corresponding to the any things that the system does.
1.75 + The reader should be able to find the use case (or cases) that correspond
1.76 +to the situation they are interested in understanding, and they should be
1.77 +able to learn how data flows through the system, what objects are involved,
1.78 +how object and data life-cycles are managed (e.g. where allocations
1.79 +ad deallocations occur, and who maintains ownership). This section makes up
1.80 +the bulk of the document. It touches on implementations and algorithms, but
1.81 +rather than describing them in detail, it stays high-level and links to the
1.82 +detailed designs that correspond.]<br>
1.83 +
1.84 + <h4>[Use Case 1: Component is Created]</h4>
1.85 + The component is created by a client with...<br>
1.86 + [Image could go here if it were interesting enough...]<br>
1.87 + <br>
1.88 +
1.89 + <h4>[Use Case 2: Component is Destroyed]</h4>
1.90 + When the client is finished with the instance they created (or were given
1.91 + ownership of) the destroy it by calling...<br>
1.92 + <br>
1.93 +
1.94 + <h4>[Use Case 3: Component is used to find all invalid links on the page]</h4>
1.95 + Descriptive text of how the component is invoked goes here. The other
1.96 +components that it uses to carry out its task are shown, and the general
1.97 +flow of data is documented.<br>
1.98 + [Picture of the component instance with annotations showing data flow,
1.99 +ownership, etc. goes here]<br>
1.100 +
1.101 + <h2>State Transitions</h2>
1.102 + [Where appropriate, the discrete states of a system should be enumerated
1.103 + and the transitions between the states defined. Not all systems require
1.104 + full state transition diagrams, but most systems have at least a handful
1.105 +of interesting states, and at least a small number of interesting stimuli
1.106 +that cause transitions from one state to another. Of course, classes
1.107 +or components that are not stateful have no need for this section.]<br>
1.108 + <br>
1.109 + <br>
1.110 +
1.111 + </body>
1.112 + </html>
