armstrong bocast integration of systems engineering and software development 2003-libre

The Integration of Systems

Engineering and Software

Development

Based on the

Object-Oriented Approach to Software Intensive Systems

SPC-2003041-CMC

Version 01.00

April 2003

The Integration of Systems

Engineering and Software

Development Based on the

Object-Oriented Approach to Software Intensive Systems

SPC-2003041-CMC

Version 01.00

April 2003

Jim Armstrong

Alex Bocast

SOFTWARE PRODUCTIVITY CONSORTIUM

SPC Building

2214 Rock Hill Road

Herndon, Virginia 20170-4227

Copyright © 2003, Software Productivity Consortium NFP, Inc. Permission to use, copy, and distribute this material for any

purpose and without fee is hereby granted consistent with 48 CFR 227 and 252, and provided that the above copyright notice

appears in all copies and that both this copyright notice and this permission notice appear in supporting documentation. This

material is based in part upon work sponsored by the Advanced Research Projects Agency under Grant #MDA972-96-1-0005.

The content does not necessarily reflect the position or the policy of the U.S. Government, and no official endorsement should be

inferred. The name Software Productivity Consortium NFP, Inc. shall not be used in advertising or publicity pertaining to this

material or otherwise without the prior written permission of Software Productivity Consortium, NFP, Inc. SOFTWARE

PRODUCTIVITY CONSORTIUM NFP, INC. MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE

SUITABILITY OF THIS MATERIAL FOR ANY PURPOSE OR ABOUT ANY OTHER MATTER, AND THIS MATERIAL

IS PROVIDED WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND.

CONTENTS

ACKNOWLEDGMENTS .......................................................................................................... IX

EXECUTIVE SUMMARY ........................................................................................................ XI

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

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

FIGURES AND DIAGRAMS

Figure 1. OOASIS Model of System and Software Interaction.................................................................... 3

Figure 2. OOASIS Software Development Flow.......................................................................................... 6

Table 1. Systems Engineering/Software Interactions ................................................................................. 10

Figure 3. Top-Level Interactions ................................................................................................................ 14

Figure 4. Mid-Level Interactions ................................................................................................................ 17

Diagram 1. SWM/A0 (Present Weather) .................................................................................................... 28

Diagram 2. STW/A0 (Produce Tsunami Warnings) ................................................................................... 29

Diagram 3. SIS/A0 (Research Ocean Weather Phenomena) ...................................................................... 29

Diagram 4. SRP/A0 (Plan Ship Itinerary)................................................................................................... 30

Diagram 5. SWF/A0 (Forecast Weather).................................................................................................... 31

Diagram 6. SNW/A0 (Increase Puerta Oveida Market Share).................................................................... 31

Diagram 7. SSP/A0 (Deliver Data)............................................................................................................. 32

Diagram 8. SNM/A0 (Maintain Buoys)...................................................................................................... 32

Diagram 9. RTP/A-1=AKB5.1 for Weather Media Stakeholder ................................................................ 37

Diagram 10. RTP/A-1=AKB5.2, Adding Environment Stakeholder ......................................................... 38

Diagram 11. RTP/FEO1: Parallel Decomposition Fragment...................................................................... 39

Diagram 12. RTP/A-1=AKB5.3, Adding GOOS Satellite System............................................................. 40

Diagram 13. RTP/FEO2, Ocean Observation Fragment............................................................................. 40

Diagram 14. RTP/A-1=AKB5.4, Adding Tsunami Warning System......................................................... 41

Diagram 15. RTP/A-1=AKB5.5, Adding National Weather Service ......................................................... 42

Diagram 16. RTP/A-1=AKB5.6, Adding Institute Scientist....................................................................... 43

Diagram 17. RTP/A-1=AKB5.7, Additional Clarification of Behaviors.................................................... 44

Diagram 18. RTP/FEO3, Relating Observing to Forecasting..................................................................... 45

Diagram 19. RTP/FEO5, Environmental Exchange Example .................................................................... 46

Diagram 20. RTO/A-1=AKB5, Operations Stakeholders........................................................................... 47

Figures and Diagrams

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

Diagram 22. RTT/A-1, Training Stakeholder ............................................................................................. 49

Diagram 23. RTP/A-1 (Stakeholder Context of Meteorological Product Generation)............................... 50

Diagram 24. RTP/A-0 (Context of Meteorological Product Generation)................................................... 51

Diagram 25. RTP/A0 (Generate Meteorological Products) ........................................................................ 53

Diagram 26. RTP/A1 (Measure Ocean Weather Characteristics)............................................................... 54

Diagram 27. RTP/A11 (Control Data Collection) ...................................................................................... 55

Diagram 28. RPT/A12 (Measure Observables) .......................................................................................... 55

Diagram 29. RTP/A13 (Transmit Collected Data) ..................................................................................... 56

Diagram 30. RTP/A2 (Provide Datasets).................................................................................................... 57

Diagram 31. RTP/A4 (Forecast Weather)................................................................................................... 58

Diagram 32. ATP/A-1 (Stakeholder Context of Meteorological Product Generation)............................... 59

Diagram 33. ATP/A-1 (Context of Meteorological Product Generation)................................................... 60

Diagram 34. ATP/A0 (Generate Meteorological Products)........................................................................ 61

Diagram 35. ATP/A1 (Measure Ocean Observables)................................................................................. 62

Diagram 36. ATP/A11 (Control Data Collection) ...................................................................................... 63

Diagram 37. ATP/A12 (Measure Observables) .......................................................................................... 63

Diagram 38. ATP/A13 ( Transmit Collected Data) .................................................................................... 64

Diagram 39. ATP/A2 (Generate Meteorology Products) ........................................................................... 65

Diagram 40. ATP/A21 (Generate Datasets)................................................................................................ 66

Diagram 41. ATP/A211 (Save Observations)............................................................................................. 67

Diagram 42. ATP/A212 (Create Datasets).................................................................................................. 68

Diagram 43. ATP/A213 (Retrieve Datasets) .............................................................................................. 69

Diagram 44. ATP/A23 (Forecast Weather) ................................................................................................ 69

Diagram 45. ATP/A3 (Distribute Products) ............................................................................................... 70

Diagram 46. ATP/A31 (Fulfill Orders)....................................................................................................... 71

Diagram 47. ATP/A32 (Stage Products)..................................................................................................... 72

Diagram 48. ATP/A33 (Post Products)....................................................................................................... 72

Diagram 49. ATP/A34 (Email Products) .................................................................................................... 73

Diagram 50. ATP/A0 (Generate Meteorological Products) with System Agents....................................... 74

Diagram 51. ATP/A11 (Control Data Collection) with System Controller ................................................ 75

vi


Diagram 52. ATP/A13 (Transmit Collected Data) with System Controller ............................................... 76

Diagram 53. ATP/A211 (Save Observations) with Data Engineer............................................................. 76

Diagram 54. ATP/A212 (Create Datasets) with Data Engineer.................................................................. 77

Diagram 55. ATP/A213 (Retrieve Datasets) with Product Engineer.......................................................... 77

Diagram 56. ATP/A3 (Distribute Product) with Fulfillment Technician ................................................... 78

Diagram 57. RTO/A-1 (Stakeholder Context of Routing Product Generation).......................................... 79

Diagram 58. RTO/A-0 (Context of Routing Product Generation).............................................................. 80

Diagram 59. RTO/A0 (Generate Routing Products)................................................................................... 81

Diagram 60. RTO/A2 (Generate Routing Products)................................................................................... 82

Diagram 61. RTO/A23 (Propose Itineraries) .............................................................................................. 83

Diagram 62. ATO/A-0 (Context of Routing Product Generation) ............................................................. 83

Diagram 63. ATO/A0 (Generating Routing Products) ............................................................................... 84

Diagram 64. ATO/A2 (Generating Routing Products) ............................................................................... 85

Diagram 65. ATO/A23 (Propose Itineraries).............................................................................................. 85

Diagram 66. ATO/A0=AKB11 (Generate Routing Products) .................................................................... 86

Diagram 67. ATO/A2=AKB9 (Generate Routing Products) ...................................................................... 87

Figure 5. Conventions for Marking Activities WRT Use Cases................................................................. 88

Diagram 68. ASU/A0 (Generate Meteorological Products) ....................................................................... 89

Figure 6. Use Case Analysis: Measure Ocean Observables........................................................................ 89

Diagram 69. OSU/A0=AKB24 (Generate Meteorological Products)......................................................... 90

Figure 7. Use Case Analysis: Run Weather Models ................................................................................... 90

Diagram 70. OSU/A3=AKB26 (Distribute Products) ................................................................................ 91

Diagram 71. OSU/A0=AKB25 (Generate Meteorological Products)......................................................... 92

Figure 8. Use Case Analysis: Stage Products ............................................................................................. 93

Figure 9. Use Cases Analysis: Maintain Meteorological Data ................................................................... 94

Diagram 72. OSC/A2 (Generate Routing Products) ................................................................................... 94

Figure 10. Use Case Analysis: Propose Itineraries ..................................................................................... 95

Diagram 73. OSC/A0 (Generate Routing Products), Final Markup ........................................................... 96

Figure 11. OOASIS System Use Case Diagram ......................................................................................... 97

Figure 12. First NDC Transform on ONA/A11.......................................................................................... 98

Figure 13. Second NDC Transformation on ONA/A11.............................................................................. 99

vii


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

Figure 15. Second NDC Transformation on ONA/A1.............................................................................. 100

Figure 16. Third NDC Transformation on ONA/A1 ................................................................................ 100

Figure 17. First NDC Transformation on ANA/A21 ................................................................................ 101

Figure 18. Second NDC Transformation on ONA/A21............................................................................ 101

Figure 19. First NDC Transformation of ANO/A23................................................................................. 102

Figure 20. First NDC Transformation of ONA/A2................................................................................... 102

Figure 21. Second NDC Transformation of ONA/A2 .............................................................................. 103

Figure 22. First DNC Transformation of ONA/A3................................................................................... 103

Figure 23. First NDC Transformation for ONA/A0 ................................................................................. 104

Figure 24. Final NDC Transformation for ONA/A0 ................................................................................ 105

Figure 25. First NDC Transformation of ONB/A2................................................................................... 106

Figure 26. Second NDC Transformation for ONB/A2 ............................................................................. 107

Figure 27. Third NDC Transformation for ONB/A2................................................................................ 107

Figure 28. First NDC Transformation for ONB/A0.................................................................................. 108

Figure 29. First NDC Information Integration.......................................................................................... 109

Figure 30. Second NDC Information Integration ..................................................................................... 110

Figure 31. OOASIS NDC Diagram .......................................................................................................... 111

Diagram 74. OCD/A-0 (Context of Meteorological Product Generation)................................................ 113

Figure 32. OOASIS System Use Case Diagram for Buoy Case Study..................................................... 114

Figure 33. OOASIS NDC Diagram for Buoy Case Study ........................................................................ 115

viii

ACKNOWLEDGMENTS

The authors wish to thank those who contributed to this report. Many hours have been spent discussing

technical points to reach resolution on several significant areas of issue between the systems engineering

and software development communities.

• Contributors and Internal Reviewers: Sarah Sheard, Rich McCabe, and Mike Polen

• External Reviewers: Dr. Ralph Freeman

Acknowledgments

This page intentionally left blank.

x

EXECUTIVE SUMMARY

Current systems engineering and software development methods have been separately created with little

regard to their interfaces. This report takes an initial look at this interface. It identifies many of the critical

aspects of the interface and proposes ways in which they may be addressed.

The report addresses the systems engineering and software development interface in general terms that

are believed to be applicable to all software development. However, specific examples and discussion

address object-oriented software development that uses Unified Modeling Language (UML). Since UML

does not specify a method, the report is based on the Object-Oriented Approach to Software-Intensive

Systems (OOASIS) method. OOASIS provides practice level guidance for application of UML with

specific steps and decisions identified. The report identifies the systems engineering activities that provide

information to the OOASIS activities or uses information from them. It also identifies guidance for

interaction between the activities on both sides of the interface to avoid some of the most critical

problems.

The report does not fully define all interface issues nor does it define the details of a method for

performing both disciplines across the interface. Also, the treatment covers those requirements that relate

to the behavior of the systems and the software. Not addressed are those systems requirements that affect

other areas of performance such as reliability, safety, survivability, etc. Some examples of systems

engineering studies that are beyond the scope of UML related methods are given but their interface

mechanisms are not fully developed. These areas should be the subject of further study.

Key points of this report are:

• Systems engineering and software development techniques have been developed to address

different specific issues and concerns. However, they do overlap and the overlap increases as the

proportion of software content increases.

• Information that is common to both areas must be identified and properly exchanged.

• Systems engineering and software development should be conducted in parallel and integrated.

Doing them sequentially in an over-the-wall manner generates severe problems.

Executive Summary


xii

1. INTRODUCTION

1.1 SCOPE

This report addresses the need for and nature of the interface between systems engineering and software

development. While providing guidance of a general nature that is applicable to any software

development method, it uses the specific examples of object-oriented development as defined in the

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

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

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

tim

e

System

Requirements

Analysis

System Design

Physical Architecture

Software Architecture

tim

e

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

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


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


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


2.3.1.1 Define System Requirements

The first activity is translating broad, top-level conceptions of system goals and use into specific

behavioral requirements, elicited and captured via use cases. This includes explicitly noting volatilities

due to unresolved requirement choices or other alternate conceptions of the system, and incorporating

these into System Use Cases. This effort relies on broader needs analyses and studies that have resulted in

a system concept and scope sufficient to begin software definition.

2.3.1.1.1 Capture System Behavioral Requirements

This task either receives the top-level requirements definition as a Summary Use Case or creates it if not

available. The Summary Use Cases are then translated into a prioritized set of system requirements

expressed as System Use Cases. The structuring of requirements into use cases is intended to:

• Present requirements in a way that is easy for users, customers, and other stakeholders to

understand and review

• Decompose the problem into more manageable pieces

• Organize the requirements into a more structured form

• Avoid unnecessarily constraining the System Software Architecture

The decomposition of requirements by use case is done from the stakeholders' perspective. Each use case

provides a focus on closely related requirements. As a result, multiple analysts may concurrently

elaborate different use cases.

2.3.1.2 Define System Software Architecture

As the requirements are defined, the software developer will create a preliminary System Software

Architecture based on the design constraints implied by the system behavioral requirements. Software

functionality is decomposed into static elements (a class hierarchy) and their dynamic (runtime)

interaction defined. Initially, orient this decomposition by designing in flexibility, especially to address

volatilities enumerated in the System Use Cases. Define an initial deployment for the objects in the

software architecture across the system's physical architecture using the Node-Device-Connector (NDC)

Diagram (Appendix C.) making adjustments and additions to the software architecture as necessary.

Identify additional failure scenarios in Elaborated System Use Cases by analyzing how elements of this

combined hardware and deployed software architecture interact to support the System Use Cases. Adjust

the software architecture and its deployment for performance and other concerns (such as commercial and

legacy software to be incorporated into the system, as enumerated in the OTS Software Components) and

include additional details visible at the system level of the architecture.

2.3.1.2.1 Realize System Use Cases

At this point in OOASIS behavioral requirements are captured as System Use Cases. It is now necessary

to make explicit the essential design implications or constraints inherent in the System Use Cases. This

will yield an OO System Software Architecture. The goal of this activity is to take the first step toward

that objective: for each System Use Case, define classes representing the important abstractions in the

problem environment (static model). Then combine these static models for each use case into one

comprehensive static architecture. Finally, define the interactions among these objects for each use case

7


(dynamic architecture). Together, the static and dynamic system designs make up the initial System

Software Architecture.

2.3.1.2.2 Define System Software Allocation

Allocate the classes to significant nodes for runtime deployment. This task may identify necessary

modifications to the existing software architecture. Further adjustments may be necessary to address

performance concerns. Also, add (and determine the deployment for) other supporting classes (e.g.,

device interface classes).

2.3.1.2.3 Elaborate System Use Cases

Having decided what objects to deploy on which system Nodes, enough decisions have been made about

the internal system design to elaborate the System Use Cases. Significant nodes and devices from the

NDC Diagram become participants in performing the System Use Cases. With this white box approach to

the system, you can further usage details added and more failure conditions and use case alternate courses

discovered.

2.3.1.2.4 Elaborate System Software Architecture

