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