The Tor Browser / file comparison
comparison: layout/doc/hld-template.html
layout/doc/hld-template.html
- branch
- TOR_BUG_3246
- changeset 6
- 8bccb770b82d
equal
deleted
inserted
replaced
| -1:000000000000 | 0:b90f0868c14c |
|---|---|
| 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. 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. There will generally be | |
| 68 use cases for each 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 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 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 [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. 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. 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> |