Based on the insight provided by the Elaborated System Use Cases, the System Software Architecture can

now be completed. This should account for possible failure conditions across all system usage scenarios.

What remains is to add details about class operations and relationships. It is also appropriate to estimate

timing budgets for nodes and operations involved in performance-sensitive usage scenarios.

2.3.1.3 Design Node Software

With classes and their interactions well defined and objects having been deployed among the significant

nodes, this stage of OOASIS concentrates on the interactions of objects within a given (type of) node and

can proceed independently for different nodes. First, define the concurrency within each node. Finally,

create Class State charts for classes having complex state behavior.

2.3.1.3.1 Define Concurrency

This OOASIS task is optional and may be tailored out when no performance or reliability requirements

challenge the system design. In this part of OOASIS, define the concurrency of the software in each node.

The treatment of concurrency necessarily varies somewhat depending on the underlying

platform/technology used to implement concurrency. Therefore, OOASIS offers alternate steps relevant

to each type of platform.

Introduce Prioritizable Concurrent Elements (PCEs) into your design for:

• Temporal correctness (response time, device characteristics)

• Clarity (cohesion/interdependency of interacting objects)

• Reliability (distinguishing critical functions or, conversely, background functions)

8


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


• 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 process T

“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


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


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


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


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

NeedsGoals

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

SamplesAnalysis

Maintenance

Requests

System Usage Reports

System

Ext I/F


�Who�What�Where�Why�When�How much�How many�How well�With what others�…..

Business Process

NeedsGoals

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

SamplesAnalysis

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


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


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


System Use Case�Details�Alternatives�Variations�Priorities�Elaborations


�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


�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


Models. These parallel activities to elaborate the definition and/or selection of physical architecture and

OTS components continue until they result in detailed Hardware Interfaces and OTS Software

Interfaces. These support low-level software design (elaboration of the System Software Architecture)

and coding.

2.5.3 GENERAL INTERFACE ISSUES

2.5.3.1 Balancing Architecture Decisions

One of the hottest issues between software developers and systems engineers revolves around old

approaches to allocation and architecture decisions. In a more classic approach, functionality is allocated

to system components and a hardware/software decision is made within each box. In modern software

intensive systems, location of specific software functionality is much less of or no concern at all. Software

developers can and prefer to develop the internal architecture of the software and then distribute it as

makes sense from a processing view. This means that attempts to force distribution to specific hardware

locations is both less than optimal from a software performance standpoint and not well received by the

software community. As a result, the systems engineer must recognize this need for delaying deployment

decisions until later in the development process and resist the urge to force functional allocations early in

the process.

On the other hand, there are often constraints and lead times that the systems engineer faces that the

software developer must be responsive to. One of the historic examples is communications limitations.

There are lots of examples of software designs that worked well on paper or on prototype systems but

could not be used in the real world. Some have been limited by security concerns, others by real world

capabilities that were as much as four orders of magnitude less than desired. The software developer must

be ready to face these constraints and work with the systems engineer to provide an optimum

compromise.

A factor in this difference of viewpoint between the two disciplines is the internal versus external view.

This is not peculiar to software. The design discipline of any component needs to focus on the internal

design of the component in question. By definition, it is the responsibility of systems engineering to

assure that those components work with the other components so that the system does what it is supposed

to. Both the systems engineer and the software engineer must be aware and live by some basic tenets.

1. The systems and software architectures are not the same thing.

The systems engineer must recognize that a software architecture needs to be developed based on the

problems to be solved in software and the actor interfaces. Negotiation of impact on system elements

should be expected as part of the software deployment activity.

2. The systems and software architectures are not totally independent.

The software developer must recognize that systems constraints and lead times require early definition of

software architecture constraints. For instance, communications limitations between two geographically

separate nodes may constrain the deployment options and force the software architecture to limit the

internode data

18


An example of the need to understand the external processes is the current effort within the air

transportation industry to add a data link capability. This system will allow pilots and controllers to pass

messages in addition to voice communications to increase the effectiveness of air traffic control. To the

software designers, the handling of message traffic can be shown in UML with the controllers and pilots

as principal actors and the software within the system described in use cases and interaction diagrams. At

the systems level, the critical factors driving the usability of the datalink concept involve the workloads of

both the pilot and controller. In order to understand these, the analyst must understand, model, and test the

activities external to the datalink system. These analyses are better supported by methods such as the

behavior diagram or other static or dynamic models.

2.5.3.2 Over- and Under-specifying

As with any component, the correct balance of specification detail is difficult to find. If the systems

engineer is unfamiliar with the issues of design that affect that discipline, it will be more difficult to

achieve the balance. If there is not an active, bi-directional communication channel in place, it will be

impossible. This is often even truer for software components.

An example of under-specification is the system that required the software to automatically reconfigure

the network if one of the links failed. No further guidance was provided. The expectation was that the

software designers could figure it out from there. After all, the maintenance crew did this regularly in the

current system.

A better approach is to be responsive to the questions that a software developer asks about the

requirement such as what reconfigurations are viable, what capabilities have priority, how many failures

must be handled, how long do we have to reconfigure, what should be done when a link comes back on

line, etc.

Over-specification, as with any component, is usually the result of forcing design rather than providing

the constraints that drive it. A typical example would be requiring either a look-up table or an algorithm

calculation rather than the accuracy requirements and letting the software developer choose the most

effective solution.

2.5.4 SE AND UML

UML has been developed as a unification of software analysis techniques. As such, it should not be

surprising that it does not yet fully cover the needs of systems engineering. This has been recognized

within the Object Management Group and a Systems Engineering Domain Special Interest Group within

OMG has issued a Request For Proposal for changes to the UML to improve coverage of systems

engineering needs. This effort is being jointly conducted with the International Council on Systems

Engineering (INCOSE). Some of the principal requirements are expanded capabilities in defining

complex behavior, systems elements, interfaces, allocation, and traceability.

It is anticipated that most of the requirements will be addressed by changes to the UML. There may be

some additional diagrams added in this effort or future changes to the UML. Beyond the scope of current

changes are various analysis techniques that have been developed by “specialty” disciplines to address

their peculiar concerns. Among them is Systems Safety with Failure Mode Analysis and Fault Tree

Analysis and testing with Design of Experiments methods for resolving issues involving complex

19


interactions and multiple alternatives. These may be incorporated at a later date or may remain an external

set of techniques that will need to interface with UML analysis as appropriate.

Another example of external analysis interfacing with the UML would be the allocation of 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

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


• NDC Diagram




The IDEF0 method is often used to perform the functional or behavioral analysis of a system. Although

some of the information is principally developed and recorded using other techniques such as concept of

operations and system architecture views, IDEF0 contains most of the information needed for the

OOASIS inputs. The application of the IDEF0 method demonstrates how this systems engineering

method may be used to satisfy some or all of the information needs represented by these artifacts. The

OOASIS information requirements represented by the first six artifacts may be fully addressed using the

IDEF0 method. The three artifacts representing OTS software and hardware components and their

interfaces are not fully addressed, but the specific components and interfaces required to meet system

requirements are identified using the IDEF0 method.

A case study using IDEF0 is provided in the appendices to this report for those interested in more details

on how that method can be applied to the software interface needs.

21

3. Applying IDEF Methods to Develop OOASIS Information Requirements


22

A. RELATING IDEF METHODS TO OOASIS

A.1 PART I. APPLYING THE IDEF0 METHOD

The OOASIS method identifies nine information artifacts that it assumes are generated by activities that

are external to the core software-oriented activities of OOASIS. OOASIS treats these primarily as inputs

to the OOASIS method:

• Stakeholders

• Context Diagram

• As-Is Process

• To-Be Process


• NDC Diagram




The OOASIS information requirements represented by the first six artifacts may be fully addressed using

the IDEF0 method. The three artifacts representing OTS software and hardware components and their

interfaces are not fully addressed, but the specific components and interfaces required to meet system

requirements are identified using the IDEF0 method as described here.

This approach to IDEF0 analyses is based upon IEEE 1320.1-1998 and the IDEF0 models developed here

comply with this standard. For the remainder of this document, unless otherwise specified, the term model

refers to an IDEF0 model. A requirements model refers to a fully decomposed IDEF0 model in which

mechanisms have not been specified. An architecture model refers to a fully decomposed IDEF0 model in

which mechanisms have been specified for all activities.

The focus of this appendix is not to teach IDEF0 modeling; we assume that the reader has some

familiarity with the IDEF0 method. The focus is first on ensuring that OOASIS information requirements

are addressed during IDEF0 model analysis and construction and second on translating this information

into artifacts understood by and useful to OOASIS and other software engineers.

23

A. Relating IDEF Methods to OOASIS Information Needs

The basis of this work is the Buoy System case study presented by the OOASIS course and website as the

vehicle for demonstrating this application. However, to reduce the number of systemic interfaces to a

manageable handful, we have recast the characters of this case study so that the problem is not deeply

embedded in a context of existing organizations and systems. We have invented the island nation of Santa

Narida to be the customer for our buoy system; the backstory about Santa Narida is given in Appendix B.

A.1.1 OVERVIEW OF METHOD

To develop the information needed by OOASIS software designers, the systems engineer will build a

family of IDEF0 models whose information elements will be mapped to the input artifacts specified by

OOASIS. Each step in the method builds upon information developed by previous steps.

1. Identify and gather source material preparatory to developing IDEF0 models.

2. Build a family of models of the interests of external stakeholders. These include models are additional

to IDEF0 but depend on the information contained in IDEF0 with a focus on stakeholder behavior.

[These models will satisfy the OOASIS requirement for external stakeholder and summary use case

information.]

3. Build a family of environmental context models for the prospective system. These models are

organized around principle outputs to satisfy the interests of external stakeholders. These models

consolidate stakeholder interests from the perspective of the prospective system. These models treat

the prospective system as a black box. [These models will satisfy the OOASIS requirement for context

and external stakeholder information.]

4. If appropriate, build an architecture model(s) of any existing system(s), to include environment

context diagrams. If you are re-engineering a system, an architecture model of the existing system is

always appropriate. If you are building a new system to provide completely new behavior, the need

for an architecture model of existing behavior is problematic and will need to be established. The

systems engineering process will generally use depictions of architecture which are additional to

IDEF0. The information in these models ties to the mechanisms in IDEF0. [This model(s) will satisfy

the OOASIS requirement for AS-IS context, external stakeholder, and process information.]

5. Build a family of requirements models for the prospective system. These requirements models

decompose the system behavior (i.e., the A0 activity) specified by the environmental context models.

The first iteration of these models will focus on expected, correct behavior (the simplest, shortest,

successful path to achieving a goal(s)). (A corollary of this modeling objective is that these

requirements models may not use call arrows.) [These models will satisfy the OOASIS requirement

for context, external stakeholder, and TO-BE process information.]

6. Build a family of architecture models for the prospective system. The architecture models allocate

mechanisms to the decomposed system behavior of the requirements models. Particular attention will

be paid in this allocation to identify internal stakeholders and COTS hardware and software. Note that

this allocation will be exploratory and tentative. The systems engineering process will generally use

depictions of architecture which are additional to IDEF0. The information in these models ties to the

mechanisms in IDEF0. [These models will satisfy the OOASIS requirement for context, external

stakeholder, and process information. In addition, these models will identify internal stakeholders,

COTS software, COTS hardware, and their interfaces.]

24


7. Build a family of system use case models. These system use case models partition and coalesce the

architecture models to specify software system boundaries and actors in a way that may be translated

directly into use case notation. [These models will satisfy OOASIS requirements for system use

cases.]

8. Build a family of NDC models. These NDC models partition and coalesce the architecture models to

specify the nodes, devices, and connectors in a way that may be translated directly into NDC diagram

notation. [These models will satisfy OOASIS requirements for NDC diagrams.]

At this point, a consistent set of information and guidance for OOASIS software practitioners should be

available. We turn attention now to exploration of (1) anomalous behaviors, (2) alternative behaviors, and

(3) enumerated behaviors. Consideration of anomalous behaviors will introduce fractal patterns into our

requirements models. Call arrows and submodels will be introduced when we consider alternative

behaviors and enumerated behaviors. The following steps will elaborate the requirements and architecture

models that we have already developed.

9. Enumerated behaviors. Extend each model in the requirements family by considering activities that

represent sets of related but mutually exclusive behaviors. (These may sometimes be inappropriately

represented by a ladder pattern in a decomposition diagram, i.e., no coupling between parallel

activities.) Such enumerated behaviors are to be represented by submodels invoked by a call arrow.

[These extensions will assist the OOASIS analysis of alternate courses and variations for system use

cases.]

10. Alternative behaviors. Extend each model in the requirements family by considering additional ways

of accomplishing the objectives of each activity, i.e., alternative decompositions. These should be

first developed as FEO pages and then migrated to submodels. Such alternative behaviors are to be

represented by submodels invoked by a call arrow. [These extensions will assist the OOASIS analysis

of alternate courses and variations for system use cases.]

11. Anomalous behaviors. Extend each model in the requirements family by considering patterns of

anomaly detection and recovery for each activity. We provide a template of fractal patterns that may

be used to guide this analysis. [These extensions will assist the OOASIS analysis of alternate courses

and variations for system use cases.]

These steps generally refer to a “family of models.” This does not imply that every exercise will

necessarily generate multiple models; a family may have only one model. How large such a family might

be will depend upon the complexity of the prospective system and the intensity of issues to be resolved to

provide adequate requirements and design guidance.

This paper discusses a recommended method for accomplishing Steps 1 though 8. Steps 9 through 11 will

be treated in a subsequent release.

Step 1. Develop a consistent understanding of system need.

• Identify and gather existing source fragments that state various aspects of the stakeholders’

problems. As in the real world, fragments of useful information are in different places. For this

case study, one set of fragments comes from the OOASIS website, another from the OOASIS

course, and the final set is the Santa Narida backstory. The OOASIS website and OOASIS course

material have been slightly edited to ensure that they are consistent with the Santa Narida

backstory. The OOASIS website teaches:

25


“A widespread fleet of buoys collects environmental data and feeds it periodically through

satellites to a land-based storage facility. Users of the system request subsets of the data and

perform analyses upon these.

The Meteorological Data system is sponsored by a government agency to provide environmental

data (mostly weather related) and analysis to scientists and the general public. The agency's goals

for this system are to provide real-time and historical data (archived from the real-time data

stream) on temperature, wind, and other conditions in a broad swath of ocean. The overall concept

for this system is that the agency will develop, deploy and maintain floating data collection buoys

throughout the area of interest. The buoys will periodically communicate their collected data

through commercial (or standard OTS) satellites to a land-based data center, where staff scientists

can access the data and run analyses from their workstations. A Web site will provide public

access to the data.

In particular, you know that the physical architecture involves buoys communicating to a land

station via satellite, and users employing work stations to access this data (probably via a large

server).”

The OOASIS course adds these thoughts:

“The case study we will use for every example will be a weather data collection system. The

system collects data from buoys floating in the Pacific Ocean and sends the data back for the 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


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


Used at: Context:

Title: Number:

Author:

P roject:

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: Stake holde r: We athe r M e dia (SWM )

Page:

A-0

AKB3 3

x12/20/2001

Present WeatherA0

I2GOOS Imagery

C2 W eathe r Show F ormat

C3 Broadc ast Sc hedule

O1W eather S how

M 1 Nat iona l W eat he r Se rv ic e

M 2 T e lev is ion S tudio

M 3 W eathe r P resente r

M 4 Santa Narida Buoy Syst em

W rit e Sc ript

3

M ix Bac kdrop

2

Read Sc ript

4

Ora l P res enta t ion

Sc ript

Forec ast

W eathe r

1Oc ean Imagery

Forec ast T ext

F orec ast P roduc t s

I1Ocean Observat io ns

Produc t Request s

C1 Image S t andards

V isua l P resent at ion

Diagram 1. SWM/A0 (Present Weather)

Used at: Context:

Title: Number:

Author:

P roject:

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: Stake holde r: Ts unami Warning Sys te m (STW)

Page:

A-0

2

x12/20/2001

Produce Tsunami WarningsA0

I1Oc eanographic Da ta

C2 Data S haring A g reement

O1T sunami W arning

M 1 T sunami W a rning Syst emM 2 Santa Narida Buo y Syst em

Provid e

Tsunam i

Pred ict io n

D a ta1

Fus e

Tsunami

S ources

3

Pred ict

