Armstrong Bocast Integration of Systems Engineering and Software Development 2003-Libre

The Integration of Systems
Engineering and Software

Development
Based on the
Object-Oriented Approach to Software Intensive Systems
SPC-2003041-CMC
Version 01.00
April 2003
The Integration of Systems

Engineering and Software
Development
Based on the
Object-Oriented Approach to Software Intensive Systems
SPC-2003041-CMC
Version 01.00
April 2003
Jim Armstrong
Alex Bocast
SOFTWARE PRODUCTIVITY CONSORTIUM
SPC Building
2214 Rock Hill Road
Herndon, Virginia 20170-4227
Copyright 2003, Software Productivity Consortium NFP, Inc. Permission to use, copy, and distribute this material for any
purpose and without fee is hereby granted consistent with 48 CFR 227 and 252, and provided that the above copyright notice
appears in all copies and that both this copyright notice and this permission notice appear in supporting documentation. This
material is based in part upon work sponsored by the Advanced Research Projects Agency under Grant #MDA972-96-1-0005.
The content does not necessarily reflect the position or the policy of the U.S. Government, and no official endorsement should be
inferred. The name Software Productivity Consortium NFP, Inc. shall not be used in advertising or publicity pertaining to this
material or otherwise without the prior written permission of Software Productivity Consortium, NFP, Inc. SOFTWARE
PRODUCTIVITY CONSORTIUM NFP, INC. MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE
SUITABILITY OF THIS MATERIAL FOR ANY PURPOSE OR ABOUT ANY OTHER MATTER, AND THIS MATERIAL
IS PROVIDED WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND.
CONTENTS
ACKNOWLEDGMENTS .......................................................................................................... IX
EXECUTIVE SUMMARY ........................................................................................................ XI
1.
2.
INTRODUCTION ................................................................................................................1
1.1
Scope.............................................................................................................................1
1.2
Audience .......................................................................................................................1
1.3
Organization .................................................................................................................1
1.4
Typographic Conventions.............................................................................................2
INTEGRATING SYSTEMS ENGINEERING AND SOFTWARE DEVELOPMENT3

2.1
Introduction ..................................................................................................................3
2.2
Systems Engineering ....................................................................................................3

2.2.1 Technical Activities ....................................................................................................... 4
2.2.2 Management Activities.................................................................................................. 5
2.2.3 Distinguishing Attributes............................................................................................... 5
2.3
Software Development .................................................................................................6

2.3.1 Scope of OOASIS.......................................................................................................... 6
2.3.2 OOASIS Inputs and Related Activities External Activities .......................................... 9
2.4
Mapping Systems Engineering to Software Development.........................................10
2.5
Interaction Guidance...................................................................................................14
2.5.1
2.5.2
2.5.3
2.5.4
2.6
Top-Level Definition/Define System Requirements ................................................... 14

Lower-Level Interactions/Software Development....................................................... 16
General Interface Issues............................................................................................... 18
SE and UML................................................................................................................ 19
Summary.....................................................................................................................20
3.
APPLYING IDEF METHODS TO DEVELOP OOASIS INFORMATION

REQUIREMENTS .............................................................................................................21
A.
RELATING IDEF METHODS TO OOASIS..................................................................23

A.1 Part I. Applying the IDEF0 Method ...........................................................................23
iii
Contents
A.1.1 Overview of Method.................................................................................................... 24
A.2 Results of this Method ..............................................................................................111

A.2.1 Stakeholders............................................................................................................... 111
B.
SANTA NARIDA BACKSTORY ...................................................................................117

B.1 Santa Narida and the Santa Narida Ocean Observation Region...............................117
C.
OOASIS NODE-DEVICE-CONNECTOR DIAGRAM ...............................................123
D.
NATIONAL DATA BUOY CENTER ............................................................................125

D.1 Standard Meteorological Data ..................................................................................125
D.2 Detailed Wave Summary ..........................................................................................126
D.3 Acoustic Doppler Current Profiler (ADCP) .............................................................126
D.4 Continuous Winds ....................................................................................................126
D.5 Spectral Wave Data ..................................................................................................127
D.6 Water Level ..............................................................................................................127
D.7 Marsh-McBirney Current Measurements .................................................................127
E.
APPLYING SADT ACTIVATION RULES TO IDEF0 ACTIVITY ANALYSIS.....129

E.1
Activation Rules .......................................................................................................129
E.2
Conditional Expressions ...........................................................................................129
E.3
Preconditions ............................................................................................................130
E.4
Postconditions...........................................................................................................131
E.5
Writing Rule Sets......................................................................................................132
E.6
Incorporating Activation Rules in a Diagram...........................................................135
E.7
Revisiting Marca and McGowans Example............................................................136
LIST OF ABBREVIATIONS AND ACRONYMS .................................................................139
iv
FIGURES AND DIAGRAMS

Figure 1. OOASIS Model of System and Software Interaction.................................................................... 3
Figure 2. OOASIS Software Development Flow.......................................................................................... 6
Table 1. Systems Engineering/Software Interactions ................................................................................. 10
Figure 3. Top-Level Interactions ................................................................................................................ 14
Figure 4. Mid-Level Interactions ................................................................................................................ 17
Diagram 1. SWM/A0 (Present Weather) .................................................................................................... 28
Diagram 2. STW/A0 (Produce Tsunami Warnings) ................................................................................... 29
Diagram 3. SIS/A0 (Research Ocean Weather Phenomena) ...................................................................... 29
Diagram 4. SRP/A0 (Plan Ship Itinerary)................................................................................................... 30
Diagram 5. SWF/A0 (Forecast Weather).................................................................................................... 31
Diagram 6. SNW/A0 (Increase Puerta Oveida Market Share).................................................................... 31
Diagram 7. SSP/A0 (Deliver Data)............................................................................................................. 32
Diagram 8. SNM/A0 (Maintain Buoys)...................................................................................................... 32
Diagram 9. RTP/A-1=AKB5.1 for Weather Media Stakeholder ................................................................ 37
Diagram 10. RTP/A-1=AKB5.2, Adding Environment Stakeholder ......................................................... 38
Diagram 11. RTP/FEO1: Parallel Decomposition Fragment...................................................................... 39
Diagram 12. RTP/A-1=AKB5.3, Adding GOOS Satellite System............................................................. 40
Diagram 13. RTP/FEO2, Ocean Observation Fragment............................................................................. 40
Diagram 14. RTP/A-1=AKB5.4, Adding Tsunami Warning System......................................................... 41
Diagram 15. RTP/A-1=AKB5.5, Adding National Weather Service ......................................................... 42
Diagram 16. RTP/A-1=AKB5.6, Adding Institute Scientist....................................................................... 43
Diagram 17. RTP/A-1=AKB5.7, Additional Clarification of Behaviors.................................................... 44
Diagram 18. RTP/FEO3, Relating Observing to Forecasting..................................................................... 45
Diagram 19. RTP/FEO5, Environmental Exchange Example .................................................................... 46
Diagram 20. RTO/A-1=AKB5, Operations Stakeholders........................................................................... 47
Figures and Diagrams
Diagram 21. RTO/A1 Measure Ocean Observables .................................................................................. 48

Diagram 22. RTT/A-1, Training Stakeholder ............................................................................................. 49
Diagram 23. RTP/A-1 (Stakeholder Context of Meteorological Product Generation)............................... 50
Diagram 24. RTP/A-0 (Context of Meteorological Product Generation)................................................... 51
Diagram 25. RTP/A0 (Generate Meteorological Products) ........................................................................ 53
Diagram 26. RTP/A1 (Measure Ocean Weather Characteristics)............................................................... 54
Diagram 27. RTP/A11 (Control Data Collection) ...................................................................................... 55
Diagram 28. RPT/A12 (Measure Observables) .......................................................................................... 55
Diagram 29. RTP/A13 (Transmit Collected Data) ..................................................................................... 56
Diagram 30. RTP/A2 (Provide Datasets).................................................................................................... 57
Diagram 31. RTP/A4 (Forecast Weather)................................................................................................... 58
Diagram 32. ATP/A-1 (Stakeholder Context of Meteorological Product Generation)............................... 59
Diagram 33. ATP/A-1 (Context of Meteorological Product Generation)................................................... 60
Diagram 34. ATP/A0 (Generate Meteorological Products)........................................................................ 61
Diagram 35. ATP/A1 (Measure Ocean Observables)................................................................................. 62
Diagram 36. ATP/A11 (Control Data Collection) ...................................................................................... 63
Diagram 37. ATP/A12 (Measure Observables) .......................................................................................... 63
Diagram 38. ATP/A13 ( Transmit Collected Data) .................................................................................... 64
Diagram 39. ATP/A2 (Generate Meteorology Products) ........................................................................... 65
Diagram 40. ATP/A21 (Generate Datasets)................................................................................................ 66
Diagram 41. ATP/A211 (Save Observations)............................................................................................. 67
Diagram 42. ATP/A212 (Create Datasets).................................................................................................. 68
Diagram 43. ATP/A213 (Retrieve Datasets) .............................................................................................. 69
Diagram 44. ATP/A23 (Forecast Weather) ................................................................................................ 69
Diagram 45. ATP/A3 (Distribute Products) ............................................................................................... 70
Diagram 46. ATP/A31 (Fulfill Orders)....................................................................................................... 71
Diagram 47. ATP/A32 (Stage Products)..................................................................................................... 72
Diagram 48. ATP/A33 (Post Products)....................................................................................................... 72
Diagram 49. ATP/A34 (Email Products) .................................................................................................... 73
Diagram 50. ATP/A0 (Generate Meteorological Products) with System Agents....................................... 74
Diagram 51. ATP/A11 (Control Data Collection) with System Controller................................................ 75
vi
Diagram 52. ATP/A13 (Transmit Collected Data) with System Controller ............................................... 76
Diagram 53. ATP/A211 (Save Observations) with Data Engineer............................................................. 76
Diagram 54. ATP/A212 (Create Datasets) with Data Engineer.................................................................. 77
Diagram 55. ATP/A213 (Retrieve Datasets) with Product Engineer.......................................................... 77
Diagram 56. ATP/A3 (Distribute Product) with Fulfillment Technician ................................................... 78
Diagram 57. RTO/A-1 (Stakeholder Context of Routing Product Generation).......................................... 79
Diagram 58. RTO/A-0 (Context of Routing Product Generation).............................................................. 80
Diagram 59. RTO/A0 (Generate Routing Products)................................................................................... 81
Diagram 60. RTO/A2 (Generate Routing Products)................................................................................... 82
Diagram 61. RTO/A23 (Propose Itineraries) .............................................................................................. 83
Diagram 62. ATO/A-0 (Context of Routing Product Generation) ............................................................. 83
Diagram 63. ATO/A0 (Generating Routing Products) ............................................................................... 84
Diagram 64. ATO/A2 (Generating Routing Products) ............................................................................... 85
Diagram 65. ATO/A23 (Propose Itineraries).............................................................................................. 85
Diagram 66. ATO/A0=AKB11 (Generate Routing Products) .................................................................... 86
Diagram 67. ATO/A2=AKB9 (Generate Routing Products) ...................................................................... 87
Figure 5. Conventions for Marking Activities WRT Use Cases................................................................. 88
Diagram 68. ASU/A0 (Generate Meteorological Products) ....................................................................... 89
Figure 6. Use Case Analysis: Measure Ocean Observables........................................................................ 89
Diagram 69. OSU/A0=AKB24 (Generate Meteorological Products)......................................................... 90
Figure 7. Use Case Analysis: Run Weather Models ................................................................................... 90
Diagram 70. OSU/A3=AKB26 (Distribute Products) ................................................................................ 91
Diagram 71. OSU/A0=AKB25 (Generate Meteorological Products)......................................................... 92
Figure 8. Use Case Analysis: Stage Products ............................................................................................. 93
Figure 9. Use Cases Analysis: Maintain Meteorological Data ................................................................... 94
Diagram 72. OSC/A2 (Generate Routing Products) ................................................................................... 94
Figure 10. Use Case Analysis: Propose Itineraries ..................................................................................... 95
Diagram 73. OSC/A0 (Generate Routing Products), Final Markup ........................................................... 96
Figure 11. OOASIS System Use Case Diagram ......................................................................................... 97
Figure 12. First NDC Transform on ONA/A11 .......................................................................................... 98
Figure 13. Second NDC Transformation on ONA/A11.............................................................................. 99
vii
Figure 14. First NDC Transformation on ONA/A1 .................................................................................... 99

Figure 15. Second NDC Transformation on ONA/A1.............................................................................. 100
Figure 16. Third NDC Transformation on ONA/A1 ................................................................................ 100
Figure 17. First NDC Transformation on ANA/A21 ................................................................................ 101
Figure 18. Second NDC Transformation on ONA/A21............................................................................ 101
Figure 19. First NDC Transformation of ANO/A23................................................................................. 102
Figure 20. First NDC Transformation of ONA/A2................................................................................... 102
Figure 21. Second NDC Transformation of ONA/A2 .............................................................................. 103
Figure 22. First DNC Transformation of ONA/A3................................................................................... 103
Figure 23. First NDC Transformation for ONA/A0 ................................................................................. 104
Figure 24. Final NDC Transformation for ONA/A0 ................................................................................ 105
Figure 25. First NDC Transformation of ONB/A2................................................................................... 106
Figure 26. Second NDC Transformation for ONB/A2 ............................................................................. 107
Figure 27. Third NDC Transformation for ONB/A2 ................................................................................ 107
Figure 28. First NDC Transformation for ONB/A0.................................................................................. 108
Figure 29. First NDC Information Integration.......................................................................................... 109
Figure 30. Second NDC Information Integration ..................................................................................... 110
Figure 31. OOASIS NDC Diagram .......................................................................................................... 111
Diagram 74. OCD/A-0 (Context of Meteorological Product Generation)................................................ 113
Figure 32. OOASIS System Use Case Diagram for Buoy Case Study..................................................... 114
Figure 33. OOASIS NDC Diagram for Buoy Case Study ........................................................................ 115
viii
ACKNOWLEDGMENTS
The authors wish to thank those who contributed to this report. Many hours have been spent discussing
technical points to reach resolution on several significant areas of issue between the systems engineering
and software development communities.
Contributors and Internal Reviewers: Sarah Sheard, Rich McCabe, and Mike Polen
External Reviewers: Dr. Ralph Freeman
Acknowledgments
This page intentionally left blank.
EXECUTIVE SUMMARY
Current systems engineering and software development methods have been separately created with little
regard to their interfaces. This report takes an initial look at this interface. It identifies many of the critical
aspects of the interface and proposes ways in which they may be addressed.
The report addresses the systems engineering and software development interface in general terms that
are believed to be applicable to all software development. However, specific examples and discussion
address object-oriented software development that uses Unified Modeling Language (UML). Since UML
does not specify a method, the report is based on the Object-Oriented Approach to Software-Intensive
Systems (OOASIS) method. OOASIS provides practice level guidance for application of UML with
specific steps and decisions identified. The report identifies the systems engineering activities that provide
information to the OOASIS activities or uses information from them. It also identifies guidance for
interaction between the activities on both sides of the interface to avoid some of the most critical
problems.
The report does not fully define all interface issues nor does it define the details of a method for
performing both disciplines across the interface. Also, the treatment covers those requirements that relate
to the behavior of the systems and the software. Not addressed are those systems requirements that affect
other areas of performance such as reliability, safety, survivability, etc. Some examples of systems
engineering studies that are beyond the scope of UML related methods are given but their interface
mechanisms are not fully developed. These areas should be the subject of further study.
Key points of this report are:
Systems engineering and software development techniques have been developed to address
different specific issues and concerns. However, they do overlap and the overlap increases as the
proportion of software content increases.
Information that is common to both areas must be identified and properly exchanged.
Systems engineering and software development should be conducted in parallel and integrated.
Doing them sequentially in an over-the-wall manner generates severe problems.
Executive Summary
xii
1. INTRODUCTION
1.1
SCOPE
This report addresses the need for and nature of the interface between systems engineering and software
development. While providing guidance of a general nature that is applicable to any software
development method, it uses the specific examples of object-oriented development as defined in the
Consortiums Object-Oriented Approach to Software-Intensive Systems (OOASIS). The treatment covers
those requirements that relate to the behavior of the systems and the software. Not addressed are those
systems requirements that affect other areas of performance such as reliability, safety, survivability, etc.
Some examples of systems engineering studies that are beyond the scope of OOASIS are given but their
interface mechanisms are not fully developed.
It is recognized that many approaches have been documented to use the software-oriented techniques of
the Unified Modeling Language (UML) to accomplish systems engineering. While these methods are
recognized to have benefit in a system that is almost totally software in content, there remain systems
engineering activities that these techniques do not address. The Object Management Group has released a
Request for Proposal to add capabilities to UML to more thoroughly address the needs of systems
engineering and reduce the gap. However, that effort recognizes that the proposed changes will not
completely cover systems engineering and there will remain a need to define the interface between the
two disciplines. This report addresses the overall activities of systems engineering and the information
generated, regardless of the specific notation used.
1.2
AUDIENCE
This report is directed to systems engineering practitioners, software developers and others who address
the interface between the two disciplines. The report focuses on but is not limited to the interface between
systems engineering methods and software methods using Unified Modeling Language (UML) with
specific attention to the methods defined in the OOASIS.
1.3
ORGANIZATION
Section 1 Introduction. Provides the scope of the report.
Section 2 Integrating Systems Engineering and Software Development. Provides the
background and approach at the process and method level
2.1 Introduction. Defines the overall interface to be addressed
1. Introduction
1.4
2.2 Systems Engineering. Defines the activities of systems engineering and those that will be
included in this report
2.3 Software Development. Reviews the OOASIS method for use of UML
2.4 Mapping. Defines the interactions between the two disciplines
2.5 Guidance. Explains the interactions and provides guidance for both sides in program
development
Section 3 Case Study. Provides specific guidance for interfacing the OOASIS UML inputs with
systems engineering analysis using IDEF
TYPOGRAPHIC CONVENTIONS
This report uses the following typographic conventions:

Serif font.....................General presentation of information
Bold Italic...................Bulleted lists and run-in headings.
2. INTEGRATING SYSTEMS ENGINEERING AND

SOFTWARE DEVELOPMENT
2.1
INTRODUCTION
time
The model used in this discussion is an interactive relationship between systems engineering and software
development. Requirements and architecture decisions are arrived at by concurrence rather than by overthe-wall direction. Also, software development is embedded within the overall requirements analysis
activity and as part of the systems design. While this is not a unique or original approach, neither is it as
commonly practiced as it should be.
System
Requirements
Analysis
System Design
Software
Architecture
Physical
Architecture
Figure 1. OOASIS Model of System and Software Interaction
The discussions that follow will first define the systems engineering and software development activities
that occur in this model using a general definition of systems engineering and the OOASIS method of
software development. Next, an information map will be presented correlating the outputs of systems
engineering activities with the inputs defined in the OOASIS method. Finally, guidance is provided for
the interactions at different levels of systems definition.
2.2
SYSTEMS ENGINEERING
Systems engineering has been defined in many ways. The definitions include systems engineering as a
process, as a group of people, as a step in the life cycle, as a set of analyses, as coordination functions, as
an approach to be taken by any engineer, and even as a way of life to be adopted by people who arent
engineers. In most descriptions of systems engineering there are both technical and management
activities. The activities following were named in at least two of several references, although in a few,
2. Integrating Systems Engineering and Software Development
notably ISO 9000-2000, these were not specifically called systems engineering activities. References
include (Sheard 1996) (CMMI) (SE-CMM)1 (IEEE 1220) (EIA 632) (DSMC SE Handbook) (ISO
9000-2000).
2.2.1
TECHNICAL ACTIVITIES
This report addresses the technical activities of systems engineering in defining and analyzing the
requirements and top-level design or architecture of a system. It is more than just the requirements
development phase of a software project. The technical activities include:
Problem Definition. Discovering system requirements and derived requirements, stating the
problem, eliciting customer need, analyzing the complexity of the problem space, developing the
concept of operations, determining system scope and boundaries, defining and decomposing
functionality, determining performance measures including Measures of Effectiveness and
Technical Performance Measures, developing subsystem specifications, including software
specifications, validating requirements, tracking requirements and design issues to closure.
Architecting. Designing the system, exploring alternative system concepts, system or product
integration, defining and designing external and internal interfaces, and system modeling.
Analysis. Performing analyses including performing trade studies with appropriate sensitivity
analysis, reliability analysis, survivability analysis, failure mode and effects analysis,
electromagnetic compatibility and survivability analysis, and other system analyses that are
specific to the system domain such as orbit analysis, thermal analysis, bandwidth analysis, signal
strength analysis, memory usage, system reaction time analysis, even cosmic particle interference.
Allocation. Maintaining traceability between requirements, behavior, and systems elements.
Integration. Integrating the system components as well as integrating the system into the external
environment and transition to use.
Verification and Validation. Prescribing a verification and validation program that will show the
system has been built correctly and that the correct system was built. Prescribing system and
lower-level tests to prove the system design.
Integrated Product Development. Including production, support logistics, and operations in all
development activities. Ensuring appropriate requirements and design features are included,
appropriate tests are done, and the additional materials such as users manuals and system
training are available
From the early stages of analysis, often referred to in systems engineering as the concept exploration
stage, these multiple activities of systems engineering become intermixed. While requirements tend to
drive design, available technology often influences requirements. The analyst suggests requirements and
design decisions for alternative concepts of operation and comparatively evaluates the alternatives. Since
the technical knowledge of what is achievable resides in the design disciplines such as software
CMMI and SE-CMM are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
development, an interactive approach between the systems engineering and all design disciplines is
essential.
2.2.2
MANAGEMENT ACTIVITIES
The management activities are included for reference but do not provide the types of information that is
defined as inputs to the OOASIS method. Management activities include:
2.2.3
Planning and Tracking. Management of technical tasks, manage product line evolution, manage
technical support environment, coordinate technical groups internally, with customer, and with
suppliers
Risk. Managing system risks, including risk identification, risk assessment, risk mitigation
recommendations, risk mitigation planning and funding, and finally, tracking of the risk profiles
to closure
Other. Additional management tasks include conducting design reviews, configuration
management, management of product data, systems engineering processes, measurement,
documentation, support new business in developing concepts for proposal opportunities, and
provide and receive the appropriate training in systems engineering topics, including
understanding of the systems and their domains.
DISTINGUISHING ATTRIBUTES
Two significant attributes of systems engineering distinguish it from software development or the
development of any systems component. These are broader scope of responsibility and an external view.
2.2.3.1 Broad Scope
Systems engineering is, by nature, responsible for any and all components and their technologies. It must
also integrate the concerns of various functional areas such as manufacturing and logistics support and
technical specialties such as reliability, safety, security, survivability, and life-cycle cost. Most of these
areas have well established analysis techniques. It is the unique role and responsibility of systems
engineering to interface among these functional areas and their techniques, including software
development.
2.2.3.2 External View
Where each component development effort, including software, has primary responsibility for the
activities internal to that component, systems engineering has the responsibility for the external view.
This is particularly true at the system level where systems engineering has the primary responsibility for
external interfaces and assuring that the system will perform as intended within the external environment.
As will be discussed later, this is one area where the application of use cases has limited value and an
interface with other analysis techniques must be defined.
2.3
SOFTWARE DEVELOPMENT
The initial tasks in any software development include definition of the requirements and the software
architecture. The following steps are described in the context of the Consortiums OOASIS and refer to
the use of Unified Modeling Language techniques. However, they are applicable to any software
development in that the actions and decisions defined are required regardless of specific method. Further,
the overall interaction with systems engineering as provided in later sections also remains valid.
OOASIS provides pragmatic guidance to the practicing engineer for systematically applying an OO
methodology for requirements capture, analysis, and design of a software-intensive system. The
expectation is that use of OOASIS will increase quality, reduce cycle time, and reduce maintenance cost
for developed systems over approaches that do not explicitly integrate systems and software engineering
and/or employ alternative (non-OO) techniques.
2.3.1
SCOPE OF OOASIS
OOASIS does not attempt to address all issues in systems and software engineering exhaustively. Instead,
OOASIS concentrates on a software perspective of system requirements and design, appropriate for
engineering a software-intensive system. Particularly in a predominantly software system, that
perspective includes a definition of behavioral requirements at the system level. The following paragraphs
describe the OOASIS technical activities. Figure 2 shows the OOASIS Software Development Flow.
Define
Capture sys behavioral
reqs
Sys Reqs
Sys Use Cases
Realize use cases

Define
Sys SW Arch
Sys SW
Arch
Define sys SW allocation
Elaborate sys use cases
Elaborated Sys
Use Cases
Elaborate architecture
Sys SW Arch
Design
Node
SW
Define concurrency
Thread Models
Define statecharts
Class Statecharts
and etc. from
previous tasks
Implement software
Figure 2. OOASIS Software Development Flow
2.3.1.1 Define System Requirements

The first activity is translating broad, top-level conceptions of system goals and use into specific
behavioral requirements, elicited and captured via use cases. This includes explicitly noting volatilities
due to unresolved requirement choices or other alternate conceptions of the system, and incorporating
these into System Use Cases. This effort relies on broader needs analyses and studies that have resulted in
a system concept and scope sufficient to begin software definition.
2.3.1.1.1 Capture System Behavioral Requirements
This task either receives the top-level requirements definition as a Summary Use Case or creates it if not
available. The Summary Use Cases are then translated into a prioritized set of system requirements
expressed as System Use Cases. The structuring of requirements into use cases is intended to:
Present requirements in a way that is easy for users, customers, and other stakeholders to
understand and review
Decompose the problem into more manageable pieces
Organize the requirements into a more structured form
Avoid unnecessarily constraining the System Software Architecture
The decomposition of requirements by use case is done from the stakeholders' perspective. Each use case
provides a focus on closely related requirements. As a result, multiple analysts may concurrently
elaborate different use cases.
2.3.1.2 Define System Software Architecture
As the requirements are defined, the software developer will create a preliminary System Software
Architecture based on the design constraints implied by the system behavioral requirements. Software
functionality is decomposed into static elements (a class hierarchy) and their dynamic (runtime)
interaction defined. Initially, orient this decomposition by designing in flexibility, especially to address
volatilities enumerated in the System Use Cases. Define an initial deployment for the objects in the
software architecture across the system's physical architecture using the Node-Device-Connector (NDC)
Diagram (Appendix C.) making adjustments and additions to the software architecture as necessary.
Identify additional failure scenarios in Elaborated System Use Cases by analyzing how elements of this
combined hardware and deployed software architecture interact to support the System Use Cases. Adjust
the software architecture and its deployment for performance and other concerns (such as commercial and
legacy software to be incorporated into the system, as enumerated in the OTS Software Components) and
include additional details visible at the system level of the architecture.
2.3.1.2.1 Realize System Use Cases
At this point in OOASIS behavioral requirements are captured as System Use Cases. It is now necessary
to make explicit the essential design implications or constraints inherent in the System Use Cases. This
will yield an OO System Software Architecture. The goal of this activity is to take the first step toward
that objective: for each System Use Case, define classes representing the important abstractions in the
problem environment (static model). Then combine these static models for each use case into one
comprehensive static architecture. Finally, define the interactions among these objects for each use case
7
(dynamic architecture). Together, the static and dynamic system designs make up the initial System
Software Architecture.
2.3.1.2.2 Define System Software Allocation
Allocate the classes to significant nodes for runtime deployment. This task may identify necessary
modifications to the existing software architecture. Further adjustments may be necessary to address
performance concerns. Also, add (and determine the deployment for) other supporting classes (e.g.,
device interface classes).
2.3.1.2.3 Elaborate System Use Cases
Having decided what objects to deploy on which system Nodes, enough decisions have been made about
the internal system design to elaborate the System Use Cases. Significant nodes and devices from the
NDC Diagram become participants in performing the System Use Cases. With this white box approach to
the system, you can further usage details added and more failure conditions and use case alternate courses
discovered.
2.3.1.2.4 Elaborate System Software Architecture
Based on the insight provided by the Elaborated System Use Cases, the System Software Architecture can
now be completed. This should account for possible failure conditions across all system usage scenarios.
What remains is to add details about class operations and relationships. It is also appropriate to estimate
timing budgets for nodes and operations involved in performance-sensitive usage scenarios.
2.3.1.3 Design Node Software
With classes and their interactions well defined and objects having been deployed among the significant
nodes, this stage of OOASIS concentrates on the interactions of objects within a given (type of) node and
can proceed independently for different nodes. First, define the concurrency within each node. Finally,
create Class State charts for classes having complex state behavior.
2.3.1.3.1 Define Concurrency
This OOASIS task is optional and may be tailored out when no performance or reliability requirements
challenge the system design. In this part of OOASIS, define the concurrency of the software in each node.
The treatment of concurrency necessarily varies somewhat depending on the underlying
platform/technology used to implement concurrency. Therefore, OOASIS offers alternate steps relevant
to each type of platform.
Introduce Prioritizable Concurrent Elements (PCEs) into your design for:
Temporal correctness (response time, device characteristics)

Clarity (cohesion/interdependency of interacting objects)
Reliability (distinguishing critical functions or, conversely, background functions)
OOASIS guides a developer to add concurrency only as justified by the requirements, with full
consideration to its potential disadvantages of:
Increased complexity
Reduced flexibility in design
Increased overhead
In light of these drawbacks, OOASIS encourages particular care to understand the system's asimplemented performance characteristics under its actual usage profile before attempting to fix presumed
performance or timing problems with additional concurrency.
2.3.1.3.2 Define Statecharts
This OOASIS task is also optional. In complex, real-time systems or those with stringent dependability or
safety concerns, it is beneficial to create a more detailed dynamic model of the more complex classes
(especially with multiple, interacting Prioritizable Concurrent Elements). To represent the objects in these
classes as finite state machines, develop statecharts for each class. These statecharts will explicitly capture
all states and state transitions of objects, including interactions among objects.
2.3.1.4 Implement Software
Implementation is currently outside the scope of OOASIS. However, this section offers some general
guidance that follows directly from previous OOASIS activities. The combination of the work products
listed as inputs to this activity should suffice as a specification to implement system code.
2.3.2
OOASIS INPUTS AND RELATED ACTIVITIES EXTERNAL ACTIVITIES
OOASIS presumes other project-related activities that precede and run in parallel with OOASIS activities.
These activities generate the work products that are inputs to the OOASIS method. Their relationship to
each OOASIS activity is shown in Table 1 in the following section. The OOASIS method also addresses
how to develop the information in cases where external activities do not exist. The following are the
primary inputs to the method:
Stakeholders
To-Be Process (optional)
As-Is Process (optional)
Summary Use Cases
Context Diagram
NDC Diagram
OTS Software Components
Hardware Interfaces
2.4
OTS Software Interfaces
MAPPING SYSTEMS ENGINEERING TO SOFTWARE DEVELOPMENT
Table 1 maps systems engineering activities described in Section 2.2 and their products to the inputs and
activities in software development as described in Section 2.3. The initial systems engineering activities
are predominantly part of problem definition such as needs analysis, requirements analysis, and functional
analysis. The entry for program alternatives is a combination of architecting design, trade studies analysis
and management planning. The emphasis shifts to architecting and integration with increasing problem
definition and analysis details continuing.
Basic inputs to OOASIS are in bold. Additional inputs described in the OOASIS method are also listed
and their sources in systems engineering activities identified. Although the basic mapping indicates the
production of inputs to the software process, it is not intended that this be a one-way interface. In all
cases, the decisions must be made in collaboration.
Table 1. Systems Engineering/Software Interactions
OOASIS SE
Task
OOASIS SW
Output
Input
Task/Subtasks
Output
Define System Req

