This action might not be possible to undo. Are you sure you want to continue?
<Project Name> System Architecture Document
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).] [To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]
c om .x> <details> Description <name> Author C TO S SDLC Internal Use Only ©SDLC. 2000 ys t em Page 2 of 6 .<Project Name> Software Architecture Document <document identifier> Version: <1.0> Date: <dd/mmm/yy> Revision History Date <dd/mmm/yy> Version <x.
Size and Performance Quality C TO S ©SDLC. 4.2 Scope 1. 5.2 Architecturally Significant Design Packages Process View Deployment View Implementation View 8. 6.1 Use-Case Realizations Logical View 5.c om Page 3 of 6 .1 Overview 8.5 Overview Architectural Representation Architectural Goals and Constraints Use-Case View 4.2 Layers Data View (optional) 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 6 6 6 2. 10. 3.1 Overview 5. 2000 SDLC Internal Use Only ys t em .0> Date: <dd/mmm/yy> Table of Contents 1. 11. 8.<Project Name> Software Architecture Document <document identifier> Version: <1.3 Definitions. Introduction 1.4 References 1.1 Purpose 1. 9. 7. Acronyms and Abbreviations 1.
Specify the sources from which the references can be obtained. Introduction [The introduction of the System Architecture Document should provide an overview of the entire System Architecture Document.2 1. Deployment. use of an off-the-shelf product. and how it is represented. abbreviations. 2000 Scope [A brief description of what the System Architecture Document applies to. Architectural Representation [This section describes what System architecture is for the current system. security.4 C TO 2. Architectural Goals and Constraints [This section describes the System requirements and objectives that have some significant impact on the architecture.1 Purpose This document provides a comprehensive architectural overview of the system. Logical. It also captures the special constraints that may apply: design and implementation strategy.<Project Name> Software Architecture Document <document identifier> Version: <1. and Implementation Views. The specific audiences for the document should be identified. for example. It should include the purpose. in the overall project documentation. definitions.] 1. distribution. acronyms. This information may be provided by reference to the project Glossary. scope. and so on. legacy code.] SDLC Internal Use Only ys t em ©SDLC. Page 4 of 6 .] 1.3 Definitions.0> Date: <dd/mmm/yy> System Architecture Document 1.] om 1. This information may be provided by reference to an appendix or to another document. acronyms. and for each view. with an indication of how they are expected to use the document. report number (if applicable). team structure. development tools. Process. central functionality of the final system. Each document should be identified by title. or if they have a large architectural coverage . and abbreviations required to properly interpret the System Architecture Document. and publishing organization. references.] References [This subsection should provide a complete list of all documents referenced elsewhere in the System Architecture Document. portability. Use-Case View [This section lists use cases or scenarios from the use-case model if they represent some significant.] . schedule. using a number of different architectural views to depict different aspects of the system. it enumerates the views that are necessary. what is affected or influenced by this document. Of the Use-Case.they exercise many S 1. Acronyms and Abbreviations [This subsection should provide the definitions of all terms. It is intended to capture and convey the significant architectural decisions which have been made on the system.] 3.] 4.c [This section defines the role or purpose of the System Architecture Document. explains what types of model elements it contains. and overview of the System Architecture Document. privacy. safety. and reuse. and briefly describes the structure of the document. date.5 Overview [This subsection should describe what the rest of the System Architecture Document contains and explain how the System Architecture Document is organized.
1 8. include its name.] 8.] 4. Process View [This section describes the system's decomposition into lightweight processes (single threads of control) and heavyweight processes (groupings of lightweight processes). or if they stress or illustrate a specific. such as message passing. ] Layers [For each layer. the decomposition of the System into layers and subsystems in the implementation model. and a component diagram. .2 For each significant class in the package. as well as a few very important relationships. You should introduce architecturally significant classes and describe their responsibilities. and attributes. and a diagram with all significant classes and packages contained within the package.1 Use-Case Realizations [This section illustrates how the System actually works by giving a few selected use-case (or scenario) realizations. operations. point-to-point. include a subsection with its name. Deployment View C TO [This section describes one or more physical network (hardware) configurations on which the System is deployed and run.] Overview [This subsection names and defines the various layers and their contents.] om Page 5 of 6 . and their interconnections (bus. 2000 Architecturally Significant Design Packages [For each significant package. and explains how the various design model elements contribute to their functionality. and so on. operations and attributes. At a minimum for each configuration it should indicate the physical nodes (computers. Implementation View [This section describes the overall structure of the implementation model.] 6. the rules that govern the inclusion to a given layer. Include a component diagram that shows the relations between layers. such as its decomposition into subsystems and packages. Organize the section by groups of processes that communicate or interact. its decomposition into classes and class utilities. and.] 7. its brief description. delicate point of the architecture.] 5. CPUs) that execute the System. Logical View [This section describes the architecturally significant parts of the design model. an enumeration of the subsystems located in the layer. And for each significant package.2 S SDLC Internal Use Only ys t em ©SDLC.1 5. include a subsection with its name.c Overview [This subsection describes the overall decomposition of the design model in terms of its package hierarchy and layers. optionally a description of some of its major responsibilities.0> Date: <dd/mmm/yy> architectural elements.] 8.<Project Name> Software Architecture Document <document identifier> Version: <1. interrupts.] 5. LAN. and any architecturally significant components. Describe the main modes of communication between processes. brief description. and the boundaries between layers. and rendezvous.) Also include a mapping of the processes of the Process View onto the physical nodes.
Quality [A description of how the System architecture contributes to all capabilities (other than functionality) of the system: extensibility. This section is optional if there is little or no persistent data.] 11. If these characteristics have special significance. they should be clearly delineated. for example safety. Size and Performance [A description of the major dimensioning characteristics of the System that impact the architecture.] C TO S SDLC Internal Use Only ©SDLC. or the translation between the Design Model and the Data Model is trivial.<Project Name> Software Architecture Document <document identifier> Version: <1. security or privacy implications.] 10. 2000 ys t em Page 6 of 6 . portability. as well as the target performance constraints.0> Date: <dd/mmm/yy> 9. Data View (optional) [A description of the persistent data storage perspective of the system. reliability.c om . and so on.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.