T s unami

4

Fused T sunami Dat a

C3 T sunami P redic t ion M ode ls

SN O OR Tsunami Data

R eceive

Data

2

Rec e iv ed T sunami Data

M a il C lientM a il Se rve r

C1 Int e rnet M a il P ro t oc o ls

28


Diagram 2. STW/A0 (Produce Tsunami Warnings)

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader DateAKBocast

OOASIS SE

P.

Model: Stake holde r: Ins titute Scie ntis t (SIS)

Page:

A-0

AKB2 2

x12/20/2001

Research Ocean Weather PhenomenaA0

I1Oc ean Obse rvables

C3 Researc h Agenda

O1Researc h P roduc t s

M 1 Sant a Narida Buoy Syst em

M 3 Inst it ut e Sc ient is t

C ap ture

Oce an Data

1

S tage

Ocean Data

2

S tudy

Ocean

W eathe r

3

Dataset Reques ts

Reques ted Datasets

Oc ean Data

C2 Datase t Spec if ic a t ions

M 2 Inst it ut e fo r M id- Pac if ic Oc ean M e teoro logy

W eb Browser

W eb Se rve r

C1 Observat ion Spec if ic a t ions

T asking

Diagram 3. SIS/A0 (Research Ocean Weather Phenomena)

29


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader DateAKBocast

OOASIS SE

P.

Model: Stake holde r: Route Planne r (SRP)

Page:

A-0

AKB3 2

x12/20/2001

Plan Ship ItineraryA0

C3 Cust omer Requirement s

O1Rout e Plan

M 2 Route P lanne r


Fo recas t

R oute-S pecific

W eather

2

Es t im ate

V es sel

S ched u les

3

D eterm ine

Feas ib le

R outes

1

S elect

Op t imum

It inerary

4

C2 Resourc e M inimiza t ion S t ra t egy

Webs it e

I1Rout ing A lt e rna t ives

Feas ib le Rout es

W eather-Pro filed R outes

Ro ute-V es s el-S chedu le Es t imates

C1 Vesse l Charac te rist ic s

M 1 W eb Brow ser

I2Oc ean W eat he r Data

Dest ina t ions

Schedules

Diagram 4. SRP/A0 (Plan Ship Itinerary)

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader DateAKBocast

OOASIS SE

P.

Model: Stake holde r: We athe r Fore cas te r (SWF)

Page:

A-0

AKB2 2

x12/20/2001

Forecast WeatherA0


C2 Out look Sc hedule

O1Forec ast P roduc t s

M 1 W eathe r F orec ast e rs

M2 Nat iona l W eathe r Se rv ic e


C o lle ct Data

1

Push D ata

2

Model

W eather

3

Pub lis h

Fo recas ts

4

C1 W eat her M ode l Requirement s

His t oric a l Da ta

Pro jec t ed Data

M eteoro logy Dataset s

30


Diagram 5. SWF/A0 (Forecast Weather)

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader DateAKBocast

OOASIS SE

P.

Model: Stake holde r: National We athe r Se rvice (SNW)

Page:

A-0

AKB2 2

x12/20/2001

Increase Puerta Oveida Market ShareA0

I2Undec ided Rout ing Quest ions

C 3 M inis t e ria l Quest ions

O1Ministerial Reports

O 2Favorable Rout ing Dec is ions

M 2 NW S Genera l M anager

M 3 Santa Narida Buoy Syst emM 1 Shipper

Provide

W eather

In fo rmat io n

1

S elect

S h ipp ing

It inerary

2

Prov ide

Repo rts

3

I1W eathe r Obse rvables

W eathe r Const ra int s

W ebs it e Ac t iv it y Report s

C2 Forec ast ing Sc hedule

Buoy Ac t iv it y Report s

Syst em Ac t iv it y Report s

Buoys W ebs it e System Adminis t ra tor

1 Actvity reports include

maintenance activity.

C1 Shipment Requirement s

Diagram 6. SNW/A0 (Increase Puerta Oveida Market Share)

31


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader DateAKBocast

OOASIS SE

P.

Model: Stake holde r: Sate llite Provide r (SSP)

Page:

A-0

2

x12/20/2001

Deliver DataA0

I1F ie ld Obse rva t ions

C1 Communic a t ions Pro toc o ls

C 2 Serv ic e Agreement

O1De live red Dat a


M 2 Argos M 3 W orld W eathe r W at c h

S end

Co mmands

1

Move

C ommands

2

S end D ata

3

Receive

D ata

4

Move Data

5A rch ive

D ata

6

O 2A rc hived Dat a

W eb Brow ser

T ransmit t ed Data

S ent D ata

T ransmit t ed Commands

Sent Commands

W eb Brow ser

Sat e llit e P ro t oc o lsW eb Pro t oc o ls

W eb Pro toc o ls

Buoy T ransc e iver

Diagram 7. SSP/A0 (Deliver Data)

Used at: Context:

Title: Number:

Author:

P roject:

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: Stake holde r: NOAA M ainte nance (SNM )

Page:

A-0

AKB2 2

x12/20/2001

Maintain BuoysA0

I1Broken Buoy

C1 M a int enanc e T rea t y

O1W orking Buoy

M 1 Santa Narida Buoy Syst em M 2 NOAA M 3 Pac if ic Obse rve r

Reques t

Main tenance

A ct io n

1

D irect

Main tenance

A ct io n

2

Fix B uoy

3

M aint ena nc e Orde r

M a int enanc e Request

C2 Buoy T ec hnic a l Da ta

M a int enanc e Report

M a int enanc e Rec ord

M a int enanc e His t o ry

M a int enanc e Not if ic a t ion

Diagram 8. SNM/A0 (Maintain Buoys)

32


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


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 Provider Grouping

Concept: Outputs Controls Inputs Mechanisms


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




institute

shipper

customer

tsunami

communications

environment communications

maintenance

trainer

34


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)




institute

shipper

media

tsunami

customer

tsunami

communications


maintenance

trainer

Stakeholders by Requirements Models: Model 2 (selected stakeholders are in bold)




institute

shipper

media

tsunami

customer

tsunami

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


the A-0 or A-1 diagrams; our interest now is fleshing out the context of the A0 function in the A-1

diagram for each model.

To make this section easier to read (and to write!), we will use the term stakeholder function to refer to

the box in the A0 diagram of a stakeholder model to which the prospective system is attached as a

mechanism. We will use the term A0 function to refer to box 0 in the A-1 diagram of a requirements

model; the prospective system is attached to this box as a mechanism.

Gather the A0 diagrams of the stakeholder models for the stakeholders allocated to the System Products

model. We will sequentially and methodically add the information in these stakeholder models to the A-1

diagram. In the A-1 diagram, whatever the stakeholder does with its input from the prospective system is

hidden within the use output box.

The prospective system becomes a mechanism of the A0 function. The stakeholder becomes a mechanism

of the use output function.

Boundary arrows that are controls for the stakeholder function becomes outputs of the provide controls

box. Controls on the stakeholder function that are outputs of stakeholder activities become controls on the

A0 function.

Boundary arrows that are inputs for the stakeholder function become outputs of the provide inputs

function.

In general, we try not to add new material nor do we try to rectify any logical anomalies (the sense of the

model) that become apparent, although we generally consider correcting modeling anomalies (the

representation of model sense) while we add successive stakeholders’ information to this diagram.

The next diagram illustrates this transferal for the first, Weather Media stakeholder. The template

elements that have not been used so far are grayed down; as these elements are used in the following

sequence of diagrams they will be restored to their normal color.

36


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

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

Context of

...

0

p rovide

m echan ism s

2

p ro vide

inp u ts

3

p rovide

con trols

4

use ou tpu t

5

1

A0 function

re sult s

con trol request m echan ism request inpu t request

Product Requests

Te lev isio Santa Narida

stakeholder is takeholder mstakeholder c Santa Nar ida Buoy System

im age standards

m echan ism bund le

Ocean Observations

Forecast Text

W eatherShow

perform ance feedback

resu lts feedback

NONE

Ocean Im agery

Forecast Products

b roadcast schedu le

GOOS Imagery

Diagram 9. RTP/A-1=AKB5.1 for Weather Media Stakeholder

The following diagram adds the environment stakeholder to generate input.

37


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

AKB5 1

x12/14/2001


Context of

...

0

p rovide

m echan ism s

2

p ro vide

inp u ts

3

p rovide

con trols

4

use ou tpu t

5

1

A0 function

re sult s


Product Requests

Te lev isio Santa Narida

Environm entstakeholder mstakeholder c Santa Nar ida Buoy System

im age standards

m echan ism bund le

Ocean Observations

Forecast Text

W eatherShow


resu lts feedback

NONE

Ocean Im agery

Forecast Products


GOOS Imagery

Ocean Observab les

Planetary Observab les

Ocean

Planet

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


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:

I1

I2

O1

O3

M easu re Ocean

W eather

C haracteris t ics

1F

Photog raph

th e Earth

2F

C1 inp u t reque st

C2 p erform ance feedback

M 1 GOOS S ate llitesM2 B uoy S ystem

Ocean Ob servat ion s

S ate llite Im agery

Ocean Ob servab les

Planetary Ob servab les

Measu red Ocea n Ob servab lesO2

Photog raphed Ob servab lesO4

Diagram 11. RTP/FEO1: Parallel Decomposition Fragment

This draft shows no coupling or cohesion whatsoever between the two boxes. This indicates that the

decomposition is suspect, an artifice by which two unrelated functions have been grouped together not

because they participate in the purpose of some larger whole but rather because they have been grouped

2 There is of course a fundamental difference between, on the one hand, changing the state of a letter from

unsigned to signed and, on the other, changing the state of a letter from unread to read. Signing a letter physically

changes the letter while reading that letter does not physically change it. In the first case, the thing itself has been

transformed; in the latter case, it is our perception of the thing that has been transformed — we have moved the

letter from one conceptual category to another. However, because philosophers of science have instructed us that

the interaction of observed and observer changes both, we can at least temporarily accept such transformation as

legitimate within an IDEF0 model.

39


by location or kind — no surprise here since our template grouped them together because they are both

sources of inputs! The Measure Ocean Weather Characteristics should really be within the A0 function,

represented by the walls of box 0.

These considerations lead us to revise our working draft:

Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

AKB5 1

x12/14/2001


Context of

...

0

p rovide

m echan ism s

2

p ro vide

inp u ts

3

p rovide

con trols

4

use ou tpu t

5

1

A0 function

re sult s


Product Requests

Telev is io San ta N arida

Environm ent

stakeholder mstakeholder c S an ta Narida Buoy Syste m

im age standards

m echan ism bund le

Forecast Text

W eatherShow


resu lts feedback

NON E

Ocean Im agery

Forecast Products


Satellite Im ageryOcean Observab les


GOOS System

Provide

Observab les

6Measured Observab 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 1O c e a n O b s e rv ab le s O 1

M e as u re d O b s e rv a b le sM e a su re O ce a n

W e a the r

C ha ra c te r is t ic s

1

O c e an O b se 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


Now we will look at the next stakeholder, the Tsunami Warning System:

Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

AKB5 1

x12/14/2001


Context of

...

0

p rovide

m echan ism s

2

p rovid e

inpu ts

3

p rovide

con trols

4

use ou tpu t

5

1

A0 funct ion

result s

con trol requestm echan ism request

inpu t request

Product Requests

Telev is io San ta N arida

Environm ent

stakeholder mstakeholder c San ta N arida Buoy System

I m age S tandards

m echan ism bund le Forecast Text

W eather S how


resu lts feedback

NON E

Ocean Im agery

Forecast Products

B road cast S chedu le

Satellite Im agery

Ocean Observab les

Planetary Ob servab les

GOO S S ystem

Provide

Observab les

6

Measured Observab lesx

xTsunam i W arn ing

Tsu nam i Data

Tsunam i W arn ing Cen ter

In ternal Mail Protocols

Tsunam i Data A g reem ent

Diagram 14. RTP/A-1=AKB5.4, Adding Tsunami Warning System

First, notice that the Internet Mail Protocols have been shown as an external control, that is, these

standards are not established by the stakeholders: regardless of what the designers of the prospective

system may or may not do, these standards will be available to the system.

Second, we can recognize that providing some controls requires the participation of stakeholders. In our

stakeholder models, these were seen as given constraints. From a systems engineering perspective, the

activities that produce such agreements must be designed and institutionalized because the agreements

they generate are necessary for successful system operation.

Third, now that we have two stakeholders represented, we can begin to judiciously generalize, that is,

raise the level of abstraction of concepts in the environmental context diagram.

The next diagram shows an elaboration of the previous diagram as it incorporates joint control activities

and higher levels of abstraction. Our work area is now becoming crowded, so note that the activity to

provide mechanisms has been removed from this A-1 diagram; we will need to ensure that we revisit this

activity in another environmental context diagram.

41


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

AKB5 1

x12/14/2001


Context of

...

0

p rovid e

inpu ts

3

p rovide

con trols

4

use ou tpu t

5

1

A0 funct ion

x

con trol request inpu t request

Product Requests

Telev is io S an ta N arida

Environm ent

National W eather S erv ice San ta N arida Buoy S ystem

Im age S tandards

Forecast Text

W eather Show


resu lts feedback

NON E

Ocean Im agery

Forecast Products

B road cast S chedu le

Satellite Im agery

Ocean Observab les


GOO S S ystem

Provid e

Observab le s

6

Measured Observab lesx

xTsunam i W arn ing

Filte red Datase ts


In ternal Mail Protocols

D ata Shar ing 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


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:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

AKB5 1

x12/14/2001


Context of

...

0

p rovid e

inpu ts

3

p rovide

con trols

4

use ou tpu t

5

1

A 0 fu nction

x


Product Requests

Telev is io San ta Narida

Environm ent

N ational W eather S erv ice San ta N arida Buoy S ystem

Im age S tandards

Forecast TextW eather Show


resu lts feedback

NON E

Ocean Im agery

Forecast Products

Schedules

S atellite Im age ry

Ocean Observab les


GOO S S ystem

Provid e

Observab le s

6Measu red Ob servab les

x

xTsunam i W arn ing

F iltered Datasets


Inte rne t Protoco ls


Institu te S c ien tist

Research Productsx

Unfiltered Datasets

Spec ificat ions

Observation Spec ifications

Dataset S pecificationsDataset Products

Diagram 16. RTP/A-1=AKB5.6, Adding Institute Scientist

In this step, we have added the Institute Scientist as mechanism and Research Products as output to the

use output activity. The datasets requested by the Institute Scientists have been represented by Unfiltered

Datasets and bundled with Filtered Datasets to form Dataset Products as output from the A0 function.

The specification of the observations that the buoy system makes and the specification of the datasets that

the buoy system provides have been added as output from the A0 function and as control on the use

output activity.

Note that the Institute Scientist is not party to data agreements with the National Weather Service.

Instead, the Institute Scientist is a user of products specified by the buoy system.

43


Note too that the presence of web server and web browser mechanisms in the Institute Scientist model

suggested the extension and generalization of Internet Mail Protocols to Internet Protocols that govern

both the A0 function and the use output function.

Now we turn to the weather forecaster model. With the A-1 diagram we have developed so far, we

immediately see an issue concerning the scope of the prospective system. The output of the weather

forecaster is Forecast Products, which we have already identified in the A-1 diagram as an output of the

A0 function. In the weather 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:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

AKB5 1

x12/17/2001


Context of

...

0

p rovid e

inpu ts

3

p rovide

con trols

4

use ou tpu t

5

1

A 0 fu nction

x


Product Requests

Telev is io San ta NaridaEnvironm ent National W eather S erv ice

S an ta N arida Buoy System

Im age S tandards



resu lts feedback

NON E

Ocean Im agery

Forecast Products

Schedules

S atellite Im age ry

Ocean Observab les


GOO S S ystem

Provid e

Observab le s


x

xTsunam i W arn ing

F iltered Datasets


Inte rne t Protoco ls



Research Productsx

Unfiltered Datasets

Spec ificat ions



W eather Model Data Requ irem ents

Diagram 17. RTP/A-1=AKB5.7, Additional Clarification of Behaviors

We bring Weather Model Requirements into our A-1 diagram as an output of the provide controls

function. One would think that there might be an interaction between operation of weather models and

development of their data requirements — oops, this control refers to data requirements, does it not?

Renaming as data requirements should flush out any alternative interpretations.

