diff options
| author | Matt A. Tobin <mattatobin@localhost.localdomain> | 2018-02-02 04:16:08 -0500 |
|---|---|---|
| committer | Matt A. Tobin <mattatobin@localhost.localdomain> | 2018-02-02 04:16:08 -0500 |
| commit | 5f8de423f190bbb79a62f804151bc24824fa32d8 (patch) | |
| tree | 10027f336435511475e392454359edea8e25895d /layout/doc/hld-template.html | |
| parent | 49ee0794b5d912db1f95dce6eb52d781dc210db5 (diff) | |
| download | UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar.gz UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar.lz UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.tar.xz UXP-5f8de423f190bbb79a62f804151bc24824fa32d8.zip | |
Add m-esr52 at 52.6.0
Diffstat (limited to 'layout/doc/hld-template.html')
| -rw-r--r-- | layout/doc/hld-template.html | 109 |
1 files changed, 109 insertions, 0 deletions
diff --git a/layout/doc/hld-template.html b/layout/doc/hld-template.html new file mode 100644 index 000000000..1d06ac9a1 --- /dev/null +++ b/layout/doc/hld-template.html @@ -0,0 +1,109 @@ +<!-- 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> |