Needs Analysis
Statement
of Stakeholders,
Needs, Concept Summary Use
of Operations
Case, Context
Diagram
Stakeholders
Obtain Summary Use System

Case
Cases
Identify Actors
Functional
Analysis
Top
level Goals (top level
functions
verb
noun
objectives)
Identify
Cases
Functional
Analysis,
Requirements
Analysis
and
Allocation
As-is
process
Decomposed
T
o-be
process
functions and
Text details
performance
requirements
Alternate
success paths
Detail
Cases
Functional
Failure Analysis
Functional
failure modes
10
Potential
problems
System Use
System
Alternatives
Use
Use
Requirements
analysis
Volatility
estimates
Potential
requirements
changes
Program
Alternatives
Capability
sequence
Release
sequences
Identify
Key Requirements
Requirements
Priorities
Variations
System Priorities
Prioritize System Use

Cases
Define SW Arch
System
Cases
Use Realize System Use Cases
System
Arch
SW
Define actor IF classes
actor
classes
IF
Find persistent entity persistent

classes
entity classes
Functional
analysis
allocation
Allocated
and functional
description
Model the Use Cases as Interaction

Interaction Diagrams
Diagrams
Combine classes into Class Diagram

single class diagram
Combine
classes
redundant
Generalize classes
Add composition
Add associations
Evaluate
variations
Allocation and Systems
Architecture
System
Architecting
System
NDC, OTS SW Define
Deployment
Components
and Interfaces
against
SW System
SW
Deployment
11
Obtain NDC & OTS

SW info
Deploy
Classes
Actor
IF
Deploy
Persistent
Entity Classes
Deploy
OTS
components
SW
Add Manager Classes

Elaborate
classes
System Design, Bandwidth and Bandwidth and
processing
processing
Requirements
requirements
analysis,
and requirements
allocation
Detailed
and functions,
Functions
node
System
Use Elaborated
System
Use
Cases
Expand Main Scenario

per
Functional
Analysis,
Failure analysis
Alternate paths,
failure modes
Expand
courses
Requirements
analysis, system
design
alternatives
Potential
changes
and
alternative
technologies
Expand variations
12
IF
Redeploy
for Performance
Performance Concerns
adjusted SW
Arch
Sys Use Cases, Elaborate

NDC, Sys SW Cases
Depl
Models,
Sys SW Arch
Functional
Analysis
allocation
Actor
Alternate
Systems Design HW interfaces

and Integration
Sys SW Depl Elaborate System

Models, Sys SW Architecture
Arch, Elab Sys
Use Cases
SW Elaborated
System
SW
Architecture
Realize
Elaborated New classes
System Use Cases
Functional
analysis,
N2,
requirements
allocation
Operations,
parameters,
returns,
conditions,
dependencies
Identify Operations
Operation
descriptions
Check Classes
Elaborate Associations
Requirements
analysis,
timelines,
allocation
Timing budgets
Assign Timing Budgets
NDC, Sys SW Define Threads

Depl
Models,
Sys SW Arch,
Elab Sys Use
Cases
Functional
analysis
threads
Timing
info,
system
alternatives,
cost
of
Allocation, Cost alternatives
trades
State diagrams
Systems Design
Hardware
interfaces
Threads
Define initial thread set
Performance analysis
Functional
analysis,
timelines,
Functional
Analysis
??
Define state charts
HW Interfaces
Class
charts
state
Design Node SW
13
2.5
INTERACTION GUIDANCE
The most significant, and least novel, point is that systems engineering and software development cannot
be done properly in series. As with any system component, any attempt to fully define the system absent
input from the software component or to unilaterally push down requirements or design decisions is
doomed to failure. As a consequence, the interface relies on parallel travel into the depths of the problem
and solution and constant communication between the parties. This was depicted in Figure 1 and a key
element of Table 1.
2.5.1
TOP-LEVEL DEFINITION/DEFINE SYSTEM REQUIREMENTS
At the highest level, the requirements definition must be done in a cooperative manner by the systems
engineering and software activities. On the system engineering side, this information will be included in
various products including needs statements, concepts of operations or top-level functional analysis. This
phase in OOASIS is Define Systems Requirements. The primary inputs identified for OOASIS software
development are identification of stakeholders, a summary use case or collection of system use cases or
goals that provide the information, and a context diagram. For systems that are principally software,
these two views may be near identical. For systems with more hardware involved, some preliminary
discussion of possible allocations will be necessary. In either case, the most likely difference in viewpoint
will be the extent to which the external processes need to be modeled and included in a complete analysis.
Needs
Ext I/F
Concept of Operations
Who
What
Where
Why
When
How much
How many
How well
With what others
..
Goals
StakeHolders
System
Context Diagram
Business Process
Environment
Readings
System
Samples
Analysis
Usage Reports
Maintenance
Requests
Summary Use Case

Public User Download Data
Maintenance
<<depends>>
<<depends>>
Collect Data
Scientist Analyze Data
<<depends>>
Admin
View Report
Environment
Figure 3. Top-Level Interactions
2.5.1.1 Stating the Problem

The requirements as provided are not always optimal. Sometimes customers request a particular design
solution because that is the design solution with which the customer is familiar, but the systems engineer
knows or suspects some other solution may meet the need better. Design parameters in specifications
have been so common in the past, in fact, that the government has undergone a large and expensive effort
14
to move toward performance specifications. The job of stating the real problem is not easy, as it involves
considerable thought about the suggested solution, backing off to the need that the solution will or
probably is intended to satisfy, and looking at what parameters of the problem are likely to be the most
critical or most problematic to address, as they will be the key drivers for the system to be built.
2.5.1.2 Eliciting Customer Need
Often customers know they have a problem, but arent quite sure what technology exists to solve it. Nor
do they know what the technology is capable of solving other than the obvious problem. As a result,
requirements written solely by customers have a tendency to be incomplete, in the sense that building a
system to meet the requirements and no more and no less will not in fact make the customer happy.
(There have been many cases of this in the development of software systems). Experienced systems
engineers know that it is important to actively elicit what the actual needs are. This can be accomplished
through structured and formal sessions with users, asking why requirements are specified in order to get
at the underlying need, showing prototypes to the customers and asking for feedback, or keeping the
customer intimately involved in systems engineering activities throughout the life cycle. Additionally,
needs should be elicited by reviewing the operational concept and operational scenarios (see below). In
this way, the systems engineers ensure that the requirements will completely and accurately capture what
is actually needed by the official customer, usually a contracting organization, and by the end users.
A needs analysis, business case analysis, mission analysis or other similar analysis establishes the basic
nature and rationale for the system to be built. The analysis identifies Stakeholders and their strategic
goals that the to-be-built system will help to satisfy that will define the basics of the Summary Use Case.
An analyst may establish quantitative "measures of effectiveness" for these strategic goals to help predict
and track whether the new system is achieving those goals. In a government project, a prior Mission
Statement or Request for Proposal may have predetermined the scope of analysis and much of the
information discussed here as initial inputs into OOASIS.
2.5.1.3 Concept of Operations
This task documents how any current system is used and how the new system is expected to be used in an
operational concept and operational scenarios. The generation of a concept of operations usually involves
the actual users of the current system. In some cases the customer creates an operational concept. Then
systems engineering must review and understand this work product and may provide comments and
questions to assure full understanding.
A proposed concept of operations, or its equivalent by any name, defines a single, cohesive vision of the
system to be built. The OOASIS method assumes the prior existence of that vision to initially sketch at
least the broad outlines of the system of interest, even if there are alternative system conceptions being
pursued and evaluated in parallel, and even if the system concept at hand has a number of unresolved
options or details. A particular Concept of Operations entails or suggests a specific To-Be Process.
Embedded within the To-Be Process are the interactions between the to-be-built system and the external
world that constitute the Context Diagram and Summary Use Case.
Whether or not a specific document is created called a Concept of Operations, the systems engineering
efforts must include a definition of how the system will be used and supported. One problem is that most
concept of operations documents emphasize the final system design. For the final version, this is
appropriate. However, the error that often occurs is to overemphasize the solution on the first version.
15
This approach will further cause the early forcing of hardware architecture limitations on the software
development.
To correct this, the initial iterations should focus on the scenarios defining what the system is supposed to
accomplish in which situations and how it will be applied to operations. This will support the
development of use cases without unnecessarily restricting the software architecture.
2.5.1.4 Requirements Analysis
Requirements analysis will define the priorities particulars of how well the systems is to perform. It will
also identify other desirable properties of the to-be-built system that may not be captured directly in use
cases. These should relate to the original strategic goals of the Stakeholders. The analyst may also
quantify these non-behavioral requirements (e.g., "97% availability" or 20 % small business
participation). Appropriate information must be conveyed to the software effort along with the use case
data.
Part of requirements analysis should be identification of the customers priorities. These priorities should
always be passed on to the component developers. In the cases where all requirements cannot be fully
met, the priorities will guide the most beneficial application of resources.
Requirements also should be analyzed for potential volatility. Which requirements are most likely to
change and which will probably stay unchanged? The impact of this information has long been identified
as critical to software development. Yet it is often overlooked.
2.5.1.5 Functional Analysis
A key stakeholder is the group that will be using some process to operate and use the to-be-built system
(e.g., a new accounting application must be incorporated into the procedures of the Accounting and
Finance Departments). In this example, the existing accounting procedures, i.e., the As-Is Process,
represents the parent system, involving not only interactions of accountants with the to-be-built
application, but also other interactions beyond the scope of the new system. The new accounting
application provides the opportunity to improve the as-is process as well, resulting in a new To-Be
Process matched with the to-be-built application. Thus, the analyst may be setting requirements for the
new system while concurrently reengineering the parent system. Understanding both the current and
future behavior is the focus of functional analysis.
2.5.2
LOWER-LEVEL INTERACTIONS/SOFTWARE DEVELOPMENT
In addition to the interfaces described in 2.5.1, the systems engineering activities continue to interact with
the software activities to provide additional inputs. In many cases, the interaction is to continue to amplify
the initial information as detail decisions are made, as is the case with an evolving concept of operations.
Other activities that provide new information are described below.
16
Reqs
Arch
Concept of Operations
How will
alternative
solutions be
operated and
maintained
New constraints
and requirements
System
System Use Case

Details
Alternatives
Variations
Priorities
Elaborations
Functional An
:
Trade Studies
Include Failures
Figure 4. Mid-Level Interactions
2.5.2.1 Functional Failure Analysis

Both systems engineering and software need to consider the impact of errors and failures on system and
component performance. Functional failure analysis allows the consideration of what can possibly go
wrong without requiring the specific knowledge design and components. This information can be
provided to the software developer as possible failure conditions that should be considered for response in
the design and raise alternatives that need to be considered. Conversely, the software developer should
communicate back to the systems engineer what the likely impacts of various failures might be and what
additional failures should be analyzed.
Because software can be more easily deployed in upgrades than hardware, the application of spiral
development is frequently used and results in incremental implementation of capabilities. As systems
engineering reviews systems alternatives and priorities, this information can help in determining the
appropriate capability sequences.
2.5.2.2 Design and Deployment
As hardware technology options are selected and an architecture is developed, the deployment of software
to processing locations in the system will evolve. However, this must be a negotiated process. This is not
only an issue with object-oriented software and will be discussed as a general problem.
Analyses apart from those currently encompassed by OOASIS determine the system design for hardware
and any other non-software aspects of the system. The NDC Diagram presents the results of these
decisions relevant to software design. These activities operate in parallel with OOASIS, coordinating
decisions on the non-software portion of the system with the software design.
Similarly, the selection of OTS Software Components to be used in construction of the system occurs
externally to OOASIS. OTS Software Components are either asserted by Stakeholders (e.g., a legacy
system that is infeasible to replace), or they are evaluated and selected based on software functional needs
drawn from preliminary versions of the System Software Architecture and System Software Deployment
17
Models. These parallel activities to elaborate the definition and/or selection of physical architecture and
OTS components continue until they result in detailed Hardware Interfaces and OTS Software
Interfaces. These support low-level software design (elaboration of the System Software Architecture)
and coding.
2.5.3
GENERAL INTERFACE ISSUES
2.5.3.1 Balancing Architecture Decisions

One of the hottest issues between software developers and systems engineers revolves around old
approaches to allocation and architecture decisions. In a more classic approach, functionality is allocated
to system components and a hardware/software decision is made within each box. In modern software
intensive systems, location of specific software functionality is much less of or no concern at all. Software
developers can and prefer to develop the internal architecture of the software and then distribute it as
makes sense from a processing view. This means that attempts to force distribution to specific hardware
locations is both less than optimal from a software performance standpoint and not well received by the
software community. As a result, the systems engineer must recognize this need for delaying deployment
decisions until later in the development process and resist the urge to force functional allocations early in
the process.
On the other hand, there are often constraints and lead times that the systems engineer faces that the
software developer must be responsive to. One of the historic examples is communications limitations.
There are lots of examples of software designs that worked well on paper or on prototype systems but
could not be used in the real world. Some have been limited by security concerns, others by real world
capabilities that were as much as four orders of magnitude less than desired. The software developer must
be ready to face these constraints and work with the systems engineer to provide an optimum
compromise.
A factor in this difference of viewpoint between the two disciplines is the internal versus external view.
This is not peculiar to software. The design discipline of any component needs to focus on the internal
design of the component in question. By definition, it is the responsibility of systems engineering to
assure that those components work with the other components so that the system does what it is supposed
to. Both the systems engineer and the software engineer must be aware and live by some basic tenets.
1. The systems and software architectures are not the same thing.
The systems engineer must recognize that a software architecture needs to be developed based on the
problems to be solved in software and the actor interfaces. Negotiation of impact on system elements
should be expected as part of the software deployment activity.
2. The systems and software architectures are not totally independent.
The software developer must recognize that systems constraints and lead times require early definition of
software architecture constraints. For instance, communications limitations between two geographically
separate nodes may constrain the deployment options and force the software architecture to limit the
internode data
18
An example of the need to understand the external processes is the current effort within the air
transportation industry to add a data link capability. This system will allow pilots and controllers to pass
messages in addition to voice communications to increase the effectiveness of air traffic control. To the
software designers, the handling of message traffic can be shown in UML with the controllers and pilots
as principal actors and the software within the system described in use cases and interaction diagrams. At
the systems level, the critical factors driving the usability of the datalink concept involve the workloads of
both the pilot and controller. In order to understand these, the analyst must understand, model, and test the
activities external to the datalink system. These analyses are better supported by methods such as the
behavior diagram or other static or dynamic models.
2.5.3.2 Over- and Under-specifying
As with any component, the correct balance of specification detail is difficult to find. If the systems
engineer is unfamiliar with the issues of design that affect that discipline, it will be more difficult to
achieve the balance. If there is not an active, bi-directional communication channel in place, it will be
impossible. This is often even truer for software components.
An example of under-specification is the system that required the software to automatically reconfigure
the network if one of the links failed. No further guidance was provided. The expectation was that the
software designers could figure it out from there. After all, the maintenance crew did this regularly in the
current system.
A better approach is to be responsive to the questions that a software developer asks about the
requirement such as what reconfigurations are viable, what capabilities have priority, how many failures
must be handled, how long do we have to reconfigure, what should be done when a link comes back on
line, etc.
Over-specification, as with any component, is usually the result of forcing design rather than providing
the constraints that drive it. A typical example would be requiring either a look-up table or an algorithm
calculation rather than the accuracy requirements and letting the software developer choose the most
effective solution.
2.5.4 SE AND UML

UML has been developed as a unification of software analysis techniques. As such, it should not be
surprising that it does not yet fully cover the needs of systems engineering. This has been recognized
within the Object Management Group and a Systems Engineering Domain Special Interest Group within
OMG has issued a Request For Proposal for changes to the UML to improve coverage of systems
engineering needs. This effort is being jointly conducted with the International Council on Systems
Engineering (INCOSE). Some of the principal requirements are expanded capabilities in defining
complex behavior, systems elements, interfaces, allocation, and traceability.
It is anticipated that most of the requirements will be addressed by changes to the UML. There may be
some additional diagrams added in this effort or future changes to the UML. Beyond the scope of current
changes are various analysis techniques that have been developed by specialty disciplines to address
their peculiar concerns. Among them is Systems Safety with Failure Mode Analysis and Fault Tree
Analysis and testing with Design of Experiments methods for resolving issues involving complex
19
interactions and multiple alternatives. These may be incorporated at a later date or may remain an external
set of techniques that will need to interface with UML analysis as appropriate.
Another example of external analysis interfacing with the UML would be the allocation of softwares
contribution to a classic hardware property such as the range of an aircraft. Typical analysis provides
equations or mathematical model making range a function of weight, drag, lift, specific fuel consumption
and other constraints. If the design relies on software to maintain optimum attitude to affect range, that
can be included in the mathematics and the allocations recorded in the analysis. This will then be a
requirements input to the UML analysis.
2.6
SUMMARY
There are three main points that are addressed in this report.
20
Systems engineering and software development techniques have been developed to address
different specific issues and concerns. However, they do overlap and the overlap increases as the
proportion of software content increases.
Information that is common to both areas must be identified and properly exchanged.
Systems engineering and software development should be conducted in parallel and integrated.
Doing them sequentially in an over-the-wall manner generates severe problems.
3. APPLYING IDEF METHODS TO DEVELOP

OOASIS INFORMATION REQUIREMENTS
The OOASIS method identifies nine information artifacts that it assumes are generated by activities that
are external to the core software-oriented activities of OOASIS. OOASIS treats these primarily as inputs
to the OOASIS method:
Stakeholders
Context Diagram
As-Is Process
To-Be Process
Summary Use Cases
NDC Diagram
Hardware Interfaces
The IDEF0 method is often used to perform the functional or behavioral analysis of a system. Although
some of the information is principally developed and recorded using other techniques such as concept of
operations and system architecture views, IDEF0 contains most of the information needed for the
OOASIS inputs. The application of the IDEF0 method demonstrates how this systems engineering
method may be used to satisfy some or all of the information needs represented by these artifacts. The
OOASIS information requirements represented by the first six artifacts may be fully addressed using the
IDEF0 method. The three artifacts representing OTS software and hardware components and their
interfaces are not fully addressed, but the specific components and interfaces required to meet system
requirements are identified using the IDEF0 method.
A case study using IDEF0 is provided in the appendices to this report for those interested in more details
on how that method can be applied to the software interface needs.
21
3. Applying IDEF Methods to Develop OOASIS Information Requirements
22
A.RELATING IDEF METHODS TO OOASIS

A.1
PART I. APPLYING THE IDEF0 METHOD
The OOASIS method identifies nine information artifacts that it assumes are generated by activities that
are external to the core software-oriented activities of OOASIS. OOASIS treats these primarily as inputs
to the OOASIS method:
Stakeholders
Context Diagram
As-Is Process
To-Be Process
Summary Use Cases
NDC Diagram
Hardware Interfaces
The OOASIS information requirements represented by the first six artifacts may be fully addressed using
the IDEF0 method. The three artifacts representing OTS software and hardware components and their
interfaces are not fully addressed, but the specific components and interfaces required to meet system
requirements are identified using the IDEF0 method as described here.
This approach to IDEF0 analyses is based upon IEEE 1320.1-1998 and the IDEF0 models developed here
comply with this standard. For the remainder of this document, unless otherwise specified, the term model
refers to an IDEF0 model. A requirements model refers to a fully decomposed IDEF0 model in which
mechanisms have not been specified. An architecture model refers to a fully decomposed IDEF0 model in
which mechanisms have been specified for all activities.
The focus of this appendix is not to teach IDEF0 modeling; we assume that the reader has some
familiarity with the IDEF0 method. The focus is first on ensuring that OOASIS information requirements
are addressed during IDEF0 model analysis and construction and second on translating this information
into artifacts understood by and useful to OOASIS and other software engineers.
23
A. Relating IDEF Methods to OOASIS Information Needs
The basis of this work is the Buoy System case study presented by the OOASIS course and website as the
vehicle for demonstrating this application. However, to reduce the number of systemic interfaces to a
manageable handful, we have recast the characters of this case study so that the problem is not deeply
embedded in a context of existing organizations and systems. We have invented the island nation of Santa
Narida to be the customer for our buoy system; the backstory about Santa Narida is given in Appendix B.
A.1.1
OVERVIEW OF METHOD
To develop the information needed by OOASIS software designers, the systems engineer will build a
family of IDEF0 models whose information elements will be mapped to the input artifacts specified by
OOASIS. Each step in the method builds upon information developed by previous steps.
1. Identify and gather source material preparatory to developing IDEF0 models.
2. Build a family of models of the interests of external stakeholders. These include models are additional
to IDEF0 but depend on the information contained in IDEF0 with a focus on stakeholder behavior.
[These models will satisfy the OOASIS requirement for external stakeholder and summary use case
information.]
3. Build a family of environmental context models for the prospective system. These models are
organized around principle outputs to satisfy the interests of external stakeholders. These models
consolidate stakeholder interests from the perspective of the prospective system. These models treat
the prospective system as a black box. [These models will satisfy the OOASIS requirement for context
and external stakeholder information.]
4. If appropriate, build an architecture model(s) of any existing system(s), to include environment
context diagrams. If you are re-engineering a system, an architecture model of the existing system is
always appropriate. If you are building a new system to provide completely new behavior, the need
for an architecture model of existing behavior is problematic and will need to be established. The
systems engineering process will generally use depictions of architecture which are additional to
IDEF0. The information in these models ties to the mechanisms in IDEF0. [This model(s) will satisfy
the OOASIS requirement for AS-IS context, external stakeholder, and process information.]
5. Build a family of requirements models for the prospective system. These requirements models
decompose the system behavior (i.e., the A0 activity) specified by the environmental context models.
The first iteration of these models will focus on expected, correct behavior (the simplest, shortest,
successful path to achieving a goal(s)). (A corollary of this modeling objective is that these
requirements models may not use call arrows.) [These models will satisfy the OOASIS requirement
for context, external stakeholder, and TO-BE process information.]
6. Build a family of architecture models for the prospective system. The architecture models allocate
mechanisms to the decomposed system behavior of the requirements models. Particular attention will
be paid in this allocation to identify internal stakeholders and COTS hardware and software. Note that
this allocation will be exploratory and tentative. The systems engineering process will generally use
depictions of architecture which are additional to IDEF0. The information in these models ties to the
mechanisms in IDEF0. [These models will satisfy the OOASIS requirement for context, external
stakeholder, and process information. In addition, these models will identify internal stakeholders,
COTS software, COTS hardware, and their interfaces.]
24
7. Build a family of system use case models. These system use case models partition and coalesce the
architecture models to specify software system boundaries and actors in a way that may be translated
directly into use case notation. [These models will satisfy OOASIS requirements for system use
cases.]
8. Build a family of NDC models. These NDC models partition and coalesce the architecture models to
specify the nodes, devices, and connectors in a way that may be translated directly into NDC diagram
notation. [These models will satisfy OOASIS requirements for NDC diagrams.]
At this point, a consistent set of information and guidance for OOASIS software practitioners should be
available. We turn attention now to exploration of (1) anomalous behaviors, (2) alternative behaviors, and
(3) enumerated behaviors. Consideration of anomalous behaviors will introduce fractal patterns into our
requirements models. Call arrows and submodels will be introduced when we consider alternative
behaviors and enumerated behaviors. The following steps will elaborate the requirements and architecture
models that we have already developed.
9. Enumerated behaviors. Extend each model in the requirements family by considering activities that
represent sets of related but mutually exclusive behaviors. (These may sometimes be inappropriately
represented by a ladder pattern in a decomposition diagram, i.e., no coupling between parallel
activities.) Such enumerated behaviors are to be represented by submodels invoked by a call arrow.
[These extensions will assist the OOASIS analysis of alternate courses and variations for system use
cases.]
10. Alternative behaviors. Extend each model in the requirements family by considering additional ways
of accomplishing the objectives of each activity, i.e., alternative decompositions. These should be
first developed as FEO pages and then migrated to submodels. Such alternative behaviors are to be
represented by submodels invoked by a call arrow. [These extensions will assist the OOASIS analysis
of alternate courses and variations for system use cases.]
11. Anomalous behaviors. Extend each model in the requirements family by considering patterns of
anomaly detection and recovery for each activity. We provide a template of fractal patterns that may
be used to guide this analysis. [These extensions will assist the OOASIS analysis of alternate courses
and variations for system use cases.]
These steps generally refer to a family of models. This does not imply that every exercise will
necessarily generate multiple models; a family may have only one model. How large such a family might
be will depend upon the complexity of the prospective system and the intensity of issues to be resolved to
provide adequate requirements and design guidance.
This paper discusses a recommended method for accomplishing Steps 1 though 8. Steps 9 through 11 will
be treated in a subsequent release.
Step 1. Develop a consistent understanding of system need.
Identify and gather existing source fragments that state various aspects of the stakeholders
problems. As in the real world, fragments of useful information are in different places. For this
case study, one set of fragments comes from the OOASIS website, another from the OOASIS
course, and the final set is the Santa Narida backstory. The OOASIS website and OOASIS course
material have been slightly edited to ensure that they are consistent with the Santa Narida
backstory. The OOASIS website teaches:
25
A widespread fleet of buoys collects environmental data and feeds it periodically through
satellites to a land-based storage facility. Users of the system request subsets of the data and
perform analyses upon these.
The Meteorological Data system is sponsored by a government agency to provide environmental
data (mostly weather related) and analysis to scientists and the general public. The agency's goals
for this system are to provide real-time and historical data (archived from the real-time data
stream) on temperature, wind, and other conditions in a broad swath of ocean. The overall concept
for this system is that the agency will develop, deploy and maintain floating data collection buoys
throughout the area of interest. The buoys will periodically communicate their collected data
through commercial (or standard OTS) satellites to a land-based data center, where staff scientists
can access the data and run analyses from their workstations. A Web site will provide public
access to the data.
In particular, you know that the physical architecture involves buoys communicating to a land
station via satellite, and users employing work stations to access this data (probably via a large
server).
The OOASIS course adds these thoughts:

The case study we will use for every example will be a weather data collection system. The
system collects data from buoys floating in the Pacific Ocean and sends the data back for the landbased subsystem to archive for future use. The buoys send the data via a satellite provided by an
international agency. The bandwidth allocations are of sufficient size as to support 6 samples per
minute for each of the 1000 buoys. If the satellite becomes over used, it may require several
orbital passes to complete these buoy transmissions.
The primary users are research scientists who perform complicated analyses on the data. Some of
the analysis is to be done by this new system, and other tools will do other analyses. Therefore,
the system must allow the scientists to download the data into a standard format for import into
other tools. The contract requires the ability for Web access. The Web access for external
scientists and general public users will be limited to downloading data; commercial shipping route
planners may access specialized weather-dependent route-planning applications.. In case of
system performance problems, route planners get priority over external scientists, and the external
scientists get priority over general public users.
Administrators of the program will be given access to the system for report generation. The data
for these reports will be based on data collected about system usage and stored in a database for
retrieval. The reports themselves need not be saved because they can be regenerated as needed.
Consolidate fragments into a set of statements that can be compared, contrasted, and evaluated for
consistency by building exploratory models. These models should identify points of ignorance,
ambiguities, contradictions, and assumptions as reader notes in model diagrams. The first set of
these exploratory models examines the interests of external stakeholders.
Step 2. Identify the Prospective Systems External Stakeholders

In this step we construct a family of stakeholder models. These models are concerned with stakeholders
who are external to the system; these stakeholders use the outputs of our prospective system or provide
inputs, mechanisms, or constraints for the system. (Other internal stakeholders will be developed later;
these internal stakeholders will be external to software behavior within the system. For internal
stakeholders, the prospective system is their job.)
26
We build a separate model for each distinct stakeholder (or class of fungible stakeholders). Start each
stakeholder model with this purpose statement:
To describe this stakeholder's interest in the prospective system and how the prospective system
will satisfy that interest from the stakeholder's viewpoint.
(As you gain understanding of the stakeholders interest, you may substitute a more pointed purpose
statement.)
Begin each stakeholder model by representing both the stakeholder and the prospective system as
mechanisms of the A0 function, that is, as means for satisfying the stakeholders interest.
Represent the observable manifestation of the stakeholders interest as output of the A0 function. The
primary output of the A0 function will be the output of interest to that stakeholder, at whatever level of
abstraction is appropriate for that stakeholder. In particular, this output is not an output of the prospective
system. This output is the output that the stakeholder will produce using the output of the prospective
system: the A0 output in a stakeholder model represents the outcome or results of operation of the
prospective system, not the outputs of the prospective system itself.
For our case study, we have developed eight stakeholder models, one each for
The internal scientist as weather forecaster (forecaster)

The external institute scientist (institute)
The buoy maintenance organization (maintenance)
The satellite communications provider (satellite provided)
The management of the National Weather Service (customer)
The shipping route planner (shipper)
The national television weather show (weather media)
The tsunami warning center (tsunami).
We will not provide a model for the environment as the provider of meteorological phenomena.
Each of these models will consist of just three pages: an A-0 diagram, an A0 diagram, and an A0T text
page. You should not expect nor need to raise the publication status of the diagrams of these stakeholder
models above working. To a traditional IDEF0 modeler, these stakeholder models will look somewhat
odd. We assume in the perspective of a stakeholder a certain lack of concern for anything other than what
directly supports the stakeholders interest. Thus, unlike a complete requirements or design model, in
which we must provide a total mapping of inputs to outputs and vice versa, our stakeholder models may
cheerfully ignore inputs and/or outputs that logic would require but that stakeholder may well be
oblivious to or ignorant of. (This is one reason why the diagrams will remains at the working level.)
The A0 diagrams of our stakeholder models follow:
27
Used at:
Date
AKBocast
Rev:
OOASIS SE
Stak e holde r: We athe r M e dia (SWM )
1 2 3 4 5 6 7 8 9 10
Author:
P roject:
Model:
Notes:
<work>
Working
Draft
Recommended
P ublication
12/20/2001
Reader
Date
Context:
A-0
C1 Ima g e S t a n d a rd s
C 3 Bro a d c a s t S c h e d u le
C 2 W e a t h e r S h o w F o rma t
P ro d u c t Re q u e s t s
F o re c a s t P ro d u c t s
I1
I2
F o re c a s t
W e at he r
O ce an O b s e rvat io n s
GO O S Ima g e ry
O c e a n I ma g e ry
V is u a l P re s e n t a t io n
M ix B a c kd ro p
W eat h e r S h o w
O1
2
S c rip t
W rit e S c rip t
3
Re a d S c rip t
F o re c a s t T e xt
4
O ra l P re s e n t a t io n
M 1 Na t io n a l W e a t h e r S e rv ic e
M 3 W e a t h e r P re s e n t e r
M 4 S a n t a Na rid a Bu o y S y s t e m
P age:
Title:
A0
M 2 T e le v is io n S t u d io
Number:
P resent Weather
AKB3
Diagram 1. SWM/A0 (Present Weather)
Used at:
Author:
P roject:
Model:
Notes:
Date
12/20/2001
AKBocast
Rev:
OOASIS SE
Stak e holde r: Ts unami Warning Sys te m (STW)
1 2 3 4 5 6 7 8 9 10
<work>
Working
Draft
Recommended
P ublication
C 1 In t e rn e t M a il P ro t o c o ls
Reader
Date
Context:
A-0
C3
T s u n a mi P re d ic t io n M o d e ls
C 2 D at a S h arin g A g reem en t
S N O O R T s u n a mi Da t a
Pr o v id e
T s u n am i
Pr ed ict io n
D a ta
R ece iv e
D at a
O c e a n o g ra p h ic Da t a
I1
F u s e d T s u n a mi Da t a
Fus e
T s u n ami
S o u rces
3
Re c e iv e d T s u n a mi Da ta
M a il S e rv e r
M a il C lie n t
Pr e d ict
T s u n am i
T s u n a mi W a rn in g
M2
P age:
28
A0
S a n t a Narid a Bu o y S y s t e m
Title:
P roduce Tsunami Warnings
M1
T s u na mi W a rn in g S y s t e m
Number:
P. 2
O1
P. 3
Diagram 2. STW/A0 (Produce Tsunami Warnings)
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
Stak e holde r: Ins titute Scie ntis t (SIS)
1 2 3 4 5 6 7 8 9 10
12/20/2001
Working
Draft
Recommended
P ublication
Reader
O b s e rv a t io n S p e c if ic a t io n s
C2
Da t a s e t S p e c if ic a t io n s
C3
T a s kin g
Re s e a rc h A g e n d a
D at as e t R e qu e s t s
O c e a n Da t a
O c e a n O b s e rv a b le s
Context:
A-0
C1
I1
Date
C ap t u r e
O ce an D at a
S t ag e
O ce an Dat a
R e q u e s t e d D at as e t s
S tud y
O ce an
W e at he r
Re s e a rc h P ro d u c t s
O1
W e b S e rv e r
W e b Bro w s e r
M3
M1
P age:
A0
Title:
S a n t a Na rid a Bu o y S y s t e m
Research Ocean Weather P henomena
M2
In s t it u t e S c ie n t is t
In s t it u t e f o r M id - P a c if ic O c e a n M e t e o ro lo g y
Number:
AKB2
P. 2
Diagram 3. SIS/A0 (Research Ocean Weather Phenomena)
29
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
Stak e holde r: Route Planne r (SRP)
1 2 3 4 5 6 7 8 9 10
12/20/2001
Working
Draft
Recommended
P ublication
C1
V e s s e l C h a ra c te ris t ic s
Reader
Date
Context:
A-0
De s t in a t io n s
C3
C u s t o me r Re q u ireme n t s
C2
Re s o u rc e M in imiz a t io n S t ra t e g y
Fe a s ib le Ro u t e s
I1
Ro u t in g A lt e rn a t iv e s
D et e rm in e
F e as ib le
R o u tes
S c h e d u les
W eat h e r- Pro file d R o u t e s
I2
F o r e cas t
R o u t e - S p e cific
W e at h e r
O c e a n W e a t h e r Da t a
R o u t e - V e s s e l- S ch e d u le E s t im at e s
E s t im at e
V es s e l
S ch e d u le s
3
S e le ct
O p t im um
It in e rary
Ro u t e Pla n
O1
M1
M2
W e b s it e
P age:
Title:
A0
M3
W e b Bro w s e r
Ro u t e P la n n e r
Number:
P lan Ship Itinerary
AKB3
P. 2
Diagram 4. SRP/A0 (Plan Ship Itinerary)
Used at:
Author:
P roject:
Model:
Notes:
Date
12/20/2001
AKBocast
Rev:
OOASIS SE
Stak e holde r: We athe r Fore cas te r (SWF)
1 2 3 4 5 6 7 8 9 10
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A-0
C 1 W e a t h e r M o d e l Re q u ire me n t s
C 2 O u t lo o k S c h e d u le
C o lle ct D at a
I1
M e t e o ro lo g y Da t a s e t s
Pu s h D at a
His t o ric a l Da t a
Mo d el
W eat h e r
P ro je c t e d Da t a
Pu b lis h
F o r e cas t s
M2 Na t io n a l W e a t h e r S e rv ic e
M 1 W e a t h e r F o re c a s t e rs
P age:
30
A0
Title:
Forecast Weather
Number:
AKB2
P. 2
O1
Diagram 5. SWF/A0 (Forecast Weather)

Used at:
Author:
P roject:
Model:
Notes:
Date
12/20/2001
AKBocast
OOASIS SE
Rev:
Stak e holde r: National We athe r Se rvice (SNW)
1 2 3 4 5 6 7 8 9 10
C1
C 2 F o re c a s t in g S c h e d u le
Reader
Working
Draft
Recommended
P ublication
Date
Context:
A-0
S h ip me n t Re q u ire me n t s
C 3 M in is t e ria l Q u e s t io n s
W e a t h e r C o n s t ra in t s
I1
Pro v id e
W e at h e r
W e a t h e r O b s e rv a b le s
In fo rm at io n
1
Bu o y A c t iv it y Re p o rt s
W e b s it e A c t iv it y Re p o rt s
I2
U n d e c id e d Ro u t in g Q u e s t io n s
S e le ct
S h ip p ing
F a v o ra b le Ro u t in g De c is io n s
O2
It in e rar y
2
A ctvity reports include

maintenance activity.
Pr o v id e
R e p o rt s
Minis terial R ep o rts
O1
3
S y s t e m A c t iv it y Re p o rt s
Bu o y s
W e b s it e
S y s t e m A d minis t ra t o r
M2
M 1 S h ip p e r
P age:
A0
Title:
Increase P uerta Oveida Market Share
NW S Ge n e ra l M a n a g e r
M 3 S a n t a N a rid a Bu o y S y s t e m
Number:
AKB2
P. 2
Diagram 6. SNW/A0 (Increase Puerta Oveida Market Share)
31
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
Stak e holde r: Sate llite Provide r (SSP)
1 2 3 4 5 6 7 8 9 10
12/20/2001
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A-0
C 2 S e rv ic e A g re e me n t
W e b P r o t o c o ls
C 1 C o mmu n ic a t io n s P ro t o c o ls
S e n t C o mman d s
W e b P r o t o c o ls
S a t e llit e P ro t o c o ls
S en d
C o m m an d s
T ra n s mit t e d C o mma n d s
1
Mo ve
C o m m an d s
S en t D at a
S e n d D at a
I1
F ie ld O b s e rv a t io n s
T ra n s mit t e d Da t a
3
M o v e D at a
A r ch ive
D at a
A rc h iv e d Da t a
O2
R e ce ive
D at a
W e b Bro w s e r
Bu o y T ra n s c e iv e r
D e liv e re d Da t a
O1
4
W e b Bro w s e r
M 2 A rg o s
P age:
Title:
A0
M 3 W o rld W e a t h e r W a t c h
Number:
Deliver Data
P. 2
Diagram 7. SSP/A0 (Deliver Data)

Used at:
Author:
P roject:
Model:
Notes:
Date
12/20/2001
AKBocast
Rev:
OOASIS SE
Stak e holde r: NOAA M ainte nance (SNM )
1 2 3 4 5 6 7 8 9 10
<work>
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A-0
C 2 Bu o y T e c h n ic a l Da t a
C 1 M a in t e n a n c e T re a t y
M a in t e n a n c e N o t if ic a t io n
I1
Bro ke n Bu o y
M a in t e n a n c e R e p o rt
M a int e n a n c e Re q u e s t
R e q u es t
M ain t e n an ce
A ct io n
1
M a in t e n a n c e Re c o rd
M a in t e n a n c e O rd e r
D ir e ct
M ain t e n an ce
A ct io n
2
M a in t e n a n c e H is t o ry
F ix B u o y
W o rkin g Bu o y
3
P age:
A0
Title:
Maintain Buoys
M 2 NO A A
M 3 Pa c if ic O b s e r v e r
Number:
Diagram 8. SNM/A0 (Maintain Buoys)
32
AKB2
P. 2
O1
Verification. By textual exegesis.

Validation. By consensus.
Step 3. Identify Current Processes, if any
In general, you will develop an exploratory AS-IS model of the problem. This model will reveal current
business processes, if any. As we develop the TO-BE model, the AS-IS model will provide some
combination of two primary kinds of information. First, it may describe ongoing processes with which the
system concept will need to interact. Second, it may describe a legacy baseline for engineering an
improved or replacement system.
(In this case study, this step will be conveniently skipped; the terms of reference for the case study have
been adroitly chosen to preclude the need for an AS-IS model. Our prospective system will provide
completely new behavior and resources for its relevant stakeholders, with two exceptions: the Santa
Narida National Weather Service scientists and the Televisio Santa Narida weather shows. For these two
stakeholders, the behavior of the prospective system will be strictly additive; no existing behavior will be
replaced.)
Step 4. Identify Behaviors for the Prospective System
In this step, you will develop one or more requirements models (shorthand for models of behavioral
requirements) for the prospective system.
Determining How Many Models To Create
As the primary source for your analysis, you will use the external stakeholder models developed in Step
1. You will determine the minimal set of outputs required too satisfy the interests of the specified
stakeholders. Each model should bring focus to a coherent set of related outputs. Begin by creating two
models, each containing an A-0 and an A-1 diagram. If you use the requirements model template
provided by the Consortium, the A-1 diagram will be seeded with five activities: A-11, A-12, A-13, A0,
and A-15; note that the A0 function will initially be the fourth activity in the A-1 diagram.
One reason that we suggest you begin with two unpopulated models is to help you overcome the mindset
that one single model is sufficient for requirements analysis. Remember that the basic epistemological
intent of any analysis is to break a problem down into manageable parts. If we should set as our goal that
one model should include everything, we would violate our basic principles of analysis and design. Our
goal is not to produce one model but to produce and integrated and consistent set of information that
contains the minimal and sufficient information needed by an OOASIS practitioner. (Of course, this does
not preclude the possibility that our analysis may coalesce and conclude with one model.)
Group the stakeholder models by characteristics that will help you find themes and affinities
among them. We have grouped our case study stakeholder models like this:
Affinity Grouping of Stakeholder Models

Grouping Concept:
User of System Products
Provider of System
Resources
Stakeholders:
forecaster
institute
shipper
media
communications
maintenance
customer
Comments
33
tsunami
Consider the canonical form for the A-1 diagram suggested by the requirements model template.
Assign stakeholders identified by the stakeholder models to this table.
Template Grouping of Stakeholder Models

Grouping
Concept:
User
Outputs
Controls
Stakeholders:
forecaster
institute
shipper
media
tsunami
customer
Provider
Inputs
Mechanisms
communications
maintenance
This template grouping is consistent with the tentative affinity grouping, but this grouping points out that
our assessment of external stakeholders which is based strictly on our source evidence may be
insufficient. In particular, we realize that we have not as yet recognized any external stakeholders who
may be required to provide inputs for our prospective system.
One clear source of input is the environment, which provides the meteorological observables that will be
measured and reported by the case study system. Other than such observables, consideration of our buoy
system does not immediately offer further sources of input for the operational system. Inputs required for
maintenance seem, at least as far as we now know, the responsibility of the maintenance organization
rather than of the prospective system directly.
The environment will definitely be identified as an actor because it is the source of observations (e.g.,
measurements, signals). It may or may not be identified as a stakeholder depending on the definitions
used. It would not if the definition limits stakeholders to those having a vested interest in the system. In
this exercise, we will list it with the stakeholders to more easily transfer the information to the
identification of actors in use cases.
Successful operation of the prospective system will require competent system staff, suggesting that we
may need to consider that training will be required to prepare mechanisms. Similarly, a major constraint
on the prospective system will be a variety of scientific, communications, technical, and formatting
standards. Some of these may be negotiated with stakeholders who are external users such as the Tsunami
Warning Center. Others may be specified by resource providers such as the Argos system. Others may be
available from standards organizations and professional associations; this last order of constraint should
not require interaction beyond routine purchasing and membership transactions.
You should then extend the content of the stakeholder grouping table to capture these ideas:
Template Grouping of Stakeholder Models

Grouping
Concept:
Stakeholders:
34
User
Provider
Outputs
Controls
Inputs
Mechanisms
forecaster
institute
shipper
customer
tsunami
communications
environment
communications
maintenance
trainer
media
tsunami
Reflecting upon the tentative groupings in this table, you can then allocate stakeholders to
separate requirements models. One such allocation is illustrated by the next two tables:
Stakeholders by Requirements Models: Model 1 (selected stakeholders are in bold)

Grouping
Concept:
Stakeholders:
User
Provider
Outputs
Controls
Inputs
Mechanisms
forecaster
institute
shipper
media
tsunami
customer
tsunami
communications
environment
communications
maintenance
trainer
Stakeholders by Requirements Models: Model 2 (selected stakeholders are in bold)

Grouping
Concept:
User
Outputs
Controls
Inputs
Mechanisms
Stakeholders:
forecaster
institute
shipper
media
tsunami
customer
tsunami
communications
environment
communications
maintenance
trainer
Provider
Notice that the customer and environment stakeholders appear in both allocations. The environment
appears in both because it alone provides input for the prospective system. The customer also appears in
both, but with a different rationale for each one. In Model 1, the idea is that the customer stakeholder is
concerned with ensuring appropriate services for system users. In Model 2, the idea is that the customer
stakeholder is concerned with ensuring appropriate supervision and control of system operations.
If these allocations are coherent and useful, you should be able to assign a distinct name to each
requirements models. You might adopt System Products as the interim name for the first model
and System Operations as the interim name for the second model.
Determining Viewpoint and Purpose for Each Model

These models will all have the viewpoint of a systems engineer in the role of elicitor of requirements. The
purpose of each model will be to specify minimal and sufficient behaviors leading necessarily to the
coherent set of related outputs required by external stakeholders.
Step 3. Specifying the Environmental Context for Each Model
Rename the two models you have created as the Requirements TO-BE System Products model and the
Requirements TO-BE System Operations model. Do not worry yet about naming the A0 function in either
35
the A-0 or A-1 diagrams; our interest now is fleshing out the context of the A0 function in the A-1
diagram for each model.
To make this section easier to read (and to write!), we will use the term stakeholder function to refer to
the box in the A0 diagram of a stakeholder model to which the prospective system is attached as a
mechanism. We will use the term A0 function to refer to box 0 in the A-1 diagram of a requirements
model; the prospective system is attached to this box as a mechanism.
Gather the A0 diagrams of the stakeholder models for the stakeholders allocated to the System Products
model. We will sequentially and methodically add the information in these stakeholder models to the A-1
diagram. In the A-1 diagram, whatever the stakeholder does with its input from the prospective system is
hidden within the use output box.
The prospective system becomes a mechanism of the A0 function. The stakeholder becomes a mechanism
of the use output function.
Boundary arrows that are controls for the stakeholder function becomes outputs of the provide controls
box. Controls on the stakeholder function that are outputs of stakeholder activities become controls on the
A0 function.
Boundary arrows that are inputs for the stakeholder function become outputs of the provide inputs
function.
In general, we try not to add new material nor do we try to rectify any logical anomalies (the sense of the
model) that become apparent, although we generally consider correcting modeling anomalies (the
representation of model sense) while we add successive stakeholders information to this diagram.
The next diagram illustrates this transferal for the first, Weather Media stakeholder. The template
elements that have not been used so far are grayed down; as these elements are used in the following
sequence of diagrams they will be restored to their normal color.
36
Used at:
Author:
P roject:
M odel:
Notes:
c o n t ro l re q u e s t
12/13/2001
AKBocast
Date:
OOASIS SE
Rev:
Requirements TO-BE Pro ducts (RTP)
1 2 3 4 5 6 7 8 9 10
W orking
Draft
Reader
Date
Context:
NO NE
R ecommended
P ublication
m e c h a n is m re q u e s t
in p u t re q u e s t
p e rfo rm a n c e fe e d b a c k
b roa d c a s t s c h e d u le
p ro v id e
c o n t rols
14
im a g e s t a n d a rd s
p ro v id e
m e c ha n is m s
2
re s u lt s fe e d b a c k
O c e a n O b s e rv a t io n s
p ro v id e
in p u t s
3
P rod u c t R e q u e s t s
AC0o nfut e
nxc tt io
o fn
...
0
G O O S I m a g e ry
O c e a n I m a g e ry
u se ou tp u t
W e a t h e rS h o w
m e c h a n is m b u n d le
re s u lt s
5
F o re c a s t Te x t
T e le v isio S a n ta N a r id a
s t a k e h o ld e r c
P age:
A-1
s t a k e h o ld e r m
T itle:
s t a k e h o ld e r i
S a n ta N a r id a B u o y S y ste m
Stakeholder Context of A0 function
Number:
AKB5
P. 1
Diagram 9. RTP/A-1=AKB5.1 for Weather Media Stakeholder
The following diagram adds the environment stakeholder to generate input.
37
Used at:
12/14/2001
AKBocast
Date:
OOASIS SE
Rev:
1 2 3 4 5 6 7 8 9 10
Author:
P roject:
M odel:
Notes:
W orking
Draft
Reader
Date
Context:
NO NE
R ecommended
P ublication
p ro v id e
c o n t rols
14
p ro v id e
m e c ha n is m s
2
Ocean
P la n e t
p ro v id e
in p u t s
P la n e t a ry O b s e rv a b le s
3
AC0o nfut e
nxc tt io
o fn
...
0
G O O S I m a g e ry
u se ou tp u t
re s u lt s
5
T e le v isio S a n ta N a r id a
P age:
A-1
T itle:
E n v iro n m e n t
S a n ta N a r id a B u o y S y ste m
Number:
AKB5
P. 1
Diagram 10. RTP/A-1=AKB5.2, Adding Environment Stakeholder
The need for our first bit of analysisas opposed to transferring concepts from the stakeholder model
now becomes obvious. 0I1 and 0I2 were transferred directly from the stakeholder model. The
environment was introduced as the ultimate mechanism for generating 3O1 and 3O2. Since 0I1 and 0I2
must be transformed from some input (absent a so-called creative act), 3I1 and 3I2 were introduced to
provide input for those transformations. Several issues now are obvious:
Environment as Transformation Agent. While the environment might be considered as a transformer of
calm into storm, electrical potential into lightning, of flat seas to towering waves, it is difficult to see how
the environment could create observations or imagery. It is much easier to see the environment as the
mechanism of a function that produces the inputs to the function that transforms observables into
observations. Indeed, for box 3, is it not our buoy system that produces the ocean observations? But also
is it not some other system (e.g., GOOS) that produces imagery rather than our buoy system? This leads
to contemplation of these issues:
Input for Environment Function. Whatever our buoy ends up sensing, it will only sense things that are
observable. What is observable does not depend on weather condition, for it is the weather itself that we
intent to observe. So unlike a transformation of cold water to warm water, an observable input to another
observable output, the function that will produce ocean observables (and for that matter global
38
observables as seen by a satellite camera) for our sensors is a creative act and will not require explicit
inputs.
Transformation of Observables. We also note that ocean observations are not a transformation of ocean
observables; if that were so, we would be proposing to convert mass and energy of the environment into
pure information. The effect of our sensors is to change the state of an observable from the perspective of
the observer: the observable is transformed from unobserved to seen, in particular, from unmeasured to
measured.2 The measured observable needs to be added as output of the function that produces ocean
observations.
System Boundary. Creep of our prospective system as mechanism to additional functions in the A-1
diagram is not unexpected. A stakeholders perspective of a prospective system should not be expected to
coincide neatly with the systems engineers concept of the scope and boundaries of the prospective
system. What is interesting about this function is that the production of ocean observables is within the
scope of the prospective system but the production of satellite imagery does not appear to be within the
scope as currently conceived.
Parallel but Unconnected Activities within a Decomposition. Your first reaction to realizing that the
buoy system transforms ocean observables into our measured observables and that the GOOS system
transforms planetary observables into our photographed observables might be to show this distinction by
decomposition of the provide inputs box, something like this:
C1
C2
I1
M e a s u re O c e a n
W eath er
C h a ra c t e ris t ic s
O1
M e a s u re d O c e a n O b s e rv a b le s
O2
1F
P h o t o g ra p h
t h e E a rt h
S a t e llit e I m a g e ry
O3
P h o t o g ra p h e d O b s e rv a b le s
I2
O4
2F
M2
B u oy S ystem
M1
G O O S S a t e llit e s
Diagram 11. RTP/FEO1: Parallel Decomposition Fragment
This draft shows no coupling or cohesion whatsoever between the two boxes. This indicates that the
decomposition is suspect, an artifice by which two unrelated functions have been grouped together not
because they participate in the purpose of some larger whole but rather because they have been grouped
2
There is of course a fundamental difference between, on the one hand, changing the state of a letter from
unsigned to signed and, on the other, changing the state of a letter from unread to read. Signing a letter physically
changes the letter while reading that letter does not physically change it. In the first case, the thing itself has been
transformed; in the latter case, it is our perception of the thing that has been transformed we have moved the
letter from one conceptual category to another. However, because philosophers of science have instructed us that
the interaction of observed and observer changes both, we can at least temporarily accept such transformation as
legitimate within an IDEF0 model.
39
by location or kind no surprise here since our template grouped them together because they are both
sources of inputs! The Measure Ocean Weather Characteristics should really be within the A0 function,
represented by the walls of box 0.
These considerations lead us to revise our working draft:
Used at:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
Author:
P roject:
M odel:
Notes:
12/14/2001
Reader
W orking
Draft
Date
Context:
NO N E
R ecommended
P ublication
p ro v id e
c o n t rols
1
4
p ro v id e
m e c ha n is m s
2
p ro v id e
in p u t s
P ro v id e
O b s e rv a b le s
AC0o nfut e
nxc tt io
o fn
...
M e a s u re d O b s e rv a b le s
u se ou tp u t
re su lt s
E n v iro n m e n t
Te le v is io S a n t a N a rid a
P age:
A-1
T itle:
G O O S S ystem
S a n t a N a rid a B uo y S y s t e m
Number:
AKB5
P. 1
Diagram 12. RTP/A-1=AKB5.3, Adding GOOS Satellite System
We have pushed our information about ocean observations into the system scope as a fragment in the A0
diagram:
I1
M e a sure O ce a n
W e a th e r
C h a r a c t e r is t ic s
O1
1
Diagram 13. RTP/FEO2, Ocean Observation Fragment
Notice that box 6 has been placed in a convenient place in the diagram. This convenient place is not a
correct place, but we have several more stakeholder models to look at before it will become worthwhile
to rearrange the topology of this diagram into a compliant visual structure.
40
Now we will look at the next stakeholder, the Tsunami Warning System:
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/14/2001
Date
Context:
NO N E
R ecommended
P ublication
B roa d c a s t S c h e d u le
Reader
W orking
Draft
I n t e rn a l M a il P ro t o c o ls
p ro v id e
c o n t rols
14
Ts u n a m i D a t a A g re e m e n t
I m a g e S t a n d a rd s
p ro vid e
m e c h a n ism s
2
p ro v id e
in p u t s
3
P ro d u c t R e q u e s t s
P ro v id e
O b s e rv a b le s
6
A 0 fu n c t io n
C on text of
...
Ts u n a m i D a t a
u se ou tp u t
W eath er S h ow
Ts u n a m i W a rn in g
E n v iro n m e n t
re su lt s
Ts u n a m i W a rn in g C e n t e r
P age:
A-1
T itle:
G OO S S ystem
S a n t a N a rid a B u o y S y s t e m
Number:
AKB5
P. 1
Diagram 14. RTP/A-1=AKB5.4, Adding Tsunami Warning System
First, notice that the Internet Mail Protocols have been shown as an external control, that is, these
standards are not established by the stakeholders: regardless of what the designers of the prospective
system may or may not do, these standards will be available to the system.
Second, we can recognize that providing some controls requires the participation of stakeholders. In our
stakeholder models, these were seen as given constraints. From a systems engineering perspective, the
activities that produce such agreements must be designed and institutionalized because the agreements
they generate are necessary for successful system operation.
Third, now that we have two stakeholders represented, we can begin to judiciously generalize, that is,
raise the level of abstraction of concepts in the environmental context diagram.
The next diagram shows an elaboration of the previous diagram as it incorporates joint control activities
and higher levels of abstraction. Our work area is now becoming crowded, so note that the activity to
provide mechanisms has been removed from this A-1 diagram; we will need to ensure that we revisit this
activity in another environmental context diagram.
41
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
D a ta S h a r in g A g r e e m e n ts
12/14/2001
Reader
W orking
Draft
Date
Context:
NO N E
R ecommended
P ublication
B roa d c a s t S c h e d u le
I n t e rn a l M a il P ro t o c o ls
p ro v id e
c o n t rols
14
p ro v id e
in p u t s
3
P ro v id e
O bs e rv a b le s
6
A 0 fu n c t io n
C on text of
...
F ore c a s t P ro d u c t s
u se ou tp u t
F ilte r e d D a ta se ts
W eath er S h ow
E n v iro n m e n t
N a t io n a l W e a t h e r S e rv ic e
P age:
A-1
G OO S S ystem
T itle:
S a n t a N a rid a B u oy S y s t e m
Number:
AKB5
P. 1
Diagram 15. RTP/A-1=AKB5.5, Adding National Weather Service
The specialized control Tsunami Data Agreement has been generalized to Data Sharing Agreement.
Similarly, Tsunami Data has been generalized to Filtered Datasets.3 This differentiates between
meteorological observations (real data) and meteorological forecasts (derived data). (Although you have
not yet made up your mind, you are wondering whether Image Standards could be usefully bundled into
Data Sharing Agreements or might eventually generalize into a separate Technical Standards.)
Because this is an obvious role for the National Weather Service as customer, we have introduced this
stakeholder as a negotiating partner of the provide controls activity. We follow this introduction by
assessing whether the customer stakeholder model supplies concepts useful for this A-1 diagram. Because
the focus of the NWS General Manager appears to be on responding to government ministers,
meteorological data is not really central to this stakeholder model. Recalling that the customer stakeholder
3
During discussion of what constitutes Tsunami Data, one of your colleagues points out that surely this data would
include swell height. To help the buoy system to filter out irrelevant observations, the Tsunami Warning Center
would most likely notify Santa Narida with the coordinates of the epicenter of seismic disturbances. Then buoy
sensors could be tasked to look for swell variance specifically along vectors radiating from the epicenter.
Although this did not come up in the initial effort to characterize the Tsunami Warning Center as a stakeholder,
you will probably want to investigate the possibility of two-way communications between Santa Narida and
Honolulu to direct searches for tsunami data.
42
has a role in both system products and system operations models, we defer these stakeholder model
concerns to be reconsidered when we address the A-1 diagram for the systems operations model. The
only concept we pick up from this model is to generalize Broadcast Schedule to Schedules.
Since the stakeholder model for the institute scientist requires meteorological data (the Datasets) to
produce research products, we now take up this stakeholder model for integration into our A-1 diagram.
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/14/2001
Reader
W orking
Draft
Date
Context:
NO N E
R ecommended
P ublication
I n te r n e t P r o to co ls
S ch e d u le s
p ro v id e
c o n t rols
14
p ro v id e
in p u t s
3
P ro v id e
Ob s e rv a b le s
A 0 fu n c t io n
C on text of
...
O b s e rv a t io n S p e c ific a t io n s
D a t a s e t S p e c ific a t io n s
D a t a s e t P ro d u c t s
S p e c ific a t io n s
F ilt e re d D a t a s e t s
us e o u t p u t
U n filt e re d D a t a s e t s
W eath er S h ow
x
x
x
5
E n v iron m e n t
I n s t it u t e S c ie n t is t
P age:
A-1
G OO S S ystem
T itle:
S a n t a N a rid a B u oy S y s t e m
Number:
AKB5
P. 1
Diagram 16. RTP/A-1=AKB5.6, Adding Institute Scientist
In this step, we have added the Institute Scientist as mechanism and Research Products as output to the
use output activity. The datasets requested by the Institute Scientists have been represented by Unfiltered
Datasets and bundled with Filtered Datasets to form Dataset Products as output from the A0 function.
The specification of the observations that the buoy system makes and the specification of the datasets that
the buoy system provides have been added as output from the A0 function and as control on the use
output activity.
Note that the Institute Scientist is not party to data agreements with the National Weather Service.
Instead, the Institute Scientist is a user of products specified by the buoy system.
43
Note too that the presence of web server and web browser mechanisms in the Institute Scientist model
suggested the extension and generalization of Internet Mail Protocols to Internet Protocols that govern
both the A0 function and the use output function.
Now we turn to the weather forecaster model. With the A-1 diagram we have developed so far, we
immediately see an issue concerning the scope of the prospective system. The output of the weather
forecaster is Forecast Products, which we have already identified in the A-1 diagram as an output of the
A0 function. In the weather forecasters stakeholder model, the National Weather Service itself and its
weather forecasters are shown as the modelers of weather and the publishers of forecasts. This would
make the National Weather Service a mechanism for the A0 function. Note that the stakeholder models
Outlook Schedule control confirms our generalization of Broadcast Schedule to the more abstract
Schedules.
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/17/2001
Reader
W orking
Draft
Date
Context:
NO N E
R ecommended
P ublication
I n te r n e t P r o to co ls
S ch e d u le s
p ro v id e
c o n t rols
14
W e a t h e r M o d e l D a t a R e q u ire m e n t s
p ro v id e
in p u t s
3
P ro v id e
Ob s e rv a b le s
A 0 fu n c t io n
C on text of
...
us e o u t p u t
W eath er S h ow
x
x
x
E n v iron m e n t
P age:
A-1
T itle:
G OO S S ystem
Number:
AKB5
P. 1
Diagram 17. RTP/A-1=AKB5.7, Additional Clarification of Behaviors
We bring Weather Model Requirements into our A-1 diagram as an output of the provide controls
function. One would think that there might be an interaction between operation of weather models and
development of their data requirements oops, this control refers to data requirements, does it not?
Renaming as data requirements should flush out any alternative interpretations.
44
We will need to address rather sooner than later whether the activities of National Weather Service
weathermen are within the scope of our model of system behavior. At this point in model development,
we put a placeholder for this issue on the requirements models A0 page, where we previously modeled
the production of ocean observations.
C 2 W e a t h e r M o d e l D a t a R e q u ire m e n t s
I1
M e a s u r e O ce a n
W e a th e r
C h a r a cte r istic s
1
F o r e ca st
W e a th e r
O1
O2
M1
W e a t h e r F o re c a s t e rs
Diagram 18. RTP/FEO3, Relating Observing to Forecasting
It is a judgment call, but this A-1 diagram seems to be sufficiently dense with concepts to be set aside for
the moment. In this diagram we have integrated and investigated stakeholder relationships with our
prospective systems for six stakeholders. Of the stakeholders tentatively allocated to this diagram, we
have addressed all but the shipper stakeholder.
We will now develop the second A-1 diagram. Having shown step-by-step development in the first A-1
diagram, we will just present the second A-1 diagram. This diagram addresses the shipper stakeholder as
well as other stakeholders of this diagrams initial allocation of stakeholders: environment, customer,
maintainer, and communications. It leaves out the trainer stakeholder, which will be the focus of our third
requirements model.
Note that the satellite communications stakeholder has been represented as external to the A0 function
as mechanism to the provide mechanisms and the provide controls activities as well as internally
within the A1 diagram. As a modeler, the choice to be made here is between showing the activities A12
(Move Commands) and A15 (Move Data) as external to the A0 function on the A-1 diagram or internal to
the logic of the A1 diagram. If we chose to model these stakeholder activities completely external to the
A0 function, we would have needed to create an A1 diagram with a structure like the following diagram
fragment:
45
C3
C 2 B u oy C om m an d s
T ra n s m i t t e d C o m m a n d s
C 1 C o m m u n ic a t io n s P ro t o c o ls
Se n d
C o mm a nd s
S e n t C o m m a n ds
O3
71F
C o lle ct D a t a
I1
O1
22F
C o lle c t e d D a t a
Se n d D a t a
S en t D ata
O4
33F
R e ce i ve D a t a
O c e a n O be rv a t io n s
I2
T ra n s m it t e d D a t a
O2
54F
Diagram 19. RTP/FEO5, Environmental Exchange Example
Instead, we have adopted the convention that a box shaded light gray signifies an activity that is outside
the scope of the A0 function (i.e., which otherwise would be modeled on an environmental context
diagram) and represented these activities within the A1 diagram:
46
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
Requirements TO-BE Operatio ns (RTO)
1 2 3 4 5 6 7 8 9 10
12/17/2001
Reader
W orking
Draft
Date
Context:
NO NE
R ecommended
P ublication
C o m m u n ic a t io n s P ro t o c o ls
M in is t e ria l Q u e s t io n s
M i n i s t e ri a l R e q u e s t s
Se rvi ce A g re e m e n t s
p ro v id e
c o n t ro ls
B u o y Te c h n ic a l D a t a
14
R ou t e P la n n in g R e q u ire m e n t s
S y s te m S t a tu s
M a in t e n a n c e R e q u e s t
R o u t in g D e c is io n s
M a in t e n a n ce N o t ific a t io n
p ro v id e
m e ch a n is m s
2
p ro v id e
in p u t s
3
M e a s u r e d O b s e rv a b le s
t enxctt ion
of
AC0o nfu
...
M in is t e ria l R e p o r t s
x
x
00
b ro k e n b u oy
C o m m u n ic a t io n s S a t e llit e s
u se ou tp u t
R o u t e P la n
5
R ou t in g P ro d u c t s
re p a ire d b u oy
A rg o s
N W S G e n e ra l M a n a g e r
P age:
A-1
N OA A
T itle:
R o u t e P la n n e r
E n vi ro n m e n t
Sa n t a N a ri d a B u o y Sys t e m
Stakeholder Context of ...
Number:
AKB5
P. 1
Diagram 20. RTO/A-1=AKB5, Operations Stakeholders
47
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/17/2001
Reader
W orking
Draft
Date
Context:
R ecommended
P ublication
A0
C 2 B u o y C om m a n d s
Se n d
Comm and s
1
T ra n s m i t t e d C o m m a n d s
Se n t C o m m a n d s
M o ve
Com m ands
2
Co lle c t D a t a
I1
O1
3
Se n d D a t a
4
M o ve D a t a
S en t D ata
T ra n s m it t e d D a t a
5
R e ce i ve D a t a
O c e a n O b e rv a t io n s
M 1 C om m u n ic a t io n s S a t e llit e s
P age:
A1
T itle:
M easure Ocean Observables
Diagram 21. RTO/A1 Measure Ocean Observables
We also prepare a third model for the trainer stakeholder:
48
Number:
AKB6
P. 5
O2
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
Requirements TO-BE Training (RTT)
1 2 3 4 5 6 7 8 9 10
12/17/2001
W orking
Draft
Reader
Date
Context:
NO NE
R ecommended
P ublication
P e rfo rm a n c e F e e d b a c k
c o n t ro l b u n d le
p ro v id e
c o n t rols
14
U n t ra in e d P e o p le
Tra in in g R e q u ire m e n t s
p ro v id e
m e c ha n is m s
2
in p u t b u n d le
p ro v id e
in p u t s
3
o u t p u t re q u e s t
AC0o nfut e
nxc tt io
o fn
...
00
u se ou tp u t
Tra in e d S t a ff
re s u lt s
re s u lt s
5
o u t p u t b u n d le
s t a k e h o ld e r o
s t a k eh o ld e r c
P age:
A-1
s t a k e h o ld e r i
Tra in e r
T itle:
S a n t a N a rid a B uo y S y s t e m
Number:
AKB5
P. 1
Diagram 22. RTT/A-1, Training Stakeholder
You should have observed in these steps a typical approach to integrating stakeholders into a
requirements models A-1 diagram. This approach proceeds by coalescing or partitioning boxes and by
bundling or unbundling objects, that is, by adjusting the level of abstraction of boxes and arrows first
presented in the individual stakeholder diagrams. If typical patterns hold, you will more likely coalesce
boxes and bundle objects, i.e., create environmental context diagrams that are at a higher level of
abstraction than the A0 diagrams of the individual stakeholder models.
Determining Decomposition Strategy
You are now ready to investigate the behaviors inside the A0 function that will provide the outputs
needed by the stakeholders of the prospective system.
We will return to the requirements models and decompose the A0 function. We will start with the three
requirements models we have built so far. When we revisit them, we will first assign a name to the A0
function in each model and complete the A-0 diagrams. We also need to determine our decomposition
strategy, including stopping rules. A useful decomposition strategy is our purpose to decompose to a level
at which end-to-end scenarios can be discerned to satisfy the requests of specific external stakeholders, in
other words, to a level at which behavior can be disambiguated across scenarios.
49
Validation/Verification. If we have been successful, each of the stakeholders identified by the separate
stakeholder models (and possible additional stakeholders newly identified) will be explicitly identified as
a mechanism for an A-1n or a tunneled mechanism for an An function (but not yet for the a models A0
function!) in at least one model within the family of requirements models. Each stakeholder behavior will
produce an output that may be readily interpreted as a result of using the outputs of the prospective
system.
Step 5. Developing Requirements Models
Now we will decompose the requirements models for which we have sketched A-1 diagrams. In the next
several pages we will look at a decomposition of requirements for behavior that will product System
Products.
We revisit the A-1 diagram to provide names for and renumber its activities now that we feel we
understand that context:
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
Re quire me nts TO -B E Products (RTP)
1 2 3 4 5 6 7 8 9 10
12/20/2001
Working
Draft
Recommended
P ublication
Reader
Date
Context:
N O NE
I n t e r n e t Pro t o c o ls
c o n t r o l re q u e st
Da t a Sh a r in g Ag r e e m e n t s
inSpcuht erdeuqle
u se st
p e rf o rma n c e f e e d ba c k
Co n t r ol
Pro d u c t io n
1
W e a t h e r M o d e l Da t a Re q u ire m e n t s
I m a g e St a n d a r d s
r e su lt s f e e d b a c k
Pla n e t a r y Ob s e r v a b le s
Pro v ide
I m a g e ry
3
Pr o d u c t Re q u e st s
Pro v id e
Sa t e llit e I m a g e ry
Ob se r v a b le s
2
Ge n e ra t e
M e t e o r o log ic a l
Pr o d u c t s
M e a su r e d Ob s e r v a b le s
Fo re c a st Pr o d u c t s
Ob se r v a t io n Sp e c ific a t io n s
Da t a se t Sp e c if ic a t io n s
Da t a s e t Pro d u c t s
Oc e a n Ob se r v a ble s
00
Oc e a n I m a g e r y
Fo r e c a s t T e x t
Filt e r e d Da t a se t s
Use
M e t e o ro lo g y
Pr o d u c t s
Un f ilt e r e d Da t a s e t s
W eat her Show

T su n a m i W a r n in g
Re s e a r c h Pr od u c t s
S a n t a Na r id a Bu o y Sy st e m
En v ir o n m e n t
P age:
A-1
Title:
GOOS Sy s t e m
A rg o s Sy s t e m
Na t io n a l W e a t h e r Se r v ic e
Stakeholder Context of Meteorological P roduct Generation
I n st it u t e S c ie n t is t
T su n a m i W a rn in g Ce n t e r
T e le v isio S a n t a Na rid a
Number:
AKB5
Diagram 23. RTP/A-1 (Stakeholder Context of Meteorological Product Generation)
50
S p ec if ic a t io n s
P. 1
x
x
x
The A-0 diagram now models the scope of the operational behavior of our prospective system. (The
activity A-11 (Control Production) is also within the scope of the whole system but, at least given our
current understanding, implementation of the A-11 activity does not require acquisition of hardware or
software components particularly crafted for the purposes of the Santa Narida Buoy System).
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/20/2001
Reader
Working
Draft
Recommended
P ublication
Date
Context:
Top
TOP
V iewpoint: S ystems E ngineer as Requirements E licitor.

P urpose: To specify minimal and sufficient behaviors
leading necessarily to a coherent set of related
outputs required by external stakeholders.
Co m m u n ic a t io n s Pr o t o c o ls
I m a g e St a n d a r d s
Da t a S h a rin g A g ree m e n t s
S c h e d u le s
Pro d u c t Re q u e st s
M e t e o r o lo g y Da t a Re q u ir e m e n t s
M e t e o r o lo g y Da t a S t a n d a rd s
Oc ean
Oc e a n Obse r v a b le s
S a t e llit e I m a g e r y
M e a s u re d Ob se rv a b le s
Ge n e ra t e
M e t e o r o lo g ic a l
Pr o d u c t s
M e t e o r o lo g ic a l Pro d u c t s
S at ellit e Im ag ery
S p e c if ic a t io n s
Meas ured
M e t e o ro lo g ical Pr o d u ct s
Sp e cif i c a t io n s
00
W e a t h e r Fo re c a st e r s
Na t io n a l W e a t h e r S e r v ic e
Ar g o s Sy st e m
S a n t a Na r id a Bu o y S y s t e m
P age:
A-0
Title:
Context of Meteorological P roduct Generation
Number:
AKB1
P. 2
Diagram 24. RTP/A-0 (Context of Meteorological Product Generation)
Some observations that may help you understand diagram RTP/A-0 as it has been developed:
The Santa Narida Buoy System is shown as a system mechanism but is immediately tunneled
away. Of course, this tunneling violates an explicit injunction of IEEE 1320.1, the IDEF0
standard. We deliberately break this rule here to emphasize that the A0 activity that we are
considering is performed in the main by the Santa Narida Buoy System but to preclude showing
mechanism detail within decomposition diagrams because this is a requirements model
The Argos System and the National Weather Service are shown as mechanisms to the A0
function. You will recall that these have been identified and modeled as external stakeholders, yet
there are certain functions performed by these stakeholders that are more readily represented
within the scope of the model than by a series of interchanges with the A0 function at the A-0
level. These functions are indicated by shaded boxes within the model itself.
51
The label Weather Forecaster is attached to the National Weather Service mechanism to indicate
that it is this specific element of that Service which is of interest within the scope of the A0
function.
Looking ahead, the A-1 term Internet Protocols has been generalized to Communications
Protocols. Similarly, the A-1 term Weather Model Data Requirements has been generalized to
Meteorology Data Requirements. These changes were made during decomposition analysis. The
names of these controls were not changed in the A-1 diagram; again, this is a violation of IEEE
1320.1 that we have allowed here to illustrate the traceability between specific terms and more
abstract terms as a model evolves in working diagrams. (We would severely criticize this
violation were publication status asserted for this or any other model.)
The outputs Forecast Products and Dataset Products have been bundled together as
Meteorological Products. We created Meteorological Products as a better abstraction at the A-0
diagram level. As with the previous point, this is a violation of IEEE 1320.1 that would not be
acceptable in a publication status model, but we allow it here to demonstrate the forming of such
abstractions.
Decomposing to the A0 diagram, we focus attention on activities logically needed to produce the required
outputs:
Used at:
Author:
P roject:
M odel:
Notes:
12/20/2001
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
Reader
W orking
Draft
Date
Context:
R ecommended
P ublication
A-0
C 4 S c h e d u le s
C 6 M e t e o ro lo g y D a t a R e q u ire m e n t s
C 5 P ro d u c t R e q u e s t s
C 3 D a t a S h a rin g A g re e m e n t s
C 7 M e t e o ro lo g y D a t a S t a n d a rd s
C 2 I m a g e S t a n d a rd s
I1
M e a su r e O ce a n
W e a th e r
C h a r a cte r istics
O1
1
P ro vi d e
Datasets
M e t e o ro log ic a l P ro d u c t s
2
Fil te r
Data sets
3
F o r e ca st
W e a th e r
I2
4
1 It seems perhaps that schedules and

product requests might be bu ndled;
meteorology data requirements an d data
sharing agreements might be bundle d; and
meteorology data standards and image
standards might be bu ndled.
M 2 A rg o s S y s t e m
P age:
52
A0
T itle:
Generate Meteorological P roducts
M3
W e a t h e r F o re c a s t e rs
Number:
AKB15
P. 3
O3
O2
Diagram 25. RTP/A0 (Generate Meteorological Products)
Some observations that may help you understand diagram RTP/A0 as it has been developed:
This diagram illustrates a useful development convention. You will notice that many of the
control arrows are rendered in light gray rather than the customary black. These gray arrows
indicate a control (or mechanism) that (1) is attached to every box in the diagram and (2) has no
arrow segment that is distinguished by an attached label. This convention serves two purposes.
First, it allows these controls to visually recede and so emphasizes controls which convey more
information.4 Second, it visually reminds us that these controls are bundles of more specific
controls that have not yet been sufficiently analyzed. In general, a publication status model has
does not contain any grayed-down control arrows.
The very mass of gray control arrows suggests a possible modeling problem, such as representing
controls or functions at too low a level of abstraction.5
Some comments about possible generalization and abstraction of these control are included in the
diagram as a reader note, indicated by the circle (well, oval) with the number 1 inside it. This is
to be distinguished from a model note, which is indicated by a square (well, rectangle) with a
number inside. A model note adds information to the meaning of the diagram; it is part of the
diagram itself and is said to be in the diagram. In contrast, a reader note comments on the
development of the meaning of a diagram; when the issue raised by a reader note is resolved, the
reader note is removed. A reader note is about the diagram and is not part of the diagram; it is
said to be on the diagram.
Only mechanisms previously identified as external stakeholders appear in this diagram.
We can decompose the A1 activity as:
Following Bateson, information is a difference that makes a difference. Grayed control arrows show no
differences.
5
Indeed, we will find that the A0 diagram in the final architectural model RTP looks quite different!
53
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
C2
12/20/2001
Working
Draft
Recommended
P ublication
M e t e o ro lo g y Da t a Re q u ire me n t s
C 3 P ro d u c t Re q u e s t s
Reader
Date
Context:
A0
C 6 M e t e o ro lo g y Da t a S t a n d a rd s
C 4 Da t a S h a rin g A g re e me n t s
Da t a C o lle c t io n C o mma n d s
C o n t ro l Da t a
C o lle c t i o n
I1
M e a s u re
O b s e rv a b le s
M e a s u re d O b s erv a b le s
O1
C o lle c t e d Da ta
T ra n s mit
C o lle c t e d
Da t a
O2
3
P age:
A1
Title:
Measure Ocean Weather Characteristics
Number:
AKB16
P. 4
Diagram 26. RTP/A1 (Measure Ocean Weather Characteristics)
The following diagrams decompose the three activities in the A1 diagram. Note that the Argos System
mechanism terminates in diagram A11 and in A13. The activity boxes to which this mechanism attaches
are shaded gray in both diagrams, indicating behavior that is actually outside the scope of the prospective
system.
54
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
OOASIS SE
Rev:
1 2 3 4 5 6 7 8 9 10
12/20/2001
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A1
In t e rn e t P ro t o c o ls
Ge n e rat e
C o mma nd s
1
U n se n t C o mma n ds
S e nd
C o mma nd s
2
S e n t C o mma n d s
Re la y
C o mma n d s
3
Re la y e d C o mma n d s
Re c e iv e
C o mma n d s
O1
P age:
Title:
A11
Number:
Control Data Collection
AKB17
P. 5
Diagram 27. RTP/A11 (Control Data Collection)

Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/10/2002
C2
Working
Draft
Recommended
P ublication
Reader
Date
A1
C1
C3
M e t e o ro lo g y Da t a S t a n d a rd s
S e nse
I1
Context:
O1
O b s e rv a b le s
M e a s u re me n t s
Ga t h er
M e a s u re me n t S e t
P a c ka g e
Da t a
C o lle c t ed Da t a
O2
P age:
A12
Title:
Measure Observables
Number:
AKB18
P. 6
Diagram 28. RPT/A12 (Measure Observables)
55
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/20/2001
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A1
C 3 Da t a S h a rin g A g re e me n t s
S e n d Dat a
I1
C o lle c t e d Da t a
S e n t Da t a
Re la y Da t a
Re la y e d Da t a
Re c e i v e Da t a
O1
P age:
A13
Title:
Transmit Collected Data
Number:
AKB19
P. 7
Diagram 29. RTP/A13 (Transmit Collected Data)
The next two diagrams show the decompositions of A2 (Provide Datasets) and A4 (Forecast Weather).
Note in A4 that the mechanism Weather Forecaster is mechanism to two activities, but that only box A4.2
is shaded. The lack of shading on box A4.1 indicates that we are currently assuming that the Weather
Forecaster and the prospective system will both be needed to carry out this activity. It may be that the
weather models or other tools needed by the Weather Forecaster to execute weather models may be
provided by and be part of our system.
56
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/20/2001
W orking
Draft
Reader
Date
Context:
R ecommended
P ublication
A0
C 4 C o m m u n ic a t ion s P ro t o c o ls
I1
Sa ve
O b s e rva t i o n s
O1
S a v e d O b s e rv a t io n s
C re a t e
D at a s e t s
S aved D atasets
R e t ri e ve
Datasets
O2
3
P age:
A2
T itle:
P rovide Datasets
Number:
AKB20
P. 8
Diagram 30. RTP/A2 (Provide Datasets)
57
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/20/2001
W orking
Draft
Date
Context:
R ecommended
P ublication
Reader
A0
W eath er D ata
I1
Ru n W e a t h e r
M o d e ls
W ri t e
W e a the r
Scri p t
O2
2
G e n e ra t e
Sym b o l i c
Im a ge s
O c e a n O v e rla y s
Co m bin e
Im a ge s
I2
O1
M 1 W e a t h e r F o re c a s t e rs
P age:
A4
T itle:
Forecast Weather
Number:
AKB21
P. 9
Diagram 31. RTP/A4 (Forecast Weather)
Step 6. Developing Architectural Models

Having verified the reasonableness and usefulness of this requirements model, our next task is to
transform the requirements model into an architecture model. We do this by allocating each activity to
some physical means, preferably without using names that imply an implicit choice between hardware,
software, or some combination of hardware and software. (Engine and Processor turn out to be useful
words for naming these abstract components.)
As we allocate mechanisms to transformational behaviors, we apply a new decomposition stopping rule.
We will decompose to a level at which each activity has only one abstract component of the prospective
system as mechanism, other than human or organizational agents. Bear in mind that an abstract
architectural component may encompass hardware, software, and other wares. Generally this means that
an architecture model will have more diagrams than its source requirements model. However, grayeddown mechanism arrows in a diagram may indicate a decomposition that exceeds the needs of
architecture analysis.
As usual, we start with the A-1 environmental context diagram. As you can see, this A-1 diagram
incorporates the generalizations and abstractions introduced into the A-0 diagram of the corresponding
requirements model. We have not yet removed all grayed-down arrows in this diagram; these elements
58
will remain until we decide finally that the concepts they represent are not to be incorporated into our
prospective systems interactions with its external environment.
This diagram reflects what has been learned during the allocation of components to activities in the
models decomposition diagrams. For example, the output A-1.1O1 (Data Sharing Agreements) is now
recursive on A-1.1; analysis during architecture development we realized that the effective meaning of
data sharing agreements for the controlled components is effectively captured by the concepts of
Schedules and Meteorology Data Requirements.
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
Architecture TO-BE Pro ducts (ATP)
1 2 3 4 5 6 7 8 9 10
12/20/2001
Reader
W orking
Draft
Date
Context:
NO N E
R ecommended
P ublication
c o n t rol re q u e s t
C o m m u n ic a t io n s P ro t o c ols
incphuetd re
qsu e s t
S
u le
D a t a S h a rin g A g re e m e n t s
C o n t ro l
P ro d u c t io n
14
M e t e o ro lo g y D a t a R e q u ire m e n t s
P ro vi d e
i m a g e ry
3
P ro v id e
Ob s e rv a b le s
C on text of
G e n e ra t e
M
rolo
Me
e tt e
eo
oro
log
g ic
ic a
a ll
ro duucctts
PProd
G e n e ra t io n
M e a s u re d O b s e r v a b le s
00
Use
Me t e o ro l o g y
P ro d u ct s
W eath er S h ow
A rg o s S y s t e m
E n v iro n m e n t
P age:
A-1
T itle:
G O O S S ystem
Stakeholder Context of Meteorological P roduct Generation
x
x
x
Number:
AKB5
P. 1
Diagram 32. ATP/A-1 (Stakeholder Context of Meteorological Product Generation)
The following diagram shows the current state of the A-0 diagram in our architectural model. This
diagram differs the A-0 diagram of the requirements model in the following ways:
The prospective system is no longer tunneled away at the boundary of the 0 box. The primary
purpose of the architectural model is to explore abstract components for the prospective system to
which system behavior can be allocated, so the tunneling used in the requirements model is no
longer appropriate.
Upon allocation analyses, the output Specifications has been bundled into the existing concept of
Meteorology Products.
59
A minor point: the label Meteorology Products was Meteorological Products in the requirements
model. This label was changed to be consistent in construction with other labels on the A-0
diagram.
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
Archite cture TO -B E Products (ATP)
1 2 3 4 5 6 7 8 9 10
12/20/2001
Working
Draft
Recommended
P ublication
Reader
Date
Context:
Top
TOP

Co m m u n ic a t io n s Pr o t o c o ls
I ma g e St an d a rd s
Sch e d u les
Pr o d u c t Re q u e st s
M e t e o r olo g y Da t a Re q u ire m e n t s
M e t e o ro lo g y D a t a S t a n d a rd s
Oc ean
S at ellit e Im ag ery
Oc e a n Obse r v a b le s
S at ellit e I m ag er y
M e a s u re d Ob se r v a b le s
G en er at e
M et eo r o lo g ical
Pr o d u ct s
Met eo r o lo g y Pr o d u ct s
Meas ured
M et e o ro lo g y Pro d u ct s
00
W e a t h e r F o re ca s t e r
Na t io n a l W e a t h e r S e rv ic e
P age:
A-0
Title:
Context of Meteorological P roduct Generation
Number:
AKB1
P. 2
Diagram 33. ATP/A-1 (Context of Meteorological Product Generation)
In the following diagram, we decompose the A0 function. Here we see significant changes that emerged
as we contemplated the allocation of behaviors to abstract components. The three activities of the
requirements diagram that modeled the different kinds of output required by different kind of users have
been replace by one activity to create meteorology products and another to distribute them. The A2
function is now parent to the original three activities; the decomposition of the A2 function will reveal
those activities.
We were moved to make this change as we considered mechanisms for moving product to user. We could
choose either to develop a distribution function in each of the original activities or to encapsulate
distribution in its own activity. Clearly, the second choice has several advantages:
60
The mass of controls that once branched from their boundary ICOM codes to every activity has
disappeared. There is now only one branching gray arrow in this diagram.
The concept of Product Requests has localized to the distribution activity; distribution of any
product occurs when it is requested (data pull). Schedules still drive data push.
Received Requests and Tasking now can propagate user needs all the way back to the buoys. This
also provides a clearer understanding of what drives activity A11 (Control Data Collection).
The decomposition of A3 (Distribute Products) now can adequately treat the relationship between
users and Specifications.
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/21/2001
Reader
Working
Draft
Recommended
P ublication
C 5 M e t e o ro lo g y Da t a Re q u ire me n t s
A-0
C 2 Ima g e S t a n d a rd s
I1
O b s e rv a b le s
Context:
Date
T a s kin g
O1
Re c e iv e d Req u e s t s
1
Ge n e ra t e
M e t e o ro lo g y
P ro d u c t s
S a t e llit e Ima g e ry
I2
2
Re a d y S p e c if ic a t io n s
Co n t ro l P a n e l
Re a d y P ro d u c t s
Dis t rib u t e
P ro d u c t s
M e t eo ro lo g y P ro d u c t s
O2
Bu o y
Bro w se r
P age:
A0
Title:
M3
W e a t h e r F o re c a s t e r
Number:
AKB15
P. 3
Diagram 34. ATP/A0 (Generate Meteorological Products)
Here at the A0 level, the Santa Narida Buoy System is disaggregated only for the first box; the modeling
reasons for this will be evident when you look at the decomposition diagrams A2 and A3. In the A2
diagram, at least one branch of the Santa Narida Buoy System mechanism is not yet ready to be
disaggregated. In the A3 diagram, this mechanism is unbundled into eight branches, which is too many to
show on this parent diagram.
Note that the arrow 1M4 (Browser) should have some relationship with the arrow 1C3 (Communications
Protocols). In other words, if we postulate a Browser, the Communications Protocols should tie this
Browser and our use of it to Internet standards.
61
The Browser and the Buoy mechanisms are fairly obvious references to physical components: Browser to
COTS software and Buoy to a floating sensor platform. In contrast, the Control Panel mechanism
represents an abstract component whose nature is not intuitively or experientially obvious: it is a posited
device for exerting some element of system control.
The next diagrams detail the behavior of activity A1:
Used at:
Author:
P roject:
Model:
Notes:
AKBocast
Date:
OOASIS SE
Rev:
1 2 3 4 5 6 7 8 9 10
12/21/2001
W orking
Draft
Reader
Date
Context:
R ecommended
P ublication
C 1 M e t e o ro lo g y D a t a
C 5 T a s kin g
A0
C 3 C om m u n ic a t io n s
C 2 M e t e o ro log y D a t a
D a t a C o l l e ct i o n C o m m a n d s
C o n t ro l D at a
C o l l e ct io n
I1
M e a s u re
O b s e rva b l e s
O1
T ra ns m i t
C o l le ct e d
Data
O2
3
R e c e iv e r
T ra n s m it t e r
S e n s o r S u it e
M 2 B u oy
M 4 B ro w s e r
M 3 C on t ro l P a n e l
P age:
A1
T itle:
M1 A rg o s
Measure Ocean Observables
Number:
AKB16
Diagram 35. ATP/A1 (Measure Ocean Observables)
62
P. 4
Used at:
Author:
P roject:
Model:
Notes:
AKBocast
Date:
OOASIS SE
Rev:
1 2 3 4 5 6 7 8 9 10
12/21/2001
W orking
Draft
Reader
Date
Context:
R ecommended
P ublication
A1
C 2 T a s k in g
S a t e llit e P ro t oc o ls
I n t e rn e t P ro t o c o ls
G e n e ra t e
Comm ands
1
U ns e n t C o m m a n d s
Se n d
Com m ands
2
S en t C om m an d s
R e la y
Com mands
3
R e la y e d C o m m a n d s
R e ce i ve
C o m m a n ds
D a t a C o ll e c t io n C o m m a n d s
O1
M 1 C o n t ro l P a n e l
P age:
M 3 B row s e r
T itle:
A11
M 4 R e c e iv e r
Number:
AKB17
P. 5
Diagram 36. ATP/A11 (Control Data Collection)

Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/10/2002
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A1
C 1 Da t a C o lle c t io n C o mma n d s
S e nse
I1
O b s e rv a b le s
O1
Ga t h er
M e a s u re me n t S e t
P a c ka ge
Da t a
S e n s o rs
C o lle c t ed Da t a
O2
Meas u r em en t Pr o ces s o r
M 1 S e n s o r S u it e
P age:
A12
Title:
Measure Observables
Number:
AKB18
P. 6
Diagram 37. ATP/A12 (Measure Observables)
63
Used at:
Author:
P roject:
Model:
Notes:
AKBocast
Date:
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/21/2001
W orking
Draft
Reader
Date
Context:
R ecommended
P ublication
A1
C 1 C o m m u n ic a t io n s P ro t oc o ls
I n t e rn e t P ro t o c o ls
Se n d D a t a
I1
S en t D ata
R e la y D a t a
R e la y e d D a t a
R e cei ve D a t a
O1
M 3 Tra n s m it t e r
P age:
A13
T itle:
T ransmit Collected Data
M 2 B ro w s e r
Number:
AKB19
P. 7
Diagram 38. ATP/A13 ( Transmit Collected Data)
Note that in the diagrams for the leaf nodes A11, A12, and A13 we see that there is one allocated
component for each identified activity. This resolution of mechanisms to one per activity suggests that
our decomposition is sufficiently detailed for an architecture model.
In the next diagram, we have a decomposition of the A2 function. Here we see three activities that were
originally in the A0 diagram of our requirements model. The mass of gray control arrows has been greatly
reduced. Now we also see Dataset Requests as feedback linking more sophisticated products to their
source datasets.
64
Used at:
Author:
P roject:
M odel:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/21/2001
W orking
Draft
Reader
Date
Context:
R ecommended
P ublication
A0
C 5 R e c e iv e d R e q u e s t s
C 2 M e t e o ro log y D a t a S t a n d a rd s
D ataset R eq u ests
C3 I m a g e S t a n d a rd s
G e n e ra t e
Datasets
I1
Ta s k in g
O1
R e a d y S p e c ific a t io n s
O2
R e a d y P ro d u c t s
O3
1
Fi l t e r
Datasets
2
Oc e a n I m a g e ry
Fo r e ca st
W e a th e r
I2
3
D a t a ba s e E n g in e
F ilt e r
M 1 W e a t h e r F o re c a s t e r
M 2 S a n t a N a rid a B u o y S y s t e m
P age:
A2
T itle:
Generate Meteorology P roducts
Number:
AKB22
P. 8
Diagram 39. ATP/A2 (Generate Meteorology Products)
As we allocate components here, attention is drawn to the need for a Database Engine to support A2.1
(Generate Datasets) while other components of the buoy system remain bundled. To carry out A2.2 (Filter
Datasets), the need for a Filter of some sort has been recognized. A22 has not been further decomposed
because support for this activity has already been allocated to a single mechanism. In contrast, the buoy
system remains bundled as mechanism to A2.3 (Forecast Weather); we will need to decompose this
function to understand the system components that appear to be needed for this activity.
The next diagram reveals the decomposition of A21 (Generate Datasets). Note that here the set of
mechanism arrows branching from the boundary ICOM code M1 (Santa Narita Buoy System) has been
grayed down. Just like similar control constructs, the gray-down convention has been used here to
indicate that this mechanism applies undifferentiated to every box in the diagram. Applied to a
mechanism, the convention conveys that a Database Engine underlies our prospective systems ability to
save raw data, process raw data into usable datasets, and make those datasets available to users as
required. Gray control arrows generally indicate that analysis of those controls is not yet complete; this is
generally not a supposition for gray mechanism arrows.
65
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/05/2002
Working
Draft
Recommended
P ublication
C 3 M et e o ro lo g y Da t a S t a n d a rd s
Reader
Date
Context:
A2
C 4 Da t a s e t Re q u e s t s
C 2 Re c e iv e d Re q u e s t s
I1
Save
O b s e rv a t io n s
O2
1
C re a t e
Dat asets
Re t rie v e
Da t a s e t s
S a v e d Da t a s e t s
T a s kin g
O1
U n f ilt e re d Da t a s e t s
O3
3
O b s e rv a t io n P ro c e s s o r
Da t a s e t P ro c e s s o r
P ro d u c t P ro c e s s o r
A ctivation rules for A213:

*1 : I1 O2
*2 : ~ I1 O1
M 2 Da t a b a s e E n g in e
P age:
A21
Title:
Generate Datasets
Number:
AKB20
P. 9
Diagram 40. ATP/A21 (Generate Datasets)
Because Database Engine applies undifferentiated to each activity, its presence in the company of an
object processor for each activity would not normally prompt us to decompose these activities. However,
because our goal is to identify such information as is needed to produce an NDC diagram for our
prospective system, our decomposition objective in this model is to decompose to a level where each
activity has only one component of the prospective system as mechanism.
Note that the respective sources of the unbundled Specifications seen in the A-1 diagram are identified
here.
A model note has been associated with box A21.3 to specify the functions activation rules. Activation
rule 1 asserts that the activity will provide a dataset (apparently without changing it) if an appropriate
dataset is available when the activity is triggered by any sort of request. However, if an appropriate
dataset is not available when the activity is triggered, activation rule 2 asserts that the activity will
generate tasking to fill that void. (For more on activation rules, see Appendix E.)
The next three diagrams show decompositions of the activities in the A21 diagram. These decomposition
diagrams are new; they are extensions to the products requirements model that support architectural
analysis, here specifically to support OOASIS NDC diagrams.
66
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/05/2002
Reader
Working
Draft
Recommended
P ublication
Date
Context:
A21
A 211.1 seems to be an activity which will require

active involvement of human intelligence, with skill
and expertise in specification and application of
meteorology data standards.
S p ecify
O b s erv at io n
D at a S t an d ar d s
O1
1
Da t a E le me n t M e t a d a t a
O b s e rv a t io n s S c h e ma
I1
Prep ar e
O b s erv at io n s
C le a n O b s e rv a t io n s
M ain t ain
O b s e rv at io n s
O2
M 1 O b s e rv a t io n P ro c e s s o r
P age:
A211
Title:
Save Observations
Number:
AKB24
P . 10
Diagram 41. ATP/A211 (Save Observations)
Not surprisingly, we observe that the structure of activities within A211 and A212 are topologically the
same when these activities are decomposed. We also note the reader notes (supplied by the modeler but
not part of the model) A211.1(1) and A212.1(1). These notes suggests that a human agent should be
identified as a mechanism for these activities in the next step of analysis, that is, when we identify internal
stakeholders, human and organizational agents of the prospective system. A similar reader note with
similar implications will also be found on diagram A213.
67
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
Working
Draft
Recommended
P ublication
01/05/2002
Reader
Date
Context:
A21
A212.1 seems to be an activity which will require

and expertise in specification and application of
meteorology data standards.
S p e cify
D at as et D at a
S t an d ard s
O1
Da t a s e t M e t a d a t a
Da t a s e t S c h e ma
Pre p ar e
D at as e t s
I1
M ain t ain
D at as et s
O2
M 1 Da t a s e t P ro c e s s o r
P age:
Title:
A212
Number:
Create Datasets
AKB25
P . 11
Diagram 42. ATP/A212 (Create Datasets)
Used at:
Author:
P roject:
Model:
Notes:
Date
Rev:
1 2 3 4 5 6 7 8 9 10
01/05/2002
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A21
C a t a lo g
I1
A 213.1 seems to be an activity which will require

and expertise in specifying and crafting
meteorological data products.
S p e cify
Pr o d u ct s
T a s kin g
O1
1
Da t a s e t S e le c t io n
P ro d u c t C o n s t ru c t io n Ru le s
P ro d u c t P ro p e rt ie s
R e t r ie ve
D at a s et s
2
Re t rie v e d Da t a s e t s
Pack age
D at as et s
P age:
68
A213
Title:
Retrieve Datasets
M 1 P ro d u c t P ro c e s s o r
Number:
P . 12
O2
Diagram 43. ATP/A213 (Retrieve Datasets)
The next diagram shows the activities and their mechanisms needed to forecast weather:
Used at:
Author:
P roject:
M odel:
Notes:
12/21/2001
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
W orking
Draft
Reader
Date
Context:
R ecommended
P ublication
A2
C 3 M e t e o ro log y D a t a S t a n d a rd s
W eath er D ata
I1
Ru n W e a t h e r
M o d e ls
O1
2
W ri t e
W eather
Scri p t
O3
O c e an O v e rla y s
1
G e n e ra t e
Sym b o l i c
Im a ge s
Co m b i n e
Im a ge s
I2
W e a t h e r M o d e ls
W e a t h e r V ie w e r
I m a g e G e n e ra t o r
O2
4
I m a g e P ro c e s s o r
M2
P age:
A23
T itle:
Forecast Weather
M 1 S a n t a N a rid a B u oy S y s t e m
Number:
AKB21
P . 10
Diagram 44. ATP/A23 (Forecast Weather)
Again we have stopped decomposition at this level because each activity could be allocated to a single
abstract component that could be unbundled from the prospective system. As before, the gray box
signifies an activity performed by an external actor outside the boundaries of our system. In contrast, this
diagram now affirmatively asserts that Weather Models used to generate weather forecasts using buoycollected data are indeed part of the Santa Narida Buoy System. (We might want to retain some residual
skepticism about this assertion.)
Now we look at the allocation of mechanisms for the A3 activity, Distribute Products. In the A3 diagram,
we can see that dual mechanisms have been allocated to three of the four activities in A3. In consequence,
the architecture model decomposes beyond the requirements model for further understanding; every
activity in the A3 diagram has been decomposed in the architecture model, as shown in the next diagram.
69
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
Reader
Working
Draft
Recommended
P ublication
01/05/2002
Context:
A0
Date
E ma il P ro t o c o ls
P ro d u c t C a t a lo g
W e b P ro t o c o ls
I2
P ro d u c t O rd e r
F u lf ill
O rd e rs
Re c e iv e d Re q u e s t s
O1
1
S t a g e d P ro d u c t s
Stage
P ro d u c t s
O2
W e b Re q ue s t s
Post
P ro d u c t s
I1
3
E ma il
P ro d u c t s
Lo c a l A re a Ne t w o rk
4
W e b s it e
O rd e r De s k
P ro d u c t io n S e rv e r
W e b S e rv e r
M a il C o mp o s e r
M a il S e rv e r
P age:
A3
Title:
Distribute P roducts
Number:
AKB23
P . 14
Diagram 45. ATP/A3 (Distribute Products)
The new decomposition diagrams are shown as the next four diagrams. Note that the single mechanism
attached to A3.1 is disaggregated in diagram A31.
Diagrams ATP/31 and ATP/32 contain only two boxes. This is allowed by IEEE 1320.1, wherein the
allowable number of boxes in a decomposition diagram is established as between 2 and 9. In general we
should note that best IDEF0 modeling practices still follow the original FIPS PUB 184 limits: at least
three boxes but no more than six boxes. Here we have invoked the less restrictive IEEE 1320.1 rule
because our immediate interest is to match mechanisms to activities. The presence of only two boxes in
these diagrams is a flag to other systems engineers that we are have not yet really completed our analysis
of these activities.
70
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
Archite cture TO-B E Products (ATP)
1 2 3 4 5 6 7 8 9 10
01/05/2002
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A3
C 3 W e b Re q u e s t s
I1
C o lle ct
R e q u es t s
O1
1
O rd e r S p e c if ic a t io n
C ollect Requests should be done across a

variety of modalities, from face-to-face
conversation, telephone, FA X, email, etc. A t a
later point in analysis, these should be
explored by diagrams invoked by a call arrow.
O r d er
Pro d u ct s
O2
2
Re q u e s t L o g g e r
O rd e r L o g g e r
M1
P age:
Title:
A31
O rd e r De s k
Number:
Fulfill Orders
AKB29
P . 15
Diagram 46. ATP/A31 (Fulfill Orders)
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocst
OOASIS SE
Rev:
1 2 3 4 5 6 7 8 9 10
01/05/2002
Reader
Working
Draft
Recommended
P ublication
C 1 P ro d u c t O rd e r
Date
Context:
A3
S t ag e
R e ad y
Pro d u ct s
I1
Ne t w o rk Re a d y P ro d u c t s
Pro v id e
Pr o d u ct
A cces s
O1
M 2 P ro d u c t io n S e rv e r
P age:
A32
Title:
Stage P roducts
M 1 L o c a l A re a Ne t w o rk
Number:
AKB28
P . 16
71
Diagram 47. ATP/A32 (Stage Products)

Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/05/2002
Working
Draft
Recommended
P ublication
C 1 P ro d u c t O rd e r
Reader
Date
Context:
A3
C2
C 3 W e b P ro t o c o ls
I1
S e le ct W e b
Pr o d u ct s
W e b Re q u e s t s
O1
F u lf illme n t A n o ma lie s
P ro d u c t S e le c t io n s
Pu b lis h
Pag e
I2
2
A v a ila b le U RL
S e rv e
Pag e
M e t e o ro lo g y P ro d u c t s
M 1 W e b s it e
P age:
A33
Title:
P ost P roducts
M 2 W e b S e rv e r
Number:
Diagram 48. ATP/A33 (Post Products)
72
AKB27
P . 17
O2
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
C1
01/05/2002
Working
Draft
Recommended
P ublication
Date
Context:
A3
C 2 E ma il P ro t o c o ls
A Fulfillment Technician
may be an appropriate
mechanism for A34.1.
Reader
E ma il P ro p e rt ie s
S p e cify
E m ail
Pr o d u ct
1
E ma il C o n t e n t S p e c if ic a t io n
E ma il De liv e ry S p e c if ic a t io n
E ma il M e s s a g e s
I1
C o n s t ru ct
E m ail Pro d u ct
M e s s ag e
E m ail
Pro d u ct
Mes s a g e
O1
M 1 M a il C o mp o s e r
P age:
A34
Title:
Email P roducts
M 2 M a il S e rv e r
Number:
AKB26
P . 18
Diagram 49. ATP/A34 (Email Products)
At this point, our architecture model has been decomposed to the point at which the behavior of any given
activity may be allocated to a mechanism representing a single abstract component. Our next iteration
through this architecture model will focus on identifying internal stakeholders who might become actors
in OOASIS use case analyses. To identify such stakeholders, we work from leaf nodes back up to the A0
diagram.
Our analysis suggests that several activities in this model seem to uniquely call for the participation of
human roles. We see all these participants identified in our A0 diagram; later we see that the Product
Engineer role bundles a Data Engineer role.
73
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/06/2002
Reader
Working
Draft
Recommended
P ublication
A-0
I1
O b s e rv a b le s
Context:
Date
T a s kin g
O1
1
Ge n e ra t e
M e t e o ro lo g y
P ro d u c t s
I2
2
B uoy
Sy s t e m C o n t ro lle r
Dis t rib u t e
P ro d u c t s
P ro d u ct E n g in e e r
Fu lfillm e n t Te ch n icia n
P age:
A0
Title:
M3
Number:
AKB15
Diagram 50. ATP/A0 (Generate Meteorological Products) with System Agents
We see where these internal stakeholders are mechanisms in the following sequence of diagrams:
74
P. 3
O2
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/06/2002
Reader
Working
Draft
Recommended
P ublication
Date
Context:
A1
C 2 T a s kin g
Ge n e rat e
C o mma nd s
1
U n se n t C o mma n ds
S end
C o mma nd s
2
S e n t C o mma n d s
Re la y
C o mma n d s
3
C o n t ro l P a n e l
Bro w s e r
Re la y e d C o mma n d s
Re c e iv e
C o mma n d s
O1
M 1 S y s t e m C o n t ro lle r
M 4 Bu o y Re c e iv e r
P age:
Title:
A11
Number:
AKB17
P. 5
Diagram 51. ATP/A11 (Control Data Collection) with System Controller
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/06/2002
Reader
Working
Draft
Recommended
P ublication
Date
Context:
A1
S e n d Dat a
I1
C o lle c t e d Da t a
S e n t Da t a
Re la y Da t a
Re la y e d Da t a
Re c e i v e Da t a
O1
Bro w s e r
M 4 Bu o y T ra n s mit t e r
P age:
A13
Title:
Transmit Collected Data
Number:
AKB19
P. 7
75
Diagram 52. ATP/A13 (Transmit Collected Data) with System Controller

Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/06/2002
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A21
S p e cify
O b s e r v at io n
D at a S t an d ar d s
O1
1
Da t a E le me n t M e t a d a t a
O b s e rv a t io n s S c h e ma
I1
Pr ep ar e
C le a n O b s e rv a t io n s
M ain t ain
O2
M 1 Da t a E n g in e e r
P age:
A211
Title:
Save Observations
M 2 O b s e rv a t io n P ro c e s s o r
Number:
AKB24
P . 10
Diagram 53. ATP/A211 (Save Observations) with Data Engineer
76
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
Working
Draft
Recommended
P ublication
01/06/2002
Reader
Date
Context:
A21
S p e cify
D at as et D at a
S t an d ard s
O1
Da t a s e t M e t a d a t a
Da t a s e t S c h e ma
Pre p ar e
D at as e t s
I1
M ain t ain
D at as et s
O2
M 1 Da t a E n g in e e r
P age:
Title:
A212
M 2 Da t a s e t P ro c e s s o r
Number:
Create Datasets
AKB25
P . 11
Diagram 54. ATP/A212 (Create Datasets) with Data Engineer

Used at:
Author:
P roject:
Model:
Notes:
Date
Rev:
1 2 3 4 5 6 7 8 9 10
01/06/2002
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A21
C a t a lo g
I1
S p e cify
Pr o d u ct s
T a s kin g
O1
1
Da t a s e t S e le c t io n
P ro d u c t C o n s t ru c t io n Ru le s
P ro d u c t P ro p e rt ie s
R e t r ie ve
D at a s et s
2
Re t rie v e d Da t a s e t s
Pack age
D at as et s
O2
M 1 P ro d u c t E n g in e e r
P age:
A213
Title:
Retrieve Datasets
M 2 P ro d u c t P ro c e s s o r
Number:
P . 12
Diagram 55. ATP/A213 (Retrieve Datasets) with Product Engineer
77
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
Working
Draft
Recommended
P ublication
01/06/2002
Reader
Date
Context:
A0
E ma il P ro t o c o ls
W e b P ro t o c o ls
F u lf ill
I2
O1
O rd e rs
1
Stage
P ro d u c t s
O2
W e b Re q ue s t s
Post
P ro d u c t s
I1
3
E ma il
P ro d u c t s
L o c a l A re a Ne t w o rk
W e b s it e
O rd e r De s k
P ro d u c t io n Se rv e r
W e b S e rv e r
M a il S e rv e r
M 1 F u lf illme n t T e c h n ic ia n
P age:
A3
Title:
Number:
AKB23
P . 14
Diagram 56. ATP/A3 (Distribute Product) with Fulfillment Technician
When we turn to developing the requirements model for operations (RTO), we have already the
advantage of the work we have done to develop the RTP and ATP models. We have deliberately given
the RTO model the same Viewpoint and the same Purpose as the RTP models. This should allow us to
reuse significant portions of the structure and content of our Product models.
As we did before, we begin by assigning helpful names to our A-1 functions, regularizing the box
numbers, and naming the A-1 diagram itself:
78
Used at:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
Author:
P roject:
M odel:
Notes:
12/21/2001
Reader
W orking
Draft
Date
Context:
NO NE
R ecommended
P ublication
C o m m u n ic a t io n s P ro t o c o ls
M in is t e ria l Q u e s t io n s
R o u t in g D e c is io n s
M i n i s t e ri a l R e q u e s t s
Se rvi ce A g re e m e n t s
C o n t rol
O p e ra t ion s
B u o y Te c h n ic a l D a t a
14
R ou t e P la n n in g R e q u ire m e n t s
S y s te m S t a tu s
M a in t e n a n c e R e q u e s t
M a in t e n a n ce N o t ific a t io n
S u p p ly
C a p it a l
R es o u rc e s
2
P ro vi d e
O b s e rva b l e s
3
ra t e
CGoennt e xt
of
R o utin g
PPro
rodduuct
cts
M e a s u r e d O b s e rv a b le s
M in is t e ria l R e p o r t s
G e n e ra t i o n
x
x
00
b ro k e n b u oy
P la n
Sh i p p i n g
Routes
C o m m u n ic a t io n s S a t e llit e s
R o u t e P la n
5
R ou t in g P ro d u c t s
re p a ire d b u oy
A rg o s
N W S G e n e ra l M a n a g e r
P age:
A-1
E n vi ro n m e n t
N OA A
T itle:
Stakeholder Context of Routing P roduct Generation
Sa n t a N a ri d a B u o y Sys t e m
Number:
AKB5
P. 1
Diagram 57. RTO/A-1 (Stakeholder Context of Routing Product Generation)
The corresponding A-0 diagram is:
79
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
12/26/2001
Rev:
OOASIS SE
Re quire me nts TO -B E O pe rations (RTO )
1 2 3 4 5 6 7 8 9 10
Working
Draft
Recommended
P ublication
Reader
Date
Context:
Top
TOP

M a in t e n a n c e No t if ic a t io n
Ro u t e P la n n in g Re q u ire me n t s
M in is t e ria l Re q u e s t s
Ro u t in g De c is io n s
C o mmu n ic a t io n s P ro t o c o ls
S y st e m S t a t us
O cean
G en erat e
R o u t in g
Pro d u ct s
M in is t e ria l Re p o rt s
Ro u t in g P ro d u c t s
00
S y ste m
M ea s u r e d
M i n is te r ia l
R o u ti n g
P age:
A-0
Title:
Context of Routing P roduct Generation
Number:
AKB1
P. 2
Diagram 58. RTO/A-0 (Context of Routing Product Generation)
We decompose the A0 function in the following diagram. In this diagram, we have made some
assumptions and refracted them as system requirements:
A-1 shows routing decisions fed back into the system. However, here we capture such decisions
as routing products -- these products in this view include the decisions made by the shipping
router, i.e., document the decision by a downloaded itinerary.
We already know what activities are needed to measure ocean observables, so we will not
decompose this activity again. We show no tasking because we assume that routing products will
use standard datasets. Buoy status is unbundled from ocean observations; buoy status should be
provided by the system controller.
We will not decompose either A3 or A4. Informed intuition suggests that these are conventional
reporting functions with nothing much interesting for a systems perspective to be revealed by
decomposition.
In the A0 diagram, A2 (Generate Routing Products) has the same structural position as Generate Products
and Distribute Products together have in the Products model. Here the two reporting activities have been
80
represented, one for routine administrative reporting and the other for reporting system performance and
goal attainment to the Santa Narida government.
Used at:
Author:
P roject:
Model:
Notes:
Date
12/26/2001
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
C6
Date
Context:
A-0
C3
C4
C5
C1
Bu o y S t a t u s
Reader
C2
I1
Working
Draft
Recommended
P ublication
M ea s u re
Oc e an
O2
O b s e rv a b le s
1
W e already know what

activities are needed to
measure oc ean
observables , so we will
not decomp ose this
activity agai n. W e show
no tasking b ecause we
assume tha t routing
products will use
standard da tasets. B uoy
status is unb undled from
ocean obse rvations;
buoy status should be
provided by the system
controller.
Ge n e ra t e
Ro u t in g
P ro d u c t s
A0
O4
2
2
S t a t u s Re q u e s t
A c t iv it y S t a t u s
Re p o rt S y s t em
S t a t us
Sy st em St at us
O1
M3
P age:
Ro u t in g Dec is io n s
Ro u t in g P ro du c t s
A -1 shows routing decisions fed back into the

system. However, here we capture such
decisions as routing products -- these products
are in this view to include the decisions made by
the shipping router, i.e., document the decision
by a donwloaded itinerary.
Title:
M2
Re p o rt S y s t e m
A c c o mp lis h me n t s
M in is t e r ia l Re p o rt s
O3
W e will not decompo se either A 3 or A 4.

Informed intuition sug gests that these are
conventional reporting functions with nothing
much interesting to be revealed by
decomposition.
Generate Routing P roducts
Number:
AKB7
P. 3
Diagram 59. RTO/A0 (Generate Routing Products)
We decompose A2 (Generate Routing Products) as shown in the following diagram. Not surprisingly, this
diagram shows the same general structure for product development we explored in the Products model:
generate datasets, filter datasets, produce final products. It is the A23 (Propose Itineraries) where we
expect to see requirements that may be significantly different from those seen in the Products model.
The structure of the decomposition of A23 should seem familiar. It is based upon the stakeholder model
for a shipping route planner. We have incorporated the logic of SRP/A0 within the scope of the
prospective system because the capabilities to be used by the route planner are to be provided by the
Santa Narida Buoy System.
In the next step we transform our Operations requirements model into an architecture model by allocating
system behaviors to hardware and software components. As with our Products model, we will allocate
system behaviors to agents after we have examined this allocation to hardware and software.
81
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
12/26/2001
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
Reader
Working
Draft
Recommended
P ublication
Date
Context:
A0
C2
C3
C1
Da t a s e t Re q u e s t s
G e n e rat e
I1
D a t a s et s
O2
U n f ilt e re d Da t as e t s
F ilt e r
Da t a s e t s
P ro p o s e
F ilt e re d Da t a s e t s
It in e ra rie s
O1
3
3
M1
P age:
Title:
A2
Ro u t e P la n ne r
Number:
AKB9
P. 6
Diagram 60. RTO/A2 (Generate Routing Products)
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
12/26/2001
OOASIS SE
Rev:
1 2 3 4 5 6 7 8 9 10
C2
Reader
Working
Draft
Recommended
P ublication
P ro d u c t Re q ue s t s
C1
Date
Context:
A2
C3
F e a s ib le Ro u t e s
De t e rmin e
I1
A c t iv it y St a t u s
O2
F e a s ib le
Ro u t e s
O3
1
Ro u t e F o re c a s t s
F o re c a s t
Ro u t e
W e at he r
2
E s t ima t e d It in e ra rie s
E s t im a t e
S h ip
S c h e d u le s
3
S e le c t
O p t imu m
It in e ra ry
4
S e le c t e d It in e ra ry
M1
P age:
82
A23
Title:
P ropose Itineraries
Number:
AKB10
P. 7
O1
Diagram 61. RTO/A23 (Propose Itineraries)
Revisiting the A-0 diagram, we will see two changes. First, we have removed the tunnel from the
mechanism arrow for our prospective system. Second, we have removed the control Routing Decisions, in
keeping with the observations we made while developing the requirements model.
Used at:
Author:
P roject:
Model:
Notes:
AKBocast
Date:
OOASIS SE
Rev:
Architecture TO-BE Operations (ATO)
1 2 3 4 5 6 7 8 9 10
12/26/2001
Working
Draft
Recommended
P ublication
Reader
Date
Context:
Top
TOP

M a in t e n a n c e Not if ic a t io n
Sy st em St at us
O cean
G en er at e
R o u t in g
Pr o d u ct s
00
S y s te m
M e a sure d
M in is te r ia l
R o u tin g
Argos Syst em
P age:
A-0
Title:
Context of Routing P roduct Generation
Number:
AKB1
P. 2
Diagram 62. ATO/A-0 (Context of Routing Product Generation)
Our A0 decomposition with abstract components allocated now looks like the next diagram. Note that we
have simply denoted our system components that Measure Ocean Observables as Buoys, because we are
adding nothing new to our understanding of requirements for the sensors, their platforms, or their
communications. For the two reporting functions, we have ascribed a System Status Reporter component
and a System Performance Reporter component as mechanisms.
When we decompose the A2 activity, we determine that new requirements are not raised for A2.1
(Generate Datasets). Instead of decomposing this activity, we bundle the individual processors of our
requirements model under the label Processing Engines to remind us that several abstract components
have been previously allocated to carry out A21.
83
Used at:
Author:
P roject:
Model:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/26/2001
Reader
Working
Draft
Recommended
P ublication
Date
Context:
A-0
C 3 M in is t e ria l Re q u e s t s
C 2 Ro u t e P la n n in g Re q u ire me n t s
C1
I1
Bu o y S t a t u s
M ea s u re
Oc e an
O2
O b s e rv a b le s
1
Ge n e ra t e
O4
Ro u t in g
P ro d u c t s
2
2
S t a t us
S y st e m S t at us
O1
3
O3
Bu o y s
S y s t e m S t a t u s Re p o rt e r
S y s t e m P e rf o rma n c e Re p o rt e r
P age:
Title:
A0
M 2 Ro u t e P la n n e r
Number:
AKB7
P. 3
Diagram 63. ATO/A0 (Generating Routing Products)
Used at:
Author:
P roject:
Model:
Notes:
Date:
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
12/26/2001
Reader
Working
Draft
Recommended
P ublication
Date
Context:
A0
G e n e rat e
I1
D a t a s et s
O2
F ilt e r
Da t a s e t s
P ro p o s e
It in e ra rie s
O1
3
3
Pr o ce s s in g E n g in e s
It in e ra ry E n g in e
Da t a b a s e E n g in e
F ilt e r P ro c e s s o r
W e b S e rv e r
Bro w s e r
P age:
84
A2
Title:
Number:
AKB9
P. 6
Diagram 64. ATO/A2 (Generating Routing Products)

Used at:
Author:
P roject:
Model:
Notes:
AKBocast
Date:
OOASIS SE
Rev:
1 2 3 4 5 6 7 8 9 10
C2
12/26/2001
Working
Draft
Recommended
P ublication
P ro d u c t Re q ue s t s
Reader
Date
Context:
A2
F e a s ib le Ro u t e s
I1
De t e rmin e
F e a s ib le
Ro u t e s
O2
O3
1
Ro u t e F o re c a s t s
F o re c a s t
Ro u t e
W e at he r
O1
2
E s t ima t e d It in e ra rie s
E s t im a t e
S h ip
S c h e d u le s
3
S e le c t
O p t imu m
It in e ra ry
4
S e le c t e d It in e ra ry
M 3 Bro w s e r
M 2 It in e ra ry E n g in e
M 1 W e b S e rv e r
P age:
A23
Title:
P ropose Itineraries
Number:
AKB10
P. 7
Diagram 65. ATO/A23 (Propose Itineraries)
We also do not readily see that new requirements are raised for A2.2 (Filter Datasets), so as before we
will not decompose this activity. However, we have modified the name of the mechanism for this activity
from Filter to Filter Engine, in part for symmetry and in part to convey more directly than previously that
we do not expect this component to be necessarily trivial.
The mechanisms for A23 have been unbundled before being attached to A2.3 (Propose Itineraries). The
import of this unbundling is seen in the decomposition diagram A23. In diagram A23, all controls and
mechanisms branch undifferentiated from their boundary ICOM codes to each of the four boxes in the
diagram; these arrows are all grayed-down to emphasize this point. From the perspective of the systems
engineer, the four activities represented in A23 appear thus to be sequential behaviors of just one
component. This suggests that our architectural decomposition has here driven down one level too far;
unless otherwise indicated, the next iteration of our architecture model, which will focus on the allocation
of behavior to internal system agents, will likely dispense with this decomposition.
But this conclusion is at odds with our stated stopping rule for decomposition for an architecture model:
that only one non-agent mechanism arrow attributable to the prospective system is to be attached to a leaf
box, i.e., an activity that is not decomposed. We could return to the parent diagram and, noting that
85
Internet Protocols would remain a control on A2.3 (Propose Itineraries), we might simply remove the
mechanism Web Server. But we intuitively sense that this is not a very satisfactory response for an
architecture model.
Instead we consider the relationship between Web Server and Itinerary Engine in the sense of OOASIS
nodes and devices. In this sense, it is easy to see the Web Server as the infrastructure for the Itinerary
Engine; the Web Server seems like an OOASIS device while the Itinerary Engine seems to be an OOASIS
node. The Web Server provides the platform to exercise the Itinerary Engine, so these two mechanisms
are really inextricably bound for any activity that they support.
In this light, we have two choices: (1) we can bundle the device and the node together into a higher-level
abstraction such as Web Itinerary Engine or (2) we can claim an exception to the models decomposition
stopping rule. The first choice does not appeal to us precisely because it does bundle two concepts that
ought to be visible at this level within an architecture model that supports development of an OOASIS
NDC diagram, with its concern to identify devices and nodes as separate concepts. Thus we opt for the
second choice and allow this exception to our overall stopping rule.
We now move to the next elaboration of our Operations architecture model by considering internal
agents. As before, our work begins with the A0 diagram:
Used at:
Author:
P roject:
Model:
Notes:
12/26/2001
AKBocast
Date:
OOASIS SE
Rev:
1 2 3 4 5 6 7 8 9 10
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A-0
C1
I1
Bu o y S t a t u s
M ea s u re
Oc e an
O2
O b s e rv a b le s
1
Ge n e ra t e
Ro u t in g
P ro d u c t s
O4
2
2
S t a t us
Sy st em St at us
O1
3
4
Bu o y s
S y s t e m S t a t u s Re p o rt e r
Ad m in is t ra t o r
P age:
A0
Title:
Diagram 66. ATO/A0=AKB11 (Generate Routing Products)
86
Number:
AKB11
P. 3
O3
In this version of ATO/A0, we introduce the Administrator6 role to support A3 (Report System Status)
and A4 (Report System Accomplishments). When we revisit diagram A2, we now identify the Database
Administrator role to support the generation of meteorological datasets, as shown in the next diagram.
We now can dispose of the third requirements model for our purpose of identifying information needed
by the OOASIS software practitioner by observing that, while critical from a systems engineering
perspective, identifying and providing trained, competent personnel is beyond the scope of the software
of our prospective system.
We are now ready to identify, translate, and/or transform the information gathered from our systems
perspective into the specific software information artifacts needed by the OOASIS method.
Used at:
Author:
P roject:
Model:
Notes:
12/26/2001
AKBocast
Date:
OOASIS SE
Rev:
1 2 3 4 5 6 7 8 9 10
Reader
Working
Draft
Recommended
P ublication
Date
Context:
A0
I1
G e n e rat e
D a t a s et s
O2
F ilt e r
Da t a s e t s
D a t a b a s e Ad m in is t ra t o r
P ro p o s e
It in e ra rie s
O1
3
3
Pr o ces s in g E n g in es
W e b S e rv e r
Bro w s e r
P age:
A2
Title:
Number:
AKB9
P. 6
Diagram 67. ATO/A2=AKB9 (Generate Routing Products)
The appearance of one label connected by two squiggles to two different arrow segments is a visual sleight-ofhand. If literal, this would violate the IEEE 1320.1 standard, because a label may be attached to only one arrow
segment. Here, there are actually two Administrator labels, one centered on top of the other.
87
Step 7. Developing System Use Case Diagrams

We will now build a family of system use case models. These system use case models partition and
coalesce the architecture models to specify software system boundaries and actors in a way that may be
translated directly into use case notation.
We start with a fresh copy of each of our architecture models. The strategy is to track into the
decomposition hierarchy of the model until a significant stakeholder, internal or external, is encountered
as a mechanism. We basically ignore allocated components at this stage; we may return to identify
components as use case actors, but we are now looking for stakeholders who may be seen as benefiting
actors.
Starting with the Products model, the first stakeholder we encounter is the System Controller for activities
A111 and A112. These activities generate the commands that are sent to the buoys and their sensors. As
seen in A11, activity A113 is actually external to the model, that is, an interchange with an external actor,
the Argos System. This introduces a potential external actor with a bi-directional relationship with our
tentative use case, but does not give us a good feeling of closure for this use case. We also note that
Schedules and Tasking are controls on A11.1 (Generate Commands). While the source of Schedules is
exogenous, the source of Tasking is endogenous; if this source is not within the use case we are currently
developing, then we must ensure a natural and intuitively plausible relationship between this use case and
other use cases to maintain this relationship.
Our System Controller reappears with activity A131 (Receive Data), which produces the Ocean
Observations used directly or indirectly by all external stakeholders. This seems to be a good point to
suggest the bounds of one set of behaviors for use case analysis. We mark the activities that we feel are
encompassed by this possible use case by graphical annotation of the activity boxes.
Because we may find that one box may seem to cohere within more than one use case during our initial
analysis, simple color-coding of boxes will not suffice. Our modeling tool gives us the option of diagonal
striping in different colors, so we begin with this convention:
A c t iv it y in
Re d U se
C ase
1F
A c t iv it y in
B lu e Us e
C ase
2F
A c t iv it y in
B o t h B lu e
a n d Re d
U s e C a se s
3F
Figure 5. Conventions for Marking Activities WRT Use Cases
Then we raise the involved actors to the outermost box that encompasses the activities of the use case.
Here, this is quite simple, for the original partitioning of behavior neatly matches our initial use case
considerations:
88
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
O O ASIS Sys te m Us e Cas e s (O SU)
1 2 3 4 5 6 7 8 9 10
01/08/2002
C5
C6
Reader
Working
Draft
Recommended
P ublication
I1
Context:
A-0
C1 C o mmu n ic a t io n s P ro t o c o ls
C4 P ro d u c t Re q u e s t s
Date
T a s kin g
M e a s ur e O c e a n
O bs e r v a b le s
O1
1
G e ne r a te
M e te o r o lo g y
P r o d uc ts
I2
2
Sy s te m C o n t ro lle r
Dis t rib u t e
P ro d u c t s
O2
Bu o y s
M 2 Arg o s Sy s te m
P age:
A0
Title:
M 3 W e a t h e r Fo re ca s te r
Number:
AKB25
P. 3
Diagram 68. ASU/A0 (Generate Meteorological Products)
In use case notation, this might be represented as:
Environment
System Controller
Argos System
Figure 6. Use Case Analysis: Measure Ocean Observables
Note that the Environment is shown as an actor in the Measure Ocean Observables use case because the
Environment is the source of the ocean observables that are to be measured.
When we move to A2, we view both the Weather Forecaster and the Product Engineer as potential
actors. When we examine diagrams A2 and A21, we see that the Product Engineer is rather neatly
associated with the activities Generate Datasets and Filter Datasets. However, the Product Engineer is
not a primary actor but rather an agent of the prospective system.
Continuing to track into the decomposition hierarchy, we find the next actor/behavior boundary at A232
(Run Weather Models). This leaves the behavior of A234 and A235 to be associated with another use
89
case. We use a lighter blue diagonal to signal that here there is not a neat overlap between activity
analysis and use case analysis. Our A0 diagram now looks like:
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/08/2002
C5
Working
Draft
Recommended
P ublication
C6
Reader
Context:
A-0
I1
Date
T a s kin g
O bs e r v a b le s
O1
1
G e ne r a te
M e te o r o lo g y
P r o d uc ts
I2
2
Dis t rib u t e
P ro d u c t s
O2
Bu o y s
P age:
A0
Title:
Number:
AKB25
P. 3
Diagram 69. OSU/A0=AKB24 (Generate Meteorological Products)
and our corresponding use case diagram looks like the next diagram:
Environment
System Controller
Argos System
<<depend>>
Weather
Forecaster
Run Weather Models
Product Engineer
Figure 7. Use Case Analysis: Run Weather Models
90
Picking up with A234, we continue our traversal of the decomposition hierarchy, looking for the next
potential actor while following the trail of artifacts that appear destined for Televisio Santa Narida. This
trail takes us to function A32, which is controlled by A31, to which the agent mechanism Fulfillment
Technician has been assigned. A32 (Stage Products) is the activity that makes available weather forecast
artifacts for Televisio Santa Narida; the additional activities A33 and A34 appear to be extensions to the
use case that incorporates A32. This is shown in the following diagram:
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
C2
C3
S c h e d ule s
Reader
Working
Draft
Recommended
P ublication
01/08/2002
Date
Context:
A0
P ro d u c t Re q u es t s
C1
F ulfill
O rde rs
O1
1
I2
S ta g e
P r o d uc ts
O2
W e b Re q ue s t s
P ost
P r o d ucts
I1
3
E m a il
P r o d uc ts
M a il C lie n t
L o c a l A re a Ne t w o rk
4
W e b s it e
O rd e r De s k
P ro d u c t io n S e rv e r
W e b S e rv e r
M a il S e rv e r
M2
M 1 Fu lfillm e n t Te ch n icia n
P age:
A3
Title:
Number:
AKB26
P . 11
Diagram 70. OSU/A3=AKB26 (Distribute Products)
We are slightly uncomfortable with grouping together A234, A235, A31, and A32 for one use case,
because A31 and A32 are more general behaviors than A234 and A235; thus we are prepared to revisit
this decision before we complete our use case analysis. Meanwhile, our mapping now looks like:
91
Used at:
Author:
P roject:
Model:
Notes:
Date
AKBocast
Rev:
OOASIS SE
1 2 3 4 5 6 7 8 9 10
01/08/2002
C5
C6
Reader
Working
Draft
Recommended
P ublication
I1
O bs e r v a b le s
Context:
A-0
Date
T a s kin g
O1
1
G e ne r a te
M e te o r o lo g y
P r o d uc ts
I2
2
Dis t rib u t e
P ro d u c t s
O2
Bu o y s
P age:
A0
Title:
Number:
AKB25
P. 3
Diagram 71. OSU/A0=AKB25 (Generate Meteorological Products)
and the expanded system use case diagram looks like the following figure. Note that the system use cases
we have identified in this use case diagram associate with all stakeholders addressed by our Products
architecture model.
Using the same approach, we analyze our Operations architecture model to enhance our system use case
understanding. The external stakeholders specifically addressed by the Operations model that have not
already been addressed are NOAA as buoy maintenance, NWS as General Manager, and the Shipping
Route Planner. Our additional internal stakeholders are the System Administrator and the Database
Administrator.
We have already encompassed activity A1 within the system use case Measure Ocean Observables.
Thus we begin our traversal with the A2 activity. In the A2 diagram we find our Database Administrator
as mechanism to A2.1 (Generate Datasets), which was previously subsumed under the use case Stage
Products. We also see again the Route Planner as mechanism to A2.3 (Propose Itineraries). The Route
Planner uses the prospective system to gain a benefit but the Database Administrator is an agent of the
system itself; the Database Administrator does not have an autonomous purpose as does the Route
Planner.
92
Environment
System Controller
Product Engineer
Argos System
<<depend>>
Maintain Meteorological Data
Database
Administrator
Run Weather Models
Weather
Forecaster
<<depend>>
Fulfillment
Technician
Stage Products
<<extend>>
Post Products
Institute Scientist
Weather
Broadcaster
<<extend>>
Email Products
Tsunami Warning
Center
Figure 8. Use Case Analysis: Stage Products
Because the Database Administrator does not have an autonomous purpose, we will give this
administrator a bi-directional relationship with a use case. However, as we reconsider the use cases Stage
Products and Run Weather Models, we realize that Run Weather Models was derived from a set of
activities that included Generate Datasets and Filter Datasets; as we then observed, these activities serve
broader purposes than just running weather models. We need to break up Run Weather Models so that
the dataset database activities can support these broader purposes, as shown in the next, revised OOASIS
System Use Case diagram, which is based upon the markup of the OSC/A2 diagram that follows it.
The next use case we introduce is of course based upon the requirements of the Shipping Route Planner,
and is shown in the next use case diagram.
93
Environment
System Controller
Argos System
Product Engineer
<<depend>>
Database
Administrator
Run Weather Models
Weather
Forecaster
<<depend>>
Stage Products
Fulfillment
Technician
Weather
Broadcaster
<<extend>>
<<extend>>
Post Products
Email Products
Institute Scientist
Tsunami Warning
Center
Figure 9. Use Cases Analysis: Maintain Meteorological Data

Used at:
Author:
P roject:
Model:
Notes:
AKBocast
Date:
OOASIS SE
Rev:
OOASIS System Use Cases (OSC)
1 2 3 4 5 6 7 8 9 10
12/30/2001
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A0
I1
G e ne r ate
D a ta s ets
O2
U n f ilt e re d Da ta s e t s
F ilte r
D a ta s e ts
D a t a b a s e Ad m in is t ra t o r
P rop ose
Itine r a r ie s
3
3
Pro ces s in g E n g in es
O1
W e b S e rv e r
Bro w s e r
M 1 R o u t e P la n n e r
P age:
A2
Title:
Number:
AKB9
P. 6
Diagram 72. OSC/A2 (Generate Routing Products)
94
Environment
System Controller
Argos System
Product Engineer
<<depend>>
Run Weather Models
Weather
Forecaster
Database
Administrator
<<depend>>
<<depend>>
Propose Itineraries
Fulfillment
Technician
Stage Products
<<extend>>
Weather
Broadcaster
<<extend>>
Post Products
Email Products
Institute Scientist
Tsunami Warning
Center
Route Planner
Figure 10. Use Case Analysis: Propose Itineraries
Now as shown in the final markup of the OSC/A0 diagram:
95
Used at:
Author:
P roject:
Model:
Notes:
AKBocast
Date:
OOASIS SE
Rev:
OOASIS System Use Cases (OSC)
1 2 3 4 5 6 7 8 9 10
12/30/2001
Working
Draft
Recommended
P ublication
Reader
Date
Context:
A-0
C 2 Ro u t e P la n n ing Re q u ire me n t s
C1
I1
Bu o y S t a t u s
M e as u re
O ce a n
O b s e rv ab le s
O2
G e ne r a te
R o u ting
P r o d uc ts
O4
2
2
R e p o r t S y s te m
S ta tus
S y st em S t at us
O1
3
R e p o r t S y s te m
A c c o m p lis hm e nts
O3
Bu o y s
S y s t e m S t a t us Re p o rt e r
S y s te m A d m in is tr a to r
M 3 Arg o s Sy s t e m
P age:
A0
Title:
Number:
AKB11
P. 3
Diagram 73. OSC/A0 (Generate Routing Products), Final Markup
We have only to add the System Administrators reporting requirements to our use case analysis. While it
should be clear that this use case would depend upon information provided by every other use case, we
will only associate Generate Reports with Measure Ocean Observables (to capture maintenance
reporting) and with Propose Itineraries (to capture ministerial reporting).
96
Environment
Argos System
System Controller
Product Engineer
Database
Administrator
<<depend>>
<<depend>>
Generate Reports
Run Weather Models
Weather
Forecaster
<<depend>>
<<depend>>
System
Administrator
<<depend>>
Propose Itineraries
Stage Products
Fulfillment
Technician
<<extend>>
Weather
Broadcaster
<<extend>>
Route Planner
Post Products
Institute Scientist
Email Products
Tsunami Warning
Center
Figure 11. OOASIS System Use Case Diagram
Step 8. Develop Node-Device-Connector (NDC) Diagram.

We evolve our NDC diagram from our IDEF0 models in several steps or tasks, as described in this
section. (The OOASIS description of an NDC diagram is reiterated here as Appendix C.)
While we will still be working within the IDEF Standard Diagram Frame as we transform our IDEF0
models into NDC information, all diagrams in this model should be considered FEO (For Exposition
Only) diagrams.
We will make these transformations to our IDEF0 diagrams:
Controls that represent exogenous information constraints (e.g., Communications Protocols)

rather than communications (e.g., Tasking) will be removed from a diagram.
Each mechanism will be assessed to determine whether it represents an agent, a device, or a
process to be run on a node. Depending upon its nature, mechanisms other than agents will be
treated as follows:
device The box for which the device is mechanism will be shaded light blue. The token
DEVICE and the mechanism label will be prefixed to the box name. The activity name will be
97
grayed-down. The mechanism arrow will be removed. (Exception: a box representing an activity
performed by an external actor should already be shaded light gray; this shading will
process The box for which the process is mechanism will be shaded light green. The token
NODE and the mechanism label will be prefixed to the box name. The activity name will be
grayed-down. The mechanism arrow will be removed.
Labels for input and output arrows connecting DEVICE and NODE boxes will be removed.
Redundant paths between two boxes will be bundled into a single arrow.
Applying these transforms to ONA/A11, we obtain:
C 2 T a s k in g
NO DE
B r o w se r
--Se n d
Com m a nds
NODE
C on tr o l
P ane l
--G e ne ra t e
C o mm a n d s
D E V IC E
Argo s
S y s te m
--R e la y
Commands
D E V IC E
Buoy
R e ce iv e r
--R e c e i ve
Commands
D a t a C o ll e c t io n C o m m a n d s
O1
Figure 12. First NDC Transform on ONA/A11
Next we apply these transforms:
Coalesce boxes by recognizing likely software components that are likely to instantiate on a
single node rather than separate nodes. Because System Controller is attached to both boxes 1 and
2, and because Browser is likely to be realized as COTS software, we coalesce boxes 1 and 2,
assigning the name Controller Workstation to the coalesced node.
Convert arrows to connection lines between transformed boxes.
Applying these transforms to ONA/All, we obtain:
98
C 2 T a s k in g
NO DE
C o n tr o lle r
W o r k s ta tio n
--C o n t ro l
P a ne l,
B ro w s e r
--G e n e ra t e
Com mands
D E V IC E
Buoy
R e c e iv e r
--R e c e ive
Comm ands
D E V IC E
Argo s
S y s te m
--R e la y
Comm ands
D a t a C o lle c t io n C o m m a n d s
O1
Figure 13. Second NDC Transformation on ONA/A11
When we complete these transformations within diagrams A11, A12, and A13, we raise the decomposed
elements to the parent diagram A1. The A1 diagram now looks like:
C 2 T a s kin g
NO DE
C o n tr o lle r
W o r k s ta tio n
--C o n t ro l P a n e l;
B ro w s e r
--G e n e ra t e
C om m a n ds
DE V IC E
Argos
Sy s te m
--R e la y
C om m a n ds
D E V IC E
B uoy
R e c e iv e r
--R e ce iv e
C o m m a n ds
72F
83F
61F
I1
D E V IC E
B uo y
S e nsor s
-- Sen s e
O bs e rv a ble s
O1
44F
NO DE
B uoy P roce ssor
--M e a s u re m e n t
P ro ce s s o r
--G ath er
M e a s u re m e n t s ;
P a c k a ge D a t a
D E V IC E
B uoy
T r a n s m itte r
-- Sen d Dat a
16F
D E V IC E
Argos
S y s te m
--R e la y D a t a
NO DE
C o nt r o lle r
W o r k s ta tio n
- -B ro w s e r
- -R e ce iv e D a t a
O2
27F
38F
55F
Figure 14. First NDC Transformation on ONA/A1
Our next transformation requires two things:
Because there are no NDC semantics adhering to which side of a box a connector is attached to,
we prefer to attach connectors to the sides of boxes in our NDC development.
99
Coalesce boxes that represent the same devices or nodes. Boxes 1 and 8 represent the same node
and boxes 3 and 6 represent the same device.
These transformations lead to this revision:

C 2 T a s kin g
I1
NO DE
C o n tr o lle r
W o r k s ta tio n
--C o n t ro l P a n e l,
D E VIC E
B u o y S e n so r s
--S en s e
O bs e rv able s
D E V IC E
Argos
S y s te m
--R e la y
C o m m a n ds ;
R ela y D a t a
11F
O1
44F
O2
B ro w s e r
--G e n e ra t e
C o m m a n ds
NO DE
B uoy P roce sso r
P ro ce s s o r
--G a th e r
M e a s u r e m e n ts ;
P a c k a g e D a ta
D E V IC E
B uoy
R e c e iv e r
--R e ce iv e
C o m m a n ds
66F
33F
22F
D E V ICE
B uoy
T r a n s m itte r
--S e n d D at a
55F
This is as good a time as any to introduce two grouping concepts that we will use in developing our NDC
information. The first is physical grouping, which is represented by a red-bordered box; the second is
logical grouping, which is represented by a blue-border box. A logical groupings may overlay a physical
grouping, thus showing an interesting relationship between nodes and devices in different physical places.
Our third transformation of ONA/A1 uses a physical grouping to emphasize the collocation of buoy
components:
C1
S c h e d u le s
C2
T a s kin g
B u oy
I1
NO DE
C o n t ro lle r
--Ge n e r a t e
Com m ands
1
O1
S e n s o rs
--O2
Se n s e
O b s e r v a b le s
W o rks t a t io n
Bro w s e r
D E V IC E
B uo y
NO DE
D E V IC E
A rg o s
Sy s te m
D E V IC E
B uo y
--Re la y
Re c e iv e r
-- -
Com m ands;
Re la y Da t a
Re c e iv e
C o m m a nd s
D E V IC E
Buoy
--M e a s u re me n t
B uoy
P ro c e s s o r
Tra n s m it te r
---
P ro c e s s o r
--Ga t h e r
M e a su re m e nt s;
Se n d Dat a
4
Pa c ka g e Da t a
2
M1
S y s t e m C o n t ro lle r
Figure 16. Third NDC Transformation on ONA/A1
Applying the same transformation logic to the child diagrams of ONA/A21 and then raising the boxes of
these decomposition back up to the A21 diagram gives a figure like this:
100
C 2 D ataset R eq u ests
C 1 R e ce iv e d R e q u e s t s
O2
I1
NO D E
O b s e r v a tio n
P r o ce s s o r
--Sp e cify
O b se rv a tio n
D a ta S ta n da r d s;
P re p a r e
O b se r va tio n s
D EV ICE
D a ta b a s e
E n g in e
--M a in ta in
O b se r v a tio n s
NODE
D a ta s e t
P roc e ss or
--S p e cify
D a ta se t D a ta
S ta n d a r d s;
Prepar e
D a ta se ts
NODE
Prod u c t
P roc e ssor
--S p e cify
P r o d u cts;
P a ck a g e
D a ta se ts
D EV IC E
D a ta b a s e
E n g in e
-- M a in ta in
D a ta se t s
4
T a s k in g
O1
O3
D EV IC E
D a ta b a s e
E n g in e
--R e tr ie v e
D a ta se ts
6
D a t a E n g in e e r
Figure 17. First NDC Transformation on ANA/A21
Because the Database Engine device appears three times in this diagram, our next task is to coalesce these
boxes:
O2
I1
NODE
O b s e rv a tio n
P r oc e s s o r
--S p e cify
O b ser v a tio n
D a ta S ta nd a r d s;
Pr e p a r e
O b se rv a tio n s
1
D EV ICE
D a ta b a s e
E n g in e
--M a in ta in
O b se r v a tio n s;
M a in ta in
D a ta se ts;
R e tr ie v e
D a ta se ts
NODE
D a ta s e t
P r o ce s s o r
--S p e cify D a ta se t
D a ta S ta nd a r d s;
Pr e p a r e
D ata se ts
C2 D a t a s e t R e q u e s t s
3
NODE
P rod u c t
P roc es s or
--S p e cify
P r o d u cts;
P a ck a g e
D a ta se ts
T a s k in g
O1
O3
Our NDC transformation of diagram ONA/A23 is shown in the next figure:
101
I1
NO DE
W e a th e r
M a ch in e
--Ru n W e a t h e r
M o d e ls
NO DE
F o r e ca ste r
W o r k sta tio n
--W eathe r
V ie w e r
--W rit e
Weathe r
Sc ri p t
F o re c a s t T e x t
NO DE
Im a g e
M a c h in e
--Im a ge
G e n e ra t o r;
Im a ge
P ro ce s s o r
--G e n e ra t e
Sy m b o l i c
I mages;
Co m bine
Images
I2
O1
O3
O2
M1
Figure 19. First NDC Transformation of ANO/A23
When we now raise these fragments to the A2 level, the A2 diagram looks something like:
I1
NO DE
O b s e rv a t io n
P ro ce s s o r
--S p e c if y
O b s e rv a tio n
D a ta
S t a n d a rd s ;
P re p a re
O b s e rv a tio ns
D E V IC E
D atabas e
E n g in e
--M a int a in
O b s e rv a tio n s ;
M a int a in
D a ta s e ts ;
R e trie v e
D a ta s e ts
NO D E
Dat aset
P ro ce s s o r
- -S p e c if y
D a ta s e t D a ta
S ta n d a rd s ;
P re p a re
Data sets
O2
NO DE
F o r e ca s te r
W o r ks ta tio n
--W eathe r
V ie w e r
--W rit e
Weather
Sc ri p t
3
NOD E
P ro du ct
P ro ce ss o r
--S pe c ify
P ro d uc t s ;
P a c ka g e
D a tas e t s
T a s k in g
O3
NO DE
F ilte r E n g in e
--F il t e r
Datase ts
NO DE
W e a th e r
M a c h in e
--Run Weath er
M o de ls
O1
I2
NO DE
Im a g e
M a ch in e
--Im a g e
G e n e ra t o r;
Im a g e
P ro ce s s o r
--G e n e ra t e
Sym b o l ic
I mages;
Co m bine
Images
M2 P ro d u c t E n g in e e r
D at a E n g in e e r
Figure 20. First NDC Transformation of ONA/A2
We observe in this diagram some patterns of coupling that suggest we consider coalescing nodes:
102
Boxes 1, 3, and 4 each has a connection to box 2.

Boxes 1 and 3 each contributes one part of the output bundle Ready Specifications.
Boxes 4 and 5 each contributes one part of the output bundle Dataset Products. Boxes 4 and 5
also share the control Received Requests.
Boxes 1 and 3 share the specific agent Data Engineer, a subset of Product Engineer. Together,
Boxes 1, 3, 4, and 5 all share the more general agent concept Product Engineer.
Taken together, these observations seem to indicate that it may be reasonable to assert either (1) one
common node for the processes represented by boxes 1, 3, 4, and 5 or (2) coalescing boxes 1 and 3 into a
common node and coalescing boxes 4 and 5 into another common node. Since it is often safer to coalesce
incrementally, we will take the second option, as shown in the next figure. The coalescing of boxes 4 and
5 also allows us to identify the connection between box 6 and box 4 as a redundant connection, thus
further simplifying this diagram.
I1
NO DE
Data
M a ch ine
-- O b s e rv a t io n
P ro ce s s o r ;
Da tas e t
P ro ce s s o r
-- S p e c if y
O b s e rv a t io n
Data
S t a n d a rd s ;
P re p a re
O b s e rv a tio ns ;
S p e c if y
D a ta s e t D a ta
S t a n d a rd s ;
P re p a re
Datase t s
O2
DE V IC E
D ata bas e
E ng in e
- -M a in t a in
O bs e rv a t io n s ;
M a in t a in
D a ta s e t s ;
R e tr ie v e
D a ta s e t s
O3
NO DE
P ro d uct
M a ch ine
--P ro d uc t
P ro c e s s o r;
F ilte r E ng in e
--S p e c ify
P ro d uc t s ;
P a ck a ge
D a ta s e t s ;
F ilt e r D a t a s e ts
NO DE
F o r e c a ste r
W o r k sta tio n
--W ea ther
V ie w e r
--W ri t e
We athe r
Sc rip t
NO DE
W e a th e r
M a c h in e
--Run Weath er
M o d e ls
T a s k in g
O1
I2
NO DE
Im a g e
M a c h in e
--Im a g e
G e n e ra t o r;
Im a g e
P ro ce s s o r
--G e n e ra t e
Sy m b o l i c
Images;
Co m bine
Images
Figure 21. Second NDC Transformation of ONA/A2
Continuing in the same way, we create an NDC transformation of ONA/A3:

C2 P ro d u c t R e q u e s t s
C1 S c h ed u le s
I2
NO DE
F ulfillm e nt
W o rk s t a t io n
--O rd e r D e s k : R e q u e s t
L o g g e r; O rd e r L o g g e r
--C o lle c t R e q u e s t s ;
O rd e r P ro d u c ts
R e c e iv e d R e q u e s t s
O1
N O DE
Pro d u ct io n
S e rv e r
--Sta g e R e a d y
P ro d u c ts
D E VIC E
L o ca l A re a
N e t w o rk
--P ro v id e P ro d u c t
Access
I1
NO DE
P ro d u ct
W e b s it e
--S e le c t W e b
P ro d u c ts ;
P u b lis h P a g e
O2
D E VIC E
W eb S erver
--S e rv e
P age
NO DE
M ail
C o m p os e r
- -S p e c if y E m a il
P ro d uc t;
C o n s tru c t
E m a il P ro d u c t
M essage
D E VIC E
E m a il S e rv e r
--E m a il P ro d u c t
M e ssa ge
M 1 c F u lfillm e n t Te c h n ic ia n
Figure 22. First DNC Transformation of ONA/A3
And now we can raise all our transformations to the A0 level, as shown in the following diagram:
103
Buoy
I1
D E V IC E
A rgo s
S ys te m
--Re la y
Com m ands;
R e la y D a t a
D E V IC E
Buo y
Se nso rs
--Se n s e
O b s e rv a b l e s
O c e an O b s e rv ab le s
D E V IC E
B uoy
R e ce iv e r
--R e c e i ve
Com m a nds
M e a s u re d O b s e rv ab le s
O1
N O DE
B u oy
P ro ce sso r
P ro ce s s o r
--G a t he r
M e a s u re m e n t s ;
P a c ka g e D a t a
4
2
D E V IC E
B uoy
T r a n sm itte r
--Se n d D a t a
10
NO DE
C o n tr o lle r
W o r k sta tio n
B ro w s e r
--G e n e ra t e
Co m m a n ds
NO DE
D a ta
M a ch in e
--O b s e rv a t i o n
P ro ce s s o r;
D a ta se t
P ro ce s s o r
--Sp e c i f y
O b s e rv a t i o n
Data
St a n d a rd s ;
P re p a re
O b s e rva t i o n s
;
Sp e c i f y
D a ta se t
Data
St a n d a rd s ;
P re p a re
System Controller
DE VIC E
D a ta b a s e
E ng ine
-- M a inta in
M a inta in
D a ta s e ts ;
Re trie v e
D a ta s e ts
NO D E
P ro d u ct
M a chin e
-- P ro d uc t
P ro c e ss o r;
F ilte r Eng ine
-- S pe c ify
P ro du c ts ;
P a c k a ge
D a ta s e ts ;
F ilt e r D a ta s e t s
NO DE
W e a th e r
M a c h in e
--R un W e a t he r
M o de ls
NO D E
M a il
C o m pos er
-- Spe c if y Em a il
P ro du c t;
Co ns tru c t
Em a il P ro duc t
M es s age
13
11
NO DE
F u lfillm e nt
W o rk s t a t io n
-- O rde r D e s k : R e qu e s t
Lo g ge r; O rde r Lo gg e r
-- C o lle c t Re que st s ;
O rde r P ro du c ts
NO DE
F o r e ca s te r
W o r ks ta tio n
--W e a t he r
V ie w e r
--W ri t e
We a the r
Sc ri p t
I2
S at e llit e I m a g e ry
N O DE
Im a ge
M a ch ine
--I m a ge
G e n e ra t o r;
I m a ge
P ro ce s so r
--G e n e ra t e
Sym b o l ic
I m a g es ;
C o m b i ne
I m a ge s
12
19
17
NO D E
P ro d u ct
W e b s it e
-- S e le c t W e b
P ro d uc t s ;
P ublis h P a g e
NO DE
P ro du ct io n
S e rv e r
-- S ta g e R e a d y
P ro duc ts
14
M3
D E V IC E
E m a il S erv e r
--E m a il P ro duc t
M e s s ag e
DE VIC E
L o ca l A rea
N e tw o rk
- -P ro v ide P ro duc t
Acce ss
D E V IC E
U se r
W o r k sta tion
--L o ca l A re a
N e t w o rk;
B ro w s e r;
E m a i l C l i e nt
D E VIC E
W e b S e rv e r
-- S e rv e
20
P age
18
16
15
W e at h e r F o re c a s t e r
P ro d u c t E n g in e e r
F u lfillm e n t T e c h n ic ia n
Figure 23. First NDC Transformation for ONA/A0
We are now ready for the finishing touches:
Transform residual IDEF0 loopbacks, such as that between the Product Machine and the
Controller Workstation, into forward connections.
Look at the boundary arrows to describe likely devices to which they may be expected to be
connected.
104
It is highly likely that a User Workstation will be the destination of Meteorological Products
and that the same User Workstation will be the likely source of Product Requests.
It is highly likely that Satellite Imagery, provided by legacy behaviors, will be drawn from
the NWS databases.
Rather than being a dynamic communication, Schedule now appears to be a manual
intervention, with action taken by appropriate system agents. We therefore remove Schedule
from our diagram of nodes, devices, and connectors.
Unbundle the stakeholders and system agents still shown as mechanisms. Gray-down their
connections to the prospective system so that the visual emphasis remains on nodes and devices.
Resolve any seemingly redundant connections between device and node boxes. For example,
there are three connection paths now shown between the Forecaster Workstation and the Image
Machine and there are two connection paths shown between the Fulfillment Workstation and the
Production Server.
Resolving redundant connections frequently involves resolving residual IDEF0 branches and
joins. Branching and joining imply a shared connection; the appropriateness of this implication
for each branch and join should be examined. However, this implication will be lost in any
transition to the sort of UML deployment diagram used by OOASIS to as the graphical basis for
an NDC diagram. To capture such a notion of a common connection path, you would need to
introduce some connection device into the NDC diagram.
Apply logical and physical grouping to visually annotate these relationships among nodes and
devices.
Uncross as many crossing connections as is topologically feasible within the groupings that have
been applied.
These final transformations give us our final NDC representation of the ONA/A0 diagram:
B uoy
I1
D E V IC E
Bu oy
S e n s o rs
D E V IC E
A rg o s
Sy st e m
-- Re la y
Com m ands;
Re la y Da t a
- -Se n s e
O b s e r v a b le s
D E V IC E
Bu oy
Re c e iv e r
-- Re c e iv e
Com m ands
5
NO DE
B uoy
P ro c e s s o r
--M e a s u re me n t
P ro c e s s o r
--Ga t h e r
M e a sure m e nt s;
Pa c ka g e Da t a
O1
DE V IC E
Buoy
T ra n s m itte r
--Se n d Dat a
11
N WS D ata C enter
NO D E
C o n t ro lle r
W o rks ta t io n
Bro w s e r
--Ge n e r a t e
Com m ands
1
NO DE
D a ta
M a c hine
--O b s e rv a t io n
P ro c e s s o r ;
D a ta s e t
P ro ce s s o r
--S pe cify
O bs e rv a t ion
D ata
S t a n da rd s ;
P re p a re
O bs e r v a t ion s ;
S pe cify
D atas et D ata
S t a n da rd s ;
P re p a re
D atas ets
D E V IC E
D a ta b a s e
E ng ine
--M a in t a in
M a in t a in
D atas ets ;
R e t rie v e
D a tas et s
NO D E
F o re c a s t e r
W o rks t a tio n
--W e at he r
V ie w e r
--W r it e
We at he r
Sc r ip t
NO DE
P r o d uc t
M a c hine
--P ro d u c t
P ro c e s s o r;
F ilt e r E n g in e
--S p e cify
P ro d u ct s ;
P a ck a g e
D a ta s e t s ;
F ilt e r
D a t a s e ts
NO DE
Im a g e
M a c h in e
--Ima g e
Ge n e ra t o r;
Ima g e
P ro c e s s o r
--Ge n e r a t e
Sy m b o lic
Im a g e s ;
C o m b in e
Im a g e s
12
16
NO D E
M a il
C om pose r
--S pe c ify E m a il
P r o du ct ;
C on s t ru ct
E m a il P rod u ct
M e s s a ge
13
D ata E ngineer
P roduct E ngineer
M3
D E V IC E
E m a il S e r v e r
--E m a il P r odu ct
M e s s a ge
D E V IC E
Us e r
W o rk s ta tio n
--Lo c a l A re a
Ne t w o rk;
Bro w s e r;
E ma il C lie n t
20
19
18
NO DE
P r o d uc tio n
S erver
--S t a ge R e a dy
P ro d u ct s
14
S ystem C ontro ller
D E V IC E
W e b S e rv e r
--S e rv e
Page
17
L o g g e r; O rd e r
Lo gge r
--C olle ct
R e qu e s t s ;
O r de r P r odu ct s
10
NO DE
W e a th e r
M a c h in e
--Ru n W e a t h e r
M o d e ls
NO DE
P r o d uct
W e b s ite
--S e le ct W e b
P r o du cts ;
P u b lis h Pa ge
NO D E
F ulfillm e nt
W o r k s ta tio n
--O rd e r D e s k:
Re q u e s t
D E V IC E
L oca l A re a
N e tw o r k
--P r o v ide P ro du c t
A cc e s s
15
Fulfillment Technician
Figure 24. Final NDC Transformation for ONA/A0
Now we turn to the Operations architecture model and apply these same transformations. Because the
Operations model shares activities and boundary arrows with our Products model, we also:
Tunnel any common inputs, controls, outputs, and mechanism arrows that are treated essentially
the same in both models. For example, we tunnel Ocean Observables, Measured Observables,
and Argos System at their attachments to the A0 box in the ONB/A-0 diagram.
Shade light red any activity boxes that are treated essentially the same in both models; we begin
with the assumption that the nodes, devices, and connections that have already been described for
that activity will continue to suffice. For example, we shade A1 (Measure Ocean Observables) in
the ONB/A0 diagram.
Diagram ONB/A2 deserves some comment. In this next figure, we have already shaded boxes A2.1 and
A2.2 a light red. First, note that we have removed the decomposition of activity A23. You should recall
our discussion of A231, which suggested that the undifferentiated attachment of all mechanisms to all
boxes indicated that we may have delved too deeply in our decomposition. For the task of generating
NDC information, this is clearly the case.
105
Used at:
Author:
P roject:
M odel:
Notes:
01/10/2002
Date:
Rev :
AKBocast
OOASIS SE
OOASIS NDC B (ONB)
1 2 3 4 5 6 7 8 9 10
Reader
W orking
Draft
Date
Context:
R ecommended
P ublication
A0
D ataset R eq u es ts
I1
Ge n e ra t e
Da t a s e t s
O2
Filte r
D at a s e t s
D a t a b a s e A d m in is t ra t o r
P ro po s e
I t i n e rari e s
R o u t in g P ro d u c t s
O1
P r o ce ssin g E n g in e s
I t in e ra ry E n g in e
D a t a b a s e E n g in e
W e b S e rv e r
B ro w s e r
P age:
A2
T itle:
Number:
AKB9
P. 6
Figure 25. First NDC Transformation of ONB/A2
Second, our transformation of box A23.1 will be different from previous box transformations because we
allowed two mechanisms to be attached to this box. Here we will generate a pair of NDC boxes to replace
the single present activity box, one for each mechanism.
Third, in the Operations model we had attached the label Browser to the Route Planner mechanism arrow
to indicate that it is expected that the route planner would use a browser to work with the Propose
Itineraries facility. Based on our work developing NDC information from the Products architecture
model, we are now fairly confident that the User Workstation we have identified, loaded as it is with a
browser and a mail client, will fulfill this requirement.
These transformations are shown in the next diagram:
106
D at a s e t R e q u e s t s
O cean O bervations
Ge n e ra t e
Da t a s e t s
O2
Filt e r
Datasets
2
NO DE
Itin e r a r y
E n g in e
--P ro p o s e
I t i n e ra ri e s
DE V IC E
W eb Se rve r
--P ro p o s e
I ti n e ra ri e s
3
F ilt e r E n g in e
P ro c e s s in g E n g in e
Routing Products
D a t a b a s e E n g in e
Figure 26. Second NDC Transformation for ONB/A2
The last changes we make are to remove mechanisms already handled in our NDC information for pink
shaded boxed and to change IDEF0 arrows representing known concepts already treated into our NDC
connectors:
I1
Ge n e ra t e
Da t a s e t s
O2
Filt e r
Datasets
NO DE
Itin e r a r y
E n g in e
--P ro p o s e
I t i n e ra r i e s
D E V IC E
W e b Se rve r
--P ro p o s e
I t i n e ra ri e s
O1
Figure 27. Third NDC Transformation for ONB/A2
When the A2 diagram information is raised to the A0 diagram level, we obtain a view like this:
107
B uo y S ta t u s
M e a s u re
Ocean
O b s e rv a b le s
C 1 M a in t e n a n c e N o t ific a t io n
C4 P ro d u c t R e q u e s t s
C 3 M in is t e ria l R e q u e s t s
1
D a t a s e t R e q u e s ts
G e n e ra t e
Datasets
Filt e r
Datasets
D a t a b a s e A d m in is tra t o r
NO DE
Itin e r a r y
E n g in e
--P ro p o s e
I t i n e ra r i e s
A c tiv it y S t a t u s
D E V IC E
W e b Se rve r
--P ro p o s e
I t i n e ra ri e s
O4
M 2 R o u te P la n n e r
NO DE
A d m in istr a to r
W o r ksta tio n
--Sy s t e m St a t u s
R e p o rt e r;
Sys t e m
P e rfo rm a n ce
R e p o rt e r
--R e p o rt Sys t e m
S y s te m S t a t u s
M in is t e ria l R e p o rt s
O1
O3
A d m in is t ra t o r
Figure 28. First NDC Transformation for ONB/A0
In the next step, we integrate what we have described in the Operations NDC model with the Products
NDC model. This entails adding the nodes and devices from the Operations NDC model and establishing
appropriate connections between these nodes and devices and existing nodes and devices. Our integration
diagram looks like the following figure.
108
Buoy
I1
O ce a n O b s e r v a b le s
D E V IC E
S a te llite
C o mms
--A rg o s
Sys t e m
--R e la y
Com mands,
R e la y D a t a
D E V IC E
Buoy
S e n so rs
-- Se n s e
O b se rv a b l e s
D E V IC E
B uo y
R e c e iv e r
--R e c e iv e
Comm ands
M e a s u r e d O b se r v a b le s
NO DE
Buoy
P r o c e sso r
P ro c e s s o r
--Ga t he r
Me a s u re m e n t s ,
P a c ka g e D a t a
O3
D E VIC E
Bu o y
T ra n smitte r
--Se n d D a t a
11
A d m in is t ra t o r
NW S Data Center
NO DE
A d m in istr a t o r
W o r ksta tio n
--Sys t e m St a t u s
R e p o rt e r; Sys t e m
P e rf o rm a n c e
R e p o rt e r
--R e p o rt Sy s t e m
St a t u s ; R e p o rt
Sy s t e m
A c c o m p li s h m e n t s
S yste m S t atu s R ep orts
O1
M ini st e ria l R e p o r t s
O2
31
NO DE
It in e ra ry
E n g in e
--P ro p o s e
I t i n e ra ri e s
30
D EVIC E
W e b S e rv e r
--S e rv e
P a ge
NO DE
C o n t ro lle r
W o rksta tio n
--C o n t ro l P a n e l ,
B ro w s e r
--G e n e ra t e
Com mands
NO D E
D a ta
M a chine
--O b s e rv a tio n
P ro c e s s o r;
D a ta s e t
Pro c e s s o r
--S pe c if y
O b s e rv a tion
D a ta
S ta n d a rd s ;
P re pa re
O b s e rv a tio n s ;
S pe c if y
D a ta s e t D a ta
S ta n d a rd s ;
P re pa re
D a ta s e ts
D E V IC E
D a ta ba se
E ng ine
--M a in ta in
O bs e rv a tio n s ;
M a in ta in
D a ta s e ts ;
R e trie v e
D a ta s e ts
NO DE
P ro d uct
M a chine
- -P ro du c t
P ro c e s s o r;
F ilte r En g in e
- -S pe c ify
Pro d u c ts ;
Pack age
D a ta s e ts ;
F ilte r D a ta s e ts
NO D E
P ro d u ct
W e b s it e
--S e le c t W e b
P rod u c t s ;
P u b lis h P a g e
NO DE
F o r e c a ste r
W o rk st a tio n
- -W eather
Vie w e r
- -W ri t e
W e ather
Sc ri p t
10
NO DE
W e a th e r
M a c h in e
--Run W eather
Mode ls
NO DE
Im a g e
M a c h in e
-- Im a ge
G en e ra t o r;
Im a ge
P ro c e s s o r
-- Ge n e ra t e
Sy m b o li c
Im a ge s ;
Co m b i n e
Im ages
8
6
12
NO D E
F ulfillm e nt
W o rk s t a t io n
--O rd e r D e s k :
R eque st
Lo g g e r; O rd e r
Lo gg e r
--C o lle c t
R e q u e s ts ;
O rd e r P ro d uc ts
16
D E V IC E
U se r
W o r ksta t io n
- -L o ca l A re a
N e t w o rk;
B ro w s e r;
E m a il C li e n t
D E V IC E
E m a il S e rv e r
--E m a il P ro d uc t
M e s s a ge
13
NO DE
P ro d uct ion
S e rv e r
--S ta ge R e a dy
Pro d u c ts
D E VIC E
L o ca l A r e a
N e t w o rk
--P rov ide P ro du c t
Access
14
S y s t e m C o n t r o lle r
P r o d u ct E n g in ee r
M3
17
N O DE
M a il
C om p o se r
-- S p e c if y E m a il
Pro d u c t;
C on s truc t
E m a il P ro du c t
M e s s age
20
19
18
15
F u lfillm e n t Te c h n ic ia n
Figure 29. First NDC Information Integration
It is now quite straightforward to translate this into a UML deployment diagram for OOASIS software
practitioners: there could be a one-to-one correspondence between the nodes, devices, and connectors in
our NDC integration diagram and the nodes, devices, and connectors of a UML diagram. However, as this
diagram is rather complex, we consider that the OOASIS practitioner looks to the NDC diagram not as a
specification of the hardware architecture but rather as a guide to constraints that hardware architecture
might impose on the design of software for the prospective system.
Our first NDC information integration view incorporates a number of boxes that rather than impose
constraints would allow the software designer to influence the selection of hardware upon which the
software would run. Perhaps a Weather Machine should run on a supercomputer; perhaps all application
logic that accesses the database should be run on one mainframe computer rather than on distributed
machines throughout the NWS Data Center.
Rather than proceed directly to the OOASIS NDC diagram, we first attempt to coalesce processor nodes
where the individual nodes of processor capability do not appear to impose constraints on software
design. In this sense, this reduction assumes that at this time it does not really matter to the system
concept what the eventual platform will be for these coalesced nodes. Such a reduction is conveyed in the
following figure.
In this reduction, we have coalesced:
The system controller, order fulfillment, and system administrator workstations into the System
Workstation
The Itinerary Engine, Product Webset, and Mail Composer nodes into the Web Services Machine
109
The Data Machine, Product Machine, and Production Server into the Product Data Machine.
E n v iro n m e n t
Buoy
I1
D E V IC E
Buoy
S e n so r s
D E V IC E
S a te llite
C o m ms
D E V IC E
Buoy
R e ce iv e r
NODE
B uo y
P r o ce sso r
O3
D E V IC E
Buoy
T r a n sm itte r
11
F u lfillm e n t T e c h n ic ia n
S y s t e m C o n t rolle r
A rg u s S y s t e m
A d m in is tra t o r
NW S Data Center
N ODE
Sys tem
W o rk s t a t io n
S y s t e m S t a t u s R e p ort s
M in i s t e ria l R e p ort s
O1
O2
D E V IC E
E m a il
S e r ve r
NO DE
Web
S e rv ice s
M a chine
19
1
D E V IC E
Are a
N e tw o r k
30
D E V IC E
W e b S e r ve r
D EVIC E
R em ot e
User
W o rk s t a t io n
DEVIC E
N e t w o rk
User
W o rk s t a t io n
20
17
15
W e a t h e r P re s e n t e r
NO DE
P r o d u ct
D a ta
M a ch in e
NO DE
F o r e ca s te r
W o r ksta tio n
Tsu n am i C en ter
NO DE
W e a th e r
M a ch in e
N O A A ( B u o y M a in t e n a n c e )
10
NO DE
Im a g e
P r o ce s s in g
M a ch in e
D E V IC E
D a ta b a se
E n g in e
12
W e a t h e r F ore c a s t e r
Figure 30. Second NDC Information Integration
We refrained from coalescing the weather forecasters workstation with the system staff workstation for
two reasons. First, the weather forecaster is an external actor for the prospective system and this
workstation is the point of contact of this actor with our system. Second, while it seems reasonable to
allow the possibility that any system workstation could be used by any system agent for any system
purpose, we should presume that software specialized to support this actor will be resident on this
workstation.
We refrained from coalescing the Weather Machine into the Product Data Machine because it seems
reasonable (although not probable) that the Santa Narida NWS may want to allocate this behavior to a
110
supercomputer. Leaving the Weather Machine as a separate node will remind us of this possibility
without committing us to a specific platform. Similar reasoning also persuaded us to keep the Image
Processing Machine as a separate node.
We have also added our stakeholders at the nodes and devices where they will interact with the
prospective system. In doing this, we broke out remote from network workstations to be able to show
which stakeholders would have direct access to the NWS network and thus direct access to meteorology
datasets and products.
Our UML deployment diagram for OOASIS is shown in the next figure.
Environment
5-10 sensors
on each buoy
Buoy Sensors
plans are for
1000 buoys
Buoy Receiver
Buoy
Processor
Buoy
Transmitter
Satellite
Communication
Tsunami
Warning Center
Argos System
Internet
Shipping Route
Planner
Email Server
Remote User
Workstation
NOAA
Maintenance
System
Workstation
System
Administrator
System
Controller
Weather
Presenter
Fulfillment
Technician
Web Services
Machine
Web Server
Network User
Workstation
Institute
Scientist
Product Data
Machine
Area Network
Forecaster
Workstation
Database
Engine
Weather
Forecaster
Image
Processing
Weather
Machine
Figure 31. OOASIS NDC Diagram
A.2
A.2.1
RESULTS OF THIS METHOD

STAKEHOLDERS
We have identified eight external stakeholders and four internal stakeholders. For each external
stakeholder we have identified:
111
A minimalist stakeholder model

A role in the stakeholder context diagram of one or more requirement and/or architecture models.
For each internal stakeholder we have identified a role in one or more decomposition diagrams of one or
more architecture models.
For each stakeholder we have concepts indicating the role they play with respect to the prospective
system, the behaviors expected of that role, the facilities (if any) provided by the prospective system for
that role, the inputs needed by the stakeholder to fulfill that role, the results of carrying out that role, and
the guidance required to successfully execute that role.
In addition to the environment, the identified external stakeholders are:
Weather Forecasters
Weather Scientists
Weather Showmen
Tsunami Warning Center
Shipping Route Planners
National Weather Service (NWS)
Argos System
National Oceanographic and Atmospheric Agency (NOAA)
The identified internal stakeholders are:
System Controller
Order Fulfillment Technician
Database Administrator
Administrator
Product/Data Engineer
Note that a model glossary entry for each stakeholder (i.e., a labeled mechanism arrow) would be a
required element of a complete IDEF0 model.
Context Diagram
The context diagram required by the OOASIS software practitioner is created by a conflation of the A-0
diagrams of our architecture models. Because it is derived from IDEF0 modeling, this context diagram
provides richer semantics and is thus a richer source of useful information than most OOASIS software
practitioners will be accustomed to. Bear in mind that each term in this context diagram will have a
112
complete entry in the model or project glossary. We will leave the reduction of information in this
diagram to the OOASIS software practitioner.
USED AT:
AUTH O R: AK B ocas t
DATE 12/27/2001
PRO JECT: O O ASIS SE
REV
M O DEL: O O ASIS Conte xt Diagram (O CD)
NO TES: 1 2 3 4 5 6 7 8 9
WORKING
READER
DATE
C O NTEXT:
DRAFT
To p
RECOMMENDED
TOP
PUBLIC AT ION
S c h e d u le s
Ima g e S t a n d a rd s
S y st e m S t at us
x O c e a n O b s e rv a b le s
G en erat e M et eo ro lo g y Pro d u ct s
S at ellit e I m ag er y
x
M e t e o r o lo g y Pr o d u c t s
x
x
x
x
x
Na t io n a l W e a t h e r S e rv ic e
PAGE:
A-0
TIT LE:
Context of Meteorology Produc t Generation
NUMBER:
AKB1
P. 1
Diagram 74. OCD/A-0 (Context of Meteorological Product Generation)
As-Is Process
We deliberately sidestepped the need for an as-is process model in this case study by calling for a de novo
prospective system.
To-Be Process
The architecture and requirements models, from stakeholder context A-1 diagrams through their leaf
decomposition diagrams, specify the to-be process. No transformation should be required for OOASIS
application.
Summary Use Case Progenitors
Look to the stakeholder context diagrams and the system backstory for information upon which to create
summary use cases for OOASIS.
113
System Use Case Progenitors

Left-branch traversal, stopping at stakeholder mechanisms, of our architectural models decomposition
diagrams gives us this system use case diagram for our case study:
Environment
Argos System
System Controller
Product Engineer
Database
Administrator
<<depend>>
<<depend>>
Generate Reports
Run Weather Models
Weather
Forecaster
<<depend>>
<<depend>>
System
Administrator
<<depend>>
Propose Itineraries
Stage Products
Fulfillment
Technician
<<extend>>
Weather
Broadcaster
<<extend>>
Route Planner
Post Products
Institute Scientist
Email Products
Tsunami Warning
Center
Figure 32. OOASIS System Use Case Diagram for Buoy Case Study
System NDC Diagram Progenitors

Our NDC transformations of our IDEF) architectural models lead to this system NDC diagram for our
case study:
114
Environment
5-10 sensors
on each buoy
Buoy Sensors
plans are for
1000 buoys
Buoy Receiver
Buoy
Processor
Buoy
Transmitter
Satellite
Communication
Tsunami
Warning Center
Argos System
Internet
Shipping Route
Planner
Email Server
Remote User
Workstation
NOAA
Maintenance
System
Workstation
System
Administrator
System
Controller
Weather
Presenter
Fulfillment
Technician
Web Services
Machine
Web Server
Network User
Workstation
Institute
Scientist
Product Data
Machine
Area Network
Forecaster
Workstation
Database
Engine
Weather
Forecaster
Image
Processing
Weather
Machine
Figure 33. OOASIS NDC Diagram for Buoy Case Study
Future Method Enhancements

Future releases of this method will include treatment of alternative, anomalous, and enumerated behaviors
to support OOASIS Use Case elaboration.
115
116
B. SANTA NARIDA BACKSTORY

B.1
SANTA NARIDA AND THE SANTA NARIDA OCEAN OBSERVATION

REGION
Santa Narida is an equatorial archipelago nation. Santa Narida is located on the equator due south of Los
Angeles. Santa Narida is roughly equidistant from the major Pacific Rim shipping destinations of Los
Angeles, Honolulu, the Panama Canal, and Guayaquil, Ecuador. Unusual for the Pacific Ocean, the Santa
Narida Islands form a rough circle around the central Baia del Handico. As a result, Puerta Oveida, Santa
Naridas principal port and capital city, have been known as a safe haven for generations of Pacific
sailors.
Puerta Oveida was founded in 1539 by Elianzo Santa Maria Delacortez, captain of the treasure galleon
San Cristobello when the San Cristobello was blown by unrelenting storms from the coastal waters of
Peru and past the Galapagos Islands as she attempted to head north to Panama. Delacortez claimed the
islands and named them after the Catholic patron saint of sudden salvations, to honor the seemingly
miraculous discovery of a sanctuary in what were then uncharted and unknown waters.
Delacortez and his crew married into the society of the native Polynesian inhabitants. Perhaps because
the sole representative of the Church, Fra Jaime Fernando, unfortunately has been swept overboard as the
San Cristobello foundered into the Baia del Handico, the strict Catholic customs of the Spanish colonies
to the West never took hold in Santa Narida. To this day, Santa Naridians are known throughout the
Spanish-speaking world as unusually informal and friendly people.
Contact with the Spanish colonies of the mainland was reestablished in 1547. Delacortez was appointed
Governor-General of the Santa Narida Empire in 1553 at the age of 45; this title shows down to today the
dreams and ambitions of the Spanish colonizers and the vast ignorance of their Pacific holdings suffered
by the Royal Court in Spain.
In spite of the aspirations of empire, Santa Narita largely remained undisturbed for centuries and largely
forgotten by Spain. She lay too far to the East to be of much use or interest even to buccaneers and pirates
preying for Spanish gold, except in times of exceptional peril from the Crown or from weather
closer to the South American coast. In 1873, competing scientific expeditions from Peru and Ecuador
battled in the waters off Senor Lopez de Menor Island on the western edge of the archipelago. The vessels
of both expeditions sank and the survivors of both sides were absorbed into the carefree Santa Narita
society. This battle is commemorated by the War of Two Losers National Park, now internationally
famous as a playground for scuba divers.
Santa Narita claimed independence from Spain in 1898, more from a desire to avoid the fate of the
Philippines, which had been invaded by American forces fighting the Spanish-American War, than from
117
B. Santa Narida Backstory
any intense yearning for political freedom. In yet another sign of the easy-going lifestyle of these islands,
Bolivar Garcia de los Rosas Rojas, the Crown-appointed Governor of Santa Narita, became the new
nations first president.
In 1934, a little known page in Pacific history was played out in the harbor of Puerta Oveida. In late 1932,
Ernesto Marquez, then Prime Minister and acting Presidentwhile the elected president Tomas Maria
Escobar was in hospital in Los Angeles in the United States for surgerylearned of the successful
annexation of the Galapagos Islands by Ecuador. He feared that, emboldened by that success and in the
growing global disorder that presaged World War Two, Ecuador might attempt to annex Santa Narida as
well. Marquez sought support from the French in Tahiti as well as from Australia and New Zealand;
during his recovery, Escobar in the United States pressed as well for the involvement of the United States
Navy.
By May 1933, all four nations has accepted this opportunity and established limited naval anchorages
under 99-year leases granted by Santa Narida on various islands surrounding the Baia del Handico. When
the long-expected Ecuadorian fleet arrived on June 6, 1934, the commanding Ecuadorian admiral,
Fernando Rio Harmizo, was greeted by a small multinational flotilla of disinterested partners of Santa
Narida. Rio Harmizo sailed back to Ecuador with a similar 99-year lease for an anchorage sheltered by
Caterina Isobella Island, but no facilities have yet to be constructed there by Ecuador, except for three
soccer fields now used by the local community as a fairgrounds when soccer is not in session.
This was the first notable involvement of the United States with Santa Narida. Of course, with the
outbreak of war in the Pacific in 1942, Santa Narida became an important part of the long supply lines to
the combatants in the eastern Pacific. The United States greatly expanded the harbor facilities of Puerta
Oveida during the war. The United States also constructed the island countrys first major airfield,
building it out on landfill into the Baia del Handico from the neighboring island of Santo Domonico del
Sur. Santa Narida International Airport is todays incarnation of the original Eagle Point Naval Air
Station built by American CeeBees in 1943.
World War II finally introduced Santa Narida into the turbulent global community of the latter part of the
20th Century. While history and tradition had led Santa Narida to identify primarily with Spanish cultures
on the eastern coasts of the Americas, the post-war years found Santa Naridians looking to Americans,
Australians, and Japanese as primary trading partners. Santa Narida discovered that it was well situated to
continue its position in trans-Pacific trade, only now in tourist and business travel and cargo
transshipment rather than in war materiel. It also found that to fully enter into these trades, Puerta Oveida
would need to compete with established trading routes that led north to Los Angeles and across the
Pacific via Honolulu to Japan and south to Santiago and across the southern Pacific via Tahiti to New
Zealand and Australia.
In 1954, Santa Narida joined the United Nations and subsequently joined the World Meteorological
Organization (WMO) in 1956. The Santa Narida National Weather Service is currently a regular
consumer of imagery produced by the WMOs Global Ocean Observing System (GOOS). When the
WMO joined with the Intergovernmental Oceanographic Commission (IOC) of UNESCO to form the
Data Buoy Cooperation Panel (DBCP) in 1985, Santa Narida was granted observer status; with the launch
of its first ocean meteorology buoy in 1991, Santa Narida applied for and became a full member of the
DBCP.
118
Santa Naridians were first formally trained in weather observation and forecasting by American forces
during World War II. The government of Santa Narida readily recognized this as an important capability
for an island nation. The Santa Narida National Weather Service (NWS) was officially formed in 1944
with advisors from the U.S. Navy and the U.S. Army Air Corps. From this beginning, the Santa Narida
NWS has always maintained strong relationships with the meteorological community in the United States.
Most Santa Naridian weather professionals are trained at universities in the United States. The Santa
Narida NWS maintains organizational relations with the American NOAA and its weather and climate
related activities. Technical advisors detached from NOAAs National Data Buoy Center (NDBC) were
instrumental in helping Santa Narida establish its ocean meteorological buoy program in the early 1990s.
As Santa Narida enters the 21st Century, the Santa Narida NWS has proposed a major role for the Service
in the nations efforts to position itself as the preferred transit point for trans-Pacific air and water traffic.
NWS market research has established that one important decision factor in ship routing decisions is the
reliability of short and long term ocean weather forecasts, because weather has major impacts on
maintaining shipping schedules and on the cost of operations of cargo vessels, principally by affecting
fuel consumption. To provide the most reliable ocean weather forecasting in the entire Pacific region and
thus gain a competitive edge for Puerta Oveida, the Service has proposed to field an array of 1000 ocean
meteorological buoys, strategically positioned throughout what the Service has named the Santa Narida
Ocean Observation Region (see Figure 1).
These buoys will report a number of observations, including water and air temperature; swell or wave
height, period, direction, and energy; wind speed and direction; humidity; salinity; and surface
atmospheric pressure. These observations will be used by the Service to provide maritime forecasts via
the World Wide Web and thus accessible to shippers around the entire Pacific Rim. As participants in
WMO and the DBCP, the Service intends to provide this buoy-collected data to the international
community and to conform to quality and data standards established by the DBCP. In cooperation with
the DBCP, the Service also proposes the establishment of an International Mid Pacific Buoy Program
(IMPCP) and volunteers to host the Secretariat for this new DBCP Action Group. A primary activity
envisioned for the IMPCP will be to support the International Tsunami Information Center (ITIC) in
Honolulu and the International Coordination Group for the Tsunami Warning System in the Pacific
(ICG/ITSU), which falls under the aegis of the IOC.
Arising from its long relationship with NOAA and its involvement with the DBCP, the Service
contemplates contracting with the Argos Data Collection and Location System (ARGOS). This system
uses the Global Telecommunications System (GTS) to transmit collected data to the World Weather
Watchs (WWW) Global Data Processing System (GDPS), which provides core information management
services for the global operational meteorology community. Argos arranges for client data to be
distributed in a variety of forms by the GDPS.
Carlos Garcia de San Matel, general manager of the Santa Narida NWS, describes the Services view over
the next few years in these words:
By establishing the Santa Narida Ocean Observation Region, Santa Narida becomes a world player in
weather and climate science, but even more important for our country, we become a world player in
ocean transportation. With 1000 buoys observing the local environment within the Ocean Observation
Region, Santa Narida will provide to the world the most detailed and comprehensive look ever obtained
of any large ocean area. Santa Narida will provide to those who ship by sea through our newly renovated
and recently expanded port of Puerta Oveida the most accurate and detailed ocean weather forecasts
119
ever made. Our value proposition for maritime commerce is simply this: routes through the Santa Narida
Ocean Observation Region will have lower operating costs and more reliable schedules than any other
trans-Pacific routes.
Gabriella Garcia Formoza, chief scientist of the Santa Narida NWS, discusses Santa Narida National
Weather Service activities in more detail:
We will begin to deploy ocean meteorology buoys throughout the Region next year. Over the next 10
years, we plan to deploy some 100 buoys each year. The deployment scheme is designed to gradually
increase resolution over the entire region each year. Each buoy will host a variety of sensors that will
observe phenomena important to short and long term weather forecasting. In addition, as a member state
of the International Coordination Group for the Tsunami Warning System in the Pacific, each buoy will
have sensors dedicated to the task of monitoring key tsunami variables in the environment.
We have undertaken discussions with the global Argos system for environmental data communications.
We anticipate that our buoys will use 2-way satellite communications provided by Argos to command
these buoys and read the data captured by them. Our data will go up into space and travel halfway
around the world before it comes back to us via various dedicated international weather systems and the
world-wide Internet. We believe that Santa Narida is extremely fortunate to be able to draw and rely
upon global mechanisms already established by the international community to enable the World
Weather Watch. The World Weather Watchs systems will even backup and archive our data for us!
We will be working closely with the international Data Buoy Cooperation Panel. In fact, we are now
working to establish the International Mid Pacific Buoy Program as an action group of the DBCP. As a
tangible sign of Santa Naridas commitment to international cooperation, the Weather Service is
establishing the Institute for Mid-Pacific Ocean Meteorology. Among other activities, this Institute will
provide a home for the International Mid Pacific Buoy Program.
We envision the Institute as an environment for international collaborative work among Santa Narida
meteorologists and scientists visiting from many countries. Even as we speak, a memorandum of
understanding is being drafted between Santa Narida and the National Oceanic and Atmospheric
Administration of the United States. The agreement we seek will provide that the Institute permanently
hosts a small group of scientists from the United States, cementing the warm relationships that we have
enjoyed now with American scientists for several decades. In turn, NOAAs National Data Buoy Center
will provide at-sea maintenance for the buoys in our Observation Region; port facilities in Puerta Oveida
will be dedicated for the Pacific Observer, the NDBCs specialized buoy maintenance ship, and other
scientific vessels as part of Santa Naridas support for the International Mid Pacific Buoy Program.
Felipe Delacortez, who is a descendent of Elianzo Santa Maria Delacortez, is Chief Engineer of the Santa
Narida National Weather Service. He discusses the technical aspects of this new endeavor:
It is a magical world, today, no? I sit here in my office in Nuevo Chile (a small town on the north side of
Santo Domonico del Sur where the main offices of the National Weather Service are located) I press a
button on my computer and the Internet genie takes my commands all the way to France. From Toulouse
they go up into the sky until they are heard by a little moon, a satellite. When this satellite comes back
overhead, high above Santa Narida, he speaks to my darling buoys, all thousand of them. They listen with
eager ears and then they tell the little moon what it is which I want to hear.
Around the world goes my little moon until it sees a big ear in Alaska or far away in Virginia in the
United States. He speaks into that big ear; that big ear speaks into the net of glass that the Americans
120
have woven over all of North America, and voila, a computer in Maryland listens and attends. This
computer, a little wizard, takes all the data from my buoys in its hands, shapes it, forms it, patterns it, and
then does marvelous things with it. It catalogs my data and puts it into a big department of store of data
in just the right place so that anybody anywhere in the whole wide world can see it, feel it, buy it, use it;
we do that because Santa Narida is proud to now be a leader in weather science. But this wizard also
knows that this is my data, and he calls up the Internet genie, who takes all my data back across the
ocean all the way here to my little island. And, poof, here, on my desk, what my buoys have said to me,
neat, clean, tidy, pretty.
But what do I do with all this pretty data? Ah, but I have some of my own magic! Did you ever see that
movie, Fantasia? I have my own magical apprentices! One of my apprentices has a perfect memory and
can remember everything I ever tell it; I command this apprentice to remember all my pretty data. I have
another apprentice who knows all about tsunamis; this one scans my data as it comes in from all my
buoys, looking for tsunami signs, she sends her analysis of the data to the Tsunami Watch people up in
Hawaii, again through the Internet genie.
Then I have all the scientists over at the Institute who want my data for their mystical research and I have
all the weathermen here at the Weather Service who want my data for their forecasts. What do the
Institute scientists actually do with my pretty data? This is a real mystery to me; I just teach them how to
dance with my apprentice with the perfect memory. The scientists tell us what data they would like to see,
we send it to them. The magical Internet genie, of course.
It is a little different for our own weathermen who are right here in Neuvo Chile. We do the real work for
the republic. We even report the weather for the national radio and the national television. See over
there, Dolores del Munozthe cutest bambita on the whole island, no?she is on the television five times
a day with our weather! We use the imagery we get from GOOS as her backdrop; when the buoy data
starts to come in, we will make digital overlays in pseudocolor to show our people what the ocean is
doing! We will show temperature, how big the waves are, things like that, all in pretty colors. But that is
just show for us.
No, our real weathermen will integrate our thousand-point grid of observations into the weather models
we use now. Already we know how to do this with the data we gather from the five buoys we operate now.
This will be our real magic. To combine our GOOS imagery, our thousand-buoy data, and our island
sensors to make the worlds most accurate ocean weather forecasts! We have developed profiles of all the
important shipping lanes, and their alternates, in and out of Santa Narida to all the important Pacific
ports, both islands and the Rim. For our observation region, we will generate three-dimensional pictures
of instantaneous ocean-level weather all along every one of these lanes, and probabilistic animation of
weather features out to ten days! You and every shipper in the Pacific will be able to see these at our
website for shipping forecasts, www.shippingweather.sna; you see, we already have our domain! Imagine
this, if you schedule cargo, you can sketch the route you want on a visualization of the globe, and
shippingweather will tell you how long the passage will be! Sketch more than one route, and
shippingweather will tell you the route that will take the smallest time! Pick a port to start from and
another to end in, and shippingweather will show you the route that will make your operating costs the
less! Is this not magic? Then shippers will see that Santa Narida should be on their routes and Puerta
Oveida should be their favorite port of call! Not to mention the wonderful cantinas on Subara Street!
121
122
C. OOASIS NODE-DEVICE-CONNECTOR DIAGRAM

The NDC Diagram is a representation of:
Significant node groups. A significant node is a single computer processor (node) or a group of
interconnected nodes treated as single node because there are no constraints upon the freedom to
deploy software objects across that group of nodes.
Abstract devices
Interconnections among these nodes and devices. A node in OOASIS denotes a single computer
processor (and attached memory). More often, an abbreviation for significant node.
Actors. An actor is a primary initiator and/or recipient of messages or other events to/from the tobe-built system.
Actors interfacing to devices (or, in the case of actors representing external systems, they may be
shown as residing on a node).
Optionally, the NDC Diagram may be augmented with deployment information, especially for
OTS Software Components.
Its purpose is to provide a high-level view of hardware architecture sufficient to drive development of the
System software Deployment Model (i.e., support decisions concerning elaboration and deployment of
the System Software Architecture), and the Elaborated System Use Cases. Otherwise, it is probably too
abstract by itself to support any hardware-oriented analyses or decisions, but should serve as a common
point of reference across disciplines.
A node is a computer processor (bundled with rapid-access memory) that will host to-be-built software. A
group of interconnected nodes is treated as only one significant node group (or just "significant node")
when there are no constraints upon the freedom to deploy software objects across that group of nodes.
That is:
Interconnections among the nodes are of sufficient bandwidth and speed compared to desired data
size and transfer rates that internode communications has negligible engineering impact.
Load balancing across the nodes need not be explicitly engineered (e.g., due to use of a
commercial object request broker or operating system in a multiprocessor environment that
performs automatic load balancing).
A further implication is that significant node groups may be scaled freely; that is, the group can be
engineered as a single (logical) node, the power of which is easily increased simply by adding additional
123
C. OOASIS Node-Device-Connector Diagram
nodes (at least up to the point where conditions of deployment freedom no longer apply). Moreover, all
nodes in a significant node group must have equal access to any abstract devices.
Note that a computer processor that figures into the system physical architecture the physical pieces (in
particular, computer hardware and devices) of the system and how they are connected but does not
host to-be-built software (i.e., it hosts only OTS Software Components) is represented as a device, not a
node.
Abstract devices are simply an abstraction of the hardware devices with which the software must interact
or which otherwise impact the software indirectly (e.g., software interacts with a transceiver directly, but
the software is also constrained to employ the protocol demanded by a satellite with which the software
must communicate through the transceiver). The device is abstract because initially you need know only
its general nature (e.g., transceiver, printer, monitor, sensor, type of sensor), not its particular hardware
model number or full specification.
Connectors are merely that; initially, they may show no more than which nodes have access to which
other nodes and devices. These connections may represent any kind of a by-wire or wireless
communication mechanism (e.g., the Internet, local area network, microwave).
Important attributes of nodes, devices, and connectors can be added to the NDC Diagram as they become
known or are posited for a feasibility study; for example: amount of memory attached to a node, the
maximum data rate of a device or connector. Of course, you will eventually need complete specifications
for nodes, devices, and connectors for Implement Software and, perhaps, to complete detailed failure
scenarios in the Elaborated System Use Cases.
Also track any associated volatilities within the NDC Diagram (e.g., alternative nodes, devices,
connectors) and similarly their attributes (e.g., denote the range of possible values for a volatile attribute).
Capturing uncertainty and volatility
The NDC Diagram can be augmented to show deployment information as well. This is particularly
convenient for OTS Software Components deployed on devices (that is, processors that do not otherwise
host any to-be-built software, as is frequently the case with legacy systems or large components such as
database management systems) because their deployment is not captured in the System Software
Deployment Models. Moreover, the System Software Deployment Models can be built as an extension of
the NDC Diagram, although this may be too cluttered in many cases.
Tool Hint: You can capture the NDC Diagram as a UML deployment diagram (without adding processes,
components, or objects). Actors and their associations to nodes and devices, as well as more detailed
specifications (e.g., node multiplicity), may be added with attached annotations (that UML modeling tools
usually support). You may find it helpful to define a special <<OTS>> stereotype for devices representing
OTS components.
Source: OOASIS Web Site
124
D.NATIONAL DATA BUOY CENTER

National Data Buoy Center
Measurement Descriptions and Units
STATION ID
five-digit WMO Station Identifier used since 1976. IDs can be reassigned to future
deployments within the same 1-degree square.
DATE
in UTC
TIME
To the nearest hour, UTC.
Data are classified according to the following groups. Any data field that contains "9 filled" represents
missing data for that observation hour. (Example: 999.9)
D.1
STANDARD METEOROLOGICAL DATA
ATMP
Air temperature (Celsius). For sensor heights on buoys, see Hull Descriptions. For
sensor heights at C-MAN stations, see C-MAN Sensor Locations.
WTMP
Sea surface temperature (Celsius). For sensor depth, see Hull Description.
DEWP
Dew point temperature taken at the same height as the air temperature measurement.
PRES
Sea level pressure (hPa). For C-MAN sites and Great Lakes buoys, the recorded
pressure is reduced to sea level using the method described in NWS Technical
Procedures Bulletin 291 (11/14/80).
WSPD
Wind speed (m/s) averaged over an eight-minute period for buoys and a two-minute
period for land stations. Reported hourly. See Wind Averaging Methods.
WDIR
Wind direction (the direction the wind is coming from in degrees clockwise from N) during
the same period used for WSPD. See Wind Averaging Methods.
GST
Peak 5- or 8-second gust speed (m/s) measured during the eight-minute or two-minute
period. The 5- or 8-second period can be determined by payload. See the Sensor
Reporting, Sampling, and Accuracy section.
WVHT
Significant wave height (meters) is calculated as the average of the highest one-third of
all of the wave heights during the 20-minute sampling period. See the Wave
Measurements section.
APD
Average wave period (seconds) of all waves during the 20-minute period. See the Wave
Measurements section.
DPD
Dominant wave period (seconds) is the period with the maximum wave energy. See the
Wave Measurements section.
125
D. National Data Buoy Center
MWD
Mean wave direction (degrees) corresponding to energy of the dominant period

(DOMPD). See the Wave Measurements section.
VIS
Station visibility (statute miles).
PTDY
Pressure Tendency is the direction (plus or minus) and the amount of pressure change
(hPa) for a three-hour period ending at the time of observation.
TIDE
The periodic rising and falling of the earth's oceans. Tide is measured in feet.
D.2
DETAILED WAVE SUMMARY
HO
Significant Wave Height is the average height (meters) of the highest one-third of the
waves during a 20-minute sampling period.
SWH
Swell height is the vertical distance (meters) between any swell crest and the succeeding
swell wave trough.
SWP
Swell Period is the time (usually measured in seconds) that it takes successive swell
wave crests or troughs to pass a fixed point.
SWD
Swell Direction is the compass direction from which the swell waves are coming from.
WWH
Wind Wave Height is the vertical distance (meters) between any wind wave crest and the
succeeding wind wave trough (independent of swell waves).
WWP
Wind Wave Period is the time (in seconds) that it takes successive wind wave crests or
troughs to pass a fixed point.
WWD
Wind Wave Direction is the compass direction (degrees) from which the wind waves are
coming.
Steepness
Wave steepness is the ratio of wave height to wave length and is a indicator of wave
stability. When wave steepness exceeds a 1/7 ratio the wave becomes unstable and
begins to break.
AVP
Average Wave Period is the average period (seconds) of the highest one-third of the
wave observed during a 20-minute sampling period.
D.3
ACOUSTIC DOPPLER CURRENT PROFILER (ADCP)
E01, E02, ,E20
Eastward directed current velocity measurements (cm/s) for twenty depth levels
separated by 16 meters of water. For station 46053, the first depth level begins at
24 meters below the water surface and the last level begins at 328 meters. For
stations 46023 and 46054, the first level begins at 25 meters and the last level
begins at 329 meters.
N01, N02, ,N20
Northward directed current velocity measurements (cm/s) for the twenty depth
levels described previously.
For more information, see the ADCP help section.
D.4
CONTINUOUS WINDS
DIR
Ten-minute average wind direction measurements in degrees clockwise from North.
SPD
Ten-minute average wind speed values in m/s.
GDR
Direction, in degrees clockwise from North, of the GUST, reported at the last hourly 10minute segment.
126
GSP
Maximum 5-second peak gust during the measurement hour, reported at the last hourly
10-minute segment.
GMN
The minute of the hour that the GUST occurred, reported at the last hourly 10-minute
segment.
For more information on continuous winds and the timing of these measurements, see the continuous
winds help section.
D.5
SPECTRAL WAVE DATA
Spectral wave density
Energy in (meter*meter)/Hz, for each frequency bin (typically from 0.03 Hz to

0.40 Hz).
Spectral wave direction
Mean wave direction, in degrees, for each frequency bin. A list of directional
stations is available.
Directional Wave Spectrum = C11(f) * D(f,A), f=frequency (Hz), A=Azimuth angle measured clockwise
from true North to the direction wave is from. D(f,A) = (1/PI)*(0.5+R1*COS(AALPHA1)+R2*COS(2*(A-ALPHA2))), in which R1 and R2 are nondimensional
and ALPHA1 and ALPHA2 are respectively mean and principal wave
directions. In terms of Longuet-Higgins Fourier Coefficients R1 =
(SQRT(a1*a1+b1*b1))/a0, R2 = (SQRT(a2*a2+b2*b2))/a0, ALPHA1 = 270.0ARCTAN(b1,a1), ALPHA2 = 270.0-(0.5*ARCTAN(b2,a2)+{0. or 180.}).
For more information on the mathematics behind the measuring of surface water waves, see the waves
help section.
D.6
WATER LEVEL
TG01, TG02, ,TG10
D.7
Six-minute water levels representing the height, in feet, of the water above or
below Mean Lower Low Water (MLLW). Please subtract 10 ft. from every
value to obtain the true water level value.
MARSH-MCBIRNEY CURRENT MEASUREMENTS
DIR
Direction the current is flowing TOWARDS, measured in degrees clockwise from North.
SPD
Current speed in cm/s.
127
128
E. APPLYING SADT ACTIVATION RULES TO IDEF0

ACTIVITY ANALYSIS
This discussion expands and elaborates the introduction to activation rules given by Marca & McGowan7.
Changes have been made to make the expression of activation rules consistent with the IEEE 1320.11998 IDEF0 standard. Unfortunately, activation rules are not treated by either the IEEE or the rescinded
FIPS PUB 183 IDEF0 standards.
E.1
ACTIVATION RULES
Activation rules are written to clarify which combinations of input, control, and mechanism produce
which combinations of output from a given activity. The general form of an activation rule is:
model/activity*rule : preconditions postconditions
comment
where:
model
activity
rule
- the abbreviated name of the model containing the box (optional)

- the node number of the activated activity
- an ordinal digit identifying the position of this rule in the set of activation rules for this
activity
preconditions
- an expression involving inputs and controls and possibly mechanisms
postconditions - an expression involving outputs and possibly inputs and controls
comment
- a comment (optional). One important use of this comment field is to identify the
appropriate called diagram when an activity is decomposed via call references rather
than by a direct decomposition diagram.
Example:
MDL/A324*3 : C3 and I1 and I2 O2 and O3
normal execution
FOO/Z6*5 : C1 and C2 and I3 and I4 O1 and O5
E.2
See SUB/D32.
CONDITIONAL EXPRESSIONS
These comments apply to both precondition and postcondition expressions.
David Marca and Clement McGowan. SADT: Structured Analysis and Design Technique. New York NY:
McGraw-Hill Book Company. 1988.
129
E. Applying SADT Activation Rules to IDEF0 Activity Analysis
Conditional expressions are constructed using ICOM codes and the logical operators AND, OR,
and NOT.
The operators AND and OR are written as the lowercase tokens and and or, respectively.
Upper case terms and symbolic operators (e.g., &, &&, +, |, ||) are not used. The
ICOM codes used in conditional expressions consist of digits and upper case letters. The lower
case terms and and or provide better visual contrast with ICOM codes and are easier to grasp
in these expressions than either upper-case terms or symbolic operators.
The operator NOT is written as the tilde character (~) or as the uppercase token NOT.
(Traditionally, an overline (like an underline, only above the term instead of under the term) has
been used as the NOT operator in IDEF0 activation rules. However, most computer-based tools
do not support overlines.)
Parentheses may be used to group elements of an expression.
Convenient conventions:
The notation X* may be used to indicate all ICOMs of the role designated by X. For example, this
activation rule states that all control, inputs, and mechanisms are required to produce all outputs:
C321*1 : C* and I* and M* O*

(This is the default activation assumption of IDEF0 semantics.)
The notation X*-n may be used to indicate all ICOMS in the role designated by X except for the
object whose ICOM codes ordinal position is n. For example:
R32*2 : C1 and I*-2 O1 and O2

This activation rule says that control C1 and all inputs except I2 are required to produce
outputs O1 and O2.
E.3
PRECONDITIONS
A precondition expression specifies the combination of control, input, and mechanism resources that are
required for a specific activation.
130
Control, input, and mechanism resources are specified by their ICOM codes.
A precondition may not include output ICOM codes.
The presence of an ICOM code in a precondition expression means that the object represented by
that ICOM code must be present for the activation to occur, unless qualified by an OR operator.
If an OR operator links two ICOM codes in a precondition, one or the other of those resources
must be present for that activation to occur.
The unary operator NOT may be used with an ICOM code to specify that this activation will
occur only in the absence of that resource, i.e., the object represented by that ICOM code must
not be present.
A precondition may not negate all controls on an activity. This would violate the basic IDEF0
semantic rule that every transformation must be constrained.
In general, precondition ICOM codes are grouped by role in the order:
Cn In Mn
and written from left to write in increasing ordinal order within a role, as this precondition expression
illustrates:
C1 and C3 and I2 and I5 and M2 and M3
ICOM codes that do not distinguish different activations may be omitted from a conditional
expression.
Examples of preconditions:
A4*2 : C2 and ( I1 or I3 ) O1
M32*4 : C1 and (I1 and NOT I4 ) O2
E.4
POSTCONDITIONS
A postcondition expression specifies the output that results from a specific activation.
Output, control, and input resources are specified by their ICOM codes.
A postcondition may not include mechanism ICOM codes. Mechanisms may not be negated in a
postcondition.
An output ICOM code in a postcondition expression means that the object represented by that
ICOM code must be produced by that activation, unless qualified by an OR operator. An output
not represented by an ICOM code in a postcondition expression will not be produced by that
activation.
If an OR operator links two output ICOM codes, one or the other of those outputs must be
produced by that activation.
Within a postcondition expression, the logical NOT operator may be applied to control and input
ICOM codes to indicate that such negated control or input has been completely consumed by the
transformation. (Note that a control so negated must be a control by virtue of role bundling.)
131
Control and input ICOM codes may appear in a postcondition only if they are negated.
A resource negated in a postcondition must appear in the precondition for that activation rule.
In general, postcondition ICOM codes are grouped by role in the order:
On ~Cn ~In
and written from left to write in increasing ordinal order within a role, as this postcondition
expression illustrates:
O1 and O3 and ~C2 and ~C3 and ~I2 and ~I5
Examples of postconditions:
A11*1 : C1 and ~I2 O1 and (O2 or O3)

A3*3 : C1 and I1 and I2 O1 and ~I2
E.5
WRITING RULE SETS
These rules apply to writing activation rule sets:
Each precondition must be distinct.

Any given output of an activity must be expressed in the postcondition of at least one activation
rule for that activity. That is, if we provide activation rules for an activity, we must account for all
possible products of that transformation; our postconditions must identify all possible outputs.
An output of an activity may be specified in the postcondition of more than one activation rule.
(For example, consider an activity status report.)
These considerations also apply to activation rules:
132
The default activation rule for an IDEF0 activity is that all controls, inputs, and mechanisms must
be present for the activity to execute. If the presence of all controls, inputs, and mechanisms is
required for activation, an explicit activation rule should not be provided.
If a control, input, or mechanism is required for all possible activations, then its ICOM code
should be omitted from all activation rules for the activity. It is for this reason that typical
activation rules do not include mechanisms.
If the postcondition of an activation rule for an activity contains OR operators, you should
decompose the activity to disambiguate that postcondition.
In a sense, an activity always completely consumes its input because an activity always
transforms its input into its output. The concept of negation should be judicially used to clarify an
activity. For example, consider this fragment:
blueprint
table legs
table top
A s s e m b le
T a b le
table
2
It would be silly to write:
A2*1 : C1 and I1 and I2 O1 and ~I1 and ~I2

However, in this case:
spark
cold air
hot air
fuel
1
furnace
it might well be useful to specify:
A1*1 : C1 and I1 and I2 O1 and ~I2

because the expended fuel has not been transformed into the hot air.
The OR operator in a precondition always signifies the conflation of otherwise distinct activation
rules. Consider:
R5*1 : (C2 or C3) and (I1 or I4) O1 and O2

This construction conflates these four distinct rules:
R5*1 : C2 and I1 O1 and O2

Consider this activation rule:
133
A14*3 : C2 and (I1 or I3) O1 and ~I3

which seems to be trying to say that I3 is totally consumed if I3 is used but I1 is not totally
consumed if I1 is used. Unfortunately, this statement actually says that I3 is totally consumed
whether it is an input or not! To capture such a distinction, separate activation rules are required:
A14*3 : C2 and I1 O1
A14*4 : C2 and I3 O1 and ~I3
There is no implied order of precedence within a set of activation rules. Consider this example:
order
m eat
h a m b u r g e r p a tty
bu n
p la in h a m b u r g e r
B u ild
B u rger
co n d im e n ts
d r e sse d h a m b u r g e r
ch e e se
ch e e se b u r g e r
1
Activation Rules:
1
2
3
4
:
:
:
:
C1
C1
C1
C1
and
and
and
and
I1
I1
I1
I1
--> O 1
and I2 --> O 2
and I2 and I3 --> O 3
and I2 and I3 and I4 --> O 4
One kind of puzzlement is evidenced by questions like:

If I already have input 2 and then I get input 1, how do I know that rule 1 wont fire when input 1
shows up instead of rule 2?
We see a second kind of puzzlement in questions like:

Does this mean that if rule 4 fires that all the other rules also fire? So that when rule 1 fires, all
possible outputs will be produced?
A third kind of puzzlement is shown by questions like:

How can I qualify C1 in an activation rule to signify its content, because which rule gets used
depends upon the content of the a control, not just its presence?
The real problem here is actually an IDEF0 modeling problem: the inputs, controls, and outputs are not at
the same level of abstraction. The following Table provides a complete set of possible activation rules
134
anomalies that may be associated with mismatched levels of abstraction for a situation like this hamburger
problem.
Table 1. Evidence for Problems in
Levels of Abstraction Provided by
Activation Rules
E.6
O full rules
short rules
comments
1 : C1 and I1
O1
2 : C2 and I1 and I2
O2
3 : C3 and I1 and I2 and I3
O3
4 : C4 and I1 and I2 and I3 and I4 O4
1 : C1
O1
2 : C2 and I2
O2
O3
4 : C4 and I2 and I3 and I4 O4
same levels of abstraction
1 : C1 and I1
O1
O1
O1
1 : C1
O1
2 : C2 and I2
O1
O1
4 : C4 and I2 and I3 and I4 O1
comments required;
understanding rule
requires decomposition
diagram
1 : C1 and I1
O1
O2
O3
1:
O1
2 : I2
O2
3 : I2 and I3
O3
4 : I2 and I3 and I4 O4
precedence puzzles;
precondition anomaly
1 : C1 and I1
O1
O1
O1
1:
O1
2 : I2
O1
3 : I2 and I3
O1
4 : I2 and I3 and I4 O1
precedence puzzles;
precondition anomaly;
comments required;
understanding rule
diagram
1 : C1 and I1
2 : C2 and I1
3 : C3 and I1
4 : C4 and I1
O1
O2
O3
O4
1 : C1 O1
2 : C2 O2
3 : C3 O3
4 : C4 O4
this is OK, I think; Im not

quite sure why the
difference in levels of
abstraction doesnt appear
to pose a problem here
1 : C1 and I1
2 : C2 and I1
3 : C3 and I1
4 : C4 and I1
O1
O1
O1
O1
1 : C1 or C2 or C3 or C4 O1
different ways of doing or

triggering the same thing;
possibility of ladder
decomposition diagram
1 : C1 and I1
2 : C1 and I1
3 : C1 and I1
4 : C1 and I1
O1
O2
O3
O4
1 : C1 and I1 O1 or O2 or O3 or O4
rule reveals no information;

understanding rule
diagram
1 : C1 and I1
O1
default IDEF0 rule; same

levels of abstraction; rule
does not need to be
expressed
INCORPORATING ACTIVATION RULES IN A DIAGRAM
A set of activation rules for an activity should be treated as a model note in the IDEF0 diagram that
contains the box that models that activity. If there is sufficient room in the diagram, the activation rules
may be fully expressed directly in the diagram as a model note. Otherwise, the model note should direct
the reader to the appropriate text page.
Examples:
135
Schedule
Blueprint
Table Legs
Table Top
Parts Request
Production Status
Table
A s s e m b le
T a b le
1
Acti vation rules for A421:
3 1: I1 and I2 O2 and O3
2: ~I1 or ~I2 O1 and O2
Note that the model/node elements of the rule statement have been omitted because the context
unambiguously identifies these rules.
Schedule
Blueprint
Table Legs
Table Top
Parts Request
Production Status
Table
A s s e m b le
T a b le
1
See A42T2 for

activation rules.
C a rp e n t e r
In this example, the model note directs the reader to the second text page accompanying diagram page
A42.
E.7
REVISITING MARCA AND MCGOWANS EXAMPLE
Marca and McGowan provide this example to illustrate activation rules:
136
Job p lans
Job
Plans
Unfinis hed Jobs
Unfinished Jobs
E v a lua te
Jo b
P r o g re ss
Job Status
Finished or Unfinished Job
Next Job O rder Step
J
21*2: I1 and C1 J
21*3: I1 and C1 J
21*4: I1 and C1 J
21*1: I1 and C1
Job S tatus
Finis hed or Unfinis hed Job
Nex t Job Order S tep
O3
(Job start.)
O 2 and O 3
(Next job step.)
O2
(Inspection time.)
O1
(Status request.)
Figure 19-3 An Activity w ith Several Activation Rules

M arca & M cG ow an, SADT, page 126.
Ignoring semantic and syntactic errors as well as style anomalies in this diagram, we would recast these
activation rules as:
A21*1 : C1 and I1 O3
A21*2 : C1 and I1 O2 and O3
A21*3 : ~C1 and I1 O2
A21*4 : C1 and I1 O1
job start
next job step
inspection time
status request
However, in light of IEEE 1320.1, some comments on the activation rules in this figure should be made.
Attached to the box of Figure 19-3 are one input, one control, and three outputs.
There are only four possible logical combinations of input and control presence for a box with only two
resource ICOMs:
1.
2.
3.
4.
I1 and C1
I1 and ~C1
~I1 and C1
~I1 and ~C1
First, IDEF0 semantics require at least one control on each transformation. Combinations 2 and 4 violate
basic IDEF0 semantics. Only combinations 1 and 3 could be valid IDEF0 preconditions.
Second, activation rules 1, 2, and 4 in the example all express the same precondition. Therefore, these
rules are ambiguous; we cannot tell whether activation rule 1, 2, or 4 will activate the transformation.
Thus, we find:
There is only one valid activation rule here:
137
A21*1 : C1 and I1 O1 or (O2 and O3) or O3

The only other possible activation rule would have the precondition:
A21*2 : C1 and ~I1 ???

In other words, this second activation rule would specify what this activity would produce if there were
no unfinished jobs.
If it is true that producing O2 all by itself requires the absence of C1, then at least one control is
missing from the diagram. If we assume at least one another control (e.g., C2) for the activity,
then and only then may we write:
A21*1 : C1 and I1 O1 or (O2 and O3) or O3

A21*2 : ~C1 and I1 O2
which assumes that C2 is required for all activations of A21. That is, exhaustive activation rule statements
would be:
A21*1 : ( C1 and C2) and I1 O1 or (O2 and O3) or O3

A21*2 : (~C1 and C2) and I1 O2
Because this example does not specify any transformations in the absence of I1, that term may be omitted
from the preconditions; therefore, these activation rules may simplify to:
A21*1 : C1 O1 or (O2 and O3) or O3

A21*2 : ~C1 O2
which implicitly states that C2 and I1 are both required for all activations.
138
LIST OF ABBREVIATIONS AND ACRONYMS

NDC
Node-Device-Connector
OOASIS
Object-Oriented Approach to Software-Intensive

Systems
OMG
Object Management Group
OTS
Off-The-Shelf
PCE
Prioritizable Concurrent Element
SE
Systems Engineering
SW
Software
UML
Unified Modeling Language
139
List of Abbreviations and Acronyms
140

Armstrong Bocast Integration of Systems Engineering and Software Development 2003-Libre

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Armstrong Bocast Integration of Systems Engineering and Software Development 2003-Libre

Загружено:

Авторское право:

Доступные форматы

The Integration of Systems

Engineering and Software

The Integration of Systems

INTEGRATING SYSTEMS ENGINEERING AND SOFTWARE DEVELOPMENT3

Systems Engineering ....................................................................................................3

Software Development .................................................................................................6

Mapping Systems Engineering to Software Development.........................................10

Top-Level Definition/Define System Requirements ................................................... 14

APPLYING IDEF METHODS TO DEVELOP OOASIS INFORMATION

RELATING IDEF METHODS TO OOASIS..................................................................23

A.1.1 Overview of Method.................................................................................................... 24

A.2 Results of this Method ..............................................................................................111

SANTA NARIDA BACKSTORY ...................................................................................117

OOASIS NODE-DEVICE-CONNECTOR DIAGRAM ...............................................123

NATIONAL DATA BUOY CENTER ............................................................................125

APPLYING SADT ACTIVATION RULES TO IDEF0 ACTIVITY ANALYSIS.....129

Activation Rules .......................................................................................................129

Conditional Expressions ...........................................................................................129

Writing Rule Sets......................................................................................................132

Incorporating Activation Rules in a Diagram...........................................................135

Revisiting Marca and McGowans Example............................................................136

LIST OF ABBREVIATIONS AND ACRONYMS .................................................................139

FIGURES AND DIAGRAMS

Figures and Diagrams

Diagram 21. RTO/A1 Measure Ocean Observables .................................................................................. 48

Figures and Diagrams

Figures and Diagrams

Figure 14. First NDC Transformation on ONA/A1 .................................................................................... 99

This page intentionally left blank.

This page intentionally left blank.

2.1 Introduction. Defines the overall interface to be addressed

This report uses the following typographic conventions:

2. INTEGRATING SYSTEMS ENGINEERING AND

Figure 1. OOASIS Model of System and Software Interaction

2. Integrating Systems Engineering and Software Development

2. Integrating Systems Engineering and Software Development

2. Integrating Systems Engineering and Software Development

Realize use cases

2. Integrating Systems Engineering and Software Development

2.3.1.1 Define System Requirements

2. Integrating Systems Engineering and Software Development

Temporal correctness (response time, device characteristics)

2. Integrating Systems Engineering and Software Development

OOASIS INPUTS AND RELATED ACTIVITIES EXTERNAL ACTIVITIES

2. Integrating Systems Engineering and Software Development

OTS Software Interfaces

MAPPING SYSTEMS ENGINEERING TO SOFTWARE DEVELOPMENT

Define System Req

Obtain Summary Use System

2. Integrating Systems Engineering and Software Development

Prioritize System Use

Use Realize System Use Cases

Define actor IF classes

Find persistent entity persistent

Model the Use Cases as Interaction

Combine classes into Class Diagram

2. Integrating Systems Engineering and Software Development

Obtain NDC & OTS

Add Manager Classes

Expand Main Scenario

Sys Use Cases, Elaborate

2. Integrating Systems Engineering and Software Development

Systems Design HW interfaces

Sys SW Depl Elaborate System