44


We will need to address rather sooner than later whether the activities of National Weather Service

weathermen are within the scope of our model of system behavior. At this point in model development,

we put a placeholder for this issue on the requirements model’s A0 page, where we previously modeled

the production of ocean observations.

I 1Ocean Ob servab les

C2 W eather M ode l D ata R eq u irem en ts

O1M easu red Ob servab les

O2Forecast Prod ucts

M easure O cean

W ea the r

C ha ra cte r istics

1

Ocean Ob servat ion s

Fo re cast

W ea the r

2

M1 W eather Forecas ters

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


I 1Ocean Observab les

C2 B uoy Com m ands

O1Measu red Observab les

O2Ocean Obervat ions

Send

Comma nds

7F

Co l le ct Da ta

2F

Send Da ta

3F

Rece ive Da ta

5F

S en t Com m ands

Collected DataS en t Data

Transm itted Data

C1 Com m un ications Protocols

O3

C3 T rans m it ted Com m ands

O4

I2

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


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .

Model: Requirements TO-BE Operations (RTO)

Page:

OOASIS SE

AKBocast

AKB5 1

x12/17/2001

Stakeholder Context of ...A-1

Context of

...

0

p rovide

m echan ism s

2

p rovide

inpu ts

3

p rovide

con trols

4

use ou tpu t

5

1

A0 function

x

con trol request

Main tenance Request

inpu t request

Product Requests

Rou te Planner

EnvironmentN OA ANW S Gene ra l Manage r Santa Na rida Buoy Sys tem

Minis te ria l Reques ts

Ocean Ob servab les

Rou ting Products

Rou te P lan

System StatusRo uting Decis ions

NONE

0

xMeasured Observab les

repa ired buoy

b roken buoy

Se rvice Agreements

Main tenance N otification

m echan ism request

Buoy Techn ical Data

M in isteria l Repor tsx

M in isteria l Quest ions

Rou te Plann ing Requ irem ents

A rgos

Com m un icat ions S atellites

Com m un ications Protocols

Diagram 20. RTO/A-1=AKB5, Operations Stakeholders

47


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

A0

AKB6 5

x12/17/2001

Measure Ocean ObservablesA1

I1Ocean Observab les

C2 Buoy Com m ands

O1Measured Observab les

O2Ocean Obervations

Send

Command s

1

Move

Commands

2

Co lle c t Da ta

3

Send Da ta

4

Move Da ta

5

Rece ive Da ta

6

M1 Comm un icat ions Satellites

Sent Commands

Transm it ted Commands

Collected Data

Sen t Data

Transm itted Data


Diagram 21. RTO/A1 Measure Ocean Observables

We also prepare a third model for the trainer stakeholder:

48


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .

Model: Requirements TO-BE Training (RTT)

Page:

OOASIS SE

AKBocast

AKB5 1

x12/17/2001


Context of

...

0

p rovide

m echan ism s

2

p ro vide

inp u ts

3

p rovide

con trols

4

use ou tpu t

5

1

A0 function

re sult s


ou tpu t request

stakeholder o

sta keholder iTrainerstakeholder c S an ta N arida Buoy Syste m

control bund le

m echan ism bund le

inpu t bund le

ou tpu t bund le

resu lts

Perfo rm ance Feedback

resu lts feedback

NONE

0

Trained S taff

Un trained Peop lex

Train ing Requ irem ents

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


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: Re quire me nts TO-B E Products (RTP)

Page:

OOASIS SE

AKBocast

AKB5 1

x12/20/2001

Stakeholder Context of Meteorological Product GenerationA-1

Genera t e

Me t eo ro log ic a l

Produc t s

0

Prov ide

I magery

3

Con t rol

Produc t ion

4

Use

Met eo ro logy

Produc t s

5

1

x

c on t ro l request inpu t request

Produc t Request s

T e lev is io San t a NaridaEnv ironmen t Na t iona l W ea t he r Se rv ic e

Sant a Nar ida Buoy Sy st em

I mage St anda rds

Forec as t T extW ea t he r Show

perf o rmanc e f eedbac k

resu lt s f eedbac k

N ONE

Oc ean I magery

Fo rec ast Produc t s

Sc hedu les

Sa t e llit e I magery

Oc ean Ob se rv ables

Plane t a ry Observ ab les

GOOS Sy st em

Prov ide

Observ ab les

2Measured Observ ab les

x

xT sunami W arn ing

Filt e red Da t ase t s

T sunami W arn ing Cen t e r

I n t e rne t Pro t oc o ls

Da t a Sha r ing Ag reement s

I nst it u t e Sc ien t is t

Resea rc h Produc t sx

Un f ilt e red Da t ase t s

Spec if ic a t ions

Observ a t ion Spec ific a t ions

Da t ase t Spec if ic a t ionsDa t ase t Produc t s

W ea t he r Mode l Da t a Requ iremen t s

0

Argos Sy st em

Diagram 23. RTP/A-1 (Stakeholder Context of Meteorological Product Generation)

50


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 .


Page:

OOASIS SE

AKBocastTop

AKB1 2

x12/20/2001

Context of Meteorological Product GenerationA-0

Genera t e

Me t eo ro log ic a l

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 Products

Measured Obse rv ab lesOc ea n Obse rv ab les

Ocean

S atellite ImagerySat e llit e I magery

Me t eo ro logy Da t a Requ iremen t s

Produc t Request s

Me t eo ro log ic a l Produc t s

Na t iona l W ea t he r Se rv ic e

W ea t her Fo rec ast e rs

Sc hedu les

Da t a Sha ring Ag reemen t s

I mage St andards

Commun ic a t ions Pro t oc o ls

Me t eo ro logy Da t a St anda rds

Argos Sy st em

Spec if ic a t ionsSpecif i c a t ions

San t a Nar ida 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


• 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:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

A-0

AKB15 3

x12/20/2001

Generate Meteorological P roductsA0


I2Satellite Im agery

C5 Product Requests

C6 Meteorology Data Requ irem ents

O1Measured Observab les

O2Meteorolog ical Products

Measure Ocean

W eathe r

C haracte ristics

1

Ocean Observations

Forecast

W eather

4

M3 W eather Forecasters

C4 S chedu les

C3 Data S haring A g reem ents

C2 Im age S tandards


P rovide

Da tase ts

2

Fi l te r

Da ta se ts

3

Dataset Products

Un filtered Datasets

F iltered Datasets

Forecast Products

Forecast Text

Ocean Im agery

C7 Meteorology Data S tandards

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.

M2 A rg os System

O3Specifications

52


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


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 .


Page:

OOASIS SE

AKBocast

A0A0A0A0

AKB16 4

x12/20/2001

Measure Ocean Weather CharacteristicsA1

I1Oc ean Ob se rvables

C1 Sc hedules C2 M et eoro logy Dat a Requirement s

C3 Produc t Request s

C4 Data Sharing Agreement s

C5 Communic a t ions P ro t oc o ls

C6 M et eoro logy Dat a S tandards

O 1M easured Observables

O 2Oc ean Observa t ions

Cont ro l Da t a

Co lle c t ion

1

M easure

Obse rvables

2

T ran smit

Co lle c t ed

Dat a

3

Data Co lle c t ion Commands

Co lle c t e d Data

M 1 Argos Sys t em

Diagram 26. RTP/A1 (Measure Ocean Weather Characteristics)

The following diagrams decompose the three activities in the A1 diagram. Note that the Argos System

mechanism terminates in diagram A11 and in A13. The activity boxes to which this mechanism attaches

are shaded gray in both diagrams, indicating behavior that is actually outside the scope of the prospective

system.

54


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P .


Page:

OOASIS SE

AKBocast

A1A1A1

AKB17 5

x12/20/2001

Control Data CollectionA11

C 1 Sc hedules



O1Data Co lle c t ion Commands

Generat e

Commands

1

Send

Commands

2

Re lay

Commands

3

Rec e ive

Commands

4

M 1 Argos Sys t em

Sent Commands

Re layed Commands

Sat e llit e P ro t oc o lsInt e rnet P ro t oc o ls

Unsent Commands

Diagram 27. RTP/A11 (Control Data Collection)

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A1A1A1

AKB18 6

x01/10/2002

Measure ObservablesA12

I1Oc ean Obse rvab le s

C1 Dat a Co lle c t ion CommandsC2 M e t eoro logy Da t a Requirement s

C3 M e teoro logy Da ta S t anda rds

O 1M easured Observab le s

O2Co lle c t ed Da ta

Sense

O bse rvab le s

1

Gather

M easurement s

2

Pac kage

Data

3

M easurement s

M easurement Se t

Diagram 28. RPT/A12 (Measure Observables)

55


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.


Page:

OOASIS SE

AKBocast

A1A1A1

AKB19 7

x12/20/2001

Transmit Collected DataA13

I1Collec t ed Dat a

C1 Communic a t ions Pro t oc o ls

C2 M eteoro logy Dat a S t andards

C3 Data Sharing Agreement s

O 1Oc ean Obse rva t ions

Send Data

1

Re lay Da t a

2

Rec e ive Da t a

3

M 1 Argos Syst em

Sent Da t a

Re layed Data

Int e rnet P ro t oc o ls

Sa t e llit e P ro t oc o ls

Diagram 29. RTP/A13 (Transmit Collected Data)

The next two diagrams show the decompositions of A2 (Provide Datasets) and A4 (Forecast Weather).

Note in A4 that the mechanism Weather Forecaster is mechanism to two activities, but that only box A4.2

is shaded. The lack of shading on box A4.1 indicates that we are currently assuming that the Weather

Forecaster and the prospective system will both be needed to carry out this activity. It may be that the

weather models or other tools needed by the Weather Forecaster to execute weather models may be

provided by and be part of our system.

56


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

A0A0A0A0

AKB20 8

x12/20/2001

P rovide DatasetsA2

I1Ocean Observations


C2 Product Requests

C3 Data Sharing Ag reem ents

C4 Com m un ication s Protocols


O2Un filtered Datasets

Save

O bse rva t ions

1

Crea te

Datase ts

2

Re trie ve

Da tase ts

3

S aved Datasets

S aved Observations

O1Specificat ions


Dataset Spec ifications

Diagram 30. RTP/A2 (Provide Datasets)

57


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

A0A0A0A0

AKB21 9

x12/20/2001

Forecast WeatherA4

I1F iltered Datasets


C1 Schedu les


C3 Product RequestsC4 Data Sharing Ag reem ents




O1Ocean Im agery

O2Forecast Text

M1 W eather Forecasters

W rite

W ea the r

Scrip t

2

Run W ea th e r

Mode ls

1

Gene ra te

Symbo lic

Images

3

Combin e

Image s

4

Ocean Overlays

W eather Data

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


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:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .

Model: Architecture TO-BE Products (ATP)

Page:

OOASIS SE

AKBocast

AKB5 1

x12/20/2001

Stakeholder Context of Meteorological P roduct GenerationA-1

Context of

Meteorolog ical

Product

Generation

0

P rovide

image ry

3

Control

Production

4

U se

Me teo ro logy

P roducts

5

1

x

con trol request

inpu t request

Product Requests

Televis io San ta N aridaEnvironm ent N ational W eather S erv ice

San ta N arida Buoy S ystem

Im age S tandards



resu lts feedback

NON E

Ocean Im agery

Forecast Products

S chedu les

Satellite Im agery

Ocean Observab les


GOOS System

Provid e

Observab le s


x

xTsunam i W arn ing

F iltered Datasets



Data Sharing Ag reem ents


Research Productsx


Spec ificat ions



Meteorology Data Requ irem ents

0

A rgos S ystem

Generate

Meteorolog ical

Products

Diagram 32. ATP/A-1 (Stakeholder Context of Meteorological Product Generation)

The following diagram shows the current state of the A-0 diagram in our architectural model. This

diagram differs the A-0 diagram of the requirements model in the following ways:

• The prospective system is no longer tunneled away at the boundary of the 0 box. The primary

purpose of the architectural model is to explore abstract components for the prospective system to

which system behavior can be allocated, so the tunneling used in the requirements model is no

longer appropriate.

• Upon allocation analyses, the output Specifications has been bundled into the existing concept of

Meteorology Products.

59


• A minor point: the label Meteorology Products was Meteorological Products in the requirements

model. This label was changed to be consistent in construction with other labels on the A-0

diagram.

Used at: 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: Archite cture TO-B E Products (ATP)

Page:

OOASIS SE

AKBocastTop

AKB1 2

x12/20/2001

Context of Meteorological Product GenerationA-0

G enerate

Meteo ro log ical

Products

0

Purpose:





TOP

0

Measured

Meteo ro lo gy Pro ducts

Measured Obse rv ab lesOc ea n Obse rv ab lesOcean

S atellite ImagerySatellit e Im ag er y

Met eo rology Da t a Requ iremen t s

Produc t Request s

Met eo r o lo g y Pr o d u ct s

Nat iona l W eathe r Se rv ic e

W e a the r Fo re ca s te r

Schedu les

I mage St anda rds

Commun ic a t ions Pro t oc o ls

M eteoro logy Data S t andards

Argos Syst em

Santa Narida Buoy Sys t em

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


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


Page:

OOASIS SE

AKBocast

A-0

AKB15 3

x12/21/2001

Generate Meteorological ProductsA0


I2Sate llit e Imagery

C 4 Produc t Request s

C5 M eteoro logy Data Requirement s

O1M easured Obse rvables

O2M et eoro logy Produc t s

M easure Oc ean

Obse rvables

1

Oc ean Obse rva t ions

M 3 W eathe r F orec ast e r

C3 Sc hedules

C2 Image S tandards


C 6 M et eoro logy Dat a S tandards

M 2 Argos Sys t em M 1 Sant a Narida Buoy Syst em

Bu oy Brow se r

Cont ro l Pane l

Genera t e

M et eoro logy

Produc t s

2

Dist ribut e

Produc t s

3

Ready P roduc t s

Rec e ived Request s

T asking

Ready Spec if ic a t 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


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:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

A0A0A0

AKB16 4

x12/21/2001

Measure Ocean ObservablesA1


C4 S ched u les C1 Meteorology Data C3 Com m un ications

C2 Meteorology Data


O2Ocean Observations

Contro l Data

Co lle ct ion

1

Measure

O bse rvable s

2

Transm it

Co l le ct ed

Da ta

3

Data Co lle ct ion Commands

Collected Data

M1 A rgos

M2 Buoy

M4 B row ser

Transm itterR eceiver S ensor S u ite

M3 Con trol Pane l

C 5 Ta sking

Diagram 35. ATP/A1 (Measure Ocean Observables)

62


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

A1A1A1

AKB17 5

x12/21/2001


C1 S chedu les C3 Com m un ications Protocols

O1Data Collect ion Com m ands

Gene ra te

Commands

1

Se nd

Comm ands

2

Re lay

Commands

3

Rece ive

Comma nds

4

M2 A rgos S ystem

S ent Com m ands

Relayed Com m ands

S atellite Protoco lsIn ternet Prot ocols

Unsen t Com m ands

M4 ReceiverM3 B row serM1 Con trol Panel

C2 Tasking

Diagram 36. ATP/A11 (Control Data Collection)

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A1A1A1

AKB18 6

x01/10/2002

Measure ObservablesA12


C1 Data Co lle c t ion CommandsC2 M e teoro logy Da ta Requirement s

C3 M e teoro logy Da ta S t anda rds

O 1M easured Observab le s

O2Co lle c t ed Da ta

Sense

O bse rvab le s

1

Gather

M easurement s

2

Pac kage

Data

3

M easurement s

M easurement Se t

M 1 Sensor Suit e

Sensors

Measurement Pro ces s o r

Diagram 37. ATP/A12 (Measure Observables)

63


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

A1A1A1

AKB19 7

x12/21/2001

T ransmit Collected DataA13

I1Collected Data



O1Ocean Observations

Send Da ta

1

R e lay Da ta

2

Receive Da ta

3

M1 A rgos System

Sent Data

Relayed Data

In ternet Protocols

Satellite Protocols

M2 B row se rM3 Transm 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


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

A0A0A0

AKB22 8

x12/21/2001

Generate Meteorology P roductsA2



C4 S che du les


C2 Meteorolog y Data S tandards


O2Ready Spec ifications

O3Ready Products

M2 S anta N arida Buoy System

M1 W eather Forecaster

Gene ra te

