| Include Page | ||||
|---|---|---|---|---|
|
Architecture Background
Problem Background
The sub-parts of this section explain the constraints that provided the significant influence over the architecture. |
System Overview
This section describes the general function and purpose for the system or subsystem whose architecture is described in this SAD. |
Context
This section describes the goals and major contextual factors for the software architecture. The section includes a description of the role software architecture plays in the life cycle, the relationship to system engineering results and artifacts, and any other relevant factors. |
Driving Requirements
This section lists the functional requirements quality attributes and design constraints. It may point to a separate requirements document. |
Solution Background
The sub-parts of this section provide a description of why the architecture is the way that it is, and a convincing argument that the architecture is the right one to satisfy the behavioral and quality attribute goals levied upon it. |
Architectural Approaches
This section provides a rationale for the major design decisions embodied by the software architecture. It describes any design approaches applied to the software architecture, including the use of architectural styles or design patterns, when the scope of those approaches transcends any single architectural view. The section also provides a rationale for the selection of those approaches. It also describes any significant alternatives that were seriously considered and why they were ultimately rejected. The section describes any relevant COTS issues, including any associated trade studies. |
Analysis Results
This section describes the results of any quantitative or qualitative analyses that have been performed that provide evidence that the software architecture is fit for purpose. If an Architecture Tradeoff Analysis Method evaluation has been performed, it is included in the analysis sections of its final report. This section refers to the results of any other relevant trade studies, quantitative modeling, or other analysis results. |
Mapping Requirements to Architecture
This section describes the requirements (original or derived) addressed by the software architecture, with a short statement about where in the architecture each requirement is addressed. |
Documentation Roadmap and Overview
...
Purpose and Scope of the SAD
This section explains the SAD�s overall purpose and scope, the criteria for deciding which design decisions are architectural (and therefore documented in the SAD), and which design decisions are non-architectural (and therefore documented elsewhere). |
This SAD specifies the software architecture for insert scope of SAD. All information regarding the software architecture may be found in this document, although much information is incorporated by reference to other documents.
The software architecture for a system is the structure or structures of that system, which comprise software elements, the externally-visible properties of those elements, and the relationships among them [ Bass 2012]. "Externally visible�properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. This definition provides the basic litmus test for what information is included in this SAD, and what information is relegated to downstream documentation.
...
Although software architecture tends to focus on structural information, behavior of each element is part of the software architecture insofar as that behavior can be observed or discerned from the point of view of another element. This behavior is what allows elements to interact with each other, which is clearly part of the software architecture and will be documented in the SAD as such. Behavior is documented in the element catalog of each view.
How the SAD Is Organized
This section provides a narrative description of the seven major sections of the SAD and the overall contents of each. Readers seeking specific information can use this section to help them locate it more quickly. |
This SAD is organized into the following seven sections:
- Documentation Roadmap and Overview provides information about this document and its intended audience. It provides the roadmap and document overview. Every reader who wishes to find information relevant to the software architecture described in this document should begin by reading this section, which describes how the document is organized, and where information may be found.
- Architecture Background provides information about the software architecture. It describes the background and rationale for the software architecture. It explains the constraints and influences that led to the current architecture, and it describes the major architectural approaches that have been utilized in the architecture.
- https://wiki-int.qa.sei.cmu.edu/confluence/display/SADT/Views and Mapping Between https://wiki-int.qa.sei.cmu.edu/confluence/display/SADT/Views specify the software architecture.
- Referenced Materials and Glossary and Acronyms provide reference information. Referenced Materials provides look-up information for documents that are cited elsewhere in this SAD. Glossary and Acronyms is an index of architectural elements and relations giving their definition, and where each is used in this SAD.
...
Process for Updating this SAD
This section describes the process a reader should follow to report discrepancies, errors, inconsistencies, or omissions from this SAD. The section also includes necessary contact information for submitting the report. If a form is required, either a link should be provided. This section also describes how error reports are handled, and how and when a submitter will be notified of the issue�s disposition. |
Glossary and Acronyms
List of definitions of special terms and acronyms used in the SAD. If terms are used in the SAD that are also used in t a parent SAD and the definition is different, this section explains why. |
Term | Definition |
software architecture | The structure or structures of that system, which comprise software elements, the exter-nally visible properties of those elements, and the relationships among them [ Bass 2012]. "Externally visibleâ� properties refer to those assumptions other elements can make of an element, such as its provided services, per-formance characteris�¬tics, fault handling, shared resource usage, and so on. |
view | A representation of a whole system from the perspective of a related set of concerns [ IEEE 1471]. A representation of a particular type of software architectural elements that occur in a system, their properties, and the relations among them. A view conforms to a defining viewpoint. |
viewpoint | A specification of the conventions for constructing and using a view; a pattern or template from which to develop individual views by establishing the purposes and audience for a view, and the techniques for its creation and analysis [ IEEE 1471]. Identifies the set of concerns to be addressed, and identifies the modeling techniques, evaluation techniques, consistency checking techniques, etc., used by any conforming view. |
view packet | The smallest package of architectural docu-mentation that could usefully be given to a stakeholder. The documentation of a view is composed of one or more view packets. |
Software Architecture Documentation
...
User's Guide for usage and configuration help.
Mapping Between Views
Each of the views specified in https://wiki-int.qa.sei.cmu.edu/confluence/display/SADT/Views provides a different perspective and design handle on a system, and each is valid and useful in its own right. Although the views give different system perspectives, they are not independent. Elements of one view will be related to elements of other views, and we need to reason about these relations. For example, a module in a decomposition view may be manifested as one, part of one, or several components in one of the component-and-connector views, reflecting its runtime alter-ego. In general, mappings between views are many to many. This section describes the relations that exist among the view. As required by ANSI/IEEE 1471-2000, it also describes any known inconsistencies among the views.
Mapping Between View1 and View2
...
Mapping Between View1 and View3
...
Referenced Materials
This section provides citations for each reference document. |
Short Name | Reference |
Barbacci 2003 | Barbacci, Ellison, Lattanze, Stafford, Weinstock, Wood, Quality Attribute Workshops (QAWs), Third Edition (CMU/SEI-2003-TR-016). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003. |
Bass 2012 | Bass, Clements, Kazman, Software Architecture in Practice, third edition, Addison Wesley, 2012. |
Clements 2001 | Clements, Kazman, Klein, Evaluating Software Architectures: Methods and Case Studies, Addison Wesley Longman, 2001. |
Clements 2003 | Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software Architectures: Views and Beyond, Addison Wesley Longman, 2003. |
IEEE 1471 | ANSI/IEEE-1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE, 21 September 2000. |
Views
My first View
Primary Presentation
- Is usually graphical
- Should include a key that explains the notation
- Shows elements and relations among them
- Shows the information you want to convey about the view first
- Should identify elements that are external to scope of the view
- If external entities are not clearly marked in the diagram, consider adding a context diagram
...
- If the current view is the refinement of another view, indicate which one
My second View
Primary Presentation
Element Catalog
...