OCD
A. Description
B. Document Sections
1. Introduction
2. Shared Vision
3. Domain/Organization Description
Using the term “organization” to represent the entity for which the system is being
developed (or purchased in the case of some COTS systems). For example, the
organization might be a business, a government agency, or some subdivision of either.
3.1 Organization Background
3.2 Organization Goals
3.3 Current Organization Environment
3.3.1 Structure
Briefly describe the current workers (e.g. people roles, systems) and customers of the
organization.
Identify which workers and customers interact with other workers and customers and are
therefore connected.
Representation: either (a) block diagram, (b) specification using an architecture
notation/language, or (c) Business Entity Model using UML Static–Structure &
Collaboration Diagrams; glossary to summarize terms.
Trade-offs: architectural notations/languages and UML provide more standard semantics;
but take longer to specify and require client reviewers to know the notation or language.
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.3.2 Artifacts
Briefly describe the current artifacts (e.g. documents, products, resources used to produce
product) used or produced by the organization, and relations among the artifacts
Representation: block diagram or Business Entity Model using UML Static–Structure
Diagrams; glossary to summarize terms.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.3.3 Processes
Briefly describe the processes of the organization
Identify which customers and workers participate in a process
Identify which artifacts are used, produced, or modified during a process.
Representation: “stories”, or formal Business Use–case Model (Use–case Diagrams and
Descriptions, and Activity Diagrams); glossary to summarize terms.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.3.4 Rules
Describe current policies or conditions (inc. laws and regulations) that must be satisfied
Representation: informal text or formal specification language (e.g. UML’s OCL).
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.4 Current Organization Shortfalls
4. Proposed System
4.1
4.2
4.3
4.4
Statement of Purpose
Project Goals and Constraints
System Capabilities
Changes in Organization Environment
4.4.1 Structure
Describe how the organization’s architecture will be changed by introduction of new (or
revised) system.
Identify new, changed, and deleted workers and customers.
Identify new, changed, deleted connections.
Representation: either (a) block diagram, (b) specification using architecture
notation/language, or (c) Business Entity Model using UML Static–Structure &
Collaboration Diagrams; glossary to summarize terms.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
4.4.2 Artifacts
Describe how the organization’s artifacts used or produced by the organization will be
changed by introduction of new (or revised) system.
Identify new, changed, and deleted artifacts.
Identify new, changed, deleted relations
Representation: block diagram or Business Entity Model using UML Static–Structure
Diagrams; glossary to summarize terms.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
4.4.3 Processes
Describe how the processes of the organization will be changed by introduction of new
(or revised) system
Identify new, changed, and deleted processes
Identify which of the revised customers and workers participate in each process, and how
responsibilities may change.
Identify which of the revised artifacts are used, produced, or modified during each
process.
Representation: glossary plus informal “stories”, or formal Business Use–case Model
(Use–case Diagrams and Descriptions, and Activity Diagrams)
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
4.4.4 Rules
Describe how revised set of policies or conditions (inc. laws and regulations) that must be
satisfied.
Identify new, changed, or deleted policies and conditions
Representation: informal text or formal specification language (e.g. UML’s OCL).
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
4.5 Operational Characteristic Goals
Including performance, usability, and Level of Service (L.O.S.) goals
Prioritized
Representation: MRS(no A) or Gilb Form?
4.6 How New System Addresses Current Organization
Shortfalls
5. Appendices
5.1 COTS Evaluation & Market Surveys
Include description of benefits and shortfalls of COTS solution.
SSAD
A. Description
B. Document Sections – Development
1. Introduction
2. System Analysis
Describe system context.
Refinement of OCD Section 4
Focus on what developers need to know about (a) other workers (person roles & systems)
and customers with which this system interacts when it is operating (for software only
systems, we us the term executing); (b) what services this system will provide and will
require of other workers; (c) process activities in which this system participates; (d) how
the system and the other workers interact to implement process activities that the system
participates in; (e) what artifacts and information that this system needs (e.g. to
communicate with other systems), including any required formats.
2.1 Structure
Describe visible structure (inc. services) of system and of organizational workers (e.g.
people roles, systems) and customers with which this system interacts when it is
operating, and the connections between the system and other the workers and customers.
We’ll adopt the UML term actor for organizational workers (e.g. people roles, systems)
and customers with which this system interacts when it is operating.
Refinement of OCD B.4.4.1.
Representation: specification in architecture notation/language, or Entity Model using
UML Static–Structure & Collaboration Diagrams (alternative: UML Component Model);
glossary to summarize terms.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
2.2 Artifacts & Information
Briefly describe the current artifacts (e.g. documents, products, resources used to produce
product).
Briefly describe the information that the system needs to know about.
Briefly describe relations among the information and artifacts that the system needs to
know about.
Refinement of OCD B.4.4.2.
Representation: Entity Model using UML Static–Structure Diagrams; glossary to
summarize terms.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
2.3 Behavior
Describe behavior of the system, and how it works with the actors to implement the
process activities in which the system participates.
Representation: “stories”; UML Use–case Model (Use–case Diagrams and Descriptions)
with Interaction Diagrams or Activity Diagrams; or UML Statecharts; or formal
specification language as used in some ADLs.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
2.4 Operational Characteristic Goals
Qualities that need to be achieved by this system.
Including performance, usability, and L.O.S.
Refinement of OCD section 4.5.
2.5 Rules
Describe current policies or conditions (inc. laws and regulations) that must be satisfied
by the system and the actors it interacts with.
Representation: informal text or formal specification language (e.g. UML’s OCL).
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3. Architecture Design & Analysis
Describe the work units (“components”) of the system, how they are connected, and each
component’s interface and behavior.
The form of the unit depends on the abstraction and architectural style employed.
For a “system of systems”, each component is itself a system, whose architecture may
need to be described
For a large system, sample components include processes, threads, databases, dynamic or
static link libraries, CORBA or COM objects, or Enterprise Java Beans.
For a small system implemented in a single executable, sample components include
objects and classes if using an object–oriented language, functions in a function–oriented
language, and rules in a rule language.
(The subsections of this section are highly dependent upon the size of the system, the
chosen representation language to, and the architectural style.)
3.1 Structure
Describe the hardware and software components of the system.
Describe the architecture style(s) used & any constraint that the architecture style(s)
imposes.
1.3.1 Hardware Model
Describe the hardware components of the system or the hardware components on which
this system will run; the classification of the hardware components; and the connections
among the instances.
Representation: specification in architecture notation/language, or UML Deployment
Diagram (UML Static–Structure & Collaboration Diagrams may be used if the UML tool
being used doesn’t support the full UML concept for the Deployment Diagram); glossary
to summarize terms.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
1.3.2 Software Model
Describe the software components of the system; the classification of the software
components; and the connections among the instances.
Representation: specification in architecture notation/language, or Component Diagram
(UML Static–Structure & Collaboration Diagrams may be used if the UML tool being
used doesn’t support the full UML concept for the Component Diagram) Diagrams;
glossary to summarize terms.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
1.3.3 Deployment Model
Describe the allocation of software components to hardware components.
Representation: specification in architecture notation/language, or UML Deployment
Diagram (UML Static–Structure & Collaboration Diagrams may be used if the UML tool
being used doesn’t support the full UML concept for the Deployment Model); glossary to
summarize terms.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
1.3.4 Component Class Descriptions
For each component class defined in the hardware and software models shown above,
provided detailed description.
3.1.4.1 Component X
(Repeat this section for each component)
3.1.4.1.1
Purpose
Describe the purpose of this class of component.
Representation: informal text.
3.1.4.1.2
Interface(s)
Describe the visible features (operations, attributes, parts) of the component class.
The visible features may be organized into related sets. Each set should be given a
unique interface name.
Representation: architecture description language, or UML Static–Structure Diagram.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.1.4.1.3
Parameters
Describe any parameters of the component class (e.g. classes of subcomponents).
Representation: architecture description language, or UML Static–Structure Diagram.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.1.4.1.4
Behavior
Describe behavior of the instances of this component class.
Representation: informal text, formal language (e.g. UML’s OCL), or UML Statecharts
Descriptions.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.1.4.1.5
Operational Characteristics
Describe execution characteristics (e.g. timing, security, LOS) shared by all instances of
the component class.
(How did we get this data?)
Representation: informal text, forms or table
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.1.4.1.6
Internal Architecture
For larger components or subsystems, may have hardware, software, and deployment
models.
For small components, this section is typically unnecessary.
Representation: see sections Error! Reference source not found.–Error! Reference
source not found..
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.1.4.1.7
Constraints
Including licensing
1.3.5 Component Descriptions
3.1.5.1 Component X
(Repeat this section for each component)
3.1.5.1.1
Purpose
Describe the purpose of this component.
Representation: informal text.
3.1.5.1.2
Classifier
Identify the classifier of this component.
3.1.5.1.3
Operational Characteristics
Describe execution characteristics (e.g. timing, security, LOS) of this particular
component.
Representation: informal text, or table
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.1.5.1.4
Internal Architecture
1.3.6 Connector Descriptions
3.1.6.1 Connector X
(Repeat this section for each connector)
3.1.6.1.1
Purpose
Describe the purpose of this connector.
Representation: informal text.
3.1.6.1.2
Interface(s)
Describe features of the connector that are the visible of the connector (e.g. expected
operations or messages).
The visible features may be organized into related sets. Each set should be given a
unique component role name.
Representation: architecture description language, or UML Static–Structure Diagram.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.1.6.1.3
Behavior
Describe behavior of the connector including message filtering, distribution, arbitration,
or adaptation performed, and any protocols enforced.
Representation: informal text or appropriate representations in architecture description
language or UML; protocols may be described using UML Sequence Diagrams.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.1.6.1.4
Operational Descriptions
Describe execution characteristics (e.g. timing, security, LOS) of this particular
connector.
Representation: informal text, or table
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.1.6.1.5
Constraints
3.2 Behavior
Describe how the components work with each other and with the actors to implement the
process activities in which the system participates.
Refines section Error! Reference source not found..
Representation: “stories”, UML Use–case Model (Use–case Diagrams and Descriptions)
with Interaction Diagrams or Activity Diagrams.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.3 Operational Characteristics
Qualities of this architecture.
Including performance, usability, and L.O.S.
(Do they achieve goals?)
3.4 Architectural Styles, Patterns & Frameworks
Describe any patterns or frameworks used in the system architecture
Representation: list of patterns and framework names with description of factors leading
to their selection.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
3.5 Rationale
Describe the rationale for architecture, inc. choice of architecture style(s), choice of
components, choice of patterns and frameworks.
4. Implementation Design
For each component class and connector in section Error! Reference source not found.,
describe how it will be implemented.
For components that will be implemented using COTS, limited the description to features
that must be known or used by developers to implement other components in the system.
4.1 Structure
Describe the elements that will be used to build the component.
For example, if using object-oriented technology (OOT) then the elements would be
objects and classes.
Representation: if using OOT then UML Static–Structure & Collaboration Diagrams;
glossary to summarize terms.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
4.2 Behavior
Describe how the parts of the component work with each other, with other components,
and with the actors to implement the process activities in which the system participates.
Representation: “stories”, UML Use–case Model (Use–case Diagrams and Descriptions)
with Interaction Diagrams.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
4.3 Operational Characteristics
Qualities of this implementation of component.
Including performance, usability, and L.O.S.
(Do they achieve goals for component?)
4.4 Patterns & Frameworks
Describe any patterns or frameworks used in the implementation of the component.
Representation: list of patterns and framework names with description of factors leading
to their selection.
Trade-offs:
Guidelines (577, UML, RUP, Architectural, Agile, XP, ROSE)
4.5 Rationale
Describe the rationale for implementation, inc. choice of implementation style(s), choice
of subcomponents, choice of patterns and frameworks.
C. Document Sections – COTS Adoption
1.
2.
3.
4.
Introduction
System Analysis
Assessment Details
Tailoring Description