Da tase ts

1

Fi lte r

Da tase ts

2

Forecast

W eather

3

F iltered Datasets


Fo recast Text

Ocean Im a gery

Database Eng ine F ilter

Forecast Products

Dataset Products

C5 Received Requests

O1Tasking

Dataset Requ 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


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 .


Page:

OOASIS SE

AKBocast

A2A2A2

AKB20 9

x01/05/2002

Generate DatasetsA21

I1Oc ean Obse rvat ions


C 3 M et eoro logy Da t a S tandards

O3Unf ilt e red Dataset s

Save

Obse rva t ions

1

Crea t e

Dat ase t s

2

Ret rieve

Datase t s

3

Saved Dat ase t s

Saved Obse rva t ions

O2Ready Spec if ic a t ions

Obse rva t ion Spec if ic a t ions

Datase t Spec if ic a t ions

M 2 Database Engine


Observa t ion P roc essor Datase t P rocessor Produc t P roc essor

C2 Rec e ived Request s

O1T asking

C4 Datase t Request 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


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 .


Page:

OOASIS SE

AKBocast

A21A21A21

AKB24 10

x01/05/2002

Save ObservationsA211

I1Oc ean Obse rva t ions

C1 M eteoro logy Data S t andards

O1Obse rva t ion Spec if ic a t ions

O2Saved Obse rva t ions

M 1 Observa t ion P roc essor M 2 Database Engine

S pecify

Observat ion

D ata S tandards

1

Prepare

Observat io ns

2

Main tain

Observat io ns

3

Clean Obse rva t ions

Obse rva t ions Sc hema

Dat a Element M e t ada t 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


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A21A21A21

AKB25 11

x01/05/2002

Create DatasetsA212

I1Saved Obse rva t ions

C1 M e t eoro logy Da t a S t anda rds

C2 M e teoro logy Da ta Requirement s

O1Datase t S pec if ic a t ions

O2Saved Da tase t s

M 1 Dat ase t P roc essor M 2 Database Eng ine

S pecify

Datas et D ata

S tandard s

1

Prepare

Datasets

2

M ain tain

D atas ets

3

Dat ase t S c hema

Dat ase t M e t ada t a



and expertise in specification and application of

meteorology data standards.

Diagram 42. ATP/A212 (Create Datasets)

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

A21A21A21

12

x01/05/2002

Retrieve DatasetsA213

I1Saved Da t ase t s

C1 Datase t Reques t s


O1T asking

O2Unfilt e red Da tase t s

M 1 Produc t P roc essorM 2 Database Engine

S pecify

Products

1

R et rieve

Data s ets

2

Package

D atasets

3

Cata log

Dat ase t Se le c t ion

Re t rieved Da t ase t s

P roduc t Const ruc t ion Rule s

P roduc t P rope rt ies



and expertise in specifying and crafting

meteorological data products.

68


Diagram 43. ATP/A213 (Retrieve Datasets)

The next diagram shows the activities and their mechanisms needed to forecast weather:

Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

A2A2A2

AKB21 10

x12/21/2001

Forecast WeatherA23

I1F iltered Datasets


C4 Schedu les

C1 Meteorology Data Requ irem ents C3 Meteorology Data S tandards


O2Ocean Im agery

O3Forecast Text


W rite

W ea ther

Scrip t

1

Run W ea th e r

Mode ls

2

Genera te

Symbo lic

Images

3

Combine

Images

4

O cean Overlays

W eather Data

M1 San ta N arida Buoy S ystem

W eather Models

Im age Processor

Im age GeneratorW eather V iew er


O1Dataset Requests

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


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 .


Page:

OOASIS SE

AKBocast

A0A0A0

AKB23 14

x01/05/2002

Distribute ProductsA3

I2Ready Produc t s

I1Ready Spec if ic a t ions

C1 Communic a t ions Pro t oc o lsC3 Produc t Request s

O1Rec e ived Request s

O2M eteoro logy Produc t s


Fulf ill

Orde rs

1

S tage

Produc t s

2

Post

Product s

3

E ma il

P rod uc t s

4

M ail Se rve rW eb Se rve rProduc t ion Se rve rOrde r Desk

Produc t Order

Loc a l A rea Ne tw ork

C2 Sc hedules

W eb Request s

S taged P roduc t s

W ebs it e

M a il Compose r

Ema il P rot oc o ls

W eb Pro t oc o ls

Produc t Ca t a log

Diagram 45. ATP/A3 (Distribute Products)

The new decomposition diagrams are shown as the next four diagrams. Note that the single mechanism

attached to A3.1 is disaggregated in diagram A31.

Diagrams ATP/31 and ATP/32 contain only two boxes. This is allowed by IEEE 1320.1, wherein the

allowable number of boxes in a decomposition diagram is established as between 2 and 9. In general we

should note that best IDEF0 modeling practices still follow the original FIPS PUB 184 limits: at least

three boxes but no more than six boxes. Here we have invoked the less restrictive IEEE 1320.1 rule

because our immediate interest is to match mechanisms to activities. The presence of only two boxes in

these diagrams is a flag to other systems engineers that we are have not yet really completed our analysis

of these activities.

70


Used at: 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.


Page:

OOASIS SE

AKBocast

A3A3A3A3

AKB29 15

x01/05/2002

Fulfill OrdersA31

I1Produc t Ca ta log

C1 Sc hedules


C3 W eb Request s


O2Produc t Orde r

M 1 Order Desk

Co llect

Reques ts

1

Order

Products

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 Spec if ic a t ion

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


Page:

OOASIS SE

AKBocst

A3A3A3A3

AKB28 16

x01/05/2002

Stage ProductsA32

I1Ready Produc t s

C1 Produc t Orde r C2 Produc t Request s

O1St aged P roduc t s

M 1 Loc a l A rea Ne tw orkM 2 Produc t ion Serve r

S tage

Ready

Products

2

Pro vide

Product

A cces s

3

Net w ork Ready P roduc t s

71


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.


Page:

OOASIS SE

AKBocast

A3A3A3A3

AKB27 17

x01/05/2002

Post ProductsA33

I1S t aged P roduc t s


C1 Produc t Orde r C2 Produc t Request s

C3 W eb Pro toc o ls

O1W eb Request s

O2M et eoro logy P roduc t s

M 1 W ebsit e M 2 W eb Se rver

S elect W eb

Products

1

Pu b lis h

Page

2

S erve

Page

3

F ulf illment Anoma lies

Produc t Ca ta log

Ava ilab le URL

Produc t Se le c t ions

Diagram 48. ATP/A33 (Post Products)

72


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.


Page:

OOASIS SE

AKBocast

A3A3A3A3

AKB26 18

x01/05/2002

Email ProductsA34

I1S taged P roduc t s

C1 Produc t Orde rC2 Ema il P ro t oc o ls

O1M eteoro logy P roduc t s

M 1 M ail Compose r M 2 M a il Se rve r

S pecify

Email

Pro duct

1

Cons truct

Email Pro duct

Mes s age

2

Em ail

Pro du ct

Mes sa ge

3

Ema il M essages

Ema il Cont ent Spec if ic a t ion Ema il De live ry Spec if ic a t ion

Email P rope 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


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 .


Page:

OOASIS SE

AKBocast

A-0

AKB15 3

x01/06/2002


Dist ribut e

Produc t s

3

Genera t e

M et eoro logy

Produc t s

2


I2Sate llit e Imagery

C 4 Produc t Request s



O2M et eoro logy Produc t s

M easure Oc ean

Obse rvables

1


M 3 W eathe r F orec ast e r

C3 Sc hedules

C2 Image S tandards


C 6 M et eoro logy Dat a S tandards

M 2 Argos Sys t em M 1 Santa Narida Buoy Sys t em

BuoyReady P roduc t s


T asking


Fulfillm ent Te chnicia n

Sy ste m C ontro lle r

Product Enginee 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


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A1A1A1

AKB17 5

x01/06/2002


C 1 Sc hedules C3 Communic a t ions P ro t oc o ls

O1Data Co lle c t ion Commands

Generat e

Commands

1

Send

Commands

2

Re lay

Commands

3

Rec e ive

Commands

4

M 2 Argos Syst em

Sent Commands

Re layed Commands

Sat e llit e P ro t oc o lsInt e rne t P ro t oc o ls

Unsent Commands

M 4 Buoy Rec e ive rM 3 Sant a Narida Buoy Syst em

C2 T asking

Brow se rCont ro l Pane l

M 1 System Cont ro lle r

Diagram 51. ATP/A11 (Control Data Collection) with System Controller

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A1A1A1

AKB19 7

x01/06/2002

Transmit Collected DataA13

I1Co lle c t ed Data


C2 M eteoro logy Data S tandards

O 1Oc ean Obse rva t ions

Send Dat a

1

Re lay Da t a

2

Rec e ive Da t a

3

M 2 Argos Syst em

Sent Da t a

Re layed Data

Int ernet P ro t oc o ls

Sa te llit e P ro t oc o ls

M 3 Sant a Narida Buoy Syst emM 4 Buoy T ransmit t e r

Brow se r

M 1 System Cont ro lle r

75


Diagram 52. ATP/A13 (Transmit Collected Data) with System Controller

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A21A21A21

AKB24 10

x01/06/2002

Save ObservationsA211

I1Oc ean Obse rva t ions


O1Obse rva t ion Spec if ic a t ions

O2Saved Obse rva t ions

M 2 Obse rva t ion P roc essor M 3 Database Engine

S pecify

Obs ervat io n

D ata S tandards

1

Prepare

Observat io ns

2

Main tain

Observat io ns

3

Clean Obse rva t ions

Obse rva t ions Sc hema

Dat a Element M e tada ta

M 1 Data Enginee r

Diagram 53. ATP/A211 (Save Observations) with Data Engineer

76


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A21A21A21

AKB25 11

x01/06/2002

Create DatasetsA212

I1Saved Obse rva t ions



O1Datase t Spec if ic a t ions

O2Saved Datase t s

M 2 Dat ase t P roc essor M 3 Database Engine

S pecify

D atas et D ata

S tandard s

1

Prepare

D atasets

2

M ain tain

D atas ets

3

Dat ase t Sc hema

Dat ase t M e t ada t a

M 1 Dat a Enginee r

Diagram 54. ATP/A212 (Create Datasets) with Data Engineer

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

A21A21A21

12

x01/06/2002

Retrieve DatasetsA213

I1Saved Dat ase t s

C1 Datase t Request s


O1T asking

O2Unfilt e red Datase t s

M 2 Produc t P roc essorM 3 Database Engine

S pecify

Products

1

R et rieve

D ata s ets

2

Package

D atasets

3

Cata log

Dat ase t Se le c t ion

Re t rieved Dat ase t s

P roduc t Const ruc t ion Rules

Produc t P rope rt ies

M 1 Produc t Enginee r

Diagram 55. ATP/A213 (Retrieve Datasets) with Product Engineer

77


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A0A0A0

AKB23 14

x01/06/2002


I2Ready Produc t s


C1 Communic a t ions P ro t oc o lsC3 Produc t Request s




F ulf ill

Orde rs

1

Stage

Produc t s

2

Post

Product s

3

E ma il

P rod uc t s

4

M a il Se rve r

W eb Se rve rP roduc t ion Se rve rOrde r Desk

Produc t Order

Loc a l A rea Ne tw ork

C2 Sc hedules

W eb Request s

S t aged P roduc t s

W ebs it e

M a il Compose r

Ema il P ro t oc o ls

W eb Pro toc o ls

P roduc t Ca t a log

M 1 F ulf illment T ec hnic ian

Diagram 56. ATP/A3 (Distribute Product) with Fulfillment Technician

When we turn to developing the requirements model for operations (RTO), we have already the

advantage of the work we have done to develop the RTP and ATP models. We have deliberately given

the RTO model the same Viewpoint and the same Purpose as the RTP models. This should allow us to

reuse significant portions of the structure and content of our Product models.

As we did before, we begin by assigning helpful names to our A-1 functions, regularizing the box

numbers, and naming the A-1 diagram itself:

78


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

R ecommended

Publication

Reader Date

P .


Page:

OOASIS SE

AKBocast

AKB5 1

x12/21/2001

Stakeholder Context of Routing P roduct GenerationA-1

Context o f

Rout in g

P rodu ct

Gene ra t io n

0

S upp ly

Cap ital

Resources

2

P rovide

O bse rvab le s

3

Control

Operat ion s

4

P lan

Shipp ing

Routes

5

1

Gene ra te

Rout ing

Products

x

con trol request

Main tenance Request

inpu t request

Product Requests

Rou te Planner

EnvironmentN OA ANW S Gene ra l Manage r Santa Na rida Buoy Sys tem

Minis te ria l Reques ts

Ocean Ob servab les

Rou ting Products

Rou te P lan

System Status

Routing Decis io ns

NONE

0

xMeasured Observab les

repa ired buoy

b roken buoy

Se rvice Agreements

Main tenance N otification

m echan ism request

Buoy Techn ical Data

M in isteria l Repor tsx

M in isteria l Quest ions

Rou te Plann ing Requ irem ents

A rgos

Com m un icat ions S atellites


Diagram 57. RTO/A-1 (Stakeholder Context of Routing Product Generation)

The corresponding A-0 diagram is:

79


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 quire me nts TO-B E Ope rations (RTO)

Page:

OOASIS SE

AKBocastTop

AKB1 2

x12/26/2001

Context of Routing Product GenerationA-0

G enerate

R ou t ing

Pro ducts

0

Purpose:





TOP

0

Produc t Request s

M inis t e ria l Request s

Oc ean Observables

Rout ing Produc t s

S y ste m

Rout ing Dec is ions

M easured Obse rvables


M in is te r ia l

Route P lanning Requirement s

O cean

M ea s u r e d

M inis t e ria l Report s

R ou tin g

Syst em S ta t us

Argos Syst em

Communic a t ions P ro t oc o ls

Sa nta Narida Buoy Syst em

Route P lanner

Diagram 58. RTO/A-0 (Context of Routing Product Generation)

We decompose the A0 function in the following diagram. In this diagram, we have made some

assumptions and refracted them as system requirements:

• A-1 shows routing decisions fed back into the system. However, here we capture such decisions

as routing products -- these products in this view include the decisions made by the shipping

router, i.e., document the decision by a downloaded itinerary.

• We already know what activities are needed to measure ocean observables, so we will not

decompose this activity again. We show no tasking because we assume that routing products will

use standard datasets. Buoy status is unbundled from ocean observations; buoy status should be

provided by the system controller.

• We will not decompose either A3 or A4. Informed intuition suggests that these are conventional

reporting functions with nothing much interesting for a systems perspective to be revealed by

decomposition.

In the A0 diagram, A2 (Generate Routing Products) has the same structural position as Generate Products

and Distribute Products together have in the Products model. Here the two reporting activities have been

80


represented, one for routine administrative reporting and the other for reporting system performance and

goal attainment to the Santa Narida government.

Used at: 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 .


Page:

OOASIS SE

AKBocast

A-0

AKB7 3

x12/26/2001

Generate Routing ProductsA0

Genera t e

Rout ing

Produc t s

2

I1Oc ean Obse rvables O2


O3M inis t e r ia l Report s

O4Rout ing P roduc t s

O1Syst em St at us

M 3 Argos Syst em


C 4 Rout ing Dec is ions

C3 M inis t e ria l Request s

C2 Rout e P lanning Requirement s

C1 M a int enanc e Not if ic a t ion


M eas ure

Oc e an

Obse rv ables

1

Oc ean Oberva t ions

2

Report Syst em

Sta tus

3

Report Syst em

Ac c omplishment s

4

St a tus Request

Buoy S t a tus

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.


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 tha t routing

products will use

standard da tasets. Buoy

status is unbundled from

ocean obse rvations;

buoy status should be

provided by the system

controller.

Ac t iv it y S t a tus

3 We will not decompose either A3 or A4.

Informed intuition sug gests that these are

conventional reporting functions with nothing

much interesting to be revealed by

decomposition.

Rout ing P roduc t s

M 2 Rout e P lanner

Diagram 59. RTO/A0 (Generate Routing Products)

We decompose A2 (Generate Routing Products) as shown in the following diagram. Not surprisingly, this

diagram shows the same general structure for product development we explored in the Products model:

generate datasets, filter datasets, produce final products. It is the A23 (Propose Itineraries) where we

