Download SSAD Guidelines for LeanMBASE: System and Software Architecture Description and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!
System and Software Architecture
Description (SSAD)
A. Description
1. Purpose
The purpose of the SSAD is to document the results of analyzing the organizational concept of operation for the system, designing an architecture, and designing an implementation. The SSAD serves as a bridge between the Operational Concept defined during the Inception phase and the Construction phase. The SSAD is started during the Inception phase, refined during the Elaboration phase, and completed during the Construction phase.
2. Completion Criteria
The following criteria must be satisfied at all milestones.
- The OCD must be defined using language appropriate to intended audience (i.e. the operational stakeholders).
- All domain– or project–specific terms and acronyms, and any common terms with domain– or project– specific definitions must be described in “Glossary for System Analysis and Design” (SSAD 6).
The following paragraphs describe the specific completion criteria for SSAD at the three project milestones.
2.1 Life-Cycle Objectives (LCO)
At LCO, the following items need to be described.
- Top-level definition of at least one feasible architecture: o A feasibility architecture should reasonably be expected to support the system operational concept, satisfy the requirements, be faithful to the prototypes, and be built within the budgets and schedules in the Life Cycle Plan. Use models, prototypes, formulas, simulations, etc. should be used to support the feasibility argument.
- Top-level definition should include o Must define essential features of each architectural component, i.e. interface(s), behavior, data, qualities. o Choices of potential COTS and reusable software elements o Detailed system analysis
- Identification of infeasible architecture options
2.2 Life-Cycle Architecture (LCA)
At LCA, the following items need to be described.
- Choice of architecture that expected to last the life of system.
Physical and logical components, connectors, configurations, constraints
- For chosen architecture, must have precise descriptions of each architectural component, i.e. interface(s), behavior, data, qualities.
COTS and technology reuse choices
Architectural style choices, deployment considerations
Critical algorithms and analysis issues must be resolved
- Architecture evolution parameters
- Design for each component of the system
- Tracing to and from OCD/SSRD
- Assurance of satisfaction of Feasibility Criterion
2.3 Initial Operational Capability (IOC)
At IOC, the following items need to be described.
- The design of a technology–specific implementation for the system (Update LCA document to reflect current implementation - “as built” specifications)
- Tracing to and from CTS
B. Document Sections
The following subsections describe the base format for the SSAD. The section headers should appear in your document. The text shown here describes the content of the section that should appear in your document.
Note: For additional details regarding ‘Representation, Recommendations, CS577 specific guidelines, Model Integration rules, Trade Offs, and Common pitfalls’ refer to LeanMBASE Additional SSAD Guideline document.
- Introduction
1.1 Purpose of the SSAD Document
Summarize the purpose and contents of this document with respect to your project and the people involved. Describe how your SSAD meets the completion criteria for the current milestone.
1.2 Standards and Conventions
Describe any standards (e.g. DOD, IEEE), notations (e.g. UML), and conventions used to produce the SSAD. For example
- Standards used (DOD, IEEE)
- Notation used (UML)
Representation:
Describe the context of the system using UML’s Static–Structure and Collaboration Diagrams.
2.1.1 System
Provide a brief description of the system’s role, purpose, and responsibilities. List the services of the system, which are used in the system’s behavior (SSAD 2.3).
2.1.2 Actor X
Create a section at this level for each actor classifier in the figure(s) shown in SSAD 2.1. The header of this section should be the name of the worker or outside actor class and its unique designator, if you have assigned an identifier and it is different from the name.
Provide a brief description of actor’s role, and responsibilities. List any attributes of the actor that the system processes (SSAD 2.3) are known to be use. List any services provided by the actor that are used in a system process (SSAD 2.3). List any processes in which the actor participates. If the actor is a system and the current instance used is a COTS product, identify the product’s name, version, and creator or distributor.
2.2 Artifacts & Information
Briefly describe the artifacts (e.g. documents, products, resources) inspected, manipulated, or produced by the system, the kinds of information that the system must inspect, manipulate, produce, or maintain (e.g. customer record, part description, event description), and the relations among the artifacts and the information.
Representation
Create a UML Class diagram (i.e. a Static–Structure Diagram showing classes) that describes the classes of artifacts and information, and their known attributes, operations, and relations. (Attributes and operations are typically “known” because they are used to describe the implementation of a system behavior.) Each Diagram should have a brief description of its purpose and any critical features.
2.2.1 Artifact or Information Class X
Create a section at this level for each artifact in the figure(s) shown in SSAD 2.2. The header of this section should be the name of the artifact or information class and its unique designator, if you have assigned an identifier and it is different from the name.
Provide a brief description of its role, purpose, and responsibilities. List any system capabilities that use the artifact.
2.3 Behavior
Describe the processes that the system uses to implement its capabilities (OCD 3.1), and if significant, how the system’s behavior depends on its state (also called mode).
2.3.1 Processes
Describe the processes that the systems uses to achieve its capabilities (OCD 3.1). For each process, identify which actors participate in the process, and which artifacts and information are inspected, manipulated, or produced by the process; and describe at a high level the actions performed by the system and each actor during the process.
Representation:
Create a Use–Case Model that describes the system’s processes; the actors that participate in each process; and the relations among the processes and the outside actors. Represent the model as a package with the stereotype <<use– case model>> with the package name “System Processes”.
- Create one or more Use–Case Diagrams that show the capabilities, the processes that implement them, and a realization relation from each process to the capability that it implements. (Some processes may support the implementation of multiple capabilities.)
- If the relation of the specific processes to the capabilities is not obvious, create one or more UML Use– Case Diagrams that show the capabilities, the processes that implement them, and a realization relation from each process to the capability that it implements. (Some processes may support the implementation of multiple capabilities.)
- For each process, create a subsection numbered 2.3.1.x (see example section below) with the name of the process in the header. Include the following in the section. o A Use–Case Description (Table 1 – LeanMBASE Additional SSAD Guideline) o An UML Activity Diagram for each high–risk or high–priority process and Table 2, 3, 4 – LeanMBASE Additional SSAD Guideline
Add any terms identified during this modeling effort that are unique to the organization or have unique meaning to the Glossary for System Analysis and Design (SSAD 6).
2.3.1.1 Process X
Create a section at this level for each process of the system. The header of this section should be the name of the process and its unique designator, if you have assigned an identifier and it is different from the name. Provide the information described in Table 1, 2, 3 and 4 – LeanMBASE Additional SSAD Guideline, and any UML Activity Diagram.
2.3.2 Modes of Operation
Describe the state behavior (also called modal behavior) of the system, i.e. how the behavior of the system depends on the state (at high–levels of behavior called mode) it is in. Describe the high–level states of the system, the events that cause the system to change modes, and how the processing is different in each mode.
Representation:
Create a UML State Model that describes the high–level modes of the system, the events that cause the system to change modes, and how the processing is different in each mode. Represent the model as a package with the stereotype <> with the package name “System Modes”. (Some UML tools allow you to attach the State Model to the classifier representing a system.). Create one or more UML Statecharts that show the modes of system and the events that cause mode changes.
3.1.1 Hardware Classifier Model
Describe the kinds of hardware components that are either part of the system or on which this system will run, the actors is for the system with which the components interacts, and the kinds of connectors that will be used to connect them.
Representation:
Describe the hardware classes the system using UML’s Deployment Diagrams
3.1.2 Software Classifier Model
Describe the kinds of software components that are part of the system, the actors for the system with which the system interacts, and the kinds of connectors that will be used to connect them.
Representation:
Describe the software classes the system using UML’s Component Diagrams.
3.1.3 Deployment Model
Describe component and connector configuration(s) that make a working version of the system. (There may be more than one configurations, e.g. for different modes.) For each configuration, describe the instances of hardware and software component classes that participate in the configuration, the allocation of software components to the hardware components, the instances of hardware connector classes that link the hardware components, and the instances software connector classes that link the software components.
Representation:
Describe the deployment configurations using UML’s Deployment Model.
3.1.4 Hardware Component Classifiers
For each hardware component classifier shown in the figure(s) shown in the Hardware Classifier Model, create a subsection with the name and unique identifier (if you have assigned an identifier and it is different from the name) of the hardware component classifier in the header.
Representation:
The description of hardware components classifiers depends on the type of system that you are defining, on the architecture language that you are using to represent your system, and possibly on architecture style considerations. For example, if you are describing a system where the hardware is not being developed as part of the system (e.g. a web application), it is usually sufficient to just describe the purpose of each hardware component and the L.O.S. that the hardware is expected to provide.
577 Guidelines:
Your system is probably simple enough, that you need only fill in the following sections for each component.
- 3.1.4.1.1 Purpose
- 3.1.4.1.2 L.O.S. Characteristics Goals (needed to determine some system goals)
It is probably less risky to either defer describing the hardware in more detail until Platform/Technology–Specific Model (SSAD 4) or not describe the hardware interfaces at all than to describe this detail here.
If you decide more detail is needed, create a UML package, with the stereotype <> and the name “Component Classifier Name TIM”, in the package that holds the classifier that represents this hardware component classifier.
3.1.4.1 Component Classifier X
Based on your chosen architectural style and language (and, as always, on your risk analysis) fill–in the details for the following sections.
3.1.4.1.1 Purpose
Describe the purpose of this class of component.
3.1.4.1.2 L.O.S. Characteristics Goals
Describe the system L.O.S. requirements (SSRD 5) that apply to this component classifier. For example, require or expected minimum memory. (Some system L.O.S. requirements may not apply.) Each L.O.S. requirement should be measurable, relevant, and specific (M.R.S.).
The classifier’s goals are used to demonstrate that the architecture will meet the system’s goals (i.e. the system goals will be meet its goals if all connectors and components achieve their goals). For example, if a hardware component doesn't have enough memory, the software components designed to reside down the hardware component and or the software component’s data may not fit on the hardware component.
The L.O.S. Goals for a component classifier defines the goals for all instances of this classifier, and the goals that an implementation of this component classifier must achieve.
Representation:
For each system goal that applies to this component class fill out the L.O.S. Form.
3.1.5 Hardware Connector Classifiers
For each hardware Connector classifier shown in the figure(s) shown in the Hardware Classifier Model, create a subsection with the name and unique identifier (if you have assigned an identifier and it is different from the name) of the hardware Connector classifier in the header.
Representation:
The description of hardware Connectors classifiers depends on the type of system that you are defining, on the architecture language that you are using to represent your system, and possibly on architecture style considerations. For example, if you are describing a system where the hardware is not being developed as part of the system (e.g. a web application), it is usually sufficient to just describe the purpose of each hardware Connector and the L.O.S. that the hardware is expected to provide.
Representation:
The description of software components classifiers depends on the type of system that you are defining, on the language (e.g. UML, architecture) that you are using to represent your system, and possibly on architecture style considerations.
577 Guidelines:
Create a UML package, with the stereotype <> and the name “Component Classifier Name TIM”, in the package that holds the classifier that represents this software component classifier.
3.1.6.1 Component Classifier X
Based on your chosen architectural style and language (and, as always, on your risk analysis) fill–in the details for the following sections.
3.1.6.1.1 Purpose
Describe the purpose of this class of component.
3.1.6.1.2 Interface(s)
Describe the visible features of the component classifier.
What features can be specified in an interface depend on your architecture style and language (inc. UML). Some common features include operations, attributes, and subcomponents.
Representation:
Describe the visible features of the component classifier using UML’s Static–Structure Diagrams & Component Diagrams.
3.1.6.1.2.1 Feature or Feature Set X
Create a section at this level for each feature or feature set described above. The header of this section should be the name of the feature or feature set and its unique designator, if you have assigned an identifier and it is different from the name. The contents of this section should include a description of the feature’s purpose and the following:
- If the feature is a attribute, include its purpose, its classifier and any default value;
- If the feature is a component that is a part, include a reference to its description in the Internal Architecture (SSAD 3.1.6.1.6) section;
- If the feature is an operation, include a description of its purpose, its parameters and result (called a signature), and any pre– and post–condition;
- If describing an interface, describe the each member of the interface.
3.1.6.1.3 Parameters
Describe any parameters of the software component classifier. The parameters need to be set when an instance of the software component classifier is created.
What parameters can be specified, if any, depend on your architecture style and language (inc. UML). Some common parameters include values, objects, classifiers, operations, and other components.
Representation:
Describe the parameters of the component classifier using UML’s Component Diagrams.
3.1.6.1.4 Behavior
Describe behavior of the instances of this component classifier.
3.1.6.1.4.1 Processes
Describe the processes of this component classifier. For each process, identify which other components and actors participate in the process, and which artifacts and information are inspected, manipulated, or produced by the process; and describe at a high level the actions performed by this component and each actor during the process.
Representation:
Create a Use–Case Model that describes the system’s processes; the actors that participate in each process; and the relations among the processes and the outside actors. Represent the model as a package with the stereotype <<use– case model>> with the package name “System Processes”.
- Create one or more Use–Case Diagrams that show the capabilities, the processes that implement them, and a realization relation from each process to the capability that it implements. (Some processes may support the implementation of multiple capabilities.)
- If the relation of the specific processes to the capabilities is not obvious, create one or more UML Use– Case Diagrams that show the capabilities, the processes that implement them, and a realization relation from each process to the capability that it implements. (Some processes may support the implementation of multiple capabilities.)
- For each process, create a subsection numbered 2.3.1.x (see example section below) with the name of the process in the header. Include the following in the section. o A Use–Case Description (Table 1 – LeanMBASE Additional SSAD Guideline) o An UML Activity Diagram for each high–risk or high–priority process and Table 2, 3, 4 – LeanMBASE Additional SSAD Guideline
Add any terms identified during this modeling effort that are unique to the organization or have unique meaning to the Glossary for System Analysis and Design (SSAD 6).
3.1.6.1.4.1.1 Process X
Create a section at this level for each process of the system. The header of this section should be the name of the process and its unique designator, if you have assigned an identifier and it is different from the name. Provide the information described in Table 1, 2, 3 and 4 – LeanMBASE Additional SSAD Guideline, and any UML Activity Diagram.
3.1.6.1.4.2 Modes of Operation
Describe the modal behavior of the component instances, i.e. how the behavior of the component depends on the mode it is in. Describe the high–level states of the component, the events that cause the component to change modes, and how the processing is different in each mode.
Note:
The description of hardware components depends on the type of system that you are defining, on the architecture language that you are using to represent your system, and possibly on architecture style considerations.
3.1.7.1 Component X
Based on your chosen architectural style and language (and, as always, on your risk analysis) fill–in the details for the following sections.
3.1.7.1.1 Purpose
Describe the purpose of this component.
3.1.7.1.2 Classifier
Identify the classifier of this component.
3.1.8 Software Components
For each software component defined in the figure(s) shown in the Deployment Model, create a subsection with the name and unique identifier (if you have assigned an identifier and it is different from the name) of the software component classifier in the header.
Note:
The description of software components depends on the type of system that you are defining, on the architecture language that you are using to represent your system, and possibly on architecture style considerations.
3.1.8.1 Component X
Based on your chosen architectural style and language (and, as always, on your risk analysis) fill–in the details for the following sections.
3.1.8.1.1 Purpose
Describe the purpose of this component.
3.1.8.1.2 Classifier
Identify the classifier of this component.
3.2 Information Classes
Create a model of the information classes that are needed to support the architectural structure (SSAD 3.1) implement the system behavior (SSAD 3.3). This class model may include classes representing following:
- Artifacts and information required by the system (SSAD 2.2);
- Forms defined in the current prototype (OCD 3.3.4);
- Information needed for communication components in the architectural structure (SSAD 3.1);
- Control behavior specific to one or a few processes performed by architectural units (i.e. “recipes” that define how to do something).
Representation
Create a class model using UML’s Class Model.
3.2.1 Information Class X
Create a section at this level for each artifact in the figure(s) shown in SSAD 3.2. The header of this section should be the name of the class and its unique designator, if you have assigned an identifier and it is different from the name.
Provide a brief description of its role, purpose, and responsibilities. List any attributes and operations that are used to describe either the structure (SSAD 3.1) or behavior (SSAD 3.3) of the information class.
3.3 Behavior
Describe how the components work with each other and with the actors to implement the required behavior of the system (SSAD 2.3).
Describe how each system process (SSAD 2.3) is implemented by the components described in the SSAD 3.1.3. For each process, identify which components participate in the system process, and which instances of the TIM information classes (SSAD 3.2) are inspected, manipulated, or produced in the process; and describe the interactions among the components and the TIM information classes.
Representation:
Create a behavior model using a Use–Case Model that describes the system’s processes, the actors that participate in each process and the relations among the processes and the outside actors. Represent the model as a package with the stereotype <<use–case model>> with the package name “Process Implementations”.
For each high priority process implementation, create a Use–Case Realization Description (along with Use Case Model – Table 10 – LeanMBASE Additional SSAD Guideline), and one or more Interaction Diagram.
For other processes its sufficient to have create a Use–Case Realization Description (Table 10 – LeanMBASE Additional SSAD Guideline)
3.4 Architectural Styles, Patterns & Frameworks
Describe any architectural styles (e.g. the Prism style [http://sunset.usc.edu/~softarch/Prism/]), patterns (e.g., pipe– and–filter and client–server), or frameworks used to describe the system architecture.
ADK EDITS START HERE *****
See Section 3.1.1.2 of the California Science Center Volunteer Tracking System project’s LCA SSAD for an example of how the software classifier model should be constructed.
4.1.3 Deployment Model
This section should describe the technology–specific deployment of the system’s software components and connectors onto its hardware components and connectors. If the system will exist in multiple configurations, e.g., for different platforms or different modes of operation, then there should be one deployment model for each.
See Section 3.1.1. 3 of the California Science Center Volunteer Tracking System project’s LCA SSAD for an example of how the deployment model should be constructed.
4.1.4 Hardware Component Classifiers
For each hardware component classifier described in the Hardware Classifier Model described above, in SSAD 4.1.1, this section should contain a subsection with the name and unique identifier (if you have assigned an identifier and it is different from the name) of the hardware component classifier as the subsection’s title. Each such subsection should describe the hardware component classifier’s purpose and its L.O.S. characteristic goals.
See Section 3.1.1.4.1-3.1.1.4.5 of the California Science Center Volunteer Tracking System project’s LCA SSAD for examples of how the individual component classifier sub-sections should be constructed.
4.1.5 Hardware Connector Classifiers
For each hardware connector classifier shown in the Hardware Classifier Model described above, in SSAD 4.1.1, this section should contain a subsection with the name and unique identifier (if you have assigned an identifier and it is different from the name) of the hardware connector classifier as the subsection’s title. Each such subsection should describe the hardware connector classifier’s purpose and its L.O.S. goals.
See Section 3.1.1.5.1 of the California Science Center Volunteer Tracking System project’s LCA SSAD for examples of how the individual hardware connector classifier sub-sections should be constructed, including sub- subsections on each connector classifier’s purpose and its L.O.S. goals.
4.1.6 Software Component Classifiers
For each software component classifier shown in the Hardware Classifier Model described above, in SSAD 4.1.2, this section should contain a subsection with the name and unique identifier (if you have assigned an identifier and it is different from the name) of the software component classifier as the subsection’s title. Each such subsection should describe the software component classifier’s purpose, its interfaces, its parameters, its behavior, its modes of operation, its constraints, and its internal architecture.
See Section 3.1.1.6.1-3.1.1.6.5 of the California Science Center Volunteer Tracking System project’s LCA SSAD for examples of how the individual software component classifier sub-sections should be constructed.
4.1.7 Hardware Components
For each hardware component defined in the figure(s) shown in the Deployment Model (SSAD 4.1.3), create a subsection with the name and unique identifier (if you have assigned an identifier and it is different from the name)
of the hardware component as the subsection’s title. Each such subsection should describe, in two separate sub-sub- sections the hardware component’s purpose and the hardware component classifier of which it is an instance.
See Section 3.1.1.7.1-3.1.1.7.5 of the California Science Center Volunteer Tracking System project’s LCA SSAD for examples of how the individual hardware component subsections should be constructed.
4.1.8 Software Components
For each software component defined in the figure(s) shown in the Deployment Model (SSAD 4.1.3), create a subsection with the name and unique identifier (if you have assigned an identifier and it is different from the name) of the software component as the subsection’s title. Each such subsection should describe, in two separate sub-sub- sections, the software component’s purpose and the software component classifier of which it is an instance.
See Section 3.1.1.8.1-3.1.1.8.5 of the California Science Center Volunteer Tracking System project’s LCA SSAD for examples of how the individual hardware component subsections should be constructed.
4.1.9 Information Classes
For each information class defined in the Error! Reference source not found. subsection of any software component in the Software Classifier Model (SSAD 4.1.2), create a subsection with the name and unique identifier (if you have assigned an identifier and it is different from the name) of the information class as the subsection’s title. Each subsection should describe, in separate sub-sub-sections, the following properties of that information class: its purpose; the component in which it resides; any interfaces that it implements (with one sub-sub-sub-section for each); its parameters; its attributes; its operations (with one sub-sub-sub-section for each); its state behavior, if it operates in more than one state; any constraints on it, and any L.O.S. requirements that apply to it.
See Section 3.1.1.9.1-3.1.1.9.5 of the California Science Center Volunteer Tracking System project’s LCA SSAD for examples of how the individual information class subsections should be constructed.
4.2 Behavior
This section should use sequence diagrams derived from the use case descriptions to describehow the various components will work with one another and with the actors to implement the system’s required behavior). There should be one subsection per sequence diagram.
See Section 3.1.2.1-3.1.2.26 of the California Science Center Volunteer Tracking System project’s LCA SSAD for an example of what the introduction to this system should contain and what should be in each subsection.
4.3 Patterns & Frameworks
This section should describe any implementation architecture styles (e.g. the Prism style [http://sunset.usc.edu/~softarch/Prism/]), patterns (e.g., pipe–and–filter and client–server), or frameworks (e.g. Java and CORBA) used to describe the system architecture.
See Section 3.2 of the California Science Center Volunteer Tracking System project’s LCA SSAD for an example of what this section should contain and how its contents should be presented.
