mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
106 lines
4.6 KiB
HTML
106 lines
4.6 KiB
HTML
|
<!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>
|