expect to see requirements that may be significantly different from those seen in the Products model.

The structure of the decomposition of A23 should seem familiar. It is based upon the stakeholder model

for a shipping route planner. We have incorporated the logic of SRP/A0 within the scope of the

prospective system because the capabilities to be used by the route planner are to be provided by the

Santa Narida Buoy System.

In the next step we transform our Operations requirements model into an architecture model by allocating

system behaviors to hardware and software components. As with our Products model, we will allocate

system behaviors to agents after we have examined this allocation to hardware and software.

81


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A0A0A0A0

AKB9 6

x12/26/2001


I1Oc ean Obervat ions

C1 Communic a t ions P rot oc o ls




O2A c t iv it y S t a tusGenerat e

Dataset s

1

F ilt e r

Da tase t s

2

Prop ose

It ine ra rie s

33

Unfilt e red Dat ase t s

F ilt e red Datase t s

Datase t Request s

M 1 Route P lanner

Diagram 60. RTO/A2 (Generate Routing Products)

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A2A2A2

AKB10 7

x12/26/2001

Propose ItinerariesA23

I1F ilt e red Datase t s O2

Ac t iv it y St a tus


De te rmine

F eas ib le

Routes

1

F orec ast

Rout e

W eat he r

2

Est imate

S hip

Sc hedu les

3

Se lec t

Opt imum

It ine rary

4

C2 Produc t Request s C 1 Route P lanning Requirement s

O1Datase t Request s

M 1 Route P lanne r


Se le c t ed It ine rary

Est imated It ine ra rie s

Route F orec ast s

F eas ib le Rout es

82


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

AKBocastTop

AKB1 2

x12/26/2001

Context of Routing Product GenerationA-0

G enerate

Ro ut ing

Products

0

Purpose:





TOP

0

Produc t Request s


Oc ean Obse rvables


S y s te m



M in is te r ia l

Rout e P lanning Requirement s

O cean

M e a s u r e d

M inis t eria l Report s

R o u tin g

Syst em St a tus

Argos Syst em

Communic a t ions P rot oc o ls

Santa Narida Buoy Syst em

Route P lanner

Diagram 62. ATO/A-0 (Context of Routing Product Generation)

Our A0 decomposition with abstract components allocated now looks like the next diagram. Note that we

have simply denoted our system components that Measure Ocean Observables as Buoys, because we are

adding nothing new to our understanding of requirements for the sensors, their platforms, or their

communications. For the two reporting functions, we have ascribed a System Status Reporter component

and a System Performance Reporter component as mechanisms.

When we decompose the A2 activity, we determine that new requirements are not raised for A2.1

(Generate Datasets). Instead of decomposing this activity, we bundle the individual “processors” of our

requirements model under the label Processing Engines to remind us that several abstract components

have been previously allocated to carry out A21.

83


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A-0

AKB7 3

x12/26/2001


Genera t e

Rout ing

Produc t s

2





O1System S t at us

M 3 Argos Syst em



C2 Route P lanning Requirement s



M eas ure

Oc e an

Observ ables

1


2

Report Syst em

S ta tus

3

Report Syst em

Ac c omplishment s

4

Sta t us Request

Buoy S t a tus




M 2 Rout e P lanne r M 1 Santa Narida Buoy Syst em

System Pe rfo rmanc e Report e r

Syst em S ta t us Report erBuoys

Diagram 63. ATO/A0 (Generating Routing Products)

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A0A0A0A0

AKB9 6

x12/26/2001








Dataset s

1

F ilt e r

Da tase t s

2

Prop ose

It ine ra rie s

33

Unfilt e red Dat ase t s

F ilt e red Datase t s

Datase t Request s

M 1 Rout e P lanne r


Pro ces s ing Eng ines

Database Engine F ilt e r P roc essor

Brow se rW eb Server

It ine ra ry Engine

84


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 .


Page:

OOASIS SE

AKBocast

A2A2A2

AKB10 7

x12/26/2001

Propose ItinerariesA23

I1F ilt e red Dat ase t s O2

Ac t iv it y St a t us


De te rmine

F eas ib le

Routes

1

Forec ast

Route

W eathe r

2

Est imate

S hip

Sc hedu les

3

Se lec t

Opt imum

It ine ra ry

4

C2 Produc t Request s C 1 Route P lanning Requirement s

O1Dat ase t Request s

M 3 Brow ser


M 2 It ine ra ry Engine

Se lec t ed It ine ra ry

Est imated It ine ra rie s

Route Forec ast s

F eas ib le Routes

M 1 W eb Se rve 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


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 .


Page:

OOASIS SE

AKBocast

A-0

AKB11 3

x12/26/2001


Genera t e

Rout ing

Produc t s

2





O1Syst em St at us

M 3 Argos Syst em

C4 Produc t Reques t s





M eas ure

Oc e an

Obse rv ables

1


2

Report Syst em

Sta tus

3

Report Syst em

Ac c omplishment s

4

St a tus Request

Buoy S t a tus




M 2 Rout e P lanner M 1 Sant a Narida Buoy Syst em

System Pe rfo rmanc e Report e r

Sys t em St a tus Report e rBuoys

Adm inis tra torAdm inis tra tor

Diagram 66. ATO/A0=AKB11 (Generate Routing Products)

86


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 .


Page:

OOASIS SE

AKBocast

A0A0A0A0

AKB9 6

x12/26/2001








Dat aset s

1

F ilt e r

Da taset s

2

Prop ose

It ine ra rie s

33

Unfilt e red Datase t s

F ilt e red Dat ase t s

Dat ase t Request s

M 1 Rout e P lanner




Brow serW eb Se rver

It ine ra ry Engine

D a ta ba se Adm inis tra tor

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


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 se

1F

A ctiv ity in

B lue Us e

C a s e

2F

A c tiv ity in

B o th B lue

a nd Red

Use C a se s3F

Figure 5. Conventions for Marking Activities WRT Use Cases

Then we raise the involved actors to the outermost box that encompasses the activities of the use case.

Here, this is quite simple, for the original partitioning of behavior neatly matches our initial use case

considerations:

88


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.

Model: OOASIS Sys te m Us e Cas e s (OSU)

Page:

OOASIS SE

AKBocast

A-0

AKB25 3

x01/08/2002


Dis t ribut e

Produc t s

3

G enerate

M eteorology

P roducts

2


I2Sa t e llit e Imagery





Measure O cean

O bservables

1


M 3 W e a the r Fore ca ste r

C3 Sc hedules

C2 Image S tandards


C6 Met eoro logy Dat a S tandards

M 2 Argos Sy ste m M 1 Santa Narida Buoy Syst em

Ready P roduc t s


T asking


Buoys


Product Engine 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


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:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A-0

AKB25 3

x01/08/2002


Dis t ribut e

Produc t s

3

G enerate

M eteorology

P roducts

2







Measure O cean

O bservables

1



C3 Sc hedules

C2 Image S tandards




Ready P roduc t s


T asking


Buoys


Product Engine e r


Diagram 69. OSU/A0=AKB24 (Generate Meteorological Products)

and our corresponding use case diagram looks like the next diagram:

Environment


Weather Forecaster

Product EngineerRun Weather Models


<<depend>>

Figure 7. Use Case Analysis: Run Weather Models

90


Picking up with A234, we continue our traversal of the decomposition hierarchy, looking for the next

potential actor while following the trail of artifacts that appear destined for Televisio Santa Narida. This

trail takes us to function A32, which is controlled by A31, to which the agent mechanism Fulfillment

Technician has been assigned. A32 (Stage Products) is the activity that makes available weather forecast

artifacts for Televisio Santa Narida; the additional activities A33 and A34 appear to be extensions to the

use case that incorporates A32. This is shown in the following diagram:

Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A0A0A0

AKB26 11

x01/08/2002


I2Ready P roduc t s

I1Ready Spec if ic at ions

C1 Communic a t ions Pro t oc o lsC3 Produc t Request s




Fulfill

O rders

1

S tage

P roducts

2

P ost

P roducts

3

E mail

P rod ucts

4

M a il Se rve rW eb Se rve rP roduc t ion Se rve rOrde r Desk

Produc t Order

Loc a l A rea Ne tw orkM a il C lient

C2 Sc hedules

W eb Request s

S t aged P roduc t s

W ebs it 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


Used at: Context:

Title: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date

Rev:

Working

Draft

Recommended

P ublication

Reader Date

P.


Page:

OOASIS SE

AKBocast

A-0

AKB25 3

x01/08/2002


Dis t ribut e

Produc t s

3

G enerate

M eteorology

P roducts

2







Measure O cean

O bservables

1



C3 Sc hedules

C2 Image S tandards




Ready P roduc t s


T asking


Buoys


Product Engine e r


Diagram 71. OSU/A0=AKB25 (Generate Meteorological Products)

and the expanded system use case diagram looks like the following figure. Note that the system use cases

we have identified in this use case diagram associate with all stakeholders addressed by our Products

architecture model.

Using the same approach, we analyze our Operations architecture model to enhance our system use case

understanding. The external stakeholders specifically addressed by the Operations model that have not

already been addressed are NOAA as buoy maintenance, NWS as General Manager, and the Shipping

Route Planner. Our additional internal stakeholders are the System Administrator and the Database

Administrator.

We have already encompassed activity A1 within the system use case Measure Ocean Observables.

Thus we begin our traversal with the A2 activity. In the A2 diagram we find our Database Administrator

as mechanism to A2.1 (Generate Datasets), which was previously subsumed under the use case Stage

Products. We also see again the Route Planner as mechanism to A2.3 (Propose Itineraries). The Route

Planner uses the prospective system to gain a benefit but the Database Administrator is an agent of the

system itself; the Database Administrator does not have an autonomous purpose as does the Route

Planner.

92


Environment

Tsunami Warning Center

Institute Scientist


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


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



Institute Scientist



Weather Broadcaster


Weather Forecaster

Stage Products

Run Weather Models


Product Engineer



<<depend>>

<<depend>>


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


I1Oc ean Oberva t ions





O2Ac t iv it y St a t us

G enerate

D atasets

1

F ilter

D a tasets

2

P rop ose

Itinera ries

33

Unfilt e red Datase t s

F ilt e red Dat ase t s

Dat ase t Request s

M 1 Route Pla nne r




Brow serW eb Serve r

It ine ra ry Engine

D a ta ba se Adm inis tra tor

Diagram 72. OSC/A2 (Generate Routing Products)

94



Institute Scientist



Weather Broadcaster


Weather Forecaster

Stage Products


Run Weather Models


Product Engineer


<<depend>>

<<depend>>

Route Planner

Propose Itineraries

<<depend>>


Environment

Figure 10. Use Case Analysis: Propose Itineraries

Now as shown in the final markup of the OSC/A0 diagram:

95


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


G enerate

Routing

P roducts

2


Measured Obse rvables



O1Syst em S t a t us

M3 Argos Sy ste m






Me asure

O ce a n

O bse rv able s

1


2

Report S ystem

S tatus

3

Report S ystem

Accomplishments

4

Sta tus Request

Buoy S t a tus




M 2 Route Pla nner M1 Sant a Narida Buoy Syst em

System Pe rfo rmanc e Reporte r

Syst em S t a t us Report e rBuoys

System A d m inistrato rSystem 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



Institute Scientist


Weather Broadcaster


Weather Forecaster

Stage Products


Run Weather Models


Product Engineer



<<depend>>

<<depend>>

Route Planner

Propose Itineraries

<<depend>>

System Administrator

Generate Reports

<<depend>>


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


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:

C1 S ched u les

O1Data Coll ec tion Com m ands

NOD E

C ontro l

P ane l

---

Ge ne ra te

Comm ands

1

NO D E

B row se r

---

Send

Com m a nds

2

D E VIC E

Argos

Syste m

---

Re lay

Com m a nds

3

D E VIC E

Buoy

R e ce ive r

---

Rec e ive

Com m ands

4

C2 Task ing

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


C 1 S ched u les

O 1D ata C ollect ion Com m and s

NO DE

C ontro lle r

W orksta tion

---

Cont ro l

P ane l,

B row se r

---

Ge ne ra te

Com m ands

1

DEVIC E

Argos

Syste m

---

Re la y

Com m ands

3

DEVIC E

Buoy

R e ce ive r

---

Re ce ive

Com m ands

4

C 2 Task ing

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:


C1 Sc hedule s

O1M easured Obse rv ab les

O 2Oc ean Observa t ions

C2 T asking

M 1 Syst em Cont ro lle r

D EVIC E

Buoy

Transmitte r

-- -

Send Dat a

1F

D EVIC E

Argos

S ystem

---

Relay Data

2F

NO D E

C ontroller

W orks tation

- --

Bro w s e r

- --

Receiv e Data

3 F

D EVIC E

Buo y

S ensor s

-- -

Sen s e

Obs ervable s

4F

NO D E

Buoy P rocessor

---

Me a s u re me n t

P ro ce s s o r

---

Gath er

Meas u rem en ts ;

Pac kage Data

5F

NO D E

C ontroller

W orkstation

---

C o n tro l P a ne l;

Bro w s e r

---

Gen erate

Com m ands

6F

DEVIC E

Argos

System

---

Relay

Com man ds

7F

D EVIC E

Buoy

Rece iver

---

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


• 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:

I1Ocean Ob se rvable s

C1 Sc hedule s

O 1M easured Observable s

O 2Oc ean Obse rv a t ions

C2 T asking

M 1 S yst em Cont ro lle r

D EVICE

Buoy

Transmitter

---

Sen d Data

6F

D EVIC E

Buoy S ensors

---

Sen s e

Obs ervables

4F

N O D E

Buoy P rocessor

---

M e a s u re me n t

P ro ce s s o r

---

G ath er

Measu rem en ts;

P ackage D ata

5F

N O D E

C ontroller

W orkstation

---

C o n tro l P a n e l,

B ro w s e r

---

Gen erate

Com m an ds

1F

D EVIC E

Argos

S ystem

---

Relay

Comm an ds ;

Relay Data

2F

D EVIC E

B uoy

Rece iver

---

Receive

Com m an ds

3F

1

23

5

4

6


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 uoy

Tra nsm itte r

- - -

Send Dat a

4

DEV IC E

B uo y

Se nsors

- - -

Sense

Obse rvab le s

7

NO DE

B uoy

P roc e ssor

- - -

M ea surement

P roc essor

- - -

Gathe r

M easu rem ent s;

Pac kage Da ta

2

NO DE

C o ntro lle r

W orksta tion

- - -

Cont ro l Pane l,

Brow se r

- - -

Genera t e

Com m ands

1

DEV IC E

Argos

Sy ste m

- - -

Re lay

Com m ands;

Re lay Da t a

3

DEV ICE

B uoy

Re ce ive r

-- -

Rec e iv e

Com m ands

5

C1 Sc hedules

C2 T asking

M 1 Syst em Cont ro lle r

Oc ean Obse rva t ionsO2

I1 O1Oc ean Obse rvable s M easured Obse rvable 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


I 1Ocean Observation s

O 3Un filtered Datasets

O2R ead y S pec ificat ions

Ob servat ion Sp ec ificat ions

Dataset S pec ificat ions

C 1 Received R equests

O1Task ing

C 2 Dataset Requests

M1 Prod uct Eng ineer

Data Eng ineer

N O D E

Prod uc t

Processor

---

Specify

Products;

Package

D ata se ts

5

D EV ICE

D atab ase

En g in e

---

R e tr iev e

D a ta se ts

6

N O D E

D atase t

Process or

---

Specify

D atase t D ata

Standard s;

Prepar e

D atase ts

3

D EV ICE

D atab ase

En g ine

-- -

M ainta in

D a tase ts

4

NO D E

O b servation

Processor

---

Specify

Obse rva tion

D ata S tanda rds;

Prepare

Obse rva tions

1

D EV ICE

D atab ase

Eng in e

---

M a inta in

Observa tions

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:


O3Un filtered Datasets

O2Ready S pecificat ions

Observation S pecifications

Dataset S pecifications


O1Tasking

C2 Dataset Requests

M1 Product Eng ineer

Data Eng ineer

NO D E

Prod u ct

Processor

---

Specify

Products;

Package

Datase ts

5

N OD E

Dataset

Processor

---

Specify Datase t

D ata Standards;

Prepare

D atase ts

3

NO D E

Ob servation

Processor

---

Specify

Observa tion

D ata Standards;

Prepare

Observations

