michael@0:
michael@0:
michael@0:
michael@0:
michael@0:
michael@0:
michael@0:
michael@0: Layout High Level design Template
michael@0:
michael@0:
michael@0:
michael@0:
michael@0:
michael@0: Gecko Layout High Level Design Document Template
michael@0: [Use this template to start your high level design. Replace items in square
michael@0: brackets with the appropriate text for your component, class or system. Keep
michael@0: in mind that this is just a general template intended for most designs.
michael@0: Your specific design may require different organization or topics - the
michael@0: goal is to provide high-level information about the software to the reader.]
michael@0:
michael@0:
michael@0: [Component/Class/System Name] High Level Design
michael@0:
michael@0:
michael@0: Overview
michael@0: [Provide a descriptive overview of the component, class, or system that
michael@0: you are documenting. Describe what the system is supposed to do, where it
michael@0: is in the overall system, who the clients are, how it is expected to perform,
michael@0: and any other information that is important to convey to somebody interested
michael@0: in understanding what the documented system is all about.]
michael@0:
michael@0:
michael@0: Data Model
michael@0: [This section describes the classes or components that make up the data
michael@0: model for the system being documented. It can include a graphical representation
michael@0: of the classes and their relationships to each other (derivation, aggregation,
michael@0: ownership, usership, etc.). No implementation details are to be included
michael@0: here, but general relationships and inter-relationships should be shown and
michael@0: briefly described. The reader should be able to understand the players in
michael@0: the system, and the extent to which those players interact with or are related
michael@0: to the other players.]
michael@0:
michael@0: Class/Component Diagram
michael@0:
michael@0:
michael@0: 
michael@0:
michael@0:
michael@0:
michael@0:
michael@0:
michael@0:
michael@0: Use Case
michael@0: [Use Cases describe interactions between specific instances of the objects
michael@0: or components described in the Data Model. There will generally be
michael@0: use cases for each interesting runtime interaction between the objects
michael@0: in the system. An extremely simple system will have at least one use case
michael@0: describing the behavior of the simple system in action, but most systems
michael@0: have many use cases corresponding to the any things that the system does.
michael@0: The reader should be able to find the use case (or cases) that correspond
michael@0: to the situation they are interested in understanding, and they should be
michael@0: able to learn how data flows through the system, what objects are involved,
michael@0: how object and data life-cycles are managed (e.g. where allocations
michael@0: ad deallocations occur, and who maintains ownership). This section makes up
michael@0: the bulk of the document. It touches on implementations and algorithms, but
michael@0: rather than describing them in detail, it stays high-level and links to the
michael@0: detailed designs that correspond.]
michael@0:
michael@0: [Use Case 1: Component is Created]
michael@0: The component is created by a client with...
michael@0: [Image could go here if it were interesting enough...]
michael@0:
michael@0:
michael@0: [Use Case 2: Component is Destroyed]
michael@0: When the client is finished with the instance they created (or were given
michael@0: ownership of) the destroy it by calling...
michael@0:
michael@0:
michael@0: [Use Case 3: Component is used to find all invalid links on the page]
michael@0: Descriptive text of how the component is invoked goes here. The other
michael@0: components that it uses to carry out its task are shown, and the general
michael@0: flow of data is documented.
michael@0: [Picture of the component instance with annotations showing data flow,
michael@0: ownership, etc. goes here]
michael@0:
michael@0: State Transitions
michael@0: [Where appropriate, the discrete states of a system should be enumerated
michael@0: and the transitions between the states defined. Not all systems require
michael@0: full state transition diagrams, but most systems have at least a handful
michael@0: of interesting states, and at least a small number of interesting stimuli
michael@0: that cause transitions from one state to another. Of course, classes
michael@0: or components that are not stateful have no need for this section.]
michael@0:
michael@0:
michael@0:
michael@0:
michael@0: