This document discusses integrating systems engineering and software development. It maps how systems engineering activities provide requirements to software development activities and vice versa. The document provides guidance on interactions between the two disciplines at different levels of abstraction. While generally applicable, it uses the object-oriented OOASIS method to illustrate specific examples and discussions. The goal is to conduct systems engineering and software development in parallel rather than sequentially to avoid problems.

1. 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

3. 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.

7. CONTENTS
ACKNOWLEDGMENTS..........................................................................................................IX
EXECUTIVE SUMMARY ........................................................................................................XI
1. INTRODUCTION................................................................................................................1
1.1 Scope.............................................................................................................................1
1.2 Audience.......................................................................................................................1
1.3 Organization .................................................................................................................1
1.4 Typographic Conventions.............................................................................................2
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 Top-Level Definition/Define System Requirements ................................................... 14
2.5.2 Lower-Level Interactions/Software Development....................................................... 16
2.5.3 General Interface Issues............................................................................................... 18
2.5.4 SE and UML................................................................................................................ 19
2.6 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

8. 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 McGowan’s Example............................................................136
LIST OF ABBREVIATIONS AND ACRONYMS .................................................................139
iv

9. 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

10. 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

11. Figures and Diagrams
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

12. Figures and Diagrams
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

13. 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

14. Acknowledgments
This page intentionally left blank.
x

15. 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.

16. Executive Summary
This page intentionally left blank.
xii

17. 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
Consortium’s 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

18. 1. Introduction
− 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
1.4 TYPOGRAPHIC CONVENTIONS
This report uses the following typographic conventions:
Serif font.....................General presentation of information
Bold Italic...................Bulleted lists and run-in headings.
2

19. 2. INTEGRATING SYSTEMS ENGINEERING AND
SOFTWARE DEVELOPMENT
2.1 INTRODUCTION
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 over-
the-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
Physical
Architecture
Software
Architecture
time
System
Requirements
Analysis
System Design
Physical
Architecture
Software
Architecture
time
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 aren’t
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,
3

20. 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
1
CMMI
and SE-CMM
are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
4

21. 2. Integrating Systems Engineering and Software Development
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:
• 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.
2.2.3 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.
5

22. 2. Integrating Systems Engineering and Software Development
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 Consortium’s 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.
Class Statecharts
and etc. from
previous tasks
Sys Use Cases
Elaborate architecture
Elaborate sys use cases
Sys SW Arch
Implement software
Thread Models
Define
Sys SW
Arch
Design
Node
SW
Define
Sys Req’s
Realize use cases
Define sys SW allocation
Define statecharts
Define concurrency
Elaborated Sys
Use Cases
Capture sys behavioral
req’s
Sys SW Arch
Class Statecharts
and etc. from
previous tasks
Sys Use Cases
Elaborate architecture
Elaborate sys use cases
Sys SW Arch
Implement software
Thread Models
Define
Sys SW
Arch
Design
Node
SW
Define
Sys Req’s
Realize use cases
Define sys SW allocation
Define statecharts
Define concurrency
Elaborated Sys
Use Cases
Capture sys behavioral
req’s
Sys SW Arch
Figure 2. OOASIS Software Development Flow
6

23. 2. Integrating Systems Engineering and Software Development
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

24. 2. Integrating Systems Engineering and Software Development
(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)
8

25. 2. Integrating Systems Engineering and Software Development
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 as-
implemented 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
9

26. 2. Integrating Systems Engineering and Software Development
• OTS Software Interfaces
2.4 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 OOASIS SW
Task Output Input Task/Subtasks Output
Define System Req
Stakeholders,
Summary Use
Case, Context
Diagram
Obtain Summary Use
Case
Needs Analysis Statement of
Needs, Concept
of Operations
Stakeholders Identify Actors
Functional
Analysis
Top level
functions
Goals (top level
verb noun
objectives)
Identify System Use
Cases
As-is process
o-be processT
“Text” details
Detail System Use
Cases
Functional
Analysis,
Requirements
Analysis and
Allocation
Decomposed
functions and
performance
requirements
Alternate
success paths
Functional
Failure Analysis
Functional
failure modes
Potential
problems
Alternatives
System Use
Cases
10

27. 2. Integrating Systems Engineering and Software Development
Requirements
analysis
Volatility
estimates
Potential
requirements
changes
Program
Alternatives
Capability
sequence
Release
sequences
Variations
Identify Key
Requirements
Requirements
Priorities
System Priorities Prioritize System Use
Cases
Define SW Arch
System Use
Cases
Realize System Use Cases System SW
Arch
Define actor IF classes actor IF
classes
Find persistent entity
classes
persistent
entity classes
Functional
analysis and
allocation
Allocated
functional
description
Model the Use Cases as
Interaction Diagrams
Interaction
Diagrams
Combine classes into
single class diagram
Combine redundant
classes
Generalize classes
Add composition
Add associations
Evaluate against
variations
Class Diagram
Allocation and
System
Architecting
Systems
Architecture
NDC, OTS SW
Components
and Interfaces
Define System SW
Deployment
System SW
Deployment
11

28. 2. Integrating Systems Engineering and Software Development
Obtain NDC & OTS
SW info
Deploy Actor IF
Classes
Deploy Persistent
Entity Classes
Deploy OTS SW
components
Add Manager Classes
Elaborate Actor IF
classes
System Design,
Requirements
analysis, and
allocation
Bandwidth and
processing
requirements
Bandwidth and
processing
requirements
Redeploy for
Performance Concerns
Performance
adjusted SW
Arch
Sys Use Cases,
NDC, Sys SW
Depl Models,
Sys SW Arch
Elaborate System Use
Cases
Elaborated
System Use
Cases
Functional
Analysis and
allocation
Detailed
functions,
Functions per
node
Expand Main Scenario
Functional
Analysis,
Failure analysis
Alternate paths,
failure modes
Expand Alternate
courses
Requirements
analysis, system
design
alternatives
Potential
changes and
alternative
technologies
Expand variations
12

29. 2. Integrating Systems Engineering and Software Development
Systems Design
and Integration
HW interfaces Sys SW Depl
Models, Sys SW
Arch, Elab Sys
Use Cases
Elaborate System SW
Architecture
Elaborated
System SW
Architecture
Realize Elaborated
System Use Cases
New classes
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
Depl Models,
Sys SW Arch,
Elab Sys Use
Cases
Define Threads Threads
Functional
analysis
threads Define initial thread set
Functional
analysis,
timelines,
Allocation, Cost
trades
Timing info,
system
alternatives,
cost of
alternatives
Performance analysis
Functional
Analysis
State diagrams Define state charts Class state
charts
Systems Design Hardware
interfaces
HW Interfaces Design Node SW
13

30. 2. Integrating Systems Engineering and Software Development
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.
System
Ext I/F
Concept of Operations
•Who
•What
•Where
•Why
•When
•How much
•How many
•How well
•With what others
•…..
Business Process
Needs
Goals
Context Diagram
Stake-
Holders
Summary Use Case
Public User
Scientist
Maintenance
View Report
Download Data
Analyze Data
Admin Environment
Collect Data
<<depends>>
<<depends>>
<<depends>>
Environment
Readings
Samples
Analysis
Maintenance
Requests
System Usage Reports
System
Ext I/F
Concept of Operations
•Who
•What
•Where
•Why
•When
•How much
•How many
•How well
•With what others
•…..
Business Process
Needs
Goals
Context Diagram
Stake-
Holders
Summary Use Case
Public User
Scientist
Maintenance
View Report
Download Data
Analyze Data
Admin Environment
Collect Data
<<depends>>
<<depends>>
<<depends>>
Environment
Readings
Samples
Analysis
Maintenance
Requests
System Usage Reports
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

31. 2. Integrating Systems Engineering and Software Development
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 aren’t 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

32. 2. Integrating Systems Engineering and Software Development
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 customer’s 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

33. 2. Integrating Systems Engineering and Software Development
System Use Case
•Details
•Alternatives
•Variations
•Priorities
•Elaborations
Concept of Operations
•How will
alternative
solutions be
operated and
maintained
•New constraints
and requirements
Functional An
System
Arch
Include Failures
Req’s
Trade Studies
:
System Use Case
•Details
•Alternatives
•Variations
•Priorities
•Elaborations
Concept of Operations
•How will
alternative
solutions be
operated and
maintained
•New constraints
and requirements
Functional An
System
Arch
Include Failures
Req’s
Trade Studies
:
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

34. 2. Integrating Systems Engineering and Software Development
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

35. 2. Integrating Systems Engineering and Software Development
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

36. 2. Integrating Systems Engineering and Software Development
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 software’s
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.
• 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.
20

37. 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
• OTS Software Components
• Hardware Interfaces
• OTS Software 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

38. 3. Applying IDEF Methods to Develop OOASIS Information Requirements
This page intentionally left blank.
22

39. 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
• OTS Software Components
• Hardware Interfaces
• OTS Software 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

40. 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

41. A. Relating IDEF Methods to OOASIS Information Needs
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

42. A. Relating IDEF Methods to OOASIS Information Needs
“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 land-
based 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 System’s 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

43. A. Relating IDEF Methods to OOASIS Information Needs
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 stakeholder’s 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 stakeholder’s interest.
Represent the observable manifestation of the stakeholder’s 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 stakeholder’s 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

44. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
<work>
Model: Stakeholder: Weather M edia (SWM )
Page:
A-0
AKB3 3
x12/20/2001
Present WeatherA0
I2
GOO S Imagery
C2 W e at he r S how F ormat
C3 Broadc ast S c he dule
O1
W eather S ho w
M 1 Nat ional W e at he r S e rv ic e
M 2 T e le v ision S t udio
M 3 W e a t he r Pre se nt e r
M 4 S ant a Narida Buoy S y st e m
W rit e S c ript
3
M ix B ac kdrop
2
Re ad S c ript
4
Oral Pre s e nt at ion
S c ript
F orec ast
W e at he r
1
O c ean Image ry
F ore c ast T e xt
F ore c ast Produc t s
I1
O cean O b s ervatio ns
Produc t Re que st s
C1 Ima ge S t a ndards
V isual Pre se nt at ion
Diagram 1. SWM/A0 (Present Weather)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
<work>
Model: Stakeholder: Tsunami Warning System (STW)
Page:
A-0
2
x12/20/2001
Produce Tsunami WarningsA0
I1
Oc e anographic Dat a
C 2 D ata S haring A g reem ent
O 1
T sunami W arning
M 1 T sunami W a rning S y st e mM 2 S ant a Narida Buo y S y st e m
Pro vid e
T s un am i
Pred ictio n
D a ta
1
Fus e
T s unami
S o urces
3
Pred ict
T s unam i
4
F use d T sunami Dat a
C3 T sunami Pre dic t ion M ode ls
S N O O R Tsunami Dat a
R eceive
D ata
2
Re c e iv e d T sunami Data
M ail Clie ntM ail S e rv e r
C 1 Int e rnet M ail Prot oc ols
28

45. A. Relating IDEF Methods to OOASIS Information Needs
Diagram 2. STW/A0 (Produce Tsunami Warnings)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
Model: Stakeholder: Institute Scientist (SIS)
Page:
A-0
AKB2 2
x12/20/2001
Research Ocean Weather PhenomenaA0
I1
O c e an O bse rv able s
C3 Re se arc h A ge nda
O1
Re se arc h Produc t s
M 1 S ant a Narida Buoy S y st e m
M 3 Inst it ut e S c ient ist
C ap ture
O ce an D ata
1
S tag e
O cean Data
2
S tud y
O cean
W eathe r
3
D atas et R eques ts
R eq ues ted D atas ets
Oc e an Dat a
C 2 Dat ase t S pec ific at ions
M 2 Inst it ut e for M id- Pac ific O c e an M e t e orology
W e b Browse r
W e b S e rv e r
C1 Observ at ion S pec ific at ions
T asking
Diagram 3. SIS/A0 (Research Ocean Weather Phenomena)
29

46. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
Model: Stakeholder: Route Planner (SRP)
Page:
A-0
AKB3 2
x12/20/2001
Plan Ship ItineraryA0
C3 C ust ome r Re quireme nt s
O1
Rout e Plan
M 2 Rout e Planne r
M 3 S ant a Narida Buoy S y st e m
Fo recas t
R o ute- S p ecific
W eather
2
Es tim ate
V es s el
S ched ules
3
D eterm ine
Feas ib le
R o utes
1
S elect
O p tim um
Itinerary
4
C2 Resourc e M inimizat ion S t rat e gy
Websit e
I1
Rout ing A lt e rnat iv e s
Fe asible Rout e s
W eather- Pro filed R o utes
R o ute- V es s el- S ched ule Es tim ates
C1 V e sse l Cha ra c te rist ic s
M 1 W e b Brow se r
I2
O c e an W e at he r Dat a
De st inat ions
S che dules
Diagram 4. SRP/A0 (Plan Ship Itinerary)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
Model: Stakeholder: Weather Forecaster (SWF)
Page:
A-0
AKB2 2
x12/20/2001
Forecast WeatherA0
I1
Oc e an Obse rv able s
C2 O ut look S c he dule
O1
F ore c ast Produc t s
M 1 W e at he r F ore c ast e rs
M2 Nat ional W e at he r S e rv ic e
M 3 S ant a Narida Buoy S y st e m
C o lle ct D ata
1
Pus h D ata
2
Mo d el
W eather
3
Pub lis h
Fo recas ts
4
C 1 W e at her M ode l Re quire me nt s
Hist oric al Dat a
Proje c t e d Dat a
M e t e orology Dat aset s
30

47. A. Relating IDEF Methods to OOASIS Information Needs
Diagram 5. SWF/A0 (Forecast Weather)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
Model: Stakeholder: National Weather Service (SNW)
Page:
A-0
AKB2 2
x12/20/2001
Increase Puerta Oveida Market ShareA0
I2
Unde c ide d Rout ing Que st ions
C 3 M inist e rial Que st ions
O1
Ministerial Reports
O 2
F av orable Rout ing Dec isions
M 2 NW S Gene ral M anage r
M 3 S ant a Narida Buoy S y st e mM 1 S hipper
Pro vid e
W eather
In fo rm atio n
1
S elect
S hip p ing
Itinerary
2
Pro v id e
R ep o rts
3
I1
W e at he r Obse rvable s
W e at he r C onst raint s
W e bsit e A c t iv it y Re port s
C2 F ore c ast ing S c he dule
Buoy A c t iv it y Re port s
S y st e m A c t iv it y Re port s
Buoys W ebsit e S y st e m A dminist rat or
1 Actvity reports include
maintenance activity.
C1 S hipme nt Re quire ment s
Diagram 6. SNW/A0 (Increase Puerta Oveida Market Share)
31

48. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
Model: Stakeholder: Satellite Provider (SSP)
Page:
A-0
2
x12/20/2001
Deliver DataA0
I1
F ie ld Obse rv at ions
C1 Communic at ions Prot oc ols
C 2 S e rvic e A gre e me nt
O 1
D e liv e re d Dat a
M 1 S ant a Narida Buoy S y st e m
M 2 A rgos M 3 W orld W e at he r W at c h
S end
C o m m and s
1
Mo ve
C o m m and s
2
S end D ata
3
R eceive
D ata
4
Mo ve D ata
5
A rch ive
D ata
6
O 2
A rc hiv e d Dat a
W e b Brow se r
T ransmit t ed Dat a
S ent D ata
T ransmit t e d Commands
S e nt Commands
W e b Brow se r
S at e llit e Prot oc ols
W e b Prot oc ols
W eb Prot oc ols
Buoy T ransc e iv er
Diagram 7. SSP/A0 (Deliver Data)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader DateAKBocast
OOASIS SE
P.
<work>
Model: Stakeholder: NOAA M aintenance (SNM )
Page:
A-0
AKB2 2
x12/20/2001
Maintain BuoysA0
I1
Broke n Buoy
C1 M aint e nanc e T re at y
O 1
W orking Buoy
M 1 S ant a Narida Buoy S y st e m M 2 NOA A M 3 Pac ific Obse rv e r
R eq u es t
Maintenance
A ctio n
1
D irect
Maintenance
A ctio n
2
Fix B uo y
3
M aint ena nc e O rde r
M aint e nanc e Re que st
C2 Buoy T e c hnic al Dat a
M aint e nanc e Re port
M aint e nanc e Re c ord
M a int e nanc e Hist ory
M aint e nanc e Not ific at ion
Diagram 8. SNM/A0 (Maintain Buoys)
32

49. A. Relating IDEF Methods to OOASIS Information Needs
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
Comments
Stakeholders: forecaster
institute
shipper
media
communications
maintenance
customer
33

50. A. Relating IDEF Methods to OOASIS Information Needs
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
User ProviderGrouping
Concept: Outputs Controls Inputs Mechanisms
Stakeholders: forecaster
institute
shipper
media
tsunami
customer 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
User ProviderGrouping
Concept: Outputs Controls Inputs Mechanisms
Stakeholders: forecaster
institute
shipper
customer
tsunami
communications
environment communications
maintenance
trainer
34

51. A. Relating IDEF Methods to OOASIS Information Needs
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)
User ProviderGrouping
Concept: Outputs Controls Inputs Mechanisms
Stakeholders: forecaster
institute
shipper
media
tsunami
customer
tsunami
communications
environment communications
maintenance
trainer
Stakeholders by Requirements Models: Model 2 (selected stakeholders are in bold)
User ProviderGrouping
Concept: Outputs Controls Inputs Mechanisms
Stakeholders: forecaster
institute
shipper
media
tsunami
customer
tsunami
communications
environment communications
maintenance
trainer
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

52. A. Relating IDEF Methods to OOASIS Information Needs
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

53. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/13/2001
Stakeholder Context of A0 functionA-1
C on text of
...
0
p rovid e
m echan ism s
2
p ro vid e
in p u ts
3
p rovid e
con trols
4
u se ou tp u t
5
1
A 0 fu n ction
re sult s
con trol req u est m ech an ism req u est in p u t req u est
Prod u ct R eq u ests
Televisio Santa Narida
stakeh old er istakeh old er mstakeh old er c Santa Narida Buoy System
im ag e stan d ard s
m ech an ism b u n d le
Ocean Ob servations
Forecast Text
W eath erS h ow
p erform an ce feed b ack
resu lts feed b ack
NONE
Ocean I m ag ery
Forecast Prod u cts
b road cast sch ed u le
GOOS Im ag ery
Diagram 9. RTP/A-1=AKB5.1 for Weather Media Stakeholder
The following diagram adds the environment stakeholder to generate input.
37

54. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/14/2001
Stakeholder Context of A0 functionA-1
C on text of
...
0
p rovid e
m echan ism s
2
p ro vid e
in p u ts
3
p rovid e
con trols
4
u se ou tp u t
5
1
A 0 fu n ction
re sult s
con trol req u est m ech an ism req u est in p u t req u est
Prod u ct R eq u ests
Televisio Santa Narida
E n viron m en tstakeh old er mstakeh old er c Santa Narida Buoy System
im ag e stan d ard s
m ech an ism b u n d le
Ocean Ob servations
Forecast Text
W eath erS h ow
p erform an ce feed b ack
resu lts feed b ack
NONE
Ocean I m ag ery
Forecast Prod u cts
b road cast sch ed u le
GOOS Im ag ery
Ocean Ob servab les
Plan etary Ob servab les
Ocean
Plan et
Diagram 10. RTP/A-1=AKB5.2, Adding Environment Stakeholder
The need for our first bit of analysis—as 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

55. A. Relating IDEF Methods to OOASIS Information Needs
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 stakeholder’s 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:
I 1
I 2
O1
O3
M easu re O cean
W eath er
C h aracteristics
1 F
Ph otog rap h
th e E arth
2 F
C 1 in p u t req u e st
C 2 p erform an ce feed b ack
M 1 G O O S S atellitesM 2 B u oy S ystem
O cean O b servation s
S atellite I m ag ery
O cean O b servab les
Plan etary O b servab les
M easu red O cea n O b servab les
O2
Ph otog rap h ed O b servab les
O4
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

56. A. Relating IDEF Methods to OOASIS Information Needs
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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/14/2001
Stakeholder Context of A0 functionA-1
C on text of
...
0
p rovid e
m echan ism s
2
p ro vid e
in p u ts
3
p rovid e
con trols
4
u se ou tp u t
5
1
A 0 fu n ction
re sult s
con trol req u est m ech an ism req u est in p u t req u est
Prod u ct R eq u ests
Televisio S an ta N arid a
E n viron m en t
stakeh old er mstakeh old er c S an ta N arid a B uoy S yste m
im ag e stan d ard s
m ech an ism b u n d le
Forecast Text
W eath erS h ow
p erform an ce feed b ack
resu lts feed b ack
NON E
Ocean I m ag ery
Forecast Prod u cts
b road cast sch ed u le
S atellite Im ag eryOcean Ob servab les
Plan etary Ob servab les
G OOS S ystem
Provid e
Ob servab les
6
M easu red Ob servab les
x
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:
I 1
O c e a n O b s e rv a b le s O 1
M e a s u re d O b s e rv a b le s
M e a su r e O ce a n
W e a th e r
C h a r a cte r istics
1
O c e a n O b s e rv a t io n s
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

57. A. Relating IDEF Methods to OOASIS Information Needs
Now we will look at the next stakeholder, the Tsunami Warning System:
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/14/2001
Stakeholder Context of A0 functionA-1
C on text of
...
0
p rovid e
m ech an ism s
2
p rovid e
in p u ts
3
p rovid e
con trols
4
u se ou tp u t
5
1
A 0 fu n ction
result s
con trol req u est
m ech an ism req u est
in p u t req u est
Prod u ct R eq u ests
Televisio S an ta N arid a
E n viron m en t
stakeh old er mstakeh old er c S an ta N arid a B u oy S ystem
I m ag e S tan d ard s
m ech an ism b u n d le Forecast Text
W eath er S h ow
p erform an ce feed b ack
resu lts feed b ack
NON E
Ocean I m ag ery
Forecast Prod u cts
B road cast S ch ed u le
S atellite I m ag ery
Ocean Ob servab les
Plan etary Ob servab les
G OO S S ystem
Provid e
Ob servab les
6
M easu red Ob servab les
x
x
Tsu n am i W arn in g
Tsu n am i D ata
Tsu n am i W arn in g C en ter
In tern al M ail Protocols
Tsu n am i D ata A g reem en t
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

58. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/14/2001
Stakeholder Context of A0 functionA-1
C on text of
...
0
p rovid e
in p u ts
3
p rovid e
con trols
4
u se ou tp u t
5
1
A 0 fu n ction
x
con trol req u est in p u t req u est
Prod u ct R eq u ests
Televisio S an ta N arid a
E n viron m en t
N ation al W eath er S ervice S an ta N arid a B u oy S ystem
Im ag e S tan d ard s
Forecast Text
W eath er S h ow
p erform an ce feed b ack
resu lts feed b ack
NON E
Ocean Im ag ery
Forecast Prod u cts
B road cast S ch ed u le
S atellite I m ag ery
Ocean Ob servab les
Plan etary Ob servab les
G OO S S ystem
Provid e
Observab le s
6
M easu red Ob servab les
x
x
Tsu n am i W arn in g
Filtered D atasets
Tsu n am i W arn in g C en ter
In tern al M ail Protocols
D ata Sharing Agreem ents
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

59. A. Relating IDEF Methods to OOASIS Information Needs
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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/14/2001
Stakeholder Context of A0 functionA-1
C on text of
...
0
p rovid e
in p u ts
3
p rovid e
con trols
4
use ou tp u t
5
1
A 0 fu n ction
x
con trol req u est in p u t req u est
Prod u ct R eq u ests
Televisio S an ta N arid a
E n viron m en t
N ation al W eath er S ervice S an ta N arid a B u oy S ystem
Im ag e S tan d ard s
Forecast Text
W eath er S h ow
p erform an ce feed b ack
resu lts feed b ack
NON E
Ocean Im ag ery
Forecast Prod u cts
Schedules
S atellite Im ag e ry
Ocean Ob servab les
Plan etary Ob servab les
G OO S S ystem
Provid e
Ob servab le s
6
M easu red Ob servab les
x
x
Tsu n am i W arn in g
Filtered D atasets
Tsu n am i W arn in g C en ter
Internet Protocols
D ata Sharing Agreem ents
I n stitu te S cien tist
Research Prod u cts x
Un filtered D atasets
S p ecification s
Ob servation S p ecification s
D ataset S p ecification sD ataset Prod u cts
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

60. A. Relating IDEF Methods to OOASIS Information Needs
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 forecaster’s 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 model’s
Outlook Schedule control confirms our generalization of Broadcast Schedule to the more abstract
Schedules.
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/17/2001
Stakeholder Context of A0 functionA-1
C on text of
...
0
p rovid e
in p u ts
3
p rovid e
con trols
4
use ou tp u t
5
1
A 0 fu n ction
x
con trol req u est in p u t req u est
Prod u ct R eq u ests
Televisio S an ta N arid aE n viron m en t N ation al W eath er S ervice
S an ta N arid a B u oy S ystem
I m ag e S tan d ard s
Forecast Text
W eath er S h ow
p erform an ce feed b ack
resu lts feed b ack
NON E
Ocean Im ag ery
Forecast Prod u cts
Schedules
S atellite Im ag e ry
Ocean Ob servab les
Plan etary Ob servab les
G OO S S ystem
Provid e
Ob servab le s
6
M easu red Ob servab les
x
x
Tsu n am i W arn in g
Filtered D atasets
Tsu n am i W arn in g C en ter
Internet Protocols
D ata Sharing Agreem ents
I n stitu te S cien tist
Research Prod u cts x
Un filtered D atasets
S p ecification s
Ob servation S p ecification s
D ataset S p ecification sD ataset Prod u cts
W eath er M od el D ata R eq u irem en ts
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

61. A. Relating IDEF Methods to OOASIS Information Needs
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 model’s A0 page, where we previously modeled
the production of ocean observations.
I 1
O cean O b servab les
C 2 W eath er M od el D ata R eq u irem en ts
O 1
M easu red O b servab les
O 2
F orecast Prod u cts
M e a sure O ce a n
W e a the r
C ha ra cte ristics
1
O cean O b servation s
Fo re ca st
W e a the r
2
M 1 W eath er F orecasters
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 diagram’s 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

62. A. Relating IDEF Methods to OOASIS Information Needs
I 1
O cean O b servab les
C 2 B u oy C om m an d s
O 1
M easu red O b servab les
O 2
O cean O bervation s
Se nd
C o mm a nds
7 F
Co lle ct D a ta
2 F
Se nd D a ta
3 F
Re ce ive Da ta
5 F
S en t C om m an ds
C ollected D ata
S en t D ata
Tran sm itted D ata
C 1 C om m u n ication s Protocols
O 3
C3 Tra ns m it te d Co m m a nd s
O 4
I 2
1
2
3
4
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

63. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Operations (RTO)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/17/2001
Stakeholder Context of ...A-1
C on text of
...
0
p rovid e
m ech an ism s
2
p rovid e
in p u ts
3
p rovid e
con trols
4
u se ou tp u t
5
1
A 0 fu n ction
x
con trol req u est
M ain ten an ce R eq u est
in p u t req u est
Prod u ct R eq u ests
R ou te Plan n er
Enviro nm e ntN OA AN W S Ge ne ra l M a na ge r Sa nta N a rida Buo y Sys te m
Minis te ria l Re que s ts
Ocean Ob servab les
R ou tin g Prod u cts
R ou te P lan
System Status
R o u tin g D ecision s
NONE
0
x
M easu red Ob servab les
rep a ired b u oy
b roken b u oy
Se rvice A gre e m e nts
M ain ten an ce N otification
m ech an ism req u est
B u oy Tech n ical D ata
M in isterial R ep orts
x
M in isterial Qu estion s
R ou te Plan n in g R eq u irem en ts
A rg os
C om m u n ication s S atellites
C om m u n ication s Protocols
Diagram 20. RTO/A-1=AKB5, Operations Stakeholders
47

64. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Operations (RTO)
Page:
OOASIS SE
AKBocast
A0
AKB6 5
x12/17/2001
Measure Ocean ObservablesA1
I 1
Ocean Ob servab les
C 2 B u oy C om m an d s
O1
M easu red Ob servab les
O2
Ocean Ob ervation s
Se nd
Co m m a nd s
1
Mo ve
Com m a nds
2
Co lle c t Da ta
3
Se nd Da ta
4
Mo ve Da ta
5
R e ce ive Da ta
6
M 1 C om m u n ication s S atellites
Se nt Co m m a nds
Tra ns m itte d Co m m a nds
C ollected D ata
S en t D ata
Tran sm itted D ata
C 1 C om m u n ication s Protocols
Diagram 21. RTO/A1 Measure Ocean Observables
We also prepare a third model for the trainer stakeholder:
48

65. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Training (RTT)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/17/2001
Stakeholder Context of A0 functionA-1
C on text of
...
0
p rovid e
m echan ism s
2
p ro vid e
in p u ts
3
p rovid e
con trols
4
u se ou tp u t
5
1
A 0 fu n ction
re sult s
con trol req u est m ech an ism req u est in p u t req u est
ou tp u t req u est
stakeh old er o
sta keh old er iTrain erstakeh old er c S an ta N arid a B uoy S yste m
con trol b u n d le
m ech an ism b u n d le
in p u t b u n d le
ou tp u t b u n d le
resu lts
Perfo rm ance F eedback
resu lts feed b ack
NONE
0
Train ed S taff
Un train ed Peop le
x
Train in g R eq u irem en ts
Diagram 22. RTT/A-1, Training Stakeholder
You should have observed in these steps a typical approach to integrating stakeholders into a
requirements model’s 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

66. A. Relating IDEF Methods to OOASIS Information Needs
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 model’s 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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Requirements TO-B E Products (RTP)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/20/2001
Stakeholder Context of Meteorological Product GenerationA-1
Generat e
Met eorologic a l
Produc t s
0
Prov ide
I magery
3
Cont rol
Produc t ion
4
Use
Met eorology
Produc t s
5
1
x
c ont rol request input request
Produc t Request s
T elev isio Sant a NaridaEnv ironment Nat ional W eat her Serv ic e
Sant a Narida Buoy Sy st em
I mage St andards
Forec as t T ext
W eat her Show
performanc e f eedbac k
result s f eedbac k
N ONE
Oc ean Imagery
Forec ast Produc t s
Sc hedules
Sat ellit e I magery
Oc ean Ob serv ables
Planet ary Observ ables
GOOS Sy st em
Prov ide
Observ ables
2
Measured Observ ables
x
x
T sunami W arning
Filt ered Dat aset s
T sunami W arning Cent er
I nt ernet Prot oc ols
Dat a Sharing Agreement s
Inst it ut e Sc ient ist
Researc h Produc t s
x
Unf ilt ered Dat aset s
Spec if ic at ions
Observ at ion Spec ific at ions
Dat aset Spec ific at ionsDat aset Produc t s
W eat her Model Dat a Requirement s
0
Argos Sy st em
Diagram 23. RTP/A-1 (Stakeholder Context of Meteorological Product Generation)
50

67. A. Relating IDEF Methods to OOASIS Information Needs
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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Requirements TO-B E Products (RTP)
Page:
OOASIS SE
AKBocast
Top
AKB1 2
x12/20/2001
Context of Meteorological Product GenerationA-0
Generat e
Met eorologic al
Produc t s
0
Purpose:
Viewpoint: Systems Engineer as Requirements Elicitor.
To specify minimal and sufficient behaviors
leading necessarily to a coherent set of related
outputs required by external stakeholders.
TOP
0
Measured
Meteo ro lo g ical Pro d u cts
Measured Observ ables
Oc ea n Observ ables
Ocean
S atellite Im ag ery
Sat ellit e Imagery
Met eorology Dat a Requirement s
Produc t Request s
Met eorologic al Produc t s
Nat ional W eat her Serv ic e
W eat her Forec ast ers
Sc hedules
Dat a Sharing Agreement s
Image St andards
Communic at ions Prot oc ols
Met eorology Dat a St andards
Argos Sy st em
Spec ific at ions
Specif ic at ions
Sant a Narida Buoy Sy st em
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

68. A. Relating IDEF Methods to OOASIS Information Needs
• 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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
A-0
AKB15 3
x12/20/2001
Generate Meteorological ProductsA0
I 1
Ocean Ob servab les
I 2
S atellite I m ag ery
C 5 Prod u ct R eq u ests
C 6 M eteorolog y D ata R eq u irem en ts
O1
M easu red Ob servab les
O2
M eteorolog ical Prod u cts
M easure O cean
W eathe r
C haracte ristics
1
O cean O b servation s
Forecast
W eather
4
M 3 W eath er Forecasters
C 4 S ch ed u les
C 3 D ata S h arin g A g reem en ts
C 2 Im ag e S tan d ard s
C 1 C om m u n ication s Protocols
P ro vide
Da ta s e ts
2
Fil te r
Da ta s e ts
3
D ataset Prod u cts
Un filtered D atasets
Filtered D atasets
Forecast Prod u cts
Forecast Text
Ocean Im ag ery
C 7 M eteorolog y D ata S tan d ard s
1 It seems perhaps that schedules and
product requests might be bundled;
meteorology data requirements and data
sharing agreements might be bundled; and
meteorology data standards and image
standards might be bundled.
M 2 A rg os S ystem
O3
S p ecification s
52

69. A. Relating IDEF Methods to OOASIS Information Needs
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:
4
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

70. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Requirements TO-B E Products (RTP)
Page:
OOASIS SE
AKBocast
A0A0A0A0
AKB16 4
x12/20/2001
Measure Ocean Weather CharacteristicsA1
I1
Oc e an Ob se rv able s
C1 S c hedule s C2 M et e orology Dat a Re quire me nt s
C3 Produc t Re que st s
C4 Dat a S ha ring A gre e me nt s
C5 Communic at ions Prot oc ols
C6 M e t e orology Dat a S t andards
O 1
M e asured Observ able s
O 2
Oc e an O bserv at ions
Cont rol Da t a
Colle c t ion
1
M e asure
O bse rv able s
2
T ran smit
Colle c t ed
Dat a
3
Dat a Colle c t ion Commands
Colle c t e d Data
M 1 A rgos S yst e m
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

71. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Re quireme nts TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
A1A1A1
AKB17 5
x12/20/2001
Control Data CollectionA11
C 1 S c he dules
C2 Produc t Re que st s
C3 Communic a t ions Prot oc ols
O 1
Da t a C olle c t ion C ommands
Ge ne rat e
Comma nds
1
S e nd
Comma nds
2
Re la y
Comma nds
3
Rec e iv e
C ommands
4
M 1 A rgos S y st e m
S e nt Comma nds
Re la y e d C omma nds
S a t e llit e Prot oc olsInt e rnet Prot oc ols
Unse nt C omma nds
Diagram 27. RTP/A11 (Control Data Collection)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
A1A1A1
AKB18 6
x01/10/2002
Measure ObservablesA12
I1
Oc e a n Obse rv a ble s
C1 Da t a Colle c t ion Comma ndsC2 M e t e orology Da t a Re quire me nt s
C3 M e t e orology Da t a S t a nda rds
O 1
M e a sured Observa ble s
O2
Colle c t ed Da t a
S e nse
O bse rva ble s
1
Ga t her
M e a sure me nt s
2
P a c ka ge
Da t a
3
M e a sure me nt s
M e asure me nt S e t
Diagram 28. RPT/A12 (Measure Observables)
55

72. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
A1A1A1
AKB19 7
x12/20/2001
Transmit Collected DataA13
I1
Collec t e d Da t a
C1 Communic a t ions Prot oc ols
C2 M e t e orology Da t a S t a nda rds
C3 Da t a S ha ring A gre e ment s
O 1
Oc e a n O bse rv a t ions
S e nd Dat a
1
Re la y Da t a
2
Re c eiv e Da t a
3
M 1 A rgos S y st em
S e nt Da t a
Re la y e d Dat a
Int e rnet Prot oc ols
S a t e llit e Prot oc ols
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

73. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
A0A0A0A0
AKB20 8
x12/20/2001
Provide DatasetsA2
I 1
Ocean O b servation s
C 1 M eteorolog y D ata R eq u irem en ts
C 2 Prod u ct R eq u ests
C 3 D ata S h arin g A g reem en ts
C 4 C om m u n ication s Protocols
C 5 M eteorolog y D ata S tan d ard s
O2
Un filtered D atasets
Sa ve
O bs e rva tio ns
1
Cre a te
Datas e ts
2
Re trie ve
Da ta s e ts
3
S aved D atasets
S aved Ob servation s
O1
S p ecification s
Ob servation S p ecification s
D ataset S p ecification s
Diagram 30. RTP/A2 (Provide Datasets)
57

74. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Products (RTP)
Page:
OOASIS SE
AKBocast
A0A0A0A0
AKB21 9
x12/20/2001
Forecast WeatherA4
I 1
Filtered D atasets
I2
S atellite I m ag ery
C 1 S ch ed u les
C 2 M eteorolog y D ata R eq u irem en ts
C 3 Prod u ct R eq u ests
C 4 D ata S h arin g A g reem en ts
C 5 C om m u n ication s Protocols
C 6 M eteorolog y D ata S tan d ard s
C 7 Im ag e S tan d ard s
O1
Ocean I m ag ery
O2
Forecast Text
M 1 W eath er Forecasters
W rite
W e a the r
Script
2
Run W e a th e r
Mo de ls
1
Ge ne ra te
Sym bolic
Im a ge s
3
Co m bin e
Im a ge s
4
Ocean Overlays
W eath er D ata
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, grayed-
down 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

75. A. Relating IDEF Methods to OOASIS Information Needs
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
model’s 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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/20/2001
Stakeholder Context of Meteorological Product GenerationA-1
C on text of
M eteorolog ical
Prod u ct
G en eration
0
P ro vide
im a ge ry
3
C on trol
Prod u ction
4
U s e
Me te o rolo gy
P ro ducts
5
1
x
con trol req u est
in p u t req u est
Prod u ct R eq u ests
Televisio S an ta N arid aE n viron m en t N ation al W eath er S ervice
S an ta N arid a B u oy S ystem
I m ag e S tan d ard s
Forecast Text
W eath er S h ow
p erform an ce feed b ack
resu lts feed b ack
NON E
Ocean Im ag ery
Forecast Prod u cts
S ch ed u les
S atellite Im ag ery
Ocean Ob servab les
Plan etary Ob servab les
GOOS S ystem
Provid e
Ob servab le s
2
M easu red Ob ser vab les
x
x
Tsu n am i W arn in g
Filtered D atasets
Tsu n am i W arn in g C en ter
C om m u n ication s Protocols
D ata S h arin g A g reem en ts
In stitu te S cien tist
Research Prod u cts
x
Un filtered D atasets
S p ecification s
Ob servation S p ecification s
D ataset S p ecification sD ataset Prod u cts
M eteorolog y D ata R eq u irem en ts
0
A rg os S ystem
G en erate
M eteorolog ical
Prod u cts
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

76. A. Relating IDEF Methods to OOASIS Information Needs
• 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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
Top
AKB1 2
x12/20/2001
Context of Meteorological Product GenerationA-0
G enerate
Meteo ro lo g ical
Pro d u cts
0
Purpose:
Viewpoint: Systems Engineer as Requirements Elicitor.
To specify minimal and sufficient behaviors
leading necessarily to a coherent set of related
outputs required by external stakeholders.
TOP
0
Measured
Meteo ro lo g y Pro d u cts
Measured Observ ablesOc ea n Observ ables
Ocean
S atellite Im ag ery
Satellit e Im ag er y
Met eorology Dat a Requirement s
Produc t Request s
Met eo ro lo g y Pro d u ct s
Nat ional W e at he r S e rvic e
W e a th e r Fo re ca s te r
Schedules
I mage St andards
Communic at ions Prot oc ols
M e t e orology D at a S t andards
A rgos S y st e m
S ant a Narida Buoy S yst e m
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:
• 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.
60

77. A. Relating IDEF Methods to OOASIS Information Needs
• 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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A-0
AKB15 3
x12/21/2001
Generate Meteorological ProductsA0
I1
O c e an Obse rv able s
I2
S at e llit e Image ry
C 4 Produc t Re que st s
C5 M e t e orology Dat a Re quire me nt s
O1
M ea sure d O bse rv a ble s
O 2
M et eorology Produc t s
M e a sure Oc e a n
O bse rv able s
1
Oc e an O bse rv at ions
M 3 W e at he r F orec ast e r
C3 S c he dule s
C2 Image S t andards
C1 Communic at ions Prot oc ols
C 6 M e t e orology Dat a S t andards
M 2 A rgos S y st e m M 1 S ant a Narida Buoy S y st e m
Bu oy Brow se r
Cont rol Pane l
Ge ne rat e
M et e orology
Produc t s
2
Dist ribut e
Produc t s
3
Re ady Produc t s
Re c eiv ed Reque st s
T asking
Re ady S pe c ific at ions
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

78. A. Relating IDEF Methods to OOASIS Information Needs
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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A0A0A0
AKB16 4
x12/21/2001
Measure Ocean ObservablesA1
I 1
Ocean Ob servab les
C 4 S ch ed u les C 1 M eteorolog y D ata C 3 C om m u n ication s
C2 M eteorolog y D ata
O1
M easu red Ob servab les
O2
Ocean Ob servation s
Co ntro l Data
Co lle ctio n
1
Me a s ure
O bs e rva ble s
2
Tra ns m it
Co lle ct e d
Da ta
3
Da ta Co lle ctio n Com m a nds
C ollected Data
M1 A rg os
M2 B u oy
M 4 B row ser
Tran sm itterR eceiver S en sor S uite
M 3 C on trol Pan e l
C 5 Ta skin g
Diagram 35. ATP/A1 (Measure Ocean Observables)
62

79. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A1A1A1
AKB17 5
x12/21/2001
Control Data CollectionA11
C 1 S ch ed u les C 3 C om m u n ications Protocols
O1
D ata C ollection C om m an d s
Ge ne ra te
Co m m a nds
1
Se nd
Co m m a nds
2
Re la y
Co m m a nds
3
Re ce ive
Co m m a nds
4
M2 A rg os S ystem
S en t C om m an d s
R elayed C om m an d s
S atellite Protoco lsI n tern et Prot ocols
Unsen t C om m an d s
M 4 R eceiverM 3 B row serM1 C on trol Pan el
C 2 Tasking
Diagram 36. ATP/A11 (Control Data Collection)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A1A1A1
AKB18 6
x01/10/2002
Measure ObservablesA12
I1
Oc e a n Obse rv a ble s
C1 Da t a Colle c t ion Comma ndsC2 M e t e orology Da t a Re quire me nt s
C3 M e t e orology Da t a S t anda rds
O 1
M e a sured Observa ble s
O2
Colle c t ed Da t a
S e nse
O bse rva ble s
1
Ga t her
M e a sure me nt s
2
P a c ka ge
Da t a
3
M e a sure me nt s
M e asure me nt S e t
M 1 S e nsor S uit e
S e nsors
Meas urem ent Pro ces s o r
Diagram 37. ATP/A12 (Measure Observables)
63

80. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A1A1A1
AKB19 7
x12/21/2001
Transmit Collected DataA13
I 1
C ollected Data
C 1 C om m u n ication s Protocols
C 2 M eteorolog y D ata S tan d ard s
O1
Ocean Ob servation s
Se nd Da ta
1
R e la y Da ta
2
Re ceive Da ta
3
M 1 A rg os S ystem
S en t D ata
R elayed D ata
I n ternet Protocols
S atellite Protocols
M2 B row se rM 3 Tran sm itter
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

81. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A0A0A0
AKB22 8
x12/21/2001
Generate Meteorology ProductsA2
I 1
O cean O b servation s
I 2
S atellite Im ag ery
C 4 S ch e d u les
C 1 M eteorolog y D ata R eq u irem en ts
C 2 M eteorolog y D ata S tan d ard s
C3 I m ag e S tan d ard s
O2
R ead y S p ecification s
O3
R ead y Prod u cts
M 2 S an ta N arid a B u oy S ystem
M 1 W eath er Forecaster
Ge ne ra te
Da ta s e ts
1
Filte r
Da ta s e ts
2
Forecast
W eather
3
Filtered D atasets
Un filtered D atasets
Fo recast Text
Ocean Im a g ery
D atabase E n g in e Filter
Forecast Prod u cts
D ataset Prod u cts
C 5 R eceived R eq u ests
O1
Taskin g
D ataset R eq u ests
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 system’s 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

82. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A2A2A2
AKB20 9
x01/05/2002
Generate DatasetsA21
I1
Oc e an Obse rv at ions
C1 M e t e orology Dat a Re quire me nt s
C 3 M et e orology Da t a S t andards
O 3
Unfilt e re d Dat aset s
S av e
Obse rv at ions
1
Cre at e
D at ase t s
2
Re t rie ve
Dat ase t s
3
Sav e d Dat ase t s
S ave d Obse rv at ions
O 2
Re ady S pe c ific at ions
O bse rv at ion S pe c ific at ions
Dat ase t S pe c ific at ions
M 2 Dat abase Engine
M 1 S ant a Narida Buoy S y st e m
Obse rv at ion Proc e ssor Dat ase t Proce ssor Produc t Proc e ssor
C2 Re c e iv e d Re que st s
O 1
T asking
C4 Dat ase t Re que st s
1 Activation rules for A213:
*1 : I1 O2
*2 : ~I1 O1
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 function’s 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

83. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A21A21A21
AKB24 10
x01/05/2002
Save ObservationsA211
I1
Oc e an O bse rv at ions
C1 M e t e orology Dat a S t andards
O1
Obse rv at ion S pe c ific at ions
O2
Sav e d Obse rvat ions
M 1 O bse rv at ion Proc essor M 2 Dat abase Engine
S p ecify
O b s ervatio n
D ata S tan d ard s
1
Prep are
O b s ervatio n s
2
Main tain
O b s ervatio n s
3
Cle an Obse rv at ions
O bse rv at ions S c he ma
Dat a Ele me nt M e t adat a
1 A211.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.
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

84. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A21A21A21
AKB25 11
x01/05/2002
Create DatasetsA212
I1
S a v ed Obse rva t ions
C1 M e t e orology Da t a S t a nda rds
C 2 M e t e orology Da t a Re quireme nt s
O1
Da t a se t S pe c ific a t ions
O 2
S a v e d Da t a se t s
M 1 Da t a se t P roc e ssor M 2 Da t a ba se Engine
S p ecify
D atas et D ata
S tand ard s
1
Prep are
D atas ets
2
M aintain
D atas ets
3
Da t ase t S c hema
Da t a se t M e t a da t a
1 A212.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.
Diagram 42. ATP/A212 (Create Datasets)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
A21A21A21
12
x01/05/2002
Retrieve DatasetsA213
I1
S a v e d Da t a se t s
C1 Da t a se t Re que st s
C2 Re c e iv e d Reque st s
O 1
T a sking
O 2
Unfilt e re d Da t a se t s
M 1 P ro duc t P ro c essorM 2 Da t a ba se Engine
S p ecify
Pro d ucts
1
R et rieve
D ata s ets
2
Package
D atas ets
3
Ca t a log
Dat a se t S e le c t ion
Re t riev e d Da t a se t s
P roduc t Const ruc t ion Rule s
P ro duc t P rope rt ies
1 A213.1 seems to be an activity which will require
active involvement of human intelligence, with skill
and expertise in specifying and crafting
meteorological data products.
68

85. A. Relating IDEF Methods to OOASIS Information Needs
Diagram 43. ATP/A213 (Retrieve Datasets)
The next diagram shows the activities and their mechanisms needed to forecast weather:
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A2A2A2
AKB21 10
x12/21/2001
Forecast WeatherA23
I1
Filtered D atasets
I2
S atellite I m ag ery
C 4 S ch ed u les
C 1 M eteorolog y D ata R eq u irem en ts C 3 M eteorolog y D ata S tan d ard s
C 5 I m ag e S tan d ard s
O2
Ocean Im ag ery
O3
Forecast Text
M 2 W eath er Forecaster
W rite
W e a the r
Script
1
Run W e a th e r
Mo de ls
2
Ge ne rate
Sym bo lic
Im a ge s
3
Co m bine
Im a ge s
4
O cean Overlays
W eath er D ata
M 1 S an ta N arid a B u oy S ystem
W eath er M od els
I m ag e Processor
I m ag e G en eratorW eath er V iew er
C 2 R eceived R eq u ests
O1
D ataset R eq u ests
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 buoy-
collected 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

86. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A0A0A0
AKB23 14
x01/05/2002
Distribute ProductsA3
I2
Re ady Produc t s
I1
Re ady S pe c ific at ions
C1 Communic at ions Prot oc olsC3 Produc t Re que st s
O1
Re c eiv ed Re que st s
O2
M e t eorology Produc t s
M 1 S ant a Narida Buoy S y st e m
F ulfill
Orde rs
1
S t age
Produc t s
2
Post
Product s
3
E mail
Prod uc t s
4
M ail S e rv e r
W e b S e rv e rProduc t ion S e rv e rO rde r De sk
Produc t Order
Loc al A re a Ne t w ork
C2 S c hedule s
W e b Re que st s
S t age d Produc t s
W e bsit e
M ail Compose r
Email Prot oc ols
W e b Prot oc ols
Produc t Cat alog
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

87. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-B E Products (ATP)
Page:
OOASIS SE
AKBocast
A3A3A3A3
AKB29 15
x01/05/2002
Fulfill OrdersA31
I1
Produc t Ca t a log
C1 S c he dule s
C2 Produc t Re que st s
C3 W e b Reque st s
O1
Re c e iv e d Re que st s
O 2
Produc t Orde r
M 1 O rder De sk
C o llect
R eq ues ts
1
O rd er
Pro d ucts
2
1 Collect Requests should be done across a
variety of modalities, from face-to-face
conversation, telephone, FAX, email, etc. At a
later point in analysis, these should be
explored by diagrams invoked by a call arrow.
Orde r S pe c ific a t ion
Re que st Logge r
Orde r Logge r
Diagram 46. ATP/A31 (Fulfill Orders)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-B E Products (ATP)
Page:
OOASIS SE
AKBocst
A3A3A3A3
AKB28 16
x01/05/2002
Stage ProductsA32
I1
Re a dy Produc t s
C1 Produc t Orde r C2 Produc t Reque st s
O 1
S t age d Produc t s
M 1 Loc al A re a Ne t w orkM 2 Produc t ion S erv e r
S tag e
R ead y
Pro d ucts
2
Pro vid e
Pro d uct
A cces s
3
Net w ork Re ady Produc t s
71

88. A. Relating IDEF Methods to OOASIS Information Needs
Diagram 47. ATP/A32 (Stage Products)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-B E Products (ATP)
Page:
OOASIS SE
AKBocast
A3A3A3A3
AKB27 17
x01/05/2002
Post ProductsA33
I1
S t a ge d Produc t s
I2
Re a dy S pec ific a t ions
C1 Produc t Orde r C2 Produc t Re quest s
C3 W e b Prot oc ols
O 1
W e b Re que st s
O2
M e t eorology Produc t s
M 1 W e bsit e M 2 W e b S e rv er
S elect W eb
Pro d ucts
1
Pu b lis h
Pag e
2
S erve
Pag e
3
F ulfillme nt A noma lies
Produc t Ca t a log
A va ilable URL
Produc t S e le c t ions
Diagram 48. ATP/A33 (Post Products)
72

89. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-B E Products (ATP)
Page:
OOASIS SE
AKBocast
A3A3A3A3
AKB26 18
x01/05/2002
Email ProductsA34
I1
S t a ged Produc t s
C1 Produc t Orde r
C2 Ema il Prot oc ols
O1
M e t e orology Produc t s
M 1 M ail Compose r M 2 M a il S e rv e r
S p ecify
Em ail
Pro d uct
1
C o ns truct
Em ail Pro d uct
Mes s ag e
2
Em ail
Pro d u ct
Mes s a g e
3
Ema il M e ssa ge s
Ema il Cont ent S pec ific a t ion Ema il De live ry S pe c ific a t ion
Email Prope rt ie s
1 A Fulfillment Technician
may be an appropriate
mechanism for A34.1.
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

90. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Products (ATP)
Page:
OOASIS SE
AKBocast
A-0
AKB15 3
x01/06/2002
Generate Meteorological ProductsA0
Dist ribut e
Produc t s
3
Ge ne rat e
M et e orology
Produc t s
2
I1
O c e an Obse rv able s
I2
S at e llit e Image ry
C 4 Produc t Re que st s
C5 M e t e orology Dat a Re quire me nt s
O1
M ea sure d O bse rv a ble s
O 2
M et eorology Produc t s
M e a sure Oc e a n
O bse rv able s
1
Oc e an O bse rv at ions
M 3 W e at he r F ore c ast e r
C3 S c he dule s
C2 Image S t andards
C1 Communic at ions Prot oc ols
C 6 M e t e orology Dat a S t andards
M 2 A rgos S y st e m M 1 S ant a Narida Buoy S y st e m
B uoy
Re ady Produc t s
Re c eiv ed Reque st s
T asking
Re ady S pe c ific at ions
Fulfillm e nt Te chnicia n
Sy s te m C o ntrolle r
Pro duct E ngine e r
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

91. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-B E Products (ATP)
Page:
OOASIS SE
AKBocast
A1A1A1
AKB17 5
x01/06/2002
Control Data CollectionA11
C 1 S c hedule s C3 Communic a t ions Prot oc ols
O1
Da t a Colle c t ion Comma nds
Ge ne rat e
Commands
1
S end
Comma nds
2
Re la y
Comma nds
3
Re c eiv e
Comma nds
4
M 2 A rgos S y st e m
S e nt Comma nds
Re la y e d Comma nds
S a t e llit e Prot oc olsInt e rne t Prot oc ols
Unse nt C omma nds
M 4 Buoy Re c eiv e r
M 3 S a nt a Na rida Buoy S y st e m
C2 T a sking
Brow se rCont rol Pa ne l
M 1 S y st e m Cont rolle r
Diagram 51. ATP/A11 (Control Data Collection) with System Controller
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-B E Products (ATP)
Page:
OOASIS SE
AKBocast
A1A1A1
AKB19 7
x01/06/2002
Transmit Collected DataA13
I1
Colle c t ed Da t a
C1 Communic a t ions Prot oc ols
C2 M e t e orology Da t a S t a nda rds
O 1
Oc e a n Obse rv a t ions
S e nd Dat a
1
Re la y Da t a
2
Re c e ive Da t a
3
M 2 A rgos S y st e m
S e nt Da t a
Re la y e d Da t a
Int ernet Prot oc ols
S a t e llit e Prot oc ols
M 3 S a nt a Na rida Buoy S y st e mM 4 Buoy T ra nsmit t e r
Brow se r
M 1 S y st e m Cont rolle r
75

92. A. Relating IDEF Methods to OOASIS Information Needs
Diagram 52. ATP/A13 (Transmit Collected Data) with System Controller
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-B E Products (ATP)
Page:
OOASIS SE
AKBocast
A21A21A21
AKB24 10
x01/06/2002
Save ObservationsA211
I1
Oc e a n Obse rv a t ions
C1 M e t eorology Da t a S t a nda rds
O 1
Obse rv a t ion S pe c ific a t ions
O2
S a v e d Obse rv a t ions
M 2 O bse rv a t ion P roc e ssor M 3 Da t a ba se Engine
S p ecify
O b s ervatio n
D ata S tand ard s
1
Prep are
O b s ervatio n s
2
Main tain
O b s ervatio ns
3
Cle a n O bse rv a t ions
O bse rv a t ions S c he ma
Da t a Ele me nt M e t a da t a
M 1 Da t a Engine e r
Diagram 53. ATP/A211 (Save Observations) with Data Engineer
76

93. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-B E Products (ATP)
Page:
OOASIS SE
AKBocast
A21A21A21
AKB25 11
x01/06/2002
Create DatasetsA212
I1
S a v ed Obse rva t ions
C1 M e t e orology Da t a S t a nda rds
C 2 M e t e orology Da t a Re quireme nt s
O1
Da t a se t S pe c ific a t ions
O 2
S a v e d Da t a se t s
M 2 Da t a se t P roc e ssor M 3 Da t a ba se Engine
S p ecify
D atas et D ata
S tand ard s
1
Prep are
D atas ets
2
M aintain
D atas ets
3
Da t ase t S c hema
Da t a se t M e t a da t a
M 1 Da t a Engine e r
Diagram 54. ATP/A212 (Create Datasets) with Data Engineer
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-B E Products (ATP)
Page:
A21A21A21
12
x01/06/2002
Retrieve DatasetsA213
I1
S a v e d Da t a se t s
C1 Da t a se t Re que st s
C2 Re c e iv e d Reque st s
O 1
T a sking
O 2
Unfilt e re d Da t a se t s
M 2 Produc t Proc essorM 3 Da t a ba se Engine
S p ecify
Pro d ucts
1
R et rieve
D ata s ets
2
Package
D atas ets
3
Ca t a log
Dat a se t S e le c t ion
Re t riev e d Da t a se t s
Produc t Const ruc t ion Rule s
Produc t Prope rt ies
M 1 Produc t Engine e r
Diagram 55. ATP/A213 (Retrieve Datasets) with Product Engineer
77

94. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-B E Products (ATP)
Page:
OOASIS SE
AKBocast
A0A0A0
AKB23 14
x01/06/2002
Distribute ProductsA3
I2
Re a dy Produc t s
I1
Re a dy S pe c ific a t ions
C1 Communic a t ions Prot oc olsC3 Produc t Re que st s
O1
Re c eiv e d Re que st s
O2
M e t eorology Produc t s
M 2 S ant a Na rida Buoy S y st e m
F ulfill
Orde rs
1
S t a ge
Produc t s
2
Post
Product s
3
E ma il
Prod uc t s
4
M a il S e rve r
W e b S e rv e rProduc t ion Se rv e rO rde r De sk
Produc t Order
Loc a l A re a Ne t w ork
C 2 S c hedule s
W e b Re que st s
S t a ge d Produc t s
W ebsit e
M a il Compose r
Ema il Prot oc ols
W e b Prot oc ols
Produc t Ca t a log
M 1 F ulfillme nt T e c hnic ia n
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

95. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: Requirements TO-BE Operations (RTO)
Page:
OOASIS SE
AKBocast
AKB5 1
x12/21/2001
Stakeholder Context of Routing Product GenerationA-1
Co nte xt of
Ro utin g
P ro du ct
Ge ne ra tio n
0
S u p p ly
C ap ital
R esou rces
2
P ro vide
O bs e rva ble s
3
C on trol
Op eration s
4
P la n
Shipping
Ro ute s
5
1
Ge ne ra te
Ro uting
Pro ducts
x
con trol req u est
M ain ten an ce R eq u est
in p u t req u est
Prod u ct R eq u ests
R ou te Plan n er
Enviro nm e ntN OA AN W S Ge ne ra l Ma na ge r Sa nta N a rida Buo y Sys te m
Minis te ria l Re que s ts
Ocean Ob servab les
R ou tin g Prod u cts
R ou te P lan
System Status
R ou tin g D ecisio n s
NONE
0
x
M easu red Ob servab les
rep a ired b u oy
b roken b u oy
Se rvice Agre e m e nts
M ain ten an ce N otification
m ech an ism req u est
B u oy Tech n ical D ata
M in isterial R ep orts
x
M in isterial Qu estion s
R ou te Plan n in g R eq u irem en ts
A rg os
C om m u n ication s S atellites
C om m u n ication s Protocols
Diagram 57. RTO/A-1 (Stakeholder Context of Routing Product Generation)
The corresponding A-0 diagram is:
79

96. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Requirements TO-B E Operations (RTO)
Page:
OOASIS SE
AKBocast
Top
AKB1 2
x12/26/2001
Context of Routing Product GenerationA-0
G en erate
R o u ting
Pro d ucts
0
Purpose:
Viewpoint: Systems Engineer as Requirements Elicitor.
To specify minimal and sufficient behaviors
leading necessarily to a coherent set of related
outputs required by external stakeholders.
TOP
0
Produc t Re que st s
M inist e rial Re que st s
Oc e an O bserv able s
Rout ing Produc t s
S y ste m
Rout ing De c isions
M e asure d Obse rv ables
M aint enanc e Not ific at ion
M in is te r ia l
Rout e Pla nning Re quire me nt s
O ce a n
M ea s u r e d
M inist e rial Re port s
R ou tin g
S y st e m S t a t us
A rgos Sy st e m
Communic at ions Prot oc ols
S a nt a Narida Buoy S y st e m
Rout e Planne r
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

97. A. Relating IDEF Methods to OOASIS Information Needs
represented, one for routine administrative reporting and the other for reporting system performance and
goal attainment to the Santa Narida government.
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Requirements TO-B E Operations (RTO)
Page:
OOASIS SE
AKBocast
A-0
AKB7 3
x12/26/2001
Generate Routing ProductsA0
Ge nerat e
Rout ing
Produc t s
2
I1
O c e an Obse rv able s O2
M e a sure d Obse rv a ble s
O3
M inist erial Re port s
O4
Rout ing Produc t s
O1
S y st e m S t at us
M 3 A rgos S y st e m
C5 Produc t Re que st s
C 4 Rout ing De c isions
C3 M inist e rial Re que st s
C2 Rout e Planning Re quire me nt s
C1 M aint e nanc e Not ific at ion
C6 Communic at ions Prot oc ols
M eas ure
Oc e an
Obse rv ables
1
O c ean Obe rv at ions
2
Re port S y st em
S t at us
3
Re port S y st e m
A c c omplishme nt s
4
S t a t us Re que st
Buoy S t at us
1 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.
Rout ing Dec isions
2 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.
Ac t iv it y S t at us
3 We will not decompose either A3 or A4.
Informed intuition suggests that these are
conventional reporting functions with nothing
much interesting to be revealed by
decomposition.
Rout ing Produc t s
M 2 Rout e Planne r
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

98. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Requirements TO-B E Operations (RTO)
Page:
OOASIS SE
AKBocast
A0A0A0A0
AKB9 6
x12/26/2001
Generate Routing ProductsA2
I1
O c e a n O berv at ions
C1 Communic a t ions Prot oc ols
C2 Rout e Planning Re quire me nt s
C3 Produc t Re que st s
O1
Rout ing Produc t s
O2
A c t iv it y S t a t usG e ne rat e
D a t a set s
1
F ilt er
Da t a se t s
2
Prop ose
It ine ra rie s
33
Unfilt e re d Dat ase t s
F ilt e re d Da t a se t s
Da t a se t Re que st s
M 1 Rout e Pla nner
Diagram 60. RTO/A2 (Generate Routing Products)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Requirements TO-B E Operations (RTO)
Page:
OOASIS SE
AKBocast
A2A2A2
AKB10 7
x12/26/2001
Propose ItinerariesA23
I1
F ilt e re d Da t a se t s O2
A c t iv it y St a t us
O3
Rout ing Produc t s
De t e rmine
F e a sible
Rout e s
1
F ore c a st
Rout e
W e at he r
2
Est im a t e
S hip
S c he du le s
3
S e le c t
Opt imum
It ine rary
4
C2 Produc t Reque st s C 1 Rout e Pla nning Re quire me nt s
O1
Da t a se t Re que st s
M 1 Rout e Pla nne r
C3 Communic a t ions Prot oc ols
S e le c t e d It ine rary
Est ima t e d It ine ra rie s
Rout e F ore c a st s
F e a sible Rout e s
82

99. A. Relating IDEF Methods to OOASIS Information Needs
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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Operations (ATO)
Page:
OOASIS SE
AKBocast
Top
AKB1 2
x12/26/2001
Context of Routing Product GenerationA-0
G enerate
R o utin g
Pro d u cts
0
Purpose:
Viewpoint: Systems Engineer as Requirements Elicitor.
To specify minimal and sufficient behaviors
leading necessarily to a coherent set of related
outputs required by external stakeholders.
TOP
0
Produc t Re que st s
M inist e rial Re que st s
Oc e an Obse rv ables
Rout ing Produc t s
S y s te m
M e asured Obse rv able s
M aint e nanc e Not ific at ion
M in is te r ia l
Rout e Planning Re quire me nt s
O ce a n
M e a s u r e d
M inist erial Re port s
R o u tin g
S y st e m S t a t us
A rgos S y st em
Communic at ions Prot oc ols
S ant a Narida Buoy S y st e m
Rout e Planne r
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

100. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Operations (ATO)
Page:
OOASIS SE
AKBocast
A-0
AKB7 3
x12/26/2001
Generate Routing ProductsA0
Ge ne ra t e
Rout ing
Produc t s
2
I1
Oc e a n Obse rv a ble s O2
M e a sure d Obse rv a ble s
O3
M inist e ria l Re port s
O4
Rout ing Produc t s
O1
S y st e m S t at us
M 3 A rgos S y st e m
C4 Produc t Re quest s
C3 M inist e ria l Reque st s
C2 Rout e Pla nning Re quire ment s
C1 M a int e na nc e Not ific a t ion
C5 Communic a t ions Prot oc ols
M ea s ure
O c e an
Observ able s
1
O c e a n Obe rv a t ions
2
Re port S y st em
S t a t us
3
Re port S y st e m
A c c omplishme nt s
4
S t a t us Re que st
Buoy S t a t us
Rout ing De c isions
A c t iv it y S t a t us
Rout ing Produc t s
M 2 Rout e Planne r M 1 S a nt a Na rida Buoy S y st e m
S y st e m Pe rforma nc e Report e r
S y st e m S t a t us Re port er
Buoy s
Diagram 63. ATO/A0 (Generating Routing Products)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Operations (ATO)
Page:
OOASIS SE
AKBocast
A0A0A0A0
AKB9 6
x12/26/2001
Generate Routing ProductsA2
I1
O c e a n O berv at ions
C1 Communic a t ions Prot oc ols
C2 Rout e Pla nning Re quire me nt s
C3 Produc t Re que st s
O1
Rout ing Produc t s
O2
A c t iv it y S t a t usG e ne rat e
D a t a set s
1
F ilt er
Da t a se t s
2
Prop ose
It ine ra rie s
33
Unfilt e re d Dat ase t s
F ilt e re d Da t a se t s
Da t a se t Re que st s
M 1 Rout e Planne r
M 2 S a nt a Na rida Buoy S yst em
Pro ces s ing En g ines
Da t a ba se Engine F ilt e r Proc e ssor
Brow se r
W e b S erv er
It ine ra ry Engine
84

101. A. Relating IDEF Methods to OOASIS Information Needs
Diagram 64. ATO/A2 (Generating Routing Products)
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Operations (ATO)
Page:
OOASIS SE
AKBocast
A2A2A2
AKB10 7
x12/26/2001
Propose ItinerariesA23
I1
F ilt e re d Dat ase t s O2
Ac t iv it y St at us
O3
Rout ing Produc t s
De t e rmine
F easible
Rout e s
1
F ore c ast
Rout e
W e at he r
2
Est im at e
S hip
S c he du le s
3
S e le c t
O pt imum
It ine rary
4
C2 Produc t Re que st s C 1 Rout e Planning Re quire me nt s
O1
Dat ase t Reque st s
M 3 Brow se r
C3 Communic at ions Prot oc ols
M 2 It ine rary Engine
S e le c t e d It ine rary
Est imat e d It ine rarie s
Rout e F ore c ast s
F e asible Rout e s
M 1 W e b S e rv e r
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

102. A. Relating IDEF Methods to OOASIS Information Needs
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 model’s 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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Operations (ATO)
Page:
OOASIS SE
AKBocast
A-0
AKB11 3
x12/26/2001
Generate Routing ProductsA0
Ge nerat e
Rout ing
Produc t s
2
I1
O c e an Obse rv able s O2
M e a sure d Obse rv a ble s
O3
M inist erial Re port s
O4
Rout ing Produc t s
O1
S y st e m S t at us
M 3 A rgos S y st e m
C4 Produc t Re quest s
C3 M inist e rial Reque st s
C2 Rout e Planning Re quirement s
C1 M aint e nanc e Not ific at ion
C5 Communic at ions Prot oc ols
M eas ure
Oc e an
Obse rv ables
1
Oc e an Obe rv at ions
2
Re port S y st em
S t at us
3
Re port S y st e m
A c c omplishme nt s
4
St at us Re quest
Buoy S t at us
Rout ing De c isions
A c t ivit y S t at us
Rout ing Produc t s
M 2 Rout e Planne r M 1 S ant a Narida Buoy S y st e m
S y st e m Pe rformanc e Re port e r
S y st e m S t a t us Re port e r
Buoy s
Adm inis tra torAdm inis tra tor
Diagram 66. ATO/A0=AKB11 (Generate Routing Products)
86

103. A. Relating IDEF Methods to OOASIS Information Needs
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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: Architecture TO-BE Operations (ATO)
Page:
OOASIS SE
AKBocast
A0A0A0A0
AKB9 6
x12/26/2001
Generate Routing ProductsA2
I1
O c e a n Obe rv at ions
C1 Communic at ions Prot oc ols
C2 Rout e Planning Re quire me nt s
C3 Produc t Re que st s
O1
Rout ing Produc t s
O2
A c t iv it y S t at usG ene rat e
D at aset s
1
F ilt e r
Da t aset s
2
Prop ose
It ine ra rie s
33
Unfilt e re d Dat ase t s
F ilt e re d Dat ase t s
Dat ase t Re que st s
M 1 Rout e Planne r
M 2 S ant a Narida Buoy S y st em
Pro ces s in g E n g in es
Dat abase Engine F ilt e r Proc e ssor
Brow se r
W e b S e rv er
It ine rary Engine
D a ta ba s e Adm inis tra to r
Diagram 67. ATO/A2=AKB9 (Generate Routing Products)
6
The appearance of one label connected by two squiggles to two different arrow segments is a visual sleight-of-
hand. 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

104. A. Relating IDEF Methods to OOASIS Information Needs
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 tiv ity in
Re d Use
C a s e
1F
A c tiv ity in
B lue Us e
C a s e
2F
A c tiv ity in
B o th B lu e
a n d Red
Us 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

105. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: OOASIS System Use Cases (OSU)
Page:
OOASIS SE
AKBocast
A-0
AKB25 3
x01/08/2002
Generate Meteorological ProductsA0
Dist ribut e
Produc t s
3
G enerate
M eteorology
P roducts
2
I1
O c e a n O bse rv a ble s
I2
S a t e llit e Ima ge ry
C4 Produc t Reque st s
C5 M e t e orology Da t a Re quireme nt s
O1
M ea sure d O bse rv a ble s
O2
M et eorology Produc t s
M easure O cean
O bserv ables
1
Oc e a n Obse rv a t ions
M 3 W e a the r Fo re ca s te r
C3 S c he dule s
C2 Ima ge S t a nda rds
C1 Communic a t ions Prot oc ols
C6 Met e orology Da t a S t a nda rds
M 2 Argo s Sy s te m M 1 S a nt a Narida Buoy S y st e m
Re a dy Produc t s
Re c e iv ed Reque st s
T a sking
Re a dy S pe c ific a t ions
Buoy s
Sy s te m C o ntro lle r
Pro duct E ngine e r
Fulfillm e nt Te chnicia n
Diagram 68. ASU/A0 (Generate Meteorological Products)
In use case notation, this might be represented as:
System Controller Argos System
Environment
Measure Ocean Observables
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

106. A. Relating IDEF Methods to OOASIS Information Needs
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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: OOASIS System Use Cases (OSU)
Page:
OOASIS SE
AKBocast
A-0
AKB25 3
x01/08/2002
Generate Meteorological ProductsA0
Dist ribut e
Produc t s
3
G enerate
M eteorology
P roducts
2
I1
O c e a n O bse rv a ble s
I2
S a t e llit e Ima ge ry
C4 Produc t Reque st s
C5 M e t e orology Da t a Re quireme nt s
O1
M ea sure d O bse rv a ble s
O2
M et eorology Produc t s
M easure O cean
O bserv ables
1
Oc e a n Obse rv a t ions
M 3 W e a the r Fo re ca s te r
C3 S c he dule s
C2 Ima ge S t a nda rds
C1 Communic a t ions Prot oc ols
C6 Met e orology Da t a S t a nda rds
M 2 Argo s Sy s te m M 1 S a nt a Narida Buoy S y st e m
Re a dy Produc t s
Re c e iv ed Reque st s
T a sking
Re a dy S pe c ific a t ions
Buoy s
Sy s te m C o ntro lle r
Pro duct E ngine e r
Fulfillm e nt Te chnicia n
Diagram 69. OSU/A0=AKB24 (Generate Meteorological Products)
and our corresponding use case diagram looks like the next diagram:
Environment
System Controller Argos System
Weather
Forecaster
Product Engineer
Run Weather Models
Measure Ocean Observables
<<depend>>
Figure 7. Use Case Analysis: Run Weather Models
90

107. A. Relating IDEF Methods to OOASIS Information Needs
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: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: OOASIS System Use Cases (OSU)
Page:
OOASIS SE
AKBocast
A0A0A0
AKB26 11
x01/08/2002
Distribute ProductsA3
I2
Re ady Produc t s
I1
Re a dy S pe c ific at ions
C1 Communic a t ions Prot oc olsC3 Produc t Re quest s
O1
Re c eiv e d Re que st s
O2
M e t eorology Produc t s
M 2 S a nt a Na rida Buoy S y st e m
F ulfill
O rders
1
S tage
P roducts
2
P ost
P roducts
3
E m ail
P rod ucts
4
M a il S e rv e r
W e b S e rv e rProduc t ion S e rv e rO rde r De sk
Produc t Order
Loc a l A re a Ne t w orkM a il C lie nt
C 2 S c he dule s
W e b Re que st s
S t a ge d Produc t s
W e bsit e
M a il Compose r
M 1 Fulfillm e nt Te chnicia n
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

108. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: OOASIS System Use Cases (OSU)
Page:
OOASIS SE
AKBocast
A-0
AKB25 3
x01/08/2002
Generate Meteorological ProductsA0
Dist ribut e
Produc t s
3
G enerate
M eteorology
P roducts
2
I1
O c e a n O bse rv a ble s
I2
S a t e llit e Ima ge ry
C4 Produc t Reque st s
C5 M e t e orology Da t a Re quireme nt s
O1
M ea sure d O bse rv a ble s
O2
M et eorology Produc t s
M easure O cean
O bserv ables
1
Oc e a n Obse rv a t ions
M 3 W e a the r Fo re ca s te r
C3 S c he dule s
C2 Ima ge S t a nda rds
C1 Communic a t ions Prot oc ols
C6 Met e orology Da t a S t a nda rds
M 2 Argo s Sy s te m M 1 S a nt a Narida Buoy S y st e m
Re a dy Produc t s
Re c e iv ed Reque st s
T a sking
Re a dy S pe c ific a t ions
Buoy s
Sy s te m C o ntro lle r
Pro duct E ngine e r
Fulfillm e nt Te chnicia n
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

109. A. Relating IDEF Methods to OOASIS Information Needs
Environment
Tsunami Warning
Center
Institute Scientist
System Controller Argos System
Post Products Email Products
Weather
Broadcaster
Fulfillment
Technician
Weather
Forecaster
Stage Products
<<extend>> <<extend>>
Run Weather Models
Database
Administrator
Maintain Meteorological Data
<<depend>>
<<depend>>Product Engineer
Measure Ocean Observables
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

110. A. Relating IDEF Methods to OOASIS Information Needs
Tsunami Warning
Center
Institute Scientist
System Controller Argos System
Post Products Email Products
Weather
Broadcaster
Fulfillment
Technician
Weather
Forecaster
Stage Products
Run Weather Models
Database
Administrator
Product Engineer
Maintain Meteorological Data
<<extend>> <<extend>>
<<depend>>
<<depend>>
Measure Ocean Observables
Environment
Figure 9. Use Cases Analysis: Maintain Meteorological Data
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: OOASIS System Use Cases (OSC)
Page:
OOASIS SE
AKBocast
A0A0A0A0
AKB9 6
x12/30/2001
Generate Routing ProductsA2
I1
Oc ean Oberv at ions
C1 Communic at ions Prot oc ols
C2 Rout e Planning Re quire me nt s
C3 Produc t Re que st s
O1
Rout ing Produc t s
O2
A c t iv it y St at us
G enerate
D atasets
1
F ilter
D a tasets
2
P rop ose
Itinera ries
33
Unfilt e re d Datase t s
F ilt e re d Dat ase t s
Dat ase t Re que st s
M 1 R o ute Pla nne r
M 2 S ant a Narida Buoy S y st e m
Pro ces s ing Eng ines
Dat abase Engine F ilt e r Proc e ssor
Brow se r
W e b S e rv e r
It ine rary Engine
D a ta ba s e Adm inis tra to r
Diagram 72. OSC/A2 (Generate Routing Products)
94

111. A. Relating IDEF Methods to OOASIS Information Needs
Tsunami Warning
Center
Institute Scientist
System Controller Argos System
Post Products Email Products
Weather
Broadcaster
Fulfillment
Technician
Weather
Forecaster
Stage Products
<<extend>> <<extend>>
Run Weather Models
Database
Administrator
Product Engineer
Maintain Meteorological Data
<<depend>>
<<depend>>
Route Planner
Propose Itineraries
<<depend>>
Measure Ocean Observables
Environment
Figure 10. Use Case Analysis: Propose Itineraries
Now as shown in the final markup of the OSC/A0 diagram:
95

112. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
P ublication
Reader Date
P.
Model: OOASIS System Use Cases (OSC)
Page:
OOASIS SE
AKBocast
A-0
AKB11 3
x12/30/2001
Generate Routing ProductsA0
G enerate
Routing
P roducts
2
I1
O c e a n O bse rva ble s O2
M e a sure d O bse rv a ble s
O3
M inist e rial Re port s
O4
Rout ing Produc t s
O1
S y st em S t at us
M 3 Argo s Sy s te m
C4 Produc t Re que st s
C3 M inist e rial Re que st s
C2 Rout e Planning Re quire ment s
C1 M aint e nanc e Not ific at ion
C5 Communic at ions Prot oc ols
M e as ure
O ce a n
O bse rv able s
1
O c e a n O be rv at ions
2
Report S y stem
S tatus
3
Report S ystem
Accom plishm ents
4
S t atus Re que st
Buoy S t atus
Rout ing De c isions
Ac t iv it y S t atus
Rout ing Produc t s
M 2 R oute Pla nne r M 1 S ant a Narida Buoy Sy st e m
S y ste m Pe rformanc e Re porte r
Sy st e m S t at us Re port e r
Buoys
S ystem A d m inistrato rS ystem A d m inistrato r
Diagram 73. OSC/A0 (Generate Routing Products), Final Markup
We have only to add the System Administrator’s 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

113. A. Relating IDEF Methods to OOASIS Information Needs
Tsunami Warning
Center
Institute Scientist
Post Products Email Products
Weather
Broadcaster
Fulfillment
Technician
Weather
Forecaster
Stage Products
<<extend>> <<extend>>
Run Weather Models
Database
Administrator
Product Engineer
System Controller Argos System
Maintain Meteorological Data
<<depend>>
<<depend>>
Route Planner
Propose Itineraries
<<depend>>
System
Administrator
Generate Reports
<<depend>>
Measure Ocean Observables
<<depend>>
Environment
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

114. A. Relating IDEF Methods to OOASIS Information Needs
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 1 S ch ed u les
O1
D ata C oll ection C om m an d s
N O D E
C ontro l
P ane l
---
Ge ne ra te
C o mm a nd s
1
N O D E
B ro w se r
---
Se nd
Co m m a nd s
2
D E V IC E
Argo s
Syste m
---
R e la y
Co m m a nds
3
D E V IC E
B uo y
R e ce ive r
---
R e c e ive
Co m m a nds
4
C 2 Taskin g
M 1 S ystem C on troller
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

115. A. Relating IDEF Methods to OOASIS Information Needs
C 1 S ch ed u les
O 1
D ata C ollection C om m an d s
N O D E
C o ntro lle r
W o rksta tio n
---
C o ntro l
P a ne l,
B ro w s e r
---
G e ne ra te
C o m m a nd s
1
D E V IC E
A rg o s
Syste m
---
R e la y
C o m m a nd s
3
D E V IC E
B uo y
R e ce ive r
---
R e c e ive
C o m m a nd s
4
C 2 Taskin g
M1 S ystem C on troller
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:
I1
O c e an O bse rv a ble s
C1 S c hedule s
O 1
M e a sured O bse rv ables
O 2
O c ea n O bserv a t ions
C2 T a sking
M 1 S y st e m Cont rolle r
D EVIC E
B uoy
Transm itte r
-- -
Sen d Dat a
1F
D EV IC E
Argos
S y ste m
---
Relay D ata
2F
N O D E
C ont rolle r
W orks tation
- --
Bro w s e r
- --
Receiv e D ata
3 F
D EV IC E
B uo y
S ensor s
-- -
Sen s e
Obs ervable s
4F
N O D E
B uoy P roce ssor
---
M e a s u re m e n t
P ro ce s s o r
---
Gath er
M eas u rem en ts ;
Pac kage Data
5F
N O D E
C ontrolle r
W orksta tion
---
C o n tro l P a n e l;
Bro w s e r
---
Gen erate
Com m an ds
6F
DEV IC E
Argos
Sy stem
---
Relay
Com man ds
7F
D EV IC E
B uoy
Rece iv e r
---
Receive
Com m an ds
8F
1
2 3
5
4
6 7
8
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

116. A. Relating IDEF Methods to OOASIS Information Needs
• 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:
I1
O ce a n O b se rv a ble s
C 1 S c he dule s
O 1
M e a sure d O bserv a ble s
O 2
O c e a n O bse rv a t ions
C2 T a sking
M 1 S y st e m Co nt rolle r
D EV ICE
B uoy
T ra nsm itte r
---
Sen d D ata
6 F
D EVIC E
B uoy S e nsors
---
Sen s e
Obs ervables
4F
N O D E
B uoy P roce ssor
---
M e a s u re me n t
P ro ce s s o r
---
G ath e r
M e a su re m e n ts;
P ackage D ata
5 F
N O D E
C ontrolle r
W orkstation
---
C o n tro l P a n e l,
Bro w s e r
---
Gen erate
Com m an ds
1F
D EV IC E
Argos
S y ste m
---
Relay
Comm an ds ;
Relay D ata
2 F
D EV IC E
B uoy
Re ce iv e r
---
Receive
Com m an ds
3 F
1
2
3
5
4
6
Figure 15. Second NDC Transformation on ONA/A1
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:
Buoy
DE V ICE
B uo y
Tra ns m itte r
- - -
Se nd Dat a
4
DE V IC E
B uo y
Se ns o rs
- - -
Se nse
Obse rv able s
7
NO DE
B uo y
P ro c e s s o r
- - -
M e a sure me nt
Proc e ssor
- - -
Ga t he r
M e a su re m e nt s;
Pa c ka ge Da t a
2
NO DE
C o ntro lle r
W o rks ta tio n
- - -
Cont rol Pa ne l,
Brow se r
- - -
Ge ne ra t e
Com m a nds
1
DE V IC E
A rgo s
Sy s te m
- - -
Re la y
Com m a nds;
Re la y Da t a
3
DE V ICE
B uo y
Re c e ive r
-- -
Re c e iv e
Co m m a nds
5
C1 S c he dule s
C 2 T a sking
M 1 S y st e m Cont rolle r
O c e a n O bse rv a t ions
O2
I1 O 1
Oc e a n Obse rv able s M e a sure d O bse rv a ble s
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

117. A. Relating IDEF Methods to OOASIS Information Needs
I 1
O cean O b servation s
O 3
Un filtered D atasets
O 2
R ead y S p ecification s
O b servation S p ecification s
D ataset S p ecification s
C 1 R eceived R eq u ests
O 1
Taskin g
C 2 D ataset R eq u ests
M 1 Prod u ct E n g in eer
D ata E n g in eer
N O D E
Prod u c t
P roc e s s or
---
Spe cify
Products;
Pa ck age
D ata se ts
5
D EV IC E
D ata b a s e
En g in e
---
R e trie v e
D a ta se ts
6
N O D E
D a tas e t
P roc e s s or
---
Spe cify
D atase t D ata
Standard s;
Pre par e
D atase ts
3
D EV IC E
D ata b a s e
En g in e
-- -
M aintain
D a tase ts
4
NO D E
O b s ervation
P roce s s or
---
Spe cify
O bse rv a tio n
D ata Standa rds;
Pre pare
O bse rvations
1
D EV IC E
D a tab a s e
En g in e
---
M a intain
O bse rv a tio ns
2
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:
I 1
O cean O b servation s
O 3
Un filtered D atasets
O 2
R ead y S p ecification s
O b servation S p ecification s
D ataset S p ecification s
C 1 R eceived R eq u ests
O 1
Taskin g
C2 D ataset R eq u ests
M 1 Prod u ct E n g in eer
D ata E n g in eer
N O D E
P rod u c t
P roc es s or
---
Spe cify
Products;
Pack age
D atase ts
5
N O D E
Datas e t
P roce s s or
---
Spe cify Datase t
D ata Standards;
Pre pare
D atase ts
3
N O D E
O b s e rv ation
P roc e s s or
---
Spe cify
O bserv ation
D ata Standards;
Prepare
O bse rv ations
1
D EV IC E
D atab as e
En g in e
---
M aintain
O bse rv ations;
M aintain
D atase ts;
R e trie v e
D atase ts
2
Figure 18. Second NDC Transformation on ONA/A21
Our NDC transformation of diagram ONA/A23 is shown in the next figure:
101

118. A. Relating IDEF Methods to OOASIS Information Needs
I 1
Filtered D atasets
I 2
S atellite Im ag e ry
C 2 S ch ed u les
O2
Ocean I m ag ery
O3
F orecast Text
M 1 W eath er Forecaster
NO D E
Fo re ca ste r
W o rksta tio n
---
W e a the r
V ie w e r
---
W rite
W e a the r
Sc ript
2
NO D E
W e a the r
M a chine
---
Run W e a the r
M o d e ls
1
NO D E
Im a ge
M a chine
---
Im a g e
G e ne ra to r;
Im a g e
P ro ce s s o r
---
Ge ne ra te
Sym bo lic
I m a ge s ;
Co m bine
I m a g e s
3
C 1 R eceived R eq u ests
O1
D ataset R eq u ests
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
Ocean Ob servation s
I 2
S atellite I m ag ery
C 1 S ch ed u les
O2
R ead y S p ecification s
O3
R ead y Prod u cts
M 1 W eath er Forecaster
NO D E
Filte r E ngine
---
Filte r
D a ta s e ts
5
Filtered D atasetsUn filtered D atasets
Forecast Text
Ocean I m ag ery
Forecast Prod u cts
D ataset Prod u cts
C 2 R eceived R eq u ests
O1
Taskin g
M2 Pro d u ct E n g in eer
NO D E
Fo re ca ste r
W orksta tio n
---
W e a the r
V ie w e r
---
Write
W e a t he r
Sc ript
7
NO D E
W e a the r
M a chine
---
R un W e a th e r
M o de ls
6
N O D E
Im a ge
M a chine
---
Im a g e
G e ne ra to r;
Im a g e
P ro ce s s o r
---
Ge n e ra te
Sym bo lic
I m a ge s ;
Co m bine
I m a g e s
8
Ob servation S p ecification s
D ataset S p ecification s
D ata E n g in eer
NOD E
P roduct
P roce ssor
---
Specify
Pro ducts;
Package
Datasets
4
NO D E
D at ase t
P roce s sor
- --
Spe cif y
Datase t Data
S tand ards;
Prep are
Data sets
3
NO D E
O bs e rv ation
P roce s sor
---
S pe cif y
O bse rvation
Data
Standards;
Prepare
O bse rvations
1
DE VIC E
D atabas e
Engine
---
M aintain
O bservations;
M aintain
Datase ts;
Re trie ve
Datase ts
2
Figure 20. First NDC Transformation of ONA/A2
We observe in this diagram some patterns of coupling that suggest we consider coalescing nodes:
• 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.
102

119. A. Relating IDEF Methods to OOASIS Information Needs
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.
I 1
Ocean O b servation s
I 2
S atellite I m ag ery
C 1 S ch ed u les
O2
R ead y S p ecification s
O 3
R ead y Prod u cts
M 1 W eath er Forecaster
Forecast Text
Ocean I m ag ery
Forecast Prod u cts
D ataset Prod u cts
C 2 R eceived R eq u ests
O 1
Taskin g
M 2 Prod u ct E n g in eer
NO D E
Fo re ca ste r
W o rksta tio n
---
W e a the r
V ie w e r
---
W rite
W e a the r
Sc rip t
5
N O D E
W e a the r
M a chine
---
R un W e a t h e r
M o de ls
4
NO D E
Im a ge
M a chine
---
Im a g e
Ge ne ra to r;
Im a g e
P ro ce s s o r
---
Ge ne ra te
Sym bo lic
I m a g e s ;
Co m bine
I m a g e s
6
D ata E n g in eer
NO D E
P roduct
M a chine
---
Pro duct
Pro cesso r;
F ilter Engine
---
Specify
Pro ducts;
Pack age
Datasets;
F ilter Datasets
3
NO D E
D ata
M achine
-- -
O bserv ation
P rocessor ;
Da tase t
P roce sso r
-- -
Specify
O bserv ation
Data
Standards ;
Prepare
O bserv ations ;
Specify
Dataset Data
Standards ;
Prepare
Dataset s
1
DEV IC E
D ata bas e
Eng ine
- --
M ain tain
O bserv ations;
M ain tain
Data sets;
Retrieve
Data sets
2
Figure 21. Second NDC Transformation of ONA/A2
Continuing in the same way, we create an NDC transformation of ONA/A3:
I 2
R ead y Prod u cts
I 1
R ead y S p ecification s
C2 Prod u ct R eq u ests
O1
R eceived R eq u ests
O2
M eteorolog y Prod u cts
C1 S ch ed u les
M 1 cFu lfillm en t Tech n ician
N O D E
M ail
C om pos er
- --
Spe cify Em ail
Produc t;
Constru ct
Em ail Produ ct
M essage
5
DEVIC E
Em ail S e rv e r
---
Em a il Product
M e ssa ge
7
NO D E
P roduct
W ebsite
---
Select W eb
Products;
Publish Page
4
DEVIC E
W e b S e r v er
---
Se rve
Page
6
N O DE
Produ ction
S erv e r
---
Stage Ready
Pro ducts
2
DEVIC E
L oca l A rea
Ne tw ork
---
Provide Product
Acce ss
3
NO DE
F ulfillm e nt
W ork station
---
O rder Desk : Reque st
Lo gge r; O rder Lo gge r
---
Colle ct Re quests;
O rder Products
1
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

120. A. Relating IDEF Methods to OOASIS Information Needs
Buoy
I 1
O cean O b servab les
I 2
S atellite I m ag ery
O 1
M easu red Ob servab les
M 3 W eath er F orecaster
System Controller
Prod u ct E n g in eer
NO D E
M ail
C om pos er
---
Specify Em ail
Product;
Co nstruct
Em ail Pro duct
M essage
1 7
DEVIC E
Em a il S erv er
---
Em ail P ro duct
M essage
1 9
NO D E
P rodu ct
W ebsite
---
Select W eb
Product s;
Publish P a ge
16
D EVIC E
W e b S e rve r
---
Se rve
P age
18
NO DE
P roduction
S e rve r
---
Sta ge Ready
Pro ducts
1 4
DEVIC E
L ocal A rea
N e tw ork
---
Pro vide Product
Acce ss
1 5
NO DE
Fulfillm e nt
W ork station
---
O rde r Desk: Request
Lo gger; O rder Lo gger
---
Colle ct Re que sts;
O rder P roducts
13
N O D E
Fo re ca ste r
W o rksta tio n
---
W ea t he r
V ie w e r
---
Writ e
We a the r
Sc rip t
1 1
N O D E
W e a the r
M a chine
---
R un W ea t he r
M o de ls
9
N O DE
Im a ge
M a chine
---
Im a ge
Ge ne ra tor;
Im a ge
P ro ce s so r
---
Ge nerate
Sym bolic
I m a g es ;
Com bine
I m a ge s
12
Data E n g in eer
NO D E
P roduct
M a chine
---
Pro duct
Pro ce sso r;
Filte r Engine
---
Specify
P ro ducts;
P acka ge
D atase ts;
Filter D a tasets
7
N O D E
D a ta
M a chine
---
O b s e rvat ion
Proce s s or;
D a ta s e t
P ro ces s o r
---
Sp e c ify
O b s e rvat ion
D at a
Sta nda rd s ;
P re pa re
O b s e rva tio ns
;
Sp e c ify
D a ta s e t
D at a
Sta nda rd s ;
P re pa re
3
DEVIC E
Da ta bas e
Engine
---
M ainta in
O bservations;
M ainta in
Da tase ts;
Re trie ve
Data sets
5
D E VIC E
B uo y
T ra nsm itte r
---
Se nd D a t a
1 0
D E VIC E
Buo y
Se nso rs
---
Se ns e
O b s e rvab le s
6
N O DE
B uoy
P ro cesso r
---
M e as ure m e nt
P roces s o r
---
Ga t he r
M e as urem e nts ;
Pa c ka g e D at a
8
N O D E
C o ntro lle r
W o rksta tio n
---
Co ntrol P a n el,
B row s e r
---
Ge ne ra t e
Co m m a n ds
1
D E V IC E
A rgo s
Syste m
---
Re la y
Com m and s ;
Re la y Da ta
2
D E VIC E
B uo y
R e ce ive r
---
Re c e ive
Com m a nds
4
D E VIC E
U se r
W o rksta tion
---
Lo cal A rea
N e tw o rk;
B ro w s e r;
Em a il Client
2 0
F u lfillm en t Tech n ician
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.
− 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.
104

121. A. Relating IDEF Methods to OOASIS Information Needs
• 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:
NWS Data Center
I1
Oc e an O bse rv able s
O 1
M e a sure d O bserv a ble s
M 3 W e at he r F ore c as t e rProduct Engineer
NO D E
M ail
C om poser
---
Specify E m ail
Produ ct;
Con s tru ct
E m ail Produ ct
M es s age
18
D E VIC E
Email S erv er
---
E m ail Produ ct
M es s age
19
N O D E
P roduct
W ebsite
---
Select Web
Produ cts ;
Pu blis h Page
16
D EV IC E
W e b S erv er
---
Serve
Page
17
N O D E
P roduction
S erv er
---
Stage R eady
Produ cts
14
D EV IC E
L ocal Area
N etw ork
---
Provide Produ ct
Acces s
15
NO D E
F ulfillment
W orkstation
---
O rd e r De s k:
Re q u e s t
L o g g e r; O rd e r
Lo g g e r
---
Collect
Requ es ts ;
Order Produ cts
13
NO DE
F o re c a s te r
W o rks ta tio n
- - -
W e at he r
V ie w e r
- - -
Wr it e
We at he r
Sc ript
10
NO DE
W e a the r
M a c hine
- - -
Run W e at he r
M ode ls
8
NO DE
Im a ge
M a c hine
- - -
Image
Ge ne rat or;
Image
P roc e ssor
- - -
Ge ne r at e
Sy m bolic
Im age s;
Com bine
Im age s
12
Data Engineer
N O D E
P roduct
M achine
-- -
P ro d u ct
P ro ce s s o r;
Filte r E n g in e
---
Sp e cify
P ro d u cts ;
P a cka g e
Da ta s e ts ;
Filte r
Da ta s e ts
6
N O D E
D ata
M achine
-- -
O b s e rva tio n
P ro ce s s o r;
Da ta s e t
P ro ce s s o r
---
Specify
Obs ervation
D ata
Stan dards ;
Prepare
Obs ervation s ;
Specify
D atas et D ata
Stan dards ;
Prepare
D atas ets
2
D EV IC E
D atabase
Engine
---
M ain tain
Obs ervation s ;
M ain tain
D atas ets ;
Retrieve
D atas ets
4
Buoy
DE V ICE
B uo y
Tra ns m itte r
- - -
Se nd Dat a
11
DE V IC E
B u o y
Se n s o rs
- - -
Se ns e
O bse r v able s
7
NO DE
B uo y
Pro c e s s o r
- - -
M e a sure me nt
Proc e sso r
- - -
Gat he r
M e a sure m e nt s;
Pac kage Dat a
9
NO DE
C o ntro lle r
W o rks ta tio n
- - -
Cont ro l Pane l,
Brow se r
- - -
Ge ne rat e
Com m ands
1
DE V IC E
A rg o s
Sy s t e m
- - -
Re lay
Com m ands;
Re lay Dat a
3
DE V IC E
B u o y
Re c e iv e r
- - -
Re c e iv e
Com m ands
5
DE VIC E
Us e r
W o rks ta tio n
- - -
Loc al A re a
Ne t w ork;
Brow se r;
Email Clie nt
20
Fulfillment TechnicianSystem Controller
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

122. A. Relating IDEF Methods to OOASIS Information Needs
Used at: Context:
Title: Number:
Author:
Project:
Notes: 1 2 3 4 5 6 7 8 9 10
Date:
Rev:
Working
Draft
Recommended
Publication
Reader Date
P.
Model: OOASIS NDC B (ONB)
Page:
OOASIS SE
AKBocast
A0A0A0A0
AKB9 6
x01/10/2002
Generate Routing ProductsA2
I 1
Ocean Ob ervations
C 1 Prod uct R eq uests
O1
R outin g Prod ucts
O2
A ctivity S tatus
Ge ne ra te
Da ta s e ts
1
Filte r
Data s e ts
2
P ro po s e
Itine rarie s
3
Unfiltered D atasets
Filtered Datasets
D ataset R eq ues ts
M 1 R oute Planner
M 2 S anta N arid a B uoy S ystem
Processing Engines
Datab ase Eng ine Filter P rocessor
B row ser
W eb S erver
I tinerary E n g in e
D atab ase A d m inistrato r
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

123. A. Relating IDEF Methods to OOASIS Information Needs
C 1 Prod u ct R eq u ests
O2
A ctivity S tatu s
Ge ne ra te
Da ta s e ts
1 Filte r
D a ta s e ts
2
DE V IC E
W eb Se rve r
---
P ro pos e
I tine ra rie s
4
D ataset R eq u ests
M 1 R ou te Plan n er
M 2 S an ta N arid a B u oy S ystem
D atab ase A d m in istrato r
NO D E
Itine ra ry
E ngine
---
P ro pos e
I tine ra rie s
3
Un filtered D atasets
Filtered D atasets
Processin g E n g in e
D atab ase E n g in e
Filter E n g ine
Routing Products
Ocean Obervations
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:
I 1
O cean O b ervation s
C 1 Prod u ct R eq u ests
O1
R ou tin g Prod u cts
O2
A ctivity S tatu s
Ge ne ra te
Da ta s e t s
1 Filte r
Da ta s e ts
2
D E V IC E
W e b Se rve r
---
P ro p o s e
I tine ra rie s
4
D ataset R eq u ests
M 1 R ou te Plan n erM 2 S an ta N arid a B u oy S ystem
D atab ase A d m in istrator
N O D E
Itine ra ry
E ng in e
---
P ro p o s e
I tine ra rie s
3
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

124. A. Relating IDEF Methods to OOASIS Information Needs
O3
M in isterial R ep orts
O 4
R ou tin g Prod u cts
O1
S ystem S tatu s
C4 Prod u ct R eq u ests
C 3 M in isterial R eq u ests
C 1 M ain ten an ce N otification
M easu re
Ocean
Ob servab les
1
NO D E
Adm inistra to r
W o rksta tio n
---
Sys te m Sta tus
Re po rte r;
Sys te m
P e rfo rm a nce
Re po rte r
---
Re port Sys te m
3
B uoy S tatu s
A ctivity S tatu s
M 2 R ou te Plan n er
A d m in istrator
G e ne ra te
Da ta s e ts
5 Filte r
D a ta s e ts
6
D E VIC E
W e b Se rve r
---
P ro po s e
I tine ra rie s
7
D ataset R eq u ests
D atab ase A d m in istrator
N O D E
Itine ra ry
E ngin e
---
P ropo s e
I tine ra rie s
4
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

125. A. Relating IDEF Methods to OOASIS Information Needs
NWS Data Center
I1
Ocean Ob servab les
O3
Measured Ob servab les
M3 W eath er ForecasterProd u ct E ng in eer
N O D E
M ail
C om p o se r
---
Specify E m ail
Prod uct;
Cons truct
Em ail Pro duct
M es sage
18
D E V IC E
E m ail S e rv er
---
Em ail P roduct
M e ssage
1 9
NO D E
P rodu ct
W ebsite
---
Select W eb
Product s;
Publish P age
1 6
D EVIC E
W eb S erv er
---
Serve
Page
1 7
NO D E
Pro duction
S erv er
---
Stage Ready
Products
14
D E VIC E
Loca l A rea
Ne twork
---
Provide Product
Access
1 5
NO D E
F ulfillm ent
W ork station
---
O rder Desk:
Request
Lo gger; O rder
Lo gger
---
Collect
Requests;
O rder Products
13
NO D E
Fore ca ste r
W orksta tio n
---
W e a the r
Vie w e r
---
W rite
W e a the r
Sc ript
10
NO D E
W e a the r
M a chine
---
R un W e a th e r
Mo de ls
8
NO D E
Im a ge
Ma chine
---
Im a ge
Gene ra t o r;
Im a ge
P ro ce ss o r
---
Ge n e ra te
Symb o lic
Im a ge s ;
Co mbine
I m a ge s
1 2
D ata E ng ineer
NO D E
Pro duct
M achine
---
Pro duct
Pro cesso r;
F ilter Engine
---
S pecify
Pro ducts;
Package
Datasets;
F ilter Datasets
6
NO D E
D ata
M achine
---
O bservatio n
Pro cesso r;
Dataset
Pro cesso r
---
S pecify
O bservation
Data
Standards;
Prepare
O bservations;
S pecify
Dataset Data
Standards;
Prepare
Datasets
2
DE VIC E
D ataba se
Engine
---
M aintain
O bservations;
M aintain
Datasets;
Retrieve
Datasets
4
Buoy
D EVIC E
Buo y
T ra nsmitte r
---
Se nd D a ta
11
D E VIC E
B uoy
Se nsors
---
Se ns e
O bse rva ble s
7
NO D E
B uoy
P roce ssor
---
Me a s ure m e nt
P ro ce s so r
---
Ga t he r
Me a s ure me nts ,
P a c ka g e Da t a
9
NO D E
C ontrolle r
W o rksta tio n
---
C o ntro l P a ne l,
B ro w se r
---
Ge ne ra te
C o m ma n ds
1
D EV IC E
Sa te llite
C o m ms
---
A rg o s
Sys te m
---
R e la y
C o m ma n ds,
R e la y D a ta
3
D EV IC E
B uo y
R e ce ive r
---
R e c e ive
C o mm a nds
5
D E V IC E
U se r
W or ksta tion
---
Lo ca l Are a
N e tw o rk;
B ro w s e r;
Em a il C lie nt
2 0
Fu lfillm en t Techn icianS ystem C ontroller
Route Plann er
NO D E
Itine ra ry
Engine
---
P ro po s e
I tine ra rie s
30
NO D E
Ad m inistra tor
W orksta tion
---
Sys te m Sta t us
Re po rte r; Sys te m
P e rfo rm a nce
R e po rte r
---
R e po rt Sys te m
St a tus ; Re p o rt
Syst e m
Ac c o mp lis hme n ts
31
D atab ase A d m inistrator
O1
S ystem S tatus R ep orts
O2
M ini sterial R ep orts
A d m inistrator
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

126. A. Relating IDEF Methods to OOASIS Information Needs
• The Data Machine, Product Machine, and Production Server into the Product Data Machine.
NWS Data Center
I1
Ocean O b servab les
O 3
M easu red Ob servab les
D EV IC E
Em a il
Se rve r
19
D E V IC E
W e b Se rve r
1 7
D E VIC E
Are a
Ne tw ork
1 5
NO D E
F ore ca ste r
W o rksta tion
1 0
N O D E
W e a the r
M a chine
8
NO D E
Im a g e
P roce ss ing
M a chin e
1 2
N O D E
P ro duct
D a ta
M a chine
6
D E V IC E
D a ta ba se
Eng ine
4
Buoy
D EV IC E
B uoy
T ra nsm itte r
1 1
D EV IC E
B uoy
Se nsors
7 NOD E
B uo y
P roce ssor
9
N O D E
S ys tem
W o rksta tio n
1
D EV ICE
Sa te llite
C om ms
3
D EV IC E
B uoy
R e ce iv e r
5
DEVIC E
R e m ot e
Use r
W orksta tion
2 0
R ou te Plan n er
NO DE
W e b
S erv ices
M achine
30
O 1
S ystem S tatu s R ep orts
O 2
M in isterial R ep orts
A d m in istrator
DEVIC E
Ne tw ork
U se r
W orkstation
2
W eath er Forecaster
In stitu te S cien tist
W eath er Presen ter
Tsunam i Center
N O A A (B u oy M ain ten an ce)
E n viron m en t
S ystem C on troller
Fu lfillm en t Tech n ician
A rg u s S ystem
Figure 30. Second NDC Information Integration
We refrained from coalescing the weather forecaster’s 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

127. A. Relating IDEF Methods to OOASIS Information Needs
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.
Buoy
Transmitter
Buoy Receiver Buoy
Processor
Buoy Sensors
Satellite
Communication
Database
Engine
Web Server
Remote User
Workstation
Area Network
Email Server
Network User
Workstation
System
Workstation
Product Data
Machine
Forecaster
Workstation
Image
Processing
Web Services
Machine
Weather
Machine
Environment
Argos System Internet
System
Administrator
System
Controller
Fulfillment
Technician
Tsunami
Warning Center
Shipping Route
Planner
NOAA
Maintenance
Weather
Presenter
Institute
Scientist
Weather
Forecaster
5-10 sensors
on each buoy
plans are for
1000 buoys
Figure 31. OOASIS NDC Diagram
A.2 RESULTS OF THIS METHOD
A.2.1 STAKEHOLDERS
We have identified eight external stakeholders and four internal stakeholders. For each external
stakeholder we have identified:
111

128. A. Relating IDEF Methods to OOASIS Information Needs
• 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

129. A. Relating IDEF Methods to OOASIS Information Needs
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: C O NTEXT:
PAGE: TITLE: NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9
DATE
REV
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER DATEAKBocast
OOASIS SE
P.
M ODEL: OOASIS Context Diagram (OCD)
To p
AKB1 1
x12/27/2001
Context of Meteorology Product GenerationA-0
G en erate Meteo ro lo g y Pro d ucts
0
Produc t Re que st s
M inist e rial Re que st s
M aint e nanc e Not ific at ion
Rout e Pla nning Re quire me nt s
Communic at ions Prot oc ols
A rgos S y st e m
Sant a Narida Buoy S y st em
Rout e Planne r
Oc e an O b se rv able s
Rout ing Produc t s
M e asured Obse rv able s
M inist e rial Re port s
Sy st em St at us
Sat ellit e Im ag er y
Met eorology Produc t s
M e t eorology Dat a Re quirement s
Sc he dule s
Image St andards
M e t e orology Dat a S t andards
Nat ional W e at he r S erv ic e
W e at he r F ore c ast e r
x
x
x
x
x
x
x
TOP
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

130. A. Relating IDEF Methods to OOASIS Information Needs
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:
Tsunami Warning
Center
Institute Scientist
Post Products Email Products
Weather
Broadcaster
Fulfillment
Technician
Weather
Forecaster
Stage Products
<<extend>> <<extend>>
Run Weather Models
Database
Administrator
Product Engineer
System Controller Argos System
Maintain Meteorological Data
<<depend>>
<<depend>>
Route Planner
Propose Itineraries
<<depend>>
System
Administrator
Generate Reports
<<depend>>
Measure Ocean Observables
<<depend>>
Environment
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

131. A. Relating IDEF Methods to OOASIS Information Needs
Buoy
Transmitter
Buoy Receiver Buoy
Processor
Buoy Sensors
Satellite
Communication
Database
Engine
Web Server
Remote User
Workstation
Area Network
Email Server
Network User
Workstation
System
Workstation
Product Data
Machine
Forecaster
Workstation
Image
Processing
Web Services
Machine
Weather
Machine
Environment
Argos System Internet
System
Administrator
System
Controller
Fulfillment
Technician
Tsunami
Warning Center
Shipping Route
Planner
NOAA
Maintenance
Weather
Presenter
Institute
Scientist
Weather
Forecaster
5-10 sensors
on each buoy
plans are for
1000 buoys
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

132. A. Relating IDEF Methods to OOASIS Information Needs
This page intentionally left blank.
116

133. 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
Narida’s 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

134. 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
nation’s 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 President—while the elected president Tomas Maria
Escobar was in hospital in Los Angeles in the United States for surgery—learned 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 country’s 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 today’s 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 WMO’s 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

135. B. Santa Narida Backstory
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 NOAA’s 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 nation’s 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
Watch’s (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 Service’s 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

136. B. Santa Narida Backstory
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 Watch’s 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 Narida’s 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, NOAA’s 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 NDBC’s specialized buoy maintenance ship, and other
scientific vessels as part of Santa Narida’s 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

137. B. Santa Narida Backstory
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 Munoz—the 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 world’s 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

138. B. Santa Narida Backstory
This page intentionally left blank.
122

139. 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 to-
be-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

140. 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

141. 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

142. 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 10-
minute segment.
126

143. D. National Data Buoy Center
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(A-
ALPHA1)+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.0-
ARCTAN(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 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.
D.7 MARSH-MCBIRNEY CURRENT MEASUREMENTS
DIR Direction the current is flowing TOWARDS, measured in degrees clockwise from North.
SPD Current speed in cm/s.
127

144. D. National Data Buoy Center
This page intentionally left blank.
128

145. 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.1-
1998 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 - the abbreviated name of the model containing the box (optional)
activity - the node number of the activated activity
rule - 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 See SUB/D32.
E.2 CONDITIONAL EXPRESSIONS
These comments apply to both precondition and postcondition expressions.
7
David Marca and Clement McGowan. SADT: Structured Analysis and Design Technique. New York NY:
McGraw-Hill Book Company. 1988.
129

146. 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 code’s 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.
• 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.
130

147. E. Applying SADT Activation Rules to IDEF0 Activity Analysis
• 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

148. E. Applying SADT Activation Rules to IDEF0 Activity Analysis
• 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:
• 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:
132

149. E. Applying SADT Activation Rules to IDEF0 Activity Analysis
A sse m ble
T a ble
2
table
blueprint
table top
table legs
It would be silly to write:
A2*1 : C1 and I1 and I2 → O1 and ~I1 and ~I2
However, in this case:
1
spark
fuel
cold air
hot air
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
R5*1 : C2 and I4 → O1 and O2
R5*1 : C3 and I1 → O1 and O2
R5*1 : C3 and I4 → O1 and O2
• Consider this activation rule:
133

150. E. Applying SADT Activation Rules to IDEF0 Activity Analysis
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:
Activation Rules:
1 : C1 and I1 --> O1
2 : C1 and I1 and I2 --> O2
3 : C1 and I1 and I2 and I3 --> O3
4 : C1 and I1 and I2 and I3 and I4 --> O4
B u ild
B u rger
1
order
h am bu rger patty
ch eesebu rger
dressed h am bu rger
plain h am bu rger
ch eese
con dim en ts
m eat
bu n
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 won’t 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

151. E. Applying SADT Activation Rules to IDEF0 Activity Analysis
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
I C O full rules short rules comments
L L L 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
3 : C3 and I2 and I3 → O3
4 : C4 and I2 and I3 and I4 → O4
same levels of abstraction
L L H 1 : C1 and I1 → O1
2 : C2 and I1 and I2 → O1
3 : C3 and I1 and I2 and I3 → O1
4 : C4 and I1 and I2 and I3 and I4 → O1
1 : C1 → O1
2 : C2 and I2 → O1
3 : C3 and I2 and I3 → O1
4 : C4 and I2 and I3 and I4 → O1
comments required;
understanding rule
requires decomposition
diagram
L H L 1 : C1 and I1 → O1
2 : C1 and I1 and I2 → O2
3 : C1 and I1 and I2 and I3 → O3
4 : C1 and I1 and I2 and I3 and I4→ O4
1 : → O1
2 : I2 → O2
3 : I2 and I3 → O3
4 : I2 and I3 and I4→ O4
precedence puzzles;
precondition anomaly
L H H 1 : C1 and I1 → O1
2 : C1 and I1 and I2 → O1
3 : C1 and I1 and I2 and I3 → O1
4 : C1 and I1 and I2 and I3 and I4 → 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
requires decomposition
diagram
H L L 1 : C1 and I1 → O1
2 : C2 and I1 → O2
3 : C3 and I1 → O3
4 : C4 and I1 → O4
1 : C1 → O1
2 : C2 → O2
3 : C3 → O3
4 : C4 → O4
this is OK, I think; I’m not
quite sure why the
difference in levels of
abstraction doesn’t appear
to pose a problem here…
H L H 1 : C1 and I1 → O1
2 : C2 and I1 → O1
3 : C3 and I1 → O1
4 : C4 and I1 → O1
1 : C1 or C2 or C3 or C4 → O1 different ways of doing or
triggering the same thing;
possibility of “ladder”
decomposition diagram
H H L 1 : C1 and I1 → O1
2 : C1 and I1 → O2
3 : C1 and I1 → O3
4 : C1 and I1 → O4
1 : C1 and I1 → O1 or O2 or O3 or O4 rule reveals no information;
understanding rule
requires decomposition
diagram
H H H 1 : C1 and I1 → O1 default IDEF0 rule; same
levels of abstraction; rule
does not need to be
expressed
E.6 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

152. E. Applying SADT Activation Rules to IDEF0 Activity Analysis
A ssem b le
Tab le
1
Blueprint
Schedule
Table Legs
Table Top
Parts Request
Production Status
Table
3
Activation rules for A421:
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.
A ssem b le
Tab le
1
Blueprint
Schedule
Table Legs
Table Top
Parts Request
Production Status
Table
3
See A42T2 for
activation rules.
C arp en ter
In this example, the model note directs the reader to the second text page accompanying diagram page
A42.
E.7 REVISITING MARCA AND MCGOWAN’S EXAMPLE
Marca and McGowan provide this example to illustrate activation rules:
136

153. E. Applying SADT Activation Rules to IDEF0 Activity Analysis
Ev aluate
Job
Progre ss
1
Job plans
Job Status
Finished or Unfinished Job
Next Job Order Step
Unfinished Jobs
Unfinished Jobs
Job Status
Finished or Unfinished Job
Next Job Order Step
Job
Plans
Figure 19-3 An Activity with Several Activation Rules
Marca & McGowan, SADT, page 126.
21*1: I1 and C1 O3 (Job start.)
21*2: I1 and C1 O2 and O3 (Next job step.)
21*3: I1 and C1 O2 (Inspection time.)
21*4: I1 and C1 O1 (Status request.)
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 job start
A21*2 : C1 and I1 → O2 and O3 next job step
A21*3 : ~C1 and I1 → O2 inspection time
A21*4 : C1 and I1 → O1 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. I1 and C1
2. I1 and ~C1
3. ~I1 and C1
4. ~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

154. E. Applying SADT Activation Rules to IDEF0 Activity Analysis
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

155. 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

156. List of Abbreviations and Acronyms
140
This page intentionally left blank.