1

D EV ICE

D atab ase

En g in e

---

M ainta in

Observa tions;

M a inta in

D atase ts;

R e tr ieve

D atase ts

2


Our NDC transformation of diagram ONA/A23 is shown in the next figure:

101


I 1F iltered Datasets

I2S atellite Im ag e ry

C 2 S chedu les

O2Ocean Im ag ery

O3Forecast Text


NO D E

Fore ca ste r

W orksta tion

---

W ea the r

V ie we r

---

Write

Wea the r

Sc rip t

2

NO DE

W e athe r

M a chine

---

Run Wea the r

Mode ls

1

NO DE

Image

M achine

---

Image

Gene ra to r;

Image

P roce s so r

---

Ge ne ra te

Symbo l ic

I mages ;

Combine

I mages

3


O1Dataset Req uests

Figure 19. First NDC Transformation of ANO/A23

When we now raise these fragments to the A2 level, the A2 diagram looks something like:

I1Ocean Ob servation s

I2Satell ite Im agery

C 1 S chedu les

O2Ready S pecificat ion s

O3R eady Products


NO DE

Filte r Engine

---

F il te r

Da ta se ts

5

F ilte red DatasetsUn filtered Datasets

Forecast Text

Ocean Im agery

Forecast Products

D ataset Products

C 2 R eceived R equests

O1Task ing

M2 Pro duct Eng ineer

NO D E

Fore ca ste r

W orksta tion

---

W ea the r

V iewe r

---

Write

Wea the r

Sc rip t

7

NO DE

W e a the r

M a chine

---

Run Wea th e r

Mode ls

6

NO DE

Ima ge

M a chine

---

Im age

Gene ra to r;

Im age

P ro ce s s o r

---

Gene ra te

Sym bo l ic

I ma ges ;

Com bine

I m ages

8

Observation S pecifica t ion s

Dataset S pec ificat ion s

D ata Eng ineer

NODE

Product

Processor

- --

Spec ify

P ro ducts;

Package

Datasets

4

NO DE

Dat ase t

Proce ssor

- --

Spe cif y

Datase t Data

S tand ards;

Prep are

Data sets

3

NO DE

O bservation

Processor

---

Specif y

O bse rva tion

Data

Standards;

Prepare

O bse rva tions

1

DEVIC E

Database

Engine

---

M ainta in

O bserva tions;

M a inta in

Datase ts;

Re trieve

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


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.


I2S atellite Im agery

C1 S chedu les

O2Ready S pec ificat ions

O3Ready Produ cts

M 1 W eather Forecaster

Forecast Text

Ocean Im agery

Forecast Produ cts

Dataset Prod ucts

C2 Rece ived Requests

O1Tasking

M 2 Prod uct Eng ineer

NO DE

Fore ca ste r

W orksta tion

---

W ea the r

V iew e r

---

Write

We a the r

Sc rip t

5

NO D E

W e a the r

M a chine

---

Run Wea th e r

Mode ls

4

NO D E

Im a ge

M a chine

---

Im age

Ge ne ra to r;

Im age

P roce s s o r

---

Gene ra te

Sym bo l ic

I m ages ;

Com bine

I m ages

6

Data Eng ineer

NO DE

Product

M achine

---

Pro duct

Pro cesso r;

F ilte r Engine

---

Spec ify

Pro ducts;

Package

Datasets;

F ilter Datase ts

3

NO DE

Data

M achine

-- -

O bserv ation

Processor ;

Datase t

Processo r

-- -

Spec ify

O bservation

Data

Standards ;

Prepare

O bservations ;

Spec ify

Dataset Data

Standards ;

Prepare

Datase t s

1

DEV IC E

Data base

Eng ine

- --

M ain ta in

O bserv ations;

M a in ta in

Data sets;

Retr ieve

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 2Ready Products

I1Ready S pec ificat ion s

C2 Product Requests

O1R eceived Requests

O2Meteorology Products

C1 S chedu les

M1 cFu lfillm en t Techn ic ian

NO DE

M ail

C om pos er

- --

Spec ify Em ail

P roduc t;

Constru ct

Em ail Produ ct

M essage

5

DEVIC E

Em ail S erv er

---

Em a il P roduct

M essage

7

NO DE

Product

W ebsite

---

Se lect W eb

Products;

Publish Page

4

DEVIC E

W eb S erv er

---

Serve

Page

6

N O DE

Produ ction

S erver

---

Stage Ready

Pro ducts

2

DEVIC E

L oca l A rea

Network

---

Prov ide Product

Access

3

NO DE

F ulfillm ent

W orkstation

---

O rder Desk : Request

Lo gge r; O rder Lo gge r

---

Co lle c t Requests;

O rder P roducts

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


Buoy


I2S ate llite Im agery

O 1Measu red Observab les


System Controller

Produc t En g ineer

NO DE

M ail

C om poser

---

Spec ify Em ail

Product;

Construct

Em ail Product

M essage

1 7

DEVIC E

Em ail S erv er

---

Em ail P roduct

M essage

19

NO DE

Produ ct

W ebsite

---

Select W eb

Product s;

Publish P age

16

DEVICE

W eb S erver

---

Se rve

Page

18

NO DE

Production

S erver

---

Stage Ready

Products

14

DEVIC E

L ocal A rea

Network

---

Prov ide Product

Access

1 5

NO DE

Fulfillm ent

W orkstation

---

O rde r Desk: Request

Lo gger; O rder Lo gger

---

Colle ct Requests;

O rder P roducts

13

NO DE

Fore caste r

W orksta tion

---

W ea the r

V ie w e r

---

Write

We a the r

Sc rip t

11

NO DE

W e athe r

M achine

---

Run Wea the r

Mode ls

9

NO DE

Image

M achine

---

Image

Ge ne ra tor;

Image

P ro ce sso r

---

Ge nerate

Sym bol ic

I mages ;

Com bine

I m age s

12

Data Eng ineer

NO DE

Product

M achine

---

Pro duct

Pro cesso r;

F ilte r Eng ine

---

Spec ify

P ro ducts;

Package

D atase ts;

F ilter D a tasets

7

NO DE

Data

M achine

---

O bse rvat ion

Proce ss or;

Da ta se t

P ro ces so r

---

Spe c ify

O bse rvat ion

Data

Standa rds ;

P re pa re

O bse rva t ions

;

Spe c ify

Da ta se t

Data

Standa rds ;

P re pa re3

DEVIC E

Database

Engine

---

M ainta in

O bservat ions;

M ainta in

Da tase ts;

Re trie ve

Datasets

5

DEVIC E

B uoy

T ransmitte r

---

Se nd Da ta

10

DEVIC E

Buo y

Se nsors

---

Se ns e

O bse rvab le s

6

NO DE

B uoy

P ro cessor

---

Me as ure me nt

P rocesso r

---

Ga the r

Me as ureme nts ;

Pa ckage Data

8

NO DE

C ontro lle r

W orksta tio n

---

Contro l P an e l,

B row se r

---

Ge ne ra te

Comm an ds

1

D EVIC E

Argos

Syste m

---

Re la y

Com m ands ;

Re la y Da ta

2

DEVIC E

B uoy

R e ce ive r

---

Re ce ive

Com mands

4

DEVIC E

U se r

W orksta tion

---

Lo ca l A rea

Ne tw o rk;

B row se r;

Ema il C l ient

20

Fu lfil lm en t Techn ic ian

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


• 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


O1M easured Observables

M3 W eathe r F orec 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

DEVIC E

Email S erver

---

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 EVIC E

W e b S erver

---

Serve

Page

17

N O DE

P roduction

S erver

---

Stage Ready

Produ cts

14

DEVIC E

L ocal Area

N etw ork

---

Provide Produ ct

Acces s

15

NO D E

Fulfillment

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

NODE

F ore ca ste r

W orksta tion

- - -

W eat he r

V iew er

- - -

Wr it e

Weat he r

Sc r ipt

10NO DE

W e a the r

M a chine

- - -

Run Weathe r

M ode ls

8

NO DE

Im a ge

M a chine

- - -

Image

Genera t or;

Image

P roc essor

- - -

Genera te

Sym bo lic

Im ages;

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;

F ilte r E n g in e

---

Sp e cify

P ro d u cts ;

P a cka g e

Da ta s e ts ;

F ilte r

Da ta s e ts

6

N O D E

D ata

M achine

-- -

O b s e rva t io n

P ro ce s s o r;

Da ta s e t

P ro ce s s o r

---

Specify

Obs ervat ion

Data

Stan dards ;

Prepare

Obs ervat ion s ;

Specify

Datas et Data

Stan dards ;

Prepare

Datas ets

2

D EVIC E

D atabase

Engine

---

M ain ta in

Obs ervat ion s ;

M ain ta in

Datas ets ;

Retrieve

Datas ets

4

Buoy

DEV ICE

Buoy

Tra nsm itte r

- - -

Send Data

11

DEV IC E

B u oy

Se n sors

- - -

Se nse

Obse r vables

7

NO DE

B uoy

Proce ssor

- - -

M easurement

Proc esso r

- - -

Gat he r

M easurem ent s;

Pac kage Data

9

NO DE

C ontro lle r

W orksta t ion

- - -

Cont ro l Pane l,

Brow ser

- - -

Genera t e

Com m ands

1

DEV IC E

Arg os

Sy st e m

- - -

Re lay

Com m ands;

Re lay Data

3

DEV IC E

B u oy

Re ce iv e r

- - -

Rec e ive

Com m ands

5

DEVIC E

Use r

W orksta tion

- - -

Loc a l A rea

Ne t w ork;

Brow se r;

Ema il C lient20

Fulfillment TechnicianSystem Contro ller

Figure 24. Final NDC Transformation for ONA/A0

Now we turn to the Operations architecture model and apply these same transformations. Because the

Operations model shares activities and boundary arrows with our Products model, we also:

• Tunnel any common inputs, controls, outputs, and mechanism arrows that are treated essentially

the same in both models. For example, we tunnel Ocean Observables, Measured Observables,

and Argos System at their attachments to the A0 box in the ONB/A-0 diagram.

• Shade light red any activity boxes that are treated essentially the same in both models; we begin

with the assumption that the nodes, devices, and connections that have already been described for

that activity will continue to suffice. For example, we shade A1 (Measure Ocean Observables) in

the ONB/A0 diagram.

Diagram ONB/A2 deserves some comment. In this next figure, we have already shaded boxes A2.1 and

A2.2 a light red. First, note that we have removed the decomposition of activity A23. You should recall

our discussion of A231, which suggested that the undifferentiated attachment of all mechanisms to all

boxes indicated that we may have delved too deeply in our decomposition. For the task of generating

NDC information, this is clearly the case.

105


Used at: Context:

T itle: Number:

Author:

P roject:

Notes: 1 2 3 4 5 6 7 8 9 10

Date:

Rev :

Working

Draft

R ecommended

Publication

Reader Date

P .

Model: OOASIS NDC B (ONB)

Page:

OOASIS SE

AKBocast

A0A0A0A0

AKB9 6

x01/10/2002

Generate Routing P roductsA2

I1Ocean Obervations

C1 Product Requests

O1Routing Products

O2A ctiv ity S tatus

Genera te

Da tase ts

1

Fi lte r

Datase ts

2

Propose

It ine rarie s

3

Unfiltered Datasets

F iltered Datasets

Dataset Reques ts

M1 Route Planner

M2 Santa Narid a Buoy System

Processing Engines

Database Eng ine F ilter P rocessor

B rowserW eb Server

I tinerary Eng ine

D atabase Adm 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


C1 Product Requests

O2A ctiv ity S tatu s

Gene ra te

Da ta s e ts

1 Fi lte r

Da ta se ts

2

DEVIC E

W eb Serve r

---

P ropose

I tine ra rie s

4

Dataset R equests

M1 Rou te Planner

M2 S an ta N arid a B uoy S ystem

Database Adm in istrato r

NO DE

Itine ra ry

Engine

---

P ropose

I t ine ra rie s

3

Unfiltered Datasets

F iltered Datasets

Processing Eng ine

Database Eng ine

F ilter Eng 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:

I1Ocean Obervat ion s

C 1 Product R equests

O1R ou ting Produ cts

O2A ctiv ity S tatu s

Ge ne ra te

Da ta se t s

1 Fi lt e r

Da ta s e ts

2

D EVIC E

W e b Se rve r

---

P ropos e

I t ine ra rie s

4

D ataset Req uests

M1 R ou te P lan nerM2 S an ta N arid a B uoy S ystem

D atabase A d m in is trator

NO D E

Itine ra ry

Eng in e

---

P ropos e

I t ine 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


O3M in isteria l Reports

O4Rou ting Products

O1System S tatu s

C4 Product Requests

C3 M in isterial R equests

C1 Main tenance N otificat ionMeasu re

Ocean

Observab les

1

NO DE

Administra tor

W orksta tion

---

Sys tem Sta tus

Repo rte r;

Sys tem

Perfo rmance

Repo rte r

---

Report Sys tem3

Buoy S tatus

A ctiv ity S tatus

M2 Rou te Planner

Adm in istrator

Gene ra te

Da tas e ts

5 Fi lte r

Da ta se ts

6

DEVIC E

We b Se rve r

---

Propose

I t ine ra rie s

7

Dataset R equests

Database Adm in is trator

NO DE

Itine ra ry

Engin e

---

P ropos e

I t ine 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


NWS Data Center


O3Measured Ob servab les

M3 W eather ForecasterProdu ct Eng in eer

N O DE

M ail

Com p ose r

-- -

Spec ify E m ail

Prod uc t;

Cons truc t

Em ail Pro duc t

M es sage

18

DE VICE

Em ail S e rver

---

Em ail P roduc t

M e ssage

19

NO DE

P roduct

W ebsite

---

Se lec t W eb

Product s;

Publish P age

16

DEVICE

W eb S erver

---

Serve

Page

17

NO DE

Production

Server

---

Stage Ready

Products

14

D EVICE

Loca l A rea

Ne twork

---

Provide Produc t

Access

1 5

NO DE

Fulfillm ent

W ork station

---

O rder Desk:

Request

Lo gger; O rder

Lo gger

---

Collec t

Requests;

O rder Produc ts

13

NO DE

Forecaste r

W orkstation

---

W ea the r

V iewe r

---

Write

Wea the r

Sc ript

10

NO DE

W ea the r

M a chine

---

Run Wea the r

Mode ls

8

NO DE

Ima ge

Machine

---

Im age

Gene ra t o r;

Im age

Processo r

---

Gene ra te

Symbo lic

Im ages ;

Combine

Im ages

12

D ata Eng ineer

NO DE

Product

M achine

---

Pro duc t

Pro cesso r;

F ilte r Engine

---

Spec ify

Pro ducts ;

Package

Datasets ;

F ilter Datasets

6

NO DE

Data

M achine

---

O bservatio n

Pro cesso r;

Dataset

Pro cesso r

---

Spec ify

O bservation

Data

Standards;

Prepare

Observations;

Spec ify

Dataset Data

Standards;

Prepare

Datasets

2

DEVIC E

Databa se

Engine

---

M ainta in

O bservations;

M a inta in

Datasets;

Retrieve

Datasets

4

Buoy

DEVIC E

Buoy

T ra nsmitte r

---

Send Da ta

11

DE VICE

Buoy

Sensors

---

Sense

O bse rvab le s

7

NO DE

Buoy

Processor

---

Measurem ent

P roces so r

---

Gathe r

Measureme nts ,

Pac kage Da t a

9

NO DE

C ontrolle r

W orksta tion

---

Contro l Pane l ,

B rowse r

---

Ge ne ra te

Com mands

1

DEVIC E

Sate llite

C omms

---

A rgos

Sys tem

---

Re lay

Com mands,

Re la y Da ta

3

DEVICE

Buoy

R e ce ive r

---

Rece ive

Comm ands

5

DE VIC E

U se r

W or kstation

---

Lo ca l Area

N e two rk;

B rowse r;

Em a il C lient

2 0

Fu lfi llm en t Techn ic ianS ystem Controller

Route Planner

NO DE

Itine ra ry

Engine

---

Propose

I t ine ra rie s

30

NO DE

Administrator

W orkstation

---

Sys tem Sta tus

Reporte r; Sys te m

Pe rfo rm ance

Reporte r

---

Report Sys tem

Sta tus ; Report

Syst em

Accomp lis hmen ts

31

Datab ase Ad m in istrator

O1System S tatus Reports

O2Mini steria l R eports

A dm in istrator

Figure 29. First NDC Information Integration

It is now quite straightforward to translate this into a UML deployment diagram for OOASIS software

practitioners: there could be a one-to-one correspondence between the nodes, devices, and connectors in

our NDC integration diagram and the nodes, devices, and connectors of a UML diagram. However, as this

diagram is rather complex, we consider that the OOASIS practitioner looks to the NDC diagram not as a

specification of the hardware architecture but rather as a guide to constraints that hardware architecture

might impose on the design of software for the prospective system.

Our first NDC information integration view incorporates a number of boxes that rather than impose

constraints would allow the software designer to influence the selection of hardware upon which the

software would run. Perhaps a Weather Machine should run on a supercomputer; perhaps all application

logic that accesses the database should be run on one mainframe computer rather than on distributed

machines throughout the NWS Data Center.

Rather than proceed directly to the OOASIS NDC diagram, we first attempt to coalesce processor nodes

where the individual nodes of processor capability do not appear to impose constraints on software

design. In this sense, this reduction assumes that at this time it does not really matter to the system

concept what the eventual platform will be for these coalesced nodes. Such a reduction is conveyed in the

following figure.

In this reduction, we have coalesced:

• The system controller, order fulfillment, and system administrator workstations into the System

Workstation

• The Itinerary Engine, Product Webset, and Mail Composer nodes into the Web Services Machine

109


• The Data Machine, Product Machine, and Production Server into the Product Data Machine.

NWS Data Center



DEVIC E

Email

Se rve r

19

DEVIC E

W eb Serve r

17

DEVIC E

Area

Netw ork

1 5

NO DE

F orecaste r

W orksta tion

10

NO DE

W e ather

M a chine

8

NO DE

Imag e

Process ing

M achin e

1 2

NO DE

P roduct

Da ta

M achine

6

DEV IC E

Data base

Eng ine

4

Buoy

DEVIC E

Buoy

T ra nsmitte r

11

DEVIC E

Buoy

Sensors

7 NODE

Buoy

Processor

9

N OD E

Sys tem

Wo rksta tio n

1

DEVICE

Sate llite

C omms

3

DEVIC E

Buoy

R ece iv e r

5

DEVIC E

R em ot e

User

Worksta tion

20

Route Planner

NO DE

Web

S erv ices

M achine

30

O1S ystem S tatu s Reports

O2M in i steria l Reports

A dm in is trator

DEVICE

Network

User

Workstation

2

W eather Forecaster

Institu te S cien tist

W eather Presen ter

Tsunam i Center

NOAA (Buoy Main tenan ce)

Environm ent

S ystem Controller

Fu lfillm ent Techn ic ian

A rgus 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


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 Controller



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


• A minimalist stakeholder model

• A role in the stakeholder context diagram of one or more requirement and/or architecture models.

For each internal stakeholder we have identified a role in one or more decomposition diagrams of one or

more architecture models.

For each stakeholder we have concepts indicating the role they play with respect to the prospective

system, the behaviors expected of that role, the facilities (if any) provided by the prospective system for

that role, the inputs needed by the stakeholder to fulfill that role, the results of carrying out that role, and

the guidance required to successfully execute that role.

In addition to the environment, the identified external stakeholders are:

• Weather Forecasters

• Weather Scientists

• Weather Showmen

• Tsunami Warning Center

• Shipping Route Planners

• National Weather Service (NWS)

• Argos System

• National Oceanographic and Atmospheric Agency (NOAA)

The identified internal stakeholders are:

• System Controller

• Order Fulfillment Technician

• Database Administrator

• Administrator

• Product/Data Engineer

Note that a model glossary entry for each stakeholder (i.e., a labeled mechanism arrow) would be a

required element of a complete IDEF0 model.

Context Diagram

The context diagram required by the OOASIS software practitioner is created by a conflation of the A-0

diagrams of our architecture models. Because it is derived from IDEF0 modeling, this context diagram

provides richer semantics and is thus a richer source of useful information than most OOASIS software

practitioners will be accustomed to. Bear in mind that each term in this context diagram will have a

112


complete entry in the model or project glossary. We will leave the reduction of information in this

diagram to the OOASIS software practitioner.

USED AT: 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 DATEAKB ocas t

OOASIS SE

P.

M ODEL: OOASIS Conte xt Diagram (OCD)

To p

AKB1 1

x12/27/2001

Context of Meteorology Product GenerationA-0

G enerate Meteo ro lo gy Pro ducts

0

Produc t Request s



Route P lanning Requirement s

Communic a t ions Pro toc o ls

A rgos Syst em

Sant a Narida Buoy Syst em

Route P lanner

Oc ean Ob se rvables



M inis t e ria l Report s

Syst em St at us

Sat ellit e Im ag er y

Met eo ro logy Produc t s

M eteoro logy Dat a Requirement s

Sc hedules

Image S t andards

M eteoro logy Data S tandards

Nat iona l W eat he r Serv ic e

W eathe r F orec as t 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


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:


Institute Scientist


Weather Broadcaster


Weather Forecaster

Stage Products


Run Weather Models


Product Engineer



<<depend>>

<<depend>>

Route Planner

Propose Itineraries

<<depend>>


Generate Reports

<<depend>>


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


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 Controller



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



116

B. SANTA NARIDA BACKSTORY

B.1 SANTA NARIDA AND THE SANTA NARIDA OCEAN OBSERVATION

REGION

Santa Narida is an equatorial archipelago nation. Santa Narida is located on the equator due south of Los

Angeles. Santa Narida is roughly equidistant from the major Pacific Rim shipping destinations of Los

Angeles, Honolulu, the Panama Canal, and Guayaquil, Ecuador. Unusual for the Pacific Ocean, the Santa

Narida Islands form a rough circle around the central Baia del Handico. As a result, Puerta Oveida, Santa

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

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


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


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


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



122

C. OOASIS NODE-DEVICE-CONNECTOR DIAGRAM

The NDC Diagram is a representation of:

• Significant node groups. A significant node is a single computer processor (node) or a group of

interconnected nodes treated as single node because there are no constraints upon the freedom to

deploy software objects across that group of nodes.

• Abstract devices

• Interconnections among these nodes and devices. A node in OOASIS denotes a single computer

processor (and attached memory). More often, an abbreviation for significant node.

• Actors. An actor is a primary initiator and/or recipient of messages or other events to/from the 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

C. OOASIS Node-Device-Connector Diagram

nodes (at least up to the point where conditions of deployment freedom no longer apply). Moreover, all

nodes in a significant node group must have equal access to any abstract devices.

Note that a computer processor that figures into the system physical architecture — the physical pieces (in

particular, computer hardware and devices) of the system and how they are connected — but does not

host to-be-built software (i.e., it hosts only OTS Software Components) is represented as a device, not a

node.

Abstract devices are simply an abstraction of the hardware devices with which the software must interact

or which otherwise impact the software indirectly (e.g., software interacts with a transceiver directly, but

the software is also constrained to employ the protocol demanded by a satellite with which the software

must communicate through the transceiver). The device is abstract because initially you need know only

its general nature (e.g., transceiver, printer, monitor, sensor, type of sensor), not its particular hardware

model number or full specification.

Connectors are merely that; initially, they may show no more than which nodes have access to which

other nodes and devices. These connections may represent any kind of a by-wire or wireless

communication mechanism (e.g., the Internet, local area network, microwave).

Important attributes of nodes, devices, and connectors can be added to the NDC Diagram as they become

known or are posited for a feasibility study; for example: amount of memory attached to a node, the

maximum data rate of a device or connector. Of course, you will eventually need complete specifications

for nodes, devices, and connectors for Implement Software and, perhaps, to complete detailed failure

scenarios in the Elaborated System Use Cases.

Also track any associated volatilities within the NDC Diagram (e.g., alternative nodes, devices,

connectors) and similarly their attributes (e.g., denote the range of possible values for a volatile attribute).

Capturing uncertainty and volatility

The NDC Diagram can be augmented to show deployment information as well. This is particularly

convenient for OTS Software Components deployed on devices (that is, processors that do not otherwise

host any to-be-built software, as is frequently the case with legacy systems or large components such as

database management systems) because their deployment is not captured in the System Software

Deployment Models. Moreover, the System Software Deployment Models can be built as an extension of

the NDC Diagram, although this may be too cluttered in many cases.

Tool Hint: You can capture the NDC Diagram as a UML deployment diagram (without adding processes,

components, or objects). Actors and their associations to nodes and devices, as well as more detailed

specifications (e.g., node multiplicity), may be added with attached annotations (that UML modeling tools

usually support). You may find it helpful to define a special <<OTS>> stereotype for devices representing

OTS components.

— Source: OOASIS Web Site

124

D. NATIONAL DATA BUOY CENTER

National Data Buoy Center

Measurement Descriptions and Units

STATION ID five-digit WMO Station Identifier used since 1976. IDs can be reassigned to future deployments within the same 1-degree square.

DATE in UTC

TIME To the nearest hour, UTC.

Data are classified according to the following groups. Any data field that contains "9 filled" represents missing data for that observation hour. (Example: 999.9)

D.1 STANDARD METEOROLOGICAL DATA

ATMP Air temperature (Celsius). For sensor heights on buoys, see Hull Descriptions. For sensor heights at C-MAN stations, see C-MAN Sensor Locations.

WTMP Sea surface temperature (Celsius). For sensor depth, see Hull Description.

DEWP Dew point temperature taken at the same height as the air temperature measurement.

PRES Sea level pressure (hPa). For C-MAN sites and Great Lakes buoys, the recorded pressure is reduced to sea level using the method described in NWS Technical Procedures Bulletin 291 (11/14/80).

WSPD Wind speed (m/s) averaged over an eight-minute period for buoys and a two-minute period for land stations. Reported hourly. See Wind Averaging Methods.

WDIR Wind direction (the direction the wind is coming from in degrees clockwise from N) during the same period used for WSPD. See Wind Averaging Methods.

GST Peak 5- or 8-second gust speed (m/s) measured during the eight-minute or two-minute period. The 5- or 8-second period can be determined by payload. See the Sensor Reporting, Sampling, and Accuracy section.

WVHT Significant wave height (meters) is calculated as the average of the highest one-third of all of the wave heights during the 20-minute sampling period. See the Wave Measurements section.

APD Average wave period (seconds) of all waves during the 20-minute period. See the Wave Measurements section.

DPD Dominant wave period (seconds) is the period with the maximum wave energy. See the Wave Measurements section.

125

http://www.ndbc.noaa.gov/staid.shtml

http://www.ndbc.noaa.gov/hull.shtml

http://www.ndbc.noaa.gov/cmanht.shtml

http://www.ndbc.noaa.gov/hull.shtml

http://www.ndbc.noaa.gov/wndav.shtml

http://www.ndbc.noaa.gov/wndav.shtml

http://www.ndbc.noaa.gov/rsa.shtml

http://www.ndbc.noaa.gov/rsa.shtml

http://www.ndbc.noaa.gov/wave.shtml





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


http://www.ndbc.noaa.gov/adcp.shtml


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

http://www.ndbc.noaa.gov/cwind.shtml

http://www.ndbc.noaa.gov/cwind.shtml

http://www.ndbc.noaa.gov/dwa.shtml

http://www.ndbc.noaa.gov/dwa.shtml




128

E. APPLYING SADT ACTIVATION RULES TO IDEF0

ACTIVITY ANALYSIS

This discussion expands and elaborates the introduction to activation rules given by Marca & McGowan7.

Changes have been made to make the expression of activation rules consistent with the IEEE 1320.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

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


• The unary operator NOT may be used with an ICOM code to specify that this activation will

occur only in the absence of that resource, i.e., the object represented by that ICOM code must

not be present.

• A precondition may not negate all controls on an activity. This would violate the basic IDEF0

semantic rule that every transformation must be constrained.

• In general, precondition ICOM codes are grouped by role in the order:

Cn … In … Mn …

and written from left to write in increasing ordinal order within a role, as this precondition expression

illustrates:

C1 and C3 and I2 and I5 and M2 and M3

• ICOM codes that do not distinguish different activations may be omitted from a conditional

expression.

• Examples of preconditions:

A4*2 : C2 and ( I1 or I3 ) → O1

M32*4 : C1 and (I1 and NOT I4 ) → O2

E.4 POSTCONDITIONS

A postcondition expression specifies the output that results from a specific activation.

• Output, control, and input resources are specified by their ICOM codes.

• A postcondition may not include mechanism ICOM codes. Mechanisms may not be negated in a

postcondition.

• An output ICOM code in a postcondition expression means that the object represented by that

ICOM code must be produced by that activation, unless qualified by an OR operator. An output

not represented by an ICOM code in a postcondition expression will not be produced by that

activation.

• If an OR operator links two output ICOM codes, one or the other of those outputs must be

produced by that activation.

• Within a postcondition expression, the logical NOT operator may be applied to control and input

ICOM codes to indicate that such negated control or input has been completely consumed by the

transformation. (Note that a control so negated must be a control by virtue of role bundling.)

131


• Control and input ICOM codes may appear in a postcondition only if they are negated.

• A resource negated in a postcondition must appear in the precondition for that activation rule.

• In general, postcondition ICOM codes are grouped by role in the order:

On … ~Cn … ~In …

and written from left to write in increasing ordinal order within a role, as this postcondition

expression illustrates:

• O1 and O3 and ~C2 and ~C3 and ~I2 and ~I5

• Examples of postconditions:

A11*1 : C1 and ~I2 → O1 and (O2 or O3)

A3*3 : C1 and I1 and I2 → O1 and ~I2

E.5 WRITING RULE SETS

These rules apply to writing activation rule sets:

• Each precondition must be distinct.

• Any given output of an activity must be expressed in the postcondition of at least one activation

rule for that activity. That is, if we provide activation rules for an activity, we must account for all

possible products of that transformation; our postconditions must identify all possible outputs.

• An output of an activity may be specified in the postcondition of more than one activation rule.

(For example, consider an activity status report.)

These considerations also apply to activation rules:

• 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


Assem ble

Tab le

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 airhot 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


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

Bu ild

Bu rger

1

order

ham burger patty

cheesebu rger

dressed ham burger

pla in ham burger

cheese

condim 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


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


A ssem b le

Tab le

1

Blueprint

Schedule

Table Legs

Table Top

Parts Request

Production Status

Table

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

3See A42T2 for

activation rules.

Carpen 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


Eva lua te

Job

Progress

1

Job p lans

Job Status

Finished or Unfinished Job

Next Job Order Step

Unfinished JobsUnfinished Jobs

Job Status

Finished or Unfinished Job

Next Job Order Step

Job

Plans

Figure 19-3 An Activity w ith 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


A21*1 : C1 and I1 → O1 or (O2 and O3) or O3

The only other possible activation rule would have the precondition:

A21*2 : C1 and ~I1 → ???

In other words, this second activation rule would specify what this activity would produce if there were

no unfinished jobs.

• If it is true that producing O2 all by itself requires the absence of C1, then at least one control is

missing from the diagram. If we assume at least one another control (e.g., C2) for the activity,

then and only then may we write:

A21*1 : C1 and I1 → O1 or (O2 and O3) or O3

A21*2 : ~C1 and I1 → O2

which assumes that C2 is required for all activations of A21. That is, exhaustive activation rule statements

would be:

A21*1 : ( C1 and C2) and I1 → O1 or (O2 and O3) or O3

A21*2 : (~C1 and C2) and I1 → O2

Because this example does not specify any transformations in the absence of I1, that term may be omitted

from the preconditions; therefore, these activation rules may simplify to:

A21*1 : C1 → O1 or (O2 and O3) or O3

A21*2 : ~C1 → O2

which implicitly states that C2 and I1 are both required for all activations.

138

LIST OF ABBREVIATIONS AND ACRONYMS

NDC Node-Device-Connector

OOASIS Object-Oriented Approach to Software-Intensive

Systems

OMG Object Management Group

OTS Off-The-Shelf

PCE Prioritizable Concurrent Element

SE Systems Engineering

SW Software

UML Unified Modeling Language

139

List of Abbreviations and Acronyms

140


armstrong bocast integration of systems engineering and software development 2003-libre

Documents

software development3

software intensive systems

permission notice

copyright notice

objectoriented approach

cmc version

technical activities

management activities