The Integration of Systems Engineering and Software

The Integration of Systems Engineering and Software Development Based on the Object-Oriented Approach to Software Intensive Systems

SPC-2003041-CMC Version 01.00

April 2003

The Integration of Systems Engineering and Software Development Based on the Object-Oriented Approach to Software Intensive Systems

SPC-2003041-CMC Version 01.00 April 2003 Jim Armstrong Alex Bocast SOFTWARE PRODUCTIVITY CONSORTIUM SPC Building 2214 Rock Hill Road Herndon, Virginia 20170-4227

Copyright © 2003, Software Productivity Consortium NFP, Inc. Permission to use, copy, and distribute this material for any purpose and without fee is hereby granted consistent with 48 CFR 227 and 252, and provided that the above copyright notice appears in all copies and that both this copyright notice and this permission notice appear in supporting documentation. This material is based in part upon work sponsored by the Advanced Research Projects Agency under Grant #MDA972-96-1-0005. The content does not necessarily reflect the position or the policy of the U.S. Government, and no official endorsement should be inferred. The name Software Productivity Consortium NFP, Inc. shall not be used in advertising or publicity pertaining to this material or otherwise without the prior written permission of Software Productivity Consortium, NFP, Inc. SOFTWARE PRODUCTIVITY CONSORTIUM NFP, INC. MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THIS MATERIAL FOR ANY PURPOSE OR ABOUT ANY OTHER MATTER, AND THIS MATERIAL IS PROVIDED WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND.

CONTENTS ACKNOWLEDGMENTS .......................................................................................................... IX EXECUTIVE SUMMARY ........................................................................................................ XI 1.

2.

INTRODUCTION ................................................................................................................1 1.1

Scope.............................................................................................................................1

1.2

Audience .......................................................................................................................1

1.3

Organization .................................................................................................................1

1.4

Typographic Conventions.............................................................................................2

INTEGRATING SYSTEMS ENGINEERING AND SOFTWARE DEVELOPMENT3 2.1

Introduction ..................................................................................................................3

2.2

Systems Engineering ....................................................................................................3 2.2.1 Technical Activities ....................................................................................................... 4 2.2.2 Management Activities.................................................................................................. 5 2.2.3 Distinguishing Attributes............................................................................................... 5

2.3

Software Development .................................................................................................6 2.3.1 Scope of OOASIS.......................................................................................................... 6 2.3.2 OOASIS Inputs and Related Activities External Activities .......................................... 9

2.4

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

2.5

Interaction Guidance...................................................................................................14 2.5.1 2.5.2 2.5.3 2.5.4

2.6

Top-Level Definition/Define System Requirements ................................................... 14 Lower-Level Interactions/Software Development....................................................... 16 General Interface Issues............................................................................................... 18 SE and UML................................................................................................................ 19

Summary.....................................................................................................................20

3.

APPLYING IDEF METHODS TO DEVELOP OOASIS INFORMATION REQUIREMENTS .............................................................................................................21

A.

RELATING IDEF METHODS TO OOASIS..................................................................23 A.1 Part I. Applying the IDEF0 Method ...........................................................................23

iii

Contents

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

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

B.

SANTA NARIDA BACKSTORY ...................................................................................117 B.1 Santa Narida and the Santa Narida Ocean Observation Region...............................117

C.

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

D.

NATIONAL DATA BUOY CENTER ............................................................................125 D.1 Standard Meteorological Data ..................................................................................125 D.2 Detailed Wave Summary ..........................................................................................126 D.3 Acoustic Doppler Current Profiler (ADCP) .............................................................126 D.4 Continuous Winds ....................................................................................................126 D.5 Spectral Wave Data ..................................................................................................127 D.6 Water Level ..............................................................................................................127 D.7 Marsh-McBirney Current Measurements .................................................................127

E.

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

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

E.2

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

E.3

Preconditions ............................................................................................................130

E.4

Postconditions...........................................................................................................131

E.5

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

E.6

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

E.7

Revisiting Marca and 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

•

1.4

−

2.2 Systems Engineering. Defines the activities of systems engineering and those that will be included in this report

−

2.3 Software Development. Reviews the OOASIS method for use of UML

−

2.4 Mapping. Defines the interactions between the two disciplines

−

2.5 Guidance. Explains the interactions and provides guidance for both sides in program development

Section 3 Case Study. Provides specific guidance for interfacing the OOASIS UML inputs with systems engineering analysis using IDEF

TYPOGRAPHIC CONVENTIONS

This report uses the following typographic conventions: Serif font.....................General presentation of information Bold Italic...................Bulleted lists and run-in headings.

2

2. INTEGRATING SYSTEMS ENGINEERING AND SOFTWARE DEVELOPMENT 2.1

INTRODUCTION

time

The model used in this discussion is an interactive relationship between systems engineering and software development. Requirements and architecture decisions are arrived at by concurrence rather than by overthe-wall direction. Also, software development is embedded within the overall requirements analysis activity and as part of the systems design. While this is not a unique or original approach, neither is it as commonly practiced as it should be.

System Requirements Analysis

System Design Software Architecture

Physical Architecture

Figure 1. OOASIS Model of System and Software Interaction

The discussions that follow will first define the systems engineering and software development activities that occur in this model using a general definition of systems engineering and the OOASIS method of software development. Next, an information map will be presented correlating the outputs of systems engineering activities with the inputs defined in the OOASIS method. Finally, guidance is provided for the interactions at different levels of systems definition.

2.2

SYSTEMS ENGINEERING

Systems engineering has been defined in many ways. The definitions include systems engineering as a process, as a group of people, as a step in the life cycle, as a set of analyses, as coordination functions, as an approach to be taken by any engineer, and even as a way of life to be adopted by people who 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

4

CMMI and SE-CMM are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.


development, an interactive approach between the systems engineering and all design disciplines is essential.

2.2.2

MANAGEMENT ACTIVITIES

The management activities are included for reference but do not provide the types of information that is defined as inputs to the OOASIS method. Management activities include: •

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.

Define Capture sys behavioral req’s Sys Req’s Sys Use Cases

Realize use cases Define Sys SW Arch Sys SW Arch Define sys SW allocation Elaborate sys use cases Elaborated Sys Use Cases

Elaborate architecture

Sys SW Arch

Design Node SW

Define concurrency Thread Models

Define statecharts Class Statecharts and etc. from previous tasks

Implement software

Figure 2. OOASIS Software Development Flow

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:

8

•

Temporal correctness (response time, device characteristics)

•

Clarity (cohesion/interdependency of interacting objects)

•

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


OOASIS guides a developer to add concurrency only as justified by the requirements, with full consideration to its potential disadvantages of: •

Increased complexity

•

Reduced flexibility in design

•

Increased overhead

In light of these drawbacks, OOASIS encourages particular care to understand the system's asimplemented performance characteristics under its actual usage profile before attempting to fix presumed performance or timing problems with additional concurrency. 2.3.1.3.2 Define Statecharts This OOASIS task is also optional. In complex, real-time systems or those with stringent dependability or safety concerns, it is beneficial to create a more detailed dynamic model of the more complex classes (especially with multiple, interacting Prioritizable Concurrent Elements). To represent the objects in these classes as finite state machines, develop statecharts for each class. These statecharts will explicitly capture all states and state transitions of objects, including interactions among objects. 2.3.1.4 Implement Software Implementation is currently outside the scope of OOASIS. However, this section offers some general guidance that follows directly from previous OOASIS activities. The combination of the work products listed as inputs to this activity should suffice as a specification to implement system code.

2.3.2

OOASIS INPUTS AND RELATED ACTIVITIES EXTERNAL ACTIVITIES

OOASIS presumes other project-related activities that precede and run in parallel with OOASIS activities. These activities generate the work products that are inputs to the OOASIS method. Their relationship to each OOASIS activity is shown in Table 1 in the following section. The OOASIS method also addresses how to develop the information in cases where external activities do not exist. The following are the primary inputs to the method: •

Stakeholders

•

To-Be Process (optional)

•

As-Is Process (optional)

•

Summary Use Cases

•

Context Diagram

•

NDC Diagram

•

OTS Software Components

•

Hardware Interfaces 9


•

2.4

OTS Software Interfaces

MAPPING SYSTEMS ENGINEERING TO SOFTWARE DEVELOPMENT

Table 1 maps systems engineering activities described in Section 2.2 and their products to the inputs and activities in software development as described in Section 2.3. The initial systems engineering activities are predominantly part of problem definition such as needs analysis, requirements analysis, and functional analysis. The entry for program alternatives is a combination of architecting design, trade studies analysis and management planning. The emphasis shifts to architecting and integration with increasing problem definition and analysis details continuing. Basic inputs to OOASIS are in bold. Additional inputs described in the OOASIS method are also listed and their sources in systems engineering activities identified. Although the basic mapping indicates the production of inputs to the software process, it is not intended that this be a one-way interface. In all cases, the decisions must be made in collaboration. Table 1. Systems Engineering/Software Interactions

OOASIS SE Task

OOASIS SW Output

Input

Task/Subtasks

Output

Define System Req Needs Analysis

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

Obtain Summary Use System Case Cases

Identify Actors

Functional Analysis

Top level Goals (top level functions verb noun objectives)

Identify Cases

Functional Analysis, Requirements Analysis and Allocation

As-is process Decomposed T o-be process functions and “Text” details performance requirements Alternate success paths

Detail Cases

Functional Failure Analysis

Functional failure modes

10

Potential problems

System Use

System

Alternatives

Use

Use


Requirements analysis

Volatility estimates

Potential requirements changes

Program Alternatives

Capability sequence

Release sequences

Identify Key Requirements Requirements Priorities

Variations

System Priorities

Prioritize System Use Cases

Define SW Arch System Cases

Use Realize System Use Cases

System Arch

SW

Define actor IF classes

actor classes

IF

Find persistent entity persistent classes entity classes Functional analysis allocation

Allocated and functional description

Model the Use Cases as Interaction Interaction Diagrams Diagrams Combine classes into Class Diagram single class diagram Combine classes

redundant

Generalize classes Add composition Add associations Evaluate variations Allocation and Systems Architecture System Architecting

System NDC, OTS SW Define Deployment Components and Interfaces

against

SW System SW Deployment

11


Obtain NDC & OTS SW info

Deploy Classes

Actor

IF

Deploy Persistent Entity Classes Deploy OTS components

SW

Add Manager Classes Elaborate classes System Design, Bandwidth and Bandwidth and processing processing Requirements requirements analysis, and requirements allocation

Detailed and functions, Functions node

System

Use Elaborated System Use Cases

Expand Main Scenario per

Functional Analysis, Failure analysis

Alternate paths, failure modes

Expand courses

Requirements analysis, system design alternatives

Potential changes and alternative technologies

Expand variations

12

IF

Redeploy for Performance Performance Concerns adjusted SW Arch

Sys Use Cases, Elaborate NDC, Sys SW Cases Depl Models, Sys SW Arch Functional Analysis allocation

Actor

Alternate


Systems Design HW interfaces and Integration

Sys SW Depl Elaborate System Models, Sys SW Architecture Arch, Elab Sys Use Cases

SW Elaborated System SW Architecture

Realize Elaborated New classes System Use Cases Functional analysis, N2, requirements allocation

Operations, parameters, returns, conditions, dependencies

Identify Operations

Operation descriptions

Check Classes Elaborate Associations Requirements analysis, timelines, allocation

Timing budgets

Assign Timing Budgets

NDC, Sys SW Define Threads Depl Models, Sys SW Arch, Elab Sys Use Cases Functional analysis

threads

Timing info, system alternatives, cost of Allocation, Cost alternatives trades State diagrams

Systems Design

Hardware interfaces

Threads

Define initial thread set

Functional analysis, timelines,

Functional Analysis

??

Performance analysis

Define state charts

HW Interfaces

Class charts

state

Design Node SW

13


2.5

INTERACTION GUIDANCE

The most significant, and least novel, point is that systems engineering and software development cannot be done properly in series. As with any system component, any attempt to fully define the system absent input from the software component or to unilaterally push down requirements or design decisions is doomed to failure. As a consequence, the interface relies on parallel travel into the depths of the problem and solution and constant communication between the parties. This was depicted in Figure 1 and a key element of Table 1.

2.5.1

TOP-LEVEL DEFINITION/DEFINE SYSTEM REQUIREMENTS

At the highest level, the requirements definition must be done in a cooperative manner by the systems engineering and software activities. On the system engineering side, this information will be included in various products including needs statements, concepts of operations or top-level functional analysis. This phase in OOASIS is Define Systems Requirements. The primary inputs identified for OOASIS software development are identification of stakeholders, a summary use case or collection of system use cases or goals that provide the information, and a context diagram. For systems that are principally software, these two views may be near identical. For systems with more hardware involved, some preliminary discussion of possible allocations will be necessary. In either case, the most likely difference in viewpoint will be the extent to which the external processes need to be modeled and included in a complete analysis. Needs Ext I/F Concept of Operations •Who •What •Where •Why •When •How much •How many •How well •With what others •…..

Goals

StakeHolders

System

Context Diagram Business Process

Environment Readings

System

Samples Analysis Usage Reports Maintenance Requests

Summary Use Case Public User Download Data Maintenance Collect Data Scientist Analyze Data Admin

View Report

Environment

Figure 3. Top-Level Interactions

2.5.1.1 Stating the Problem The requirements as provided are not always optimal. Sometimes customers request a particular design solution because that is the design solution with which the customer is familiar, but the systems engineer knows or suspects some other solution may meet the need better. Design parameters in specifications have been so common in the past, in fact, that the government has undergone a large and expensive effort

14


to move toward performance specifications. The job of stating the real problem is not easy, as it involves considerable thought about the suggested solution, backing off to the need that the solution will or probably is intended to satisfy, and looking at what parameters of the problem are likely to be the most critical or most problematic to address, as they will be the key drivers for the system to be built. 2.5.1.2 Eliciting Customer Need Often customers know they have a problem, but 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


Req’s Concept of Operations •How will alternative solutions be operated and maintained •New constraints and requirements

Arch System

Functional An

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

:

Trade Studies Include Failures

Figure 4. Mid-Level Interactions

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

17


Models. These parallel activities to elaborate the definition and/or selection of physical architecture and OTS components continue until they result in detailed Hardware Interfaces and OTS Software Interfaces. These support low-level software design (elaboration of the System Software Architecture) and coding.

2.5.3

GENERAL INTERFACE ISSUES

2.5.3.1 Balancing Architecture Decisions One of the hottest issues between software developers and systems engineers revolves around old approaches to allocation and architecture decisions. In a more classic approach, functionality is allocated to system components and a hardware/software decision is made within each box. In modern software intensive systems, location of specific software functionality is much less of or no concern at all. Software developers can and prefer to develop the internal architecture of the software and then distribute it as makes sense from a processing view. This means that attempts to force distribution to specific hardware locations is both less than optimal from a software performance standpoint and not well received by the software community. As a result, the systems engineer must recognize this need for delaying deployment decisions until later in the development process and resist the urge to force functional allocations early in the process. On the other hand, there are often constraints and lead times that the systems engineer faces that the software developer must be responsive to. One of the historic examples is communications limitations. There are lots of examples of software designs that worked well on paper or on prototype systems but could not be used in the real world. Some have been limited by security concerns, others by real world capabilities that were as much as four orders of magnitude less than desired. The software developer must be ready to face these constraints and work with the systems engineer to provide an optimum compromise. A factor in this difference of viewpoint between the two disciplines is the internal versus external view. This is not peculiar to software. The design discipline of any component needs to focus on the internal design of the component in question. By definition, it is the responsibility of systems engineering to assure that those components work with the other components so that the system does what it is supposed to. Both the systems engineer and the software engineer must be aware and live by some basic tenets. 1. The systems and software architectures are not the same thing. The systems engineer must recognize that a software architecture needs to be developed based on the problems to be solved in software and the actor interfaces. Negotiation of impact on system elements should be expected as part of the software deployment activity. 2. The systems and software architectures are not totally independent. The software developer must recognize that systems constraints and lead times require early definition of software architecture constraints. For instance, communications limitations between two geographically separate nodes may constrain the deployment options and force the software architecture to limit the internode data

18


An example of the need to understand the external processes is the current effort within the air transportation industry to add a data link capability. This system will allow pilots and controllers to pass messages in addition to voice communications to increase the effectiveness of air traffic control. To the software designers, the handling of message traffic can be shown in UML with the controllers and pilots as principal actors and the software within the system described in use cases and interaction diagrams. At the systems level, the critical factors driving the usability of the datalink concept involve the workloads of both the pilot and controller. In order to understand these, the analyst must understand, model, and test the activities external to the datalink system. These analyses are better supported by methods such as the behavior diagram or other static or dynamic models. 2.5.3.2 Over- and Under-specifying As with any component, the correct balance of specification detail is difficult to find. If the systems engineer is unfamiliar with the issues of design that affect that discipline, it will be more difficult to achieve the balance. If there is not an active, bi-directional communication channel in place, it will be impossible. This is often even truer for software components. An example of under-specification is the system that required the software to automatically reconfigure the network if one of the links failed. No further guidance was provided. The expectation was that the software designers could figure it out from there. After all, the maintenance crew did this regularly in the current system. A better approach is to be responsive to the questions that a software developer asks about the requirement such as what reconfigurations are viable, what capabilities have priority, how many failures must be handled, how long do we have to reconfigure, what should be done when a link comes back on line, etc. Over-specification, as with any component, is usually the result of forcing design rather than providing the constraints that drive it. A typical example would be requiring either a look-up table or an algorithm calculation rather than the accuracy requirements and letting the software developer choose the most effective solution.

2.5.4 SE AND UML UML has been developed as a unification of software analysis techniques. As such, it should not be surprising that it does not yet fully cover the needs of systems engineering. This has been recognized within the Object Management Group and a Systems Engineering Domain Special Interest Group within OMG has issued a Request For Proposal for changes to the UML to improve coverage of systems engineering needs. This effort is being jointly conducted with the International Council on Systems Engineering (INCOSE). Some of the principal requirements are expanded capabilities in defining complex behavior, systems elements, interfaces, allocation, and traceability. It is anticipated that most of the requirements will be addressed by changes to the UML. There may be some additional diagrams added in this effort or future changes to the UML. Beyond the scope of current changes are various analysis techniques that have been developed by “specialty” disciplines to address their peculiar concerns. Among them is Systems Safety with Failure Mode Analysis and Fault Tree Analysis and testing with Design of Experiments methods for resolving issues involving complex

19


interactions and multiple alternatives. These may be incorporated at a later date or may remain an external set of techniques that will need to interface with UML analysis as appropriate. Another example of external analysis interfacing with the UML would be the allocation of 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.

20

•

Systems engineering and software development techniques have been developed to address different specific issues and concerns. However, they do overlap and the overlap increases as the proportion of software content increases.

•

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

•

Systems engineering and software development should be conducted in parallel and integrated. Doing them sequentially in an over-the-wall manner generates severe problems.

3. APPLYING IDEF METHODS TO DEVELOP OOASIS INFORMATION REQUIREMENTS The OOASIS method identifies nine information artifacts that it assumes are generated by activities that are external to the core software-oriented activities of OOASIS. OOASIS treats these primarily as inputs to the OOASIS method: •

Stakeholders

•

Context Diagram

•

As-Is Process

•

To-Be Process

•

Summary Use Cases

•

NDC Diagram

•


•

Hardware Interfaces

•


The IDEF0 method is often used to perform the functional or behavioral analysis of a system. Although some of the information is principally developed and recorded using other techniques such as concept of operations and system architecture views, IDEF0 contains most of the information needed for the OOASIS inputs. The application of the IDEF0 method demonstrates how this systems engineering method may be used to satisfy some or all of the information needs represented by these artifacts. The OOASIS information requirements represented by the first six artifacts may be fully addressed using the IDEF0 method. The three artifacts representing OTS software and hardware components and their interfaces are not fully addressed, but the specific components and interfaces required to meet system requirements are identified using the IDEF0 method. A case study using IDEF0 is provided in the appendices to this report for those interested in more details on how that method can be applied to the software interface needs.

21

3. Applying IDEF Methods to Develop OOASIS Information Requirements


22

A.RELATING IDEF METHODS TO OOASIS A.1

PART I. APPLYING THE IDEF0 METHOD

The OOASIS method identifies nine information artifacts that it assumes are generated by activities that are external to the core software-oriented activities of OOASIS. OOASIS treats these primarily as inputs to the OOASIS method: •

Stakeholders

•

Context Diagram

•

As-Is Process

•

To-Be Process

•

Summary Use Cases

•

NDC Diagram

•


•

Hardware Interfaces

•


The OOASIS information requirements represented by the first six artifacts may be fully addressed using the IDEF0 method. The three artifacts representing OTS software and hardware components and their interfaces are not fully addressed, but the specific components and interfaces required to meet system requirements are identified using the IDEF0 method as described here. This approach to IDEF0 analyses is based upon IEEE 1320.1-1998 and the IDEF0 models developed here comply with this standard. For the remainder of this document, unless otherwise specified, the term model refers to an IDEF0 model. A requirements model refers to a fully decomposed IDEF0 model in which mechanisms have not been specified. An architecture model refers to a fully decomposed IDEF0 model in which mechanisms have been specified for all activities. The focus of this appendix is not to teach IDEF0 modeling; we assume that the reader has some familiarity with the IDEF0 method. The focus is first on ensuring that OOASIS information requirements are addressed during IDEF0 model analysis and construction and second on translating this information into artifacts understood by and useful to OOASIS and other software engineers.

23

A. Relating IDEF Methods to OOASIS Information Needs

The basis of this work is the Buoy System case study presented by the OOASIS course and website as the vehicle for demonstrating this application. However, to reduce the number of systemic interfaces to a manageable handful, we have recast the characters of this case study so that the problem is not deeply embedded in a context of existing organizations and systems. We have invented the island nation of Santa Narida to be the customer for our buoy system; the backstory about Santa Narida is given in Appendix B.

A.1.1

OVERVIEW OF METHOD

To develop the information needed by OOASIS software designers, the systems engineer will build a family of IDEF0 models whose information elements will be mapped to the input artifacts specified by OOASIS. Each step in the method builds upon information developed by previous steps. 1. Identify and gather source material preparatory to developing IDEF0 models. 2. Build a family of models of the interests of external stakeholders. These include models are additional to IDEF0 but depend on the information contained in IDEF0 with a focus on stakeholder behavior. [These models will satisfy the OOASIS requirement for external stakeholder and summary use case information.] 3. Build a family of environmental context models for the prospective system. These models are organized around principle outputs to satisfy the interests of external stakeholders. These models consolidate stakeholder interests from the perspective of the prospective system. These models treat the prospective system as a black box. [These models will satisfy the OOASIS requirement for context and external stakeholder information.] 4. If appropriate, build an architecture model(s) of any existing system(s), to include environment context diagrams. If you are re-engineering a system, an architecture model of the existing system is always appropriate. If you are building a new system to provide completely new behavior, the need for an architecture model of existing behavior is problematic and will need to be established. The systems engineering process will generally use depictions of architecture which are additional to IDEF0. The information in these models ties to the mechanisms in IDEF0. [This model(s) will satisfy the OOASIS requirement for AS-IS context, external stakeholder, and process information.] 5. Build a family of requirements models for the prospective system. These requirements models decompose the system behavior (i.e., the A0 activity) specified by the environmental context models. The first iteration of these models will focus on expected, correct behavior (the simplest, shortest, successful path to achieving a goal(s)). (A corollary of this modeling objective is that these requirements models may not use call arrows.) [These models will satisfy the OOASIS requirement for context, external stakeholder, and TO-BE process information.] 6. Build a family of architecture models for the prospective system. The architecture models allocate mechanisms to the decomposed system behavior of the requirements models. Particular attention will be paid in this allocation to identify internal stakeholders and COTS hardware and software. Note that this allocation will be exploratory and tentative. The systems engineering process will generally use depictions of architecture which are additional to IDEF0. The information in these models ties to the mechanisms in IDEF0. [These models will satisfy the OOASIS requirement for context, external stakeholder, and process information. In addition, these models will identify internal stakeholders, COTS software, COTS hardware, and their interfaces.]

24


7. Build a family of system use case models. These system use case models partition and coalesce the architecture models to specify software system boundaries and actors in a way that may be translated directly into use case notation. [These models will satisfy OOASIS requirements for system use cases.] 8. Build a family of NDC models. These NDC models partition and coalesce the architecture models to specify the nodes, devices, and connectors in a way that may be translated directly into NDC diagram notation. [These models will satisfy OOASIS requirements for NDC diagrams.] At this point, a consistent set of information and guidance for OOASIS software practitioners should be available. We turn attention now to exploration of (1) anomalous behaviors, (2) alternative behaviors, and (3) enumerated behaviors. Consideration of anomalous behaviors will introduce fractal patterns into our requirements models. Call arrows and submodels will be introduced when we consider alternative behaviors and enumerated behaviors. The following steps will elaborate the requirements and architecture models that we have already developed. 9. Enumerated behaviors. Extend each model in the requirements family by considering activities that represent sets of related but mutually exclusive behaviors. (These may sometimes be inappropriately represented by a ladder pattern in a decomposition diagram, i.e., no coupling between parallel activities.) Such enumerated behaviors are to be represented by submodels invoked by a call arrow. [These extensions will assist the OOASIS analysis of alternate courses and variations for system use cases.] 10. Alternative behaviors. Extend each model in the requirements family by considering additional ways of accomplishing the objectives of each activity, i.e., alternative decompositions. These should be first developed as FEO pages and then migrated to submodels. Such alternative behaviors are to be represented by submodels invoked by a call arrow. [These extensions will assist the OOASIS analysis of alternate courses and variations for system use cases.] 11. Anomalous behaviors. Extend each model in the requirements family by considering patterns of anomaly detection and recovery for each activity. We provide a template of fractal patterns that may be used to guide this analysis. [These extensions will assist the OOASIS analysis of alternate courses and variations for system use cases.] These steps generally refer to a “family of models.” This does not imply that every exercise will necessarily generate multiple models; a family may have only one model. How large such a family might be will depend upon the complexity of the prospective system and the intensity of issues to be resolved to provide adequate requirements and design guidance. This paper discusses a recommended method for accomplishing Steps 1 though 8. Steps 9 through 11 will be treated in a subsequent release. Step 1. Develop a consistent understanding of system need. •

Identify and gather existing source fragments that state various aspects of the stakeholders’ problems. As in the real world, fragments of useful information are in different places. For this case study, one set of fragments comes from the OOASIS website, another from the OOASIS course, and the final set is the Santa Narida backstory. The OOASIS website and OOASIS course material have been slightly edited to ensure that they are consistent with the Santa Narida backstory. The OOASIS website teaches:

25


“A widespread fleet of buoys collects environmental data and feeds it periodically through satellites to a land-based storage facility. Users of the system request subsets of the data and perform analyses upon these. The Meteorological Data system is sponsored by a government agency to provide environmental data (mostly weather related) and analysis to scientists and the general public. The agency's goals for this system are to provide real-time and historical data (archived from the real-time data stream) on temperature, wind, and other conditions in a broad swath of ocean. The overall concept for this system is that the agency will develop, deploy and maintain floating data collection buoys throughout the area of interest. The buoys will periodically communicate their collected data through commercial (or standard OTS) satellites to a land-based data center, where staff scientists can access the data and run analyses from their workstations. A Web site will provide public access to the data. In particular, you know that the physical architecture involves buoys communicating to a land station via satellite, and users employing work stations to access this data (probably via a large server).”

The OOASIS course adds these thoughts: “The case study we will use for every example will be a weather data collection system. The system collects data from buoys floating in the Pacific Ocean and sends the data back for the landbased subsystem to archive for future use. The buoys send the data via a satellite provided by an international agency. The bandwidth allocations are of sufficient size as to support 6 samples per minute for each of the 1000 buoys. If the satellite becomes over used, it may require several orbital passes to complete these buoy transmissions. The primary users are research scientists who perform complicated analyses on the data. Some of the analysis is to be done by this new system, and other tools will do other analyses. Therefore, the system must allow the scientists to download the data into a standard format for import into other tools. The contract requires the ability for Web access. The Web access for external scientists and general public users will be limited to downloading data; commercial shipping route planners may access specialized weather-dependent route-planning applications.. In case of system performance problems, route planners get priority over external scientists, and the external scientists get priority over general public users. Administrators of the program will be given access to the system for report generation. The data for these reports will be based on data collected about system usage and stored in a database for retrieval. The reports themselves need not be saved because they can be regenerated as needed.”

•

Consolidate fragments into a set of statements that can be compared, contrasted, and evaluated for consistency by building exploratory models. These models should identify points of ignorance, ambiguities, contradictions, and assumptions as reader notes in model diagrams. The first set of these exploratory models examines the interests of external stakeholders.

Step 2. Identify the Prospective 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:

Date AKBocast Rev: OOASIS SE Stak e holde r: We athe r M e dia (SWM ) 1 2 3 4 5 6 7 8 9 10

Author: P roject: Model: Notes:

x

12/20/2001

Working Draft Recommended P ublication

Reader

Date

Context:

A-0

C1 Ima g e S t a n d a rd s

C 3 Bro a d c a s t S c h e d u le C 2 W e a t h e r S h o w F o rma t

P ro d u c t Re q u e s t s

F o re c a s t P ro d u c t s

I1 I2

F o re c a s t W e at he r

O ce an O b s e rvat io n s GO O S Ima g e ry

1

O c e a n I ma g e ry V is u a l P re s e n t a t io n M ix B a c kd ro p

W eat h e r S h o w

O1

2 S c rip t W rit e S c rip t

3 Re a d S c rip t F o re c a s t T e xt

4 O ra l P re s e n t a t io n

M 1 Na t io n a l W e a t h e r S e rv ic e

M 3 W e a t h e r P re s e n t e r

M 4 S a n t a Na rid a Bu o y S y s t e m

P age:

Title:

A0

M 2 T e le v is io n S t u d io

Number:

P resent Weather

AKB3

Diagram 1. SWM/A0 (Present Weather)

Used at:


Date 12/20/2001 AKBocast Rev: OOASIS SE Stak e holde r: Ts unami Warning Sys te m (STW) 1 2 3 4 5 6 7 8 9 10

x


C 1 In t e rn e t M a il P ro t o c o ls

Reader

Date

Context:

A-0 C3

T s u n a mi P re d ic t io n M o d e ls

C 2 D at a S h arin g A g reem en t

S N O O R T s u n a mi Da t a

Pr o v id e T s u n am i Pr ed ict io n D a ta

I1

1

R ece iv e D at a

O c e a n o g ra p h ic Da t a

2

F u s e d T s u n a mi Da t a

Fus e T s u n ami S o u rces 3 Re c e iv e d T s u n a mi Da ta M a il S e rv e r

M a il C lie n t

Pr e d ict T s u n am i

T s u n a mi W a rn in g 4

M2

P age:

28

A0

S a n t a Narid a Bu o y S y s t e m

Title:

P roduce Tsunami Warnings

M1

T s u na mi W a rn in g S y s t e m

Number:

P. 2

O1

P. 3


Diagram 2. STW/A0 (Produce Tsunami Warnings)

Used at:


Date AKBocast Rev: OOASIS SE Stak e holde r: Ins titute Scie ntis t (SIS) 1 2 3 4 5 6 7 8 9 10

12/20/2001

x


Reader

O b s e rv a t io n S p e c if ic a t io n s C2

Da t a s e t S p e c if ic a t io n s C3

T a s kin g

Re s e a rc h A g e n d a

D at as e t R e qu e s t s

O c e a n Da t a

O c e a n O b s e rv a b le s

Context:

A-0

C1

I1

Date

C ap t u r e O ce an D at a 1

S t ag e O ce an Dat a 2

R e q u e s t e d D at as e t s

S tud y O ce an W e at he r

Re s e a rc h P ro d u c t s

O1

3

W e b S e rv e r W e b Bro w s e r

M3 M1

P age:

A0

Title:

S a n t a Na rid a Bu o y S y s t e m

Research Ocean Weather P henomena

M2

In s t it u t e S c ie n t is t

In s t it u t e f o r M id - P a c if ic O c e a n M e t e o ro lo g y

Number:

AKB2

P. 2

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

29


Used at:


Date AKBocast Rev: OOASIS SE Stak e holde r: Route Planne r (SRP) 1 2 3 4 5 6 7 8 9 10

12/20/2001

x


C1

V e s s e l C h a ra c te ris t ic s

Reader

Date

Context:

A-0

De s t in a t io n s C3

C u s t o me r Re q u ireme n t s C2

Re s o u rc e M in imiz a t io n S t ra t e g y

Fe a s ib le Ro u t e s

I1

Ro u t in g A lt e rn a t iv e s

D et e rm in e F e as ib le R o u tes

S c h e d u les

1

W eat h e r- Pro file d R o u t e s

I2

F o r e cas t R o u t e - S p e cific W e at h e r

O c e a n W e a t h e r Da t a

2

R o u t e - V e s s e l- S ch e d u le E s t im at e s E s t im at e V es s e l S ch e d u le s 3

S e le ct O p t im um It in e rary

Ro u t e Pla n

O1

4

M1 M2 W e b s it e

P age:

Title:

A0

M3

W e b Bro w s e r

Ro u t e P la n n e r


Number:

P lan Ship Itinerary

AKB3

P. 2

Diagram 4. SRP/A0 (Plan Ship Itinerary)

Used at:


Date 12/20/2001 AKBocast Rev: OOASIS SE Stak e holde r: We athe r Fore cas te r (SWF) 1 2 3 4 5 6 7 8 9 10

x


Reader

Date

Context:

A-0

C 1 W e a t h e r M o d e l Re q u ire me n t s C 2 O u t lo o k S c h e d u le

C o lle ct D at a I1

O c e a n O b s e rv a b le s 1

M e t e o ro lo g y Da t a s e t s

Pu s h D at a

2

His t o ric a l Da t a

Mo d el W eat h e r 3

P ro je c t e d Da t a

Pu b lis h F o r e cas t s

F o re c a s t P ro d u c t s 4

M2 Na t io n a l W e a t h e r S e rv ic e M 1 W e a t h e r F o re c a s t e rs M 3 S a n t a Na rid a Bu o y S y s t e m

P age:

30

A0

Title:

Forecast Weather

Number:

AKB2

P. 2

O1


Diagram 5. SWF/A0 (Forecast Weather) Used at:


x

Date 12/20/2001 AKBocast Rev: OOASIS SE Stak e holde r: National We athe r Se rvice (SNW) 1 2 3 4 5 6 7 8 9 10 C 2 F o re c a s t in g S c h e d u le

C1


Reader

Date

Context:

A-0

S h ip me n t Re q u ire me n t s C 3 M in is t e ria l Q u e s t io n s

W e a t h e r C o n s t ra in t s

I1

Pro v id e W e at h e r

W e a t h e r O b s e rv a b le s

In fo rm at io n 1 Bu o y A c t iv it y Re p o rt s

W e b s it e A c t iv it y Re p o rt s

I2

U n d e c id e d Ro u t in g Q u e s t io n s

S e le ct S h ip p ing

F a v o ra b le Ro u t in g De c is io n s

O2

It in e rar y 2

1

A ctvity reports include maintenance activity. Pr o v id e R e p o rt s

Minis terial R ep o rts

O1

3 S y s t e m A c t iv it y Re p o rt s Bu o y s

W e b s it e

S y s t e m A d minis t ra t o r

M2 M 1 S h ip p e r

P age:

A0

Title:

Increase P uerta Oveida Market Share

NW S Ge n e ra l M a n a g e r

M 3 S a n t a N a rid a Bu o y S y s t e m

Number:

AKB2

P. 2

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

31


Used at:


Date AKBocast Rev: OOASIS SE Stak e holde r: Sate llite Provide r (SSP) 1 2 3 4 5 6 7 8 9 10

x

12/20/2001


Reader

Date

Context:

A-0 C 2 S e rv ic e A g re e me n t

W e b P r o t o c o ls

C 1 C o mmu n ic a t io n s P ro t o c o ls

S e n t C o mman d s

W e b P r o t o c o ls

S a t e llit e P ro t o c o ls

S en d C o m m an d s T ra n s mit t e d C o mma n d s 1

Mo ve C o m m an d s 2

S en t D at a S e n d D at a

I1

F ie ld O b s e rv a t io n s T ra n s mit t e d Da t a 3

M o v e D at a

A r ch ive D at a

5

A rc h iv e d Da t a

O2

6

R e ce ive D at a

W e b Bro w s e r Bu o y T ra n s c e iv e r

D e liv e re d Da t a

O1

4 W e b Bro w s e r

M 1 S a n t a Na rid a Bu o y S y s t e m M 2 A rg o s

P age:

Title:

A0

M 3 W o rld W e a t h e r W a t c h

Number:

Deliver Data

P. 2

Diagram 7. SSP/A0 (Deliver Data) Used at:


x

Date 12/20/2001 AKBocast Rev: OOASIS SE Stak e holde r: NOAA M ainte nance (SNM ) 1 2 3 4 5 6 7 8 9 10


Reader

Date

Context:

A-0 C 2 Bu o y T e c h n ic a l Da t a

C 1 M a in t e n a n c e T re a t y M a in t e n a n c e N o t if ic a t io n

I1

Bro ke n Bu o y

M a in t e n a n c e R e p o rt

M a int e n a n c e Re q u e s t

R e q u es t M ain t e n an ce A ct io n 1

M a in t e n a n c e Re c o rd M a in t e n a n c e O rd e r

D ir e ct M ain t e n an ce A ct io n 2

M a in t e n a n c e H is t o ry

F ix B u o y W o rkin g Bu o y 3


P age:

A0

Title:

Maintain Buoys

M 2 NO A A

M 3 Pa c if ic O b s e r v e r

Number:

Diagram 8. SNM/A0 (Maintain Buoys)

32

AKB2

P. 2

O1


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

Group the stakeholder models by characteristics that will help you find themes and affinities among them. We have grouped our case study stakeholder models like this:

Affinity Grouping of Stakeholder Models Grouping Concept:

User of System Products

Provider of System Resources

Stakeholders:

forecaster institute shipper media

communications maintenance customer

Comments

33


tsunami

•

Consider the canonical form for the A-1 diagram suggested by the requirements model template. Assign stakeholders identified by the stakeholder models to this table.

Template Grouping of Stakeholder Models Grouping Concept:

User

Provider

Outputs

Controls

Stakeholders:

forecaster institute shipper media tsunami

customer

Inputs

Mechanisms communications maintenance

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

You should then extend the content of the stakeholder grouping table to capture these ideas:

Template Grouping of Stakeholder Models Grouping Concept:

User Outputs

Controls

Inputs

Mechanisms

Stakeholders:

forecaster institute shipper

customer tsunami communications

environment

communications maintenance trainer

34

Provider


media tsunami

•

Reflecting upon the tentative groupings in this table, you can then allocate stakeholders to separate requirements models. One such allocation is illustrated by the next two tables:

Stakeholders by Requirements Models: Model 1 (selected stakeholders are in bold) Grouping Concept:

User

Provider

Outputs

Controls

Inputs

Mechanisms

Stakeholders:



environment


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

User

Provider

Outputs

Controls

Inputs

Mechanisms

Stakeholders:



environment


Notice that the customer and environment stakeholders appear in both allocations. The environment appears in both because it alone provides input for the prospective system. The customer also appears in both, but with a different rationale for each one. In Model 1, the idea is that the customer stakeholder is concerned with ensuring appropriate services for system users. In Model 2, the idea is that the customer stakeholder is concerned with ensuring appropriate supervision and control of system operations. •

If these allocations are coherent and useful, you should be able to assign a distinct name to each requirements models. You might adopt System Products as the interim name for the first model and System Operations as the interim name for the second model.

Determining Viewpoint and Purpose for Each Model These models will all have the viewpoint of a systems engineer in the role of elicitor of requirements. The purpose of each model will be to specify minimal and sufficient behaviors leading necessarily to the coherent set of related outputs required by external stakeholders. Step 3. Specifying the Environmental Context for Each Model Rename the two models you have created as the Requirements TO-BE System Products model and the Requirements TO-BE System Operations model. Do not worry yet about naming the A0 function in either

35


the A-0 or A-1 diagrams; our interest now is fleshing out the context of the A0 function in the A-1 diagram for each model. To make this section easier to read (and to write!), we will use the term stakeholder function to refer to the box in the A0 diagram of a stakeholder model to which the prospective system is attached as a mechanism. We will use the term A0 function to refer to box 0 in the A-1 diagram of a requirements model; the prospective system is attached to this box as a mechanism. Gather the A0 diagrams of the stakeholder models for the stakeholders allocated to the System Products model. We will sequentially and methodically add the information in these stakeholder models to the A-1 diagram. In the A-1 diagram, whatever the stakeholder does with its input from the prospective system is hidden within the use output box. The prospective system becomes a mechanism of the A0 function. The stakeholder becomes a mechanism of the use output function. Boundary arrows that are controls for the stakeholder function becomes outputs of the provide controls box. Controls on the stakeholder function that are outputs of stakeholder activities become controls on the A0 function. Boundary arrows that are inputs for the stakeholder function become outputs of the provide inputs function. In general, we try not to add new material nor do we try to rectify any logical anomalies (the sense of the model) that become apparent, although we generally consider correcting modeling anomalies (the representation of model sense) while we add successive stakeholders’ information to this diagram. The next diagram illustrates this transferal for the first, Weather Media stakeholder. The template elements that have not been used so far are grayed down; as these elements are used in the following sequence of diagrams they will be restored to their normal color.

36


Used at:

Author: P roject: M odel: Notes:

AKBocast Date: OOASIS SE Rev: Requirements TO-BE Pro ducts (RTP) 1 2 3 4 5 6 7 8 9 10

c o n t ro l re q u e s t

x

12/13/2001

W orking Draft

Reader

Date

Context:

NO NE

R ecommended P ublication

m e c h a n is m re q u e s t

in p u t re q u e s t

p e rfo rm a n c e fe e d b a c k

b roa d c a s t s c h e d u le p ro v id e c o n t rols

14 im a g e s t a n d a rd s p ro v id e m e c ha n is m s 2

re s u lt s fe e d b a c k

O c e a n O b s e rv a t io n s

p ro v id e in p u t s 3

P rod u c t R e q u e s t s F o re c a s t P ro d u c t s AC0o nfut e nxc tt io o fn ... 0

G O O S I m a g e ry

O c e a n I m a g e ry

u se ou tp u t m e c h a n is m b u n d le

W e a t h e rS h o w

5

re s u lt s

F o re c a s t Te x t

T e le v isio S a n ta N a r id a s t a k e h o ld e r c

P age:

A-1

s t a k e h o ld e r m

T itle:

s t a k e h o ld e r i

S a n ta N a r id a B u o y S y ste m

Stakeholder Context of A0 function

Number:

AKB5

P. 1

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

The following diagram adds the environment stakeholder to generate input.

37


Used at:

AKBocast Date: OOASIS SE Rev: Requirements TO-BE Pro ducts (RTP) 1 2 3 4 5 6 7 8 9 10



x

12/14/2001

W orking Draft

Reader

Date

Context:

NO NE





b roa d c a s t s c h e d u le p ro v id e c o n t rols

14 im a g e s t a n d a rd s p ro v id e m e c ha n is m s 2

Ocean P la n e t




p ro v id e in p u t s

P la n e t a ry O b s e rv a b le s

3

P rod u c t R e q u e s t s F o re c a s t P ro d u c t s AC0o nfut e nxc tt io o fn ... 0

G O O S I m a g e ry




5

re s u lt s


T e le v isio S a n ta N a r id a s t a k e h o ld e r c

P age:

A-1


T itle:

E n v iro n m e n t


S a n ta N a r id a B u o y S y ste m

Number:

AKB5

P. 1

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

The need for our first bit of 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: C1

in p u t re q u e s t C2

I1



M e a s u re O c e a n W eath er C h a ra c t e ris t ic s

O c e a n O b s e rv a t io n s M e a s u re d O c e a n O b s e rv a b le s

O1

O2

1F

P h o t o g ra p h t h e E a rt h

P la n e t a ry O b s e rv a b le s I2

S a t e llit e I m a g e ry P h o t o g ra p h e d O b s e rv a b le s

O3

O4

2F

M2

B u oy S ystem

M1

G O O S S a t e llit e s

Diagram 11. RTP/FEO1: Parallel Decomposition Fragment

This draft shows no coupling or cohesion whatsoever between the two boxes. This indicates that the decomposition is suspect, an artifice by which two unrelated functions have been grouped together not because they participate in the purpose of some larger whole but rather because they have been grouped 2

There is of course a fundamental difference between, on the one hand, changing the state of a letter from unsigned to signed and, on the other, changing the state of a letter from unread to read. Signing a letter physically changes the letter while reading that letter does not physically change it. In the first case, the thing itself has been transformed; in the latter case, it is our perception of the thing that has been transformed — we have moved the letter from one conceptual category to another. However, because philosophers of science have instructed us that the interaction of observed and observer changes both, we can at least temporarily accept such transformation as legitimate within an IDEF0 model. 39


by location or kind — no surprise here since our template grouped them together because they are both sources of inputs! The Measure Ocean Weather Characteristics should really be within the A0 function, represented by the walls of box 0. These considerations lead us to revise our working draft: Used at:


Date: AKBocast Rev: OOASIS SE Requirements TO-BE Pro ducts (RTP) 1 2 3 4 5 6 7 8 9 10


x

12/14/2001

W orking Draft

Reader

Date

Context: NO N E





b roa d c a s t s c h e d u le p ro v id e c o n t rols 1 4 im a g e s t a n d a rd s p ro v id e m e c ha n is m s 2


p ro v id e in p u t s P la n e t a ry O b s e rv a b le s

3

P rod u c t R e q u e s t s

P ro v id e O b s e rv a b le s

F o re c a s t P ro d u c t s AC0o nfut e nxc tt io o fn ...

6

0 S a t e llit e I m a g e ry


M e a s u re d O b s e rv a b le s



E n v iro n m e n t

x


5

re su lt s

F o re c a s t Te x t Te le v is io S a n t a N a rid a s t a k e h o ld e r c

P age:

A-1


T itle:

G O O S S ystem

S a n t a N a rid a B uo y S y s t e m

Number:


AKB5

P. 1

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

We have pushed our information about ocean observations into the system scope as a fragment in the A0 diagram:

I1


M e a sure O ce a n W e a th e r C h a r a c t e r is t ic s


O1


1

Diagram 13. RTP/FEO2, Ocean Observation Fragment

Notice that box 6 has been placed in a convenient place in the diagram. This convenient place is not a correct place, but we have several more stakeholder models to look at before it will become worthwhile to rearrange the topology of this diagram into a compliant visual structure.

40


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




x

12/14/2001

W orking Draft

Date

Context: NO N E


in p u t re q u e s t B roa d c a s t S c h e d u le


Reader


I n t e rn a l M a il P ro t o c o ls

p ro v id e c o n t rols 14

Ts u n a m i D a t a A g re e m e n t

I m a g e S t a n d a rd s

p ro vid e m e c h a n ism s re s u lt s fe e d b a c k

2 p ro v id e in p u t s P ro v id e O b s e rv a b le s

3


P ro d u c t R e q u e s t s

S a t e llit e I m a g e ry

6

A 0 fu n c t io n C on text of ...

M e a s u re d O b s e rv a b le s F o re c a s t P ro d u c t s

x

O c e a n I m a g e ry O c e a n O b s e rv a b le s

0

Ts u n a m i D a t a

u se ou tp u t

W eath er S h ow Ts u n a m i W a rn in g

E n v iro n m e n t

m e c h a n is m b u n d le


re su lt s

x

5

Ts u n a m i W a rn in g C e n t e r Te le v is io S a n t a N a rid a s t a k e h o ld e r c

P age:

A-1


T itle:

G OO S S ystem


S a n t a N a rid a B u o y S y s t e m

Number:

AKB5

P. 1

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

First, notice that the Internet Mail Protocols have been shown as an external control, that is, these standards are not established by the stakeholders: regardless of what the designers of the prospective system may or may not do, these standards will be available to the system. Second, we can recognize that providing some controls requires the participation of stakeholders. In our stakeholder models, these were seen as given constraints. From a systems engineering perspective, the activities that produce such agreements must be designed and institutionalized because the agreements they generate are necessary for successful system operation. Third, now that we have two stakeholders represented, we can begin to judiciously generalize, that is, raise the level of abstraction of concepts in the environmental context diagram. The next diagram shows an elaboration of the previous diagram as it incorporates joint control activities and higher levels of abstraction. Our work area is now becoming crowded, so note that the activity to provide mechanisms has been removed from this A-1 diagram; we will need to ensure that we revisit this activity in another environmental context diagram.

41


Used at:




D a ta S h a r in g A g r e e m e n ts

x

12/14/2001

W orking Draft

Reader

Date

Context: NO N E


in p u t re q u e s t B roa d c a s t S c h e d u le


I n t e rn a l M a il P ro t o c o ls

p ro v id e c o n t rols 14 I m a g e S t a n d a rd s

re s u lt s fe e d b a c k P la n e t a ry O b s e rv a b le s


P ro v id e O bs e rv a b le s



6


M e a s u re d O b s e rv a b le s F ore c a s t P ro d u c t s

x

O c e a n I m a g e ry 0


F ilte r e d D a ta se ts

u se ou tp u t

W eath er S h ow Ts u n a m i W a rn in g


x

x

5

E n v iro n m e n t

Ts u n a m i W a rn in g C e n t e r

N a t io n a l W e a t h e r S e rv ic e

P age:

A-1

G OO S S ystem

T itle:


S a n t a N a rid a B u oy S y s t e m

Te le v is io S a n t a N a rid a

Number:

AKB5

P. 1

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

The specialized control Tsunami Data Agreement has been generalized to Data Sharing Agreement. Similarly, Tsunami Data has been generalized to Filtered Datasets.3 This differentiates between meteorological observations (real data) and meteorological forecasts (derived data). (Although you have not yet made up your mind, you are wondering whether Image Standards could be usefully bundled into Data Sharing Agreements or might eventually generalize into a separate Technical Standards.) Because this is an obvious role for the National Weather Service as customer, we have introduced this stakeholder as a negotiating partner of the provide controls activity. We follow this introduction by assessing whether the customer stakeholder model supplies concepts useful for this A-1 diagram. Because the focus of the NWS General Manager appears to be on responding to government ministers, meteorological data is not really central to this stakeholder model. Recalling that the customer stakeholder 3

During discussion of what constitutes Tsunami Data, one of your colleagues points out that surely this data would include swell height. To help the buoy system to filter out irrelevant observations, the Tsunami Warning Center would most likely notify Santa Narida with the coordinates of the epicenter of seismic disturbances. Then buoy sensors could be tasked to look for swell variance specifically along vectors radiating from the epicenter. Although this did not come up in the initial effort to characterize the Tsunami Warning Center as a stakeholder, you will probably want to investigate the possibility of two-way communications between Santa Narida and Honolulu to direct searches for tsunami data.

42


has a role in both system products and system operations models, we defer these stakeholder model concerns to be reconsidered when we address the A-1 diagram for the systems operations model. The only concept we pick up from this model is to generalize Broadcast Schedule to Schedules. Since the stakeholder model for the institute scientist requires meteorological data (the Datasets) to produce research products, we now take up this stakeholder model for integration into our A-1 diagram. Used at:



x

12/14/2001

W orking Draft

Reader

Date

Context: NO N E

R ecommended P ublication I n te r n e t P r o to co ls





S ch e d u le s

p ro v id e c o n t rols 14 I m a g e S t a n d a rd s


P la n e t a ry O b s e rv a b le s p ro v id e in p u t s 3 P ro v id e Ob s e rv a b le s



6




O b s e rv a t io n S p e c ific a t io n s D a t a s e t S p e c ific a t io n s

D a t a s e t P ro d u c t s O c e a n O b s e rv a b le s

0

x

S p e c ific a t io n s

O c e a n I m a g e ry F o re c a s t Te x t F ilt e re d D a t a s e t s

us e o u t p u t

U n filt e re d D a t a s e t s

W eath er S h ow Ts u n a m i W a rn in g Re s e a rc h P ro d u c t s

5

x x x

E n v iron m e n t I n s t it u t e S c ie n t is t Ts u n a m i W a rn in g C e n t e r N a t io n a l W e a t h e r S e rv ic e

P age:

A-1

G OO S S ystem

T itle:

S a n t a N a rid a B u oy S y s t e m

Te le v is io S a n t a N a rid a


Number:

AKB5

P. 1

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

In this step, we have added the Institute Scientist as mechanism and Research Products as output to the use output activity. The datasets requested by the Institute Scientists have been represented by Unfiltered Datasets and bundled with Filtered Datasets to form Dataset Products as output from the A0 function. The specification of the observations that the buoy system makes and the specification of the datasets that the buoy system provides have been added as output from the A0 function and as control on the use output activity. Note that the Institute Scientist is not party to data agreements with the National Weather Service. Instead, the Institute Scientist is a user of products specified by the buoy system.

43


Note too that the presence of web server and web browser mechanisms in the Institute Scientist model suggested the extension and generalization of Internet Mail Protocols to Internet Protocols that govern both the A0 function and the use output function. Now we turn to the weather forecaster model. With the A-1 diagram we have developed so far, we immediately see an issue concerning the scope of the prospective system. The output of the weather forecaster is Forecast Products, which we have already identified in the A-1 diagram as an output of the A0 function. In the weather 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:



x

12/17/2001

W orking Draft

Reader

Date

Context: NO N E

R ecommended P ublication I n te r n e t P r o to co ls





S ch e d u le s

p ro v id e c o n t rols 14 W e a t h e r M o d e l D a t a R e q u ire m e n t s I m a g e S t a n d a rd s




P ro v id e Ob s e rv a b le s



6





D a t a s e t P ro d u c t s O c e a n O b s e rv a b le s

0

x



us e o u t p u t



5

x x x

I n s t it u t e S c ie n t is t S a n t a N a rid a B u o y S y s t e m E n v iron m e n t

P age:

A-1

T itle:

G OO S S ystem



Ts u n a m i W a rn in g C e n t e r Te le v is io S a n t a N a rid a

Number:

AKB5

P. 1

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

We bring Weather Model Requirements into our A-1 diagram as an output of the provide controls function. One would think that there might be an interaction between operation of weather models and development of their data requirements — oops, this control refers to data requirements, does it not? Renaming as data requirements should flush out any alternative interpretations.

44


We will need to address rather sooner than later whether the activities of National Weather Service weathermen are within the scope of our model of system behavior. At this point in model development, we put a placeholder for this issue on the requirements model’s A0 page, where we previously modeled the production of ocean observations.

C 2 W e a t h e r M o d e l D a t a R e q u ire m e n t s O c e a n O b s e rv a t io n s

I1


M e a s u r e O ce a n W e a th e r C h a r a cte r istic s 1


F o r e ca st W e a th e r


O1

O2

2

M1

W e a t h e r F o re c a s t e rs

Diagram 18. RTP/FEO3, Relating Observing to Forecasting

It is a judgment call, but this A-1 diagram seems to be sufficiently dense with concepts to be set aside for the moment. In this diagram we have integrated and investigated stakeholder relationships with our prospective systems for six stakeholders. Of the stakeholders tentatively allocated to this diagram, we have addressed all but the shipper stakeholder. We will now develop the second A-1 diagram. Having shown step-by-step development in the first A-1 diagram, we will just present the second A-1 diagram. This diagram addresses the shipper stakeholder as well as other stakeholders of this 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


C 2 B u oy C om m an d s

C3

T ra n s m i t t e d C o m m a n d s

C 1 C o m m u n ic a t io n s P ro t o c o ls

Se n d C o mm a nd s

S e n t C o m m a n ds

O3

71F C o lle ct D a t a

I1



O1

22F C o lle c t e d D a t a

Se n d D a t a

S en t D ata

O4

33F R e ce i ve D a t a

O c e a n O be rv a t io n s I2

T ra n s m it t e d D a t a

O2

54F

Diagram 19. RTP/FEO5, Environmental Exchange Example

Instead, we have adopted the convention that a box shaded light gray signifies an activity that is outside the scope of the A0 function (i.e., which otherwise would be modeled on an environmental context diagram) and represented these activities within the A1 diagram:

46


Used at:


Date: AKBocast Rev: OOASIS SE Requirements TO-BE Operatio ns (RTO) 1 2 3 4 5 6 7 8 9 10

12/17/2001

x

W orking Draft

Reader

Date

Context:

NO NE


C o m m u n ic a t io n s P ro t o c o ls

M in is t e ria l Q u e s t io n s




M i n i s t e ri a l R e q u e s t s

Se rvi ce A g re e m e n t s

p ro v id e c o n t ro ls B u o y Te c h n ic a l D a t a

14

R ou t e P la n n in g R e q u ire m e n t s

S y s te m S t a tu s

M a in t e n a n c e R e q u e s t

R o u t in g D e c is io n s

M a in t e n a n ce N o t ific a t io n

p ro v id e m e ch a n is m s 2 P ro d u c t R e q u e s t s

p ro v id e in p u t s 3 O c e a n O b s e rv a b le s

M e a s u r e d O b s e rv a b le s

t enxctt ion of AC0o nfu ...

M in is t e ria l R e p o r t s

x x

00

b ro k e n b u oy C o m m u n ic a t io n s S a t e llit e s

u se ou tp u t

R o u t e P la n

x

5 R ou t in g P ro d u c t s re p a ire d b u oy A rg o s N W S G e n e ra l M a n a g e r

P age:

A-1

N OA A

T itle:

R o u t e P la n n e r E n vi ro n m e n t

Sa n t a N a ri d a B u o y Sys t e m

Stakeholder Context of ...

Number:

AKB5

P. 1

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

47


Used at:



x

12/17/2001

W orking Draft

Reader

Date

Context:


A0

C 2 B u o y C om m a n d s


Se n d Comm and s

1 Se n t C o m m a n d s

T ra n s m i t t e d C o m m a n d s M o ve Com m ands

2 Co lle c t D a t a

I1



O1

3 C o lle c t e d D a t a

Se n d D a t a

4 S en t D ata

M o ve D a t a

T ra n s m it t e d D a t a 5 R e ce i ve D a t a

O c e a n O b e rv a t io n s 6

M 1 C om m u n ic a t io n s S a t e llit e s

P age:

A1

T itle:

M easure Ocean Observables

Diagram 21. RTO/A1 Measure Ocean Observables

We also prepare a third model for the trainer stakeholder:

48

Number:

AKB6

P. 5

O2


Used at:


Date: AKBocast Rev: OOASIS SE Requirements TO-BE Training (RTT) 1 2 3 4 5 6 7 8 9 10


x

12/17/2001

W orking Draft

Reader

Date

Context:

NO NE




P e rfo rm a n c e F e e d b a c k

c o n t ro l b u n d le p ro v id e c o n t rols

14

x

U n t ra in e d P e o p le

Tra in in g R e q u ire m e n t s

p ro v id e m e c ha n is m s 2


in p u t b u n d le p ro v id e in p u t s 3

o u t p u t re q u e s t

AC0o nfut e nxc tt io o fn ... 00 m e c h a n is m b u n d le

u se ou tp u t

Tra in e d S t a ff

re s u lt s

5

re s u lt s

o u t p u t b u n d le s t a k e h o ld e r o s t a k eh o ld e r c

P age:

A-1

Tra in e r

T itle:

s t a k e h o ld e r i

S a n t a N a rid a B uo y S y s t e m


Number:

AKB5

P. 1

Diagram 22. RTT/A-1, Training Stakeholder

You should have observed in these steps a typical approach to integrating stakeholders into a requirements 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:


Date AKBocast Rev: OOASIS SE Re quire me nts TO -B E Products (RTP) 1 2 3 4 5 6 7 8 9 10

x

12/20/2001


Reader

Date

Context: N O NE

I n t e r n e t Pro t o c o ls c o n t r o l re q u e st Da t a Sh a r in g Ag r e e m e n t s

inSpcuht erdeuqle u se st

p e rf o rma n c e f e e d ba c k

Co n t r ol Pro d u c t io n 1

4

W e a t h e r M o d e l Da t a Re q u ire m e n t s I m a g e St a n d a r d s Pla n e t a r y Ob s e r v a b le s

r e su lt s f e e d b a c k Pro v ide I m a g e ry 3

Pr o d u c t Re q u e st s Pro v id e Sa t e llit e I m a g e ry

Ob se r v a b le s 2

Ge n e ra t e M e t e o r o log ic a l Pr o d u c t s

M e a su r e d Ob s e r v a b le s

Fo re c a st Pr o d u c t s

Ob se r v a t io n Sp e c ific a t io n s Da t a se t Sp e c if ic a t io n s

Da t a s e t Pro d u c t s

Oc e a n Ob se r v a ble s 00

Oc e a n I m a g e r y Fo r e c a s t T e x t Filt e r e d Da t a se t s Un f ilt e r e d Da t a s e t s

Use M e t e o ro lo g y Pr o d u c t s

W eat her Show T su n a m i W a r n in g Re s e a r c h Pr od u c t s

5

S a n t a Na r id a Bu o y Sy st e m En v ir o n m e n t

P age:

A-1

Title:

GOOS Sy s t e m

A rg o s Sy s t e m Na t io n a l W e a t h e r Se r v ic e

Stakeholder Context of Meteorological P roduct Generation

I n st it u t e S c ie n t is t T su n a m i W a rn in g Ce n t e r T e le v isio S a n t a Na rid a

Number:

AKB5

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

50

x

S p ec if ic a t io n s

P. 1

x x x


The A-0 diagram now models the scope of the operational behavior of our prospective system. (The activity A-11 (Control Production) is also within the scope of the whole system but, at least given our current understanding, implementation of the A-11 activity does not require acquisition of hardware or software components particularly crafted for the purposes of the Santa Narida Buoy System). Used at:



x

12/20/2001

Reader


Date

Context: Top

TOP

V iewpoint: S ystems E ngineer as Requirements E licitor. P urpose: To specify minimal and sufficient behaviors leading necessarily to a coherent set of related outputs required by external stakeholders. Co m m u n ic a t io n s Pr o t o c o ls I m a g e St a n d a r d s Da t a S h a rin g A g ree m e n t s S c h e d u le s Pro d u c t Re q u e st s M e t e o r o lo g y Da t a Re q u ir e m e n t s M e t e o r o lo g y Da t a S t a n d a rd s

Oc ean

S at ellit e Im ag ery

Oc e a n Obse r v a b le s S a t e llit e I m a g e r y

M e a s u re d Ob se rv a b le s

Ge n e ra t e M e t e o r o lo g ic a l Pr o d u c t s

M e t e o r o lo g ic a l Pro d u c t s S p e c if ic a t io n s

Meas ured

M et eo ro lo g ical Pr o d u ct s

Sp e cif i c a t io n s

00

W e a t h e r Fo re c a st e r s Na t io n a l W e a t h e r S e r v ic e Ar g o s Sy st e m S a n t a Na r id a Bu o y S y s t e m

P age:

A-0

Title:

Context of Meteorological P roduct Generation

Number:

AKB1

P. 2

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

Some observations that may help you understand diagram RTP/A-0 as it has been developed: •

The Santa Narida Buoy System is shown as a system mechanism but is immediately tunneled away. Of course, this tunneling violates an explicit injunction of IEEE 1320.1, the IDEF0 standard. We deliberately break this rule here to emphasize that the A0 activity that we are considering is performed in the main by the Santa Narida Buoy System but to preclude showing mechanism detail within decomposition diagrams because this is a requirements model

•

The Argos System and the National Weather Service are shown as mechanisms to the A0 function. You will recall that these have been identified and modeled as external stakeholders, yet there are certain functions performed by these stakeholders that are more readily represented within the scope of the model than by a series of interchanges with the A0 function at the A-0 level. These functions are indicated by shaded boxes within the model itself.

51


•

The label Weather Forecaster is attached to the National Weather Service mechanism to indicate that it is this specific element of that Service which is of interest within the scope of the A0 function.

•

Looking ahead, the A-1 term Internet Protocols has been generalized to Communications Protocols. Similarly, the A-1 term Weather Model Data Requirements has been generalized to Meteorology Data Requirements. These changes were made during decomposition analysis. The names of these controls were not changed in the A-1 diagram; again, this is a violation of IEEE 1320.1 that we have allowed here to illustrate the traceability between specific terms and more abstract terms as a model evolves in working diagrams. (We would severely criticize this violation were publication status asserted for this or any other model.)

•

The outputs Forecast Products and Dataset Products have been bundled together as Meteorological Products. We created Meteorological Products as a better abstraction at the A-0 diagram level. As with the previous point, this is a violation of IEEE 1320.1 that would not be acceptable in a publication status model, but we allow it here to demonstrate the forming of such abstractions.

Decomposing to the A0 diagram, we focus attention on activities logically needed to produce the required outputs: Used at:


12/20/2001


x

W orking Draft

Reader

Date

Context:


A-0 C 4 S c h e d u le s C 6 M e t e o ro lo g y D a t a R e q u ire m e n t s C 5 P ro d u c t R e q u e s t s C 3 D a t a S h a rin g A g re e m e n t s C 1 C o m m u n ic a t io n s P ro t o c o ls C 7 M e t e o ro lo g y D a t a S t a n d a rd s C 2 I m a g e S t a n d a rd s

I1


M e a su r e O ce a n W e a th e r C h a r a cte r istics


O1

1 O c e a n O b s e rv a t io n s

D a t a s e t P ro d u c t s

P ro vi d e Datasets

S p e c ific a t io n s M e t e o ro log ic a l P ro d u c t s

2 U n filt e re d D a t a s e t s

Fil te r Data sets

F o re c a s t P ro d u c t s 3 O c e a n I m a g e ry

F ilt e re d D a t a s e t s

I2

F o r e ca st W e a th e r


4

1 It seems perhaps that schedules and product requests might be bu ndled; meteorology data requirements an d data sharing agreements might be bundle d; and meteorology data standards and image standards might be bu ndled. M 2 A rg o s S y s t e m

P age:

52

A0

T itle:

Generate Meteorological P roducts


M3

W e a t h e r F o re c a s t e rs

Number:

AKB15

P. 3

O3 O2


Diagram 25. RTP/A0 (Generate Meteorological Products)

Some observations that may help you understand diagram RTP/A0 as it has been developed: •

This diagram illustrates a useful development convention. You will notice that many of the control arrows are rendered in light gray rather than the customary black. These gray arrows indicate a control (or mechanism) that (1) is attached to every box in the diagram and (2) has no arrow segment that is distinguished by an attached label. This convention serves two purposes. First, it allows these controls to visually recede and so emphasizes controls which convey more information.4 Second, it visually reminds us that these controls are bundles of more specific controls that have not yet been sufficiently analyzed. In general, a publication status model has does not contain any grayed-down control arrows.

•

The very mass of gray control arrows suggests a possible modeling problem, such as representing controls or functions at too low a level of abstraction.5

•

Some comments about possible generalization and abstraction of these control are included in the diagram as a reader note, indicated by the circle (well, oval) with the number “1” inside it. This is to be distinguished from a model note, which is indicated by a square (well, rectangle) with a number inside. A model note adds information to the meaning of the diagram; it is part of the diagram itself and is said to be “in” the diagram. In contrast, a reader note comments on the development of the meaning of a diagram; when the issue raised by a reader note is resolved, the reader note is removed. A reader note is about the diagram and is not part of the diagram; it is said to be “on” the diagram.

•

Only mechanisms previously identified as external stakeholders appear in this diagram.

We can decompose the A1 activity as:

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:



C 1 S c h e d u le s

C2

12/20/2001

x


M e t e o ro lo g y Da t a Re q u ire me n t s

C 3 P ro d u c t Re q u e s t s

Reader

Date

Context:

A0 C 5 C o mmu n ic a t io n s P ro t o c o ls C 6 M e t e o ro lo g y Da t a S t a n d a rd s C 4 Da t a S h a rin g A g re e me n t s

Da t a C o lle c t io n C o mma n d s C o n t ro l Da t a C o lle c t i o n

1

I1

M e a s u re O b s e rv a b le s


M e a s u re d O b s erv a b le s

O1

2

C o lle c t e d Da ta T ra n s mit C o lle c t e d Da t a


O2

3

M 1 A rg o s S y s t e m

P age:

A1

Title:

Measure Ocean Weather Characteristics

Number:

AKB16

P. 4

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

The following diagrams decompose the three activities in the A1 diagram. Note that the Argos System mechanism terminates in diagram A11 and in A13. The activity boxes to which this mechanism attaches are shaded gray in both diagrams, indicating behavior that is actually outside the scope of the prospective system.

54


Used at:


Date AKBocast OOASIS SE Rev: Re quire me nts TO -B E Products (RTP) 1 2 3 4 5 6 7 8 9 10

x

12/20/2001



Reader

Date

Context:

A1 C 3 C o mmu n ic a t io n s P ro t o c o ls

C 2 P ro d u c t Re q u e s t s In t e rn e t P ro t o c o ls


Ge n e rat e C o mma nd s

1 U n se n t C o mma n ds

S e nd C o mma nd s

2 S e n t C o mma n d s

Re la y C o mma n d s

3 Re la y e d C o mma n d s Re c e iv e C o mma n d s

Da t a C o lle c t io n C o mma n d s

O1

4


P age:

Title:

A11

Number:

Control Data Collection

AKB17

P. 5

Diagram 27. RTP/A11 (Control Data Collection) Used at:



x

01/10/2002

C2


M e t e o ro lo g y Da t a Re q u ire me n t s

Reader

Date

A1 C1

Da t a C o lle c t io n C o mma n d s C3

M e t e o ro lo g y Da t a S t a n d a rd s

S e nse I1


Context:


O b s e rv a b le s

O1

1

M e a s u re me n t s

Ga t h er M e a s u re me n t s

2

M e a s u re me n t S e t P a c ka g e Da t a

C o lle c t ed Da t a

O2

3

P age:

A12

Title:

Measure Observables

Number:

AKB18

P. 6

Diagram 28. RPT/A12 (Measure Observables)

55


Used at:



x

12/20/2001



Reader

Date

Context:

A1 C 1 C o mmu n ic a t io n s P ro t o c o ls C 2 M e t e o ro lo g y Da t a S t a n d a rd s

In t e rn e t P ro t o c o ls

C 3 Da t a S h a rin g A g re e me n t s

S e n d Dat a I1

C o lle c t e d Da t a 1

S e n t Da t a Re la y Da t a

2

Re la y e d Da t a Re c e i v e Da t a O c e a n O b s e rv a t io n s

O1

3


P age:

A13

Title:

Transmit Collected Data

Number:

AKB19

P. 7

Diagram 29. RTP/A13 (Transmit Collected Data)

The next two diagrams show the decompositions of A2 (Provide Datasets) and A4 (Forecast Weather). Note in A4 that the mechanism Weather Forecaster is mechanism to two activities, but that only box A4.2 is shaded. The lack of shading on box A4.1 indicates that we are currently assuming that the Weather Forecaster and the prospective system will both be needed to carry out this activity. It may be that the weather models or other tools needed by the Weather Forecaster to execute weather models may be provided by and be part of our system.

56


Used at:



12/20/2001

x

W orking Draft

Reader

Date

Context:

R ecommended P ublication C 5 M e t e o ro lo g y D a t a S t a n d a rd s C 1 M e t e o ro lo g y D a t a R e q u ire m e n t s

A0 C 2 P ro d u c t R e q u e s t s C 4 C o m m u n ic a t ion s P ro t o c o ls C 3 D a t a S h a rin g A g re e m e n t s

O b s e rv a t io n S p e c ific a t io n s

I1


Sa ve O b s e rva t i o n s


O1

1

S a v e d O b s e rv a t io n s D a t a s e t S p e c ific a t io n s C re a t e D at a s e t s

2

S aved D atasets R e t ri e ve Datasets


O2

3

P age:

A2

T itle:

P rovide Datasets

Number:

AKB20

P. 8

Diagram 30. RTP/A2 (Provide Datasets)

57


Used at:



12/20/2001

x

W orking Draft

Date

Context:


C 2 M e t e o ro lo g y D a t a R e q u ire m e n t s C 3 P ro d u c t R e q u e s t s

Reader

A0 C 5 C o m m u n ic a t io n s P ro t o c o ls

C 4 D a t a S h a rin g A g re e m e n t s


C 6 M e t e o ro lo g y D a t a S t a n d a rd s C 7 I m a g e S t a n d a rd s

I1


Ru n W e a t h e r Mo de ls

W eath er D ata

1 W ri t e W e a the r Scri p t


O2

2 G e n e ra t e Sym b o l i c Im a ge s

3

O c e a n O v e rla y s Co m bin e Im a ge s

I2



O1

4

M 1 W e a t h e r F o re c a s t e rs

P age:

A4

T itle:

Forecast Weather

Number:

AKB21

P. 9

Diagram 31. RTP/A4 (Forecast Weather)

Step 6. Developing Architectural Models Having verified the reasonableness and usefulness of this requirements model, our next task is to transform the requirements model into an architecture model. We do this by allocating each activity to some physical means, preferably without using names that imply an implicit choice between hardware, software, or some combination of hardware and software. (“Engine” and “Processor” turn out to be useful words for naming these abstract components.) As we allocate mechanisms to transformational behaviors, we apply a new decomposition stopping rule. We will decompose to a level at which each activity has only one abstract component of the prospective system as mechanism, other than human or organizational agents. Bear in mind that an abstract architectural component may encompass hardware, software, and other wares. Generally this means that an architecture model will have more diagrams than its source requirements model. However, grayeddown mechanism arrows in a diagram may indicate a decomposition that exceeds the needs of architecture analysis. As usual, we start with the A-1 environmental context diagram. As you can see, this A-1 diagram incorporates the generalizations and abstractions introduced into the A-0 diagram of the corresponding requirements model. We have not yet removed all grayed-down arrows in this diagram; these elements 58


will remain until we decide finally that the concepts they represent are not to be incorporated into our prospective systems interactions with its external environment. This diagram reflects what has been learned during the allocation of components to activities in the 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:


Date: AKBocast Rev: OOASIS SE Architecture TO-BE Pro ducts (ATP) 1 2 3 4 5 6 7 8 9 10

x

12/20/2001

W orking Draft

Reader

Date

Context: NO N E


c o n t rol re q u e s t

C o m m u n ic a t io n s P ro t o c ols incphuetd re qsu e s t S u le

D a t a S h a rin g A g re e m e n t s


C o n t ro l P ro d u c t io n 14 M e t e o ro lo g y D a t a R e q u ire m e n t s I m a g e S t a n d a rd s



P ro vi d e i m a g e ry

3 P ro v id e Ob s e rv a b le s



2

C on text of G e n e ra t e M rolo Me e tt e eo oro log g ic ic a a ll ro duucctts PProd G e n e ra t io n

M e a s u re d O b s e r v a b le s




O c e a n O b s e rv a b le s 00


Use Me t e o ro l o g y P ro d u ct s



5

S a n t a N a rid a B u o y S y s t e m A rg o s S y s t e m E n v iro n m e n t

P age:

A-1

T itle:

G O O S S ystem

x



Stakeholder Context of Meteorological P roduct Generation

x x x

I n s t it u t e S c ie n t is t Ts u n a m i W a rn in g C e n t e r Te le v is io S a n t a N a rid a

Number:

AKB5

P. 1

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

The following diagram shows the current state of the A-0 diagram in our architectural model. This diagram differs the A-0 diagram of the requirements model in the following ways: •

The prospective system is no longer tunneled away at the boundary of the 0 box. The primary purpose of the architectural model is to explore abstract components for the prospective system to which system behavior can be allocated, so the tunneling used in the requirements model is no longer appropriate.

•

Upon allocation analyses, the output Specifications has been bundled into the existing concept of Meteorology Products.

59


•

A minor point: the label Meteorology Products was Meteorological Products in the requirements model. This label was changed to be consistent in construction with other labels on the A-0 diagram.

Used at:


Date AKBocast Rev: OOASIS SE Archite cture TO -B E Products (ATP) 1 2 3 4 5 6 7 8 9 10

x

12/20/2001


Reader

Date

Context: Top

TOP

V iewpoint: S ystems E ngineer as Requirements E licitor. P urpose: To specify minimal and sufficient behaviors leading necessarily to a coherent set of related outputs required by external stakeholders.

Co m m u n ic a t io n s Pr o t o c o ls I ma g e St an d a rd s Sch e d u les Pr o d u c t Re q u e st s M e t e o r olo g y Da t a Re q u ire m e n t s M e t e o ro lo g y D a t a S t a n d a rd s

Oc ean

S at ellit e Im ag ery

Oc e a n Obse r v a b le s

S at ellit e I m ag er y

M e a s u re d Ob se r v a b le s

G en er at e M et eo r o lo g ical Pr o d u ct s

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

Meas ured

M et e o ro lo g y Pro d u ct s

00

W e a t h e r F o re ca s t e r

Na t io n a l W e a t h e r S e rv ic e A rg o s S y s t e m S a n t a Na rid a Bu o y S y s t e m

P age:

A-0

Title:

Context of Meteorological P roduct Generation

Number:

AKB1

P. 2

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

In the following diagram, we decompose the A0 function. Here we see significant changes that emerged as we contemplated the allocation of behaviors to abstract components. The three activities of the requirements diagram that modeled the different kinds of output required by different kind of users have been replace by one activity to create meteorology products and another to distribute them. The A2 function is now parent to the original three activities; the decomposition of the A2 function will reveal those activities. We were moved to make this change as we considered mechanisms for moving product to user. We could choose either to develop a distribution function in each of the original activities or to encapsulate distribution in its own activity. Clearly, the second choice has several advantages: •

60

The mass of controls that once branched from their boundary ICOM codes to every activity has disappeared. There is now only one branching gray arrow in this diagram.


•

The concept of Product Requests has localized to the distribution activity; distribution of any product occurs when it is requested (data pull). Schedules still drive data push.

•

Received Requests and Tasking now can propagate user needs all the way back to the buoys. This also provides a clearer understanding of what drives activity A11 (Control Data Collection).

•

The decomposition of A3 (Distribute Products) now can adequately treat the relationship between users and Specifications.

Used at:



x

12/21/2001

Reader


C 5 M e t e o ro lo g y Da t a Re q u ire me n t s

A-0 C 3 S c h e d u le s

C 2 Ima g e S t a n d a rd s

I1

M e a s u re O c e a n O b s e rv a b le s

Context:


C 6 M e t e o ro lo g y Da t a S t a n d a rd s


Date


T a s kin g M e a s u re d O b s e rv a b le s

O1

Re c e iv e d Req u e s t s 1


I2

S a t e llit e Ima g e ry

Ge n e ra t e M e t e o ro lo g y P ro d u c t s 2 Re a d y S p e c if ic a t io n s

Co n t ro l P a n e l

Re a d y P ro d u c t s

Dis t rib u t e P ro d u c t s M e t eo ro lo g y P ro d u c t s

O2

3

Bu o y

Bro w se r


P age:

A0

Title:

M3

W e a t h e r F o re c a s t e r



Number:

AKB15

P. 3

Diagram 34. ATP/A0 (Generate Meteorological Products)

Here at the A0 level, the Santa Narida Buoy System is disaggregated only for the first box; the modeling reasons for this will be evident when you look at the decomposition diagrams A2 and A3. In the A2 diagram, at least one branch of the Santa Narida Buoy System mechanism is not yet ready to be disaggregated. In the A3 diagram, this mechanism is unbundled into eight branches, which is too many to show on this parent diagram. Note that the arrow 1M4 (Browser) should have some relationship with the arrow 1C3 (Communications Protocols). In other words, if we postulate a Browser, the Communications Protocols should tie this Browser and our use of it to Internet standards.

61


The Browser and the Buoy mechanisms are fairly obvious references to physical components: Browser to COTS software and Buoy to a floating sensor platform. In contrast, the Control Panel mechanism represents an abstract component whose nature is not intuitively or experientially obvious: it is a posited device for exerting some element of system control. The next diagrams detail the behavior of activity A1: Used at:


AKBocast Date: OOASIS SE Rev: Architecture TO-BE Pro ducts (ATP) 1 2 3 4 5 6 7 8 9 10


12/21/2001

x

W orking Draft

Reader

Date

Context:


C 1 M e t e o ro lo g y D a t a

C 5 T a s kin g

A0 C 3 C om m u n ic a t io n s C 2 M e t e o ro log y D a t a

D a t a C o l l e ct i o n C o m m a n d s C o n t ro l D at a C o l l e ct io n

1

I1

M e a s u re O b s e rva b l e s



O1

2

C o lle c t e d D a t a

T ra ns m i t C o l le ct e d Data


3 R e c e iv e r

T ra n s m it t e r

S e n s o r S u it e

M 2 B u oy M 4 B ro w s e r M 3 C on t ro l P a n e l

P age:

A1

T itle:

M1 A rg o s

Measure Ocean Observables

Number:

AKB16

Diagram 35. ATP/A1 (Measure Ocean Observables)

62

P. 4

O2


Used at:



x

12/21/2001

W orking Draft

Reader

Date

Context:


A1



C 2 T a s k in g S a t e llit e P ro t oc o ls

I n t e rn e t P ro t o c o ls G e n e ra t e Comm ands

1 U ns e n t C o m m a n d s Se n d Com m ands

2 S en t C om m an d s R e la y Com mands

3 R e la y e d C o m m a n d s R e ce i ve C o m m a n ds

D a t a C o ll e c t io n C o m m a n d s

O1

4

M 1 C o n t ro l P a n e l

P age:

M 3 B row s e r

T itle:

A11


M 4 R e c e iv e r

Number:


AKB17

P. 5

Diagram 36. ATP/A11 (Control Data Collection) Used at:



x

01/10/2002



Reader

Date

Context:

A1 C 1 Da t a C o lle c t io n C o mma n d s C 3 M e t e o ro lo g y Da t a S t a n d a rd s

S e nse I1



O b s e rv a b le s

O1

1

M e a s u re me n t s

Ga t h er M e a s u re me n t s

2

M e a s u re me n t S e t P a c ka ge Da t a S e n s o rs

C o lle c t ed Da t a

O2

3

Meas u r em en t Pr o ces s o r

M 1 S e n s o r S u it e

P age:

A12

Title:

Measure Observables

Number:

AKB18

P. 6

Diagram 37. ATP/A12 (Measure Observables)

63


Used at:



x

12/21/2001

W orking Draft

Reader

Date

Context:

R ecommended P ublication S a t e llit e P ro t o c o ls

A1 C 1 C o m m u n ic at io n s P ro t oc o ls C 2 M e t e o ro lo g y D a t a S t a n d a rd s

I n t e rn e t P ro t o c o ls

Se n d D a t a

I1

C o lle c t e d D a t a 1

S en t D ata R e la y D a t a

2

R e lay e d D a t a R e cei ve D a t a


O1

3

M 3 Tra n s m it t e r

P age:

A13

T itle:

T ransmit Collected Data


M 2 B ro w s e r

Number:

AKB19

P. 7

Diagram 38. ATP/A13 ( Transmit Collected Data)

Note that in the diagrams for the leaf nodes A11, A12, and A13 we see that there is one allocated component for each identified activity. This resolution of mechanisms to one per activity suggests that our decomposition is sufficiently detailed for an architecture model. In the next diagram, we have a decomposition of the A2 function. Here we see three activities that were originally in the A0 diagram of our requirements model. The mass of gray control arrows has been greatly reduced. Now we also see Dataset Requests as feedback linking more sophisticated products to their source datasets.

64


Used at:



x

12/21/2001

W orking Draft

Reader

Date

Context:


A0 C 1 M e t e o ro lo g y D a t a R e q u ire m e n t s C 5 R e c e iv e d R e q u e s t s C 2 M e t e o ro log y D a t a S t a n d a rd s C 4 S c h e d u le s

D ataset R eq u ests

C3 I m a g e S t a n d a rd s

G e n e ra t e Datasets

I1

Ta s k in g R e a d y S p e c ific a t io n s


R e a d y P ro d u c t s

O1 O2 O3

1 D a t a s e t P ro d u c t s

U n filt e re d D a t a s e t s Fi l t e r Datasets

F o re c a s t P ro d u c t s 2 F ilt e re d D a t a s e t s Oc e a n I m a g e ry

I2

Fo r e ca st W e a th e r


3 F o re c a s t Te x t D a t a ba s e E n g in e

F ilt e r M 1 W e a t h e r F o re c a s t e r M 2 S a n t a N a rid a B u o y S y s t e m

P age:

A2

T itle:

Generate Meteorology P roducts

Number:

AKB22

P. 8

Diagram 39. ATP/A2 (Generate Meteorology Products)

As we allocate components here, attention is drawn to the need for a Database Engine to support A2.1 (Generate Datasets) while other components of the buoy system remain bundled. To carry out A2.2 (Filter Datasets), the need for a Filter of some sort has been recognized. A22 has not been further decomposed because support for this activity has already been allocated to a single mechanism. In contrast, the buoy system remains bundled as mechanism to A2.3 (Forecast Weather); we will need to decompose this function to understand the system components that appear to be needed for this activity. The next diagram reveals the decomposition of A21 (Generate Datasets). Note that here the set of mechanism arrows branching from the boundary ICOM code M1 (Santa Narita Buoy System) has been grayed down. Just like similar control constructs, the gray-down convention has been used here to indicate that this mechanism applies undifferentiated to every box in the diagram. Applied to a mechanism, the convention conveys that a Database Engine underlies our prospective 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:



01/05/2002

x


C 3 M et e o ro lo g y Da t a S t a n d a rd s C 1 M e t e o ro lo g y Da t a Re q u ire me n t s

Reader

Date

Context:

A2 C 4 Da t a s e t Re q u e s t s C 2 Re c e iv e d Re q u e s t s

O b s e rv a t io n S p e c if ic a t io n s

I1


Save O b s e rv a t io n s

Re a d y S p e c if ic a t io n s

O2

1 Da t a s e t S p e c if ic a t io n s S a v e d O b s e rv a t io n s

C re a t e Dat asets

2

Re t rie v e Da t a s e t s

S a v e d Da t a s e t s

T a s kin g U n f ilt e re d Da t a s e t s

O1 O3

3

O b s e rv a t io n P ro c e s s o r

Da t a s e t P ro c e s s o r

P ro d u c t P ro c e s s o r

1

A ctivation rules for A213: *1 : I1 Æ O2 *2 : ~ I1 Æ O1

M 2 Da t a b a s e E n g in e M 1 S a n t a Na rid a Bu o y S y s t e m

P age:

A21

Title:

Generate Datasets

Number:

AKB20

P. 9

Diagram 40. ATP/A21 (Generate Datasets)

Because Database Engine applies undifferentiated to each activity, its presence in the company of an object processor for each activity would not normally prompt us to decompose these activities. However, because our goal is to identify such information as is needed to produce an NDC diagram for our prospective system, our decomposition objective in this model is to decompose to a level where each activity has only one component of the prospective system as mechanism. Note that the respective sources of the unbundled Specifications seen in the A-1 diagram are identified here. A model note has been associated with box A21.3 to specify the 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:



x

01/05/2002

Reader


Date

Context:

A21


1

A 211.1 seems to be an activity which will require active involvement of human intelligence, with skill and expertise in specification and application of meteorology data standards.

S p ecify O b s erv at io n D at a S t an d ar d s


O1

1 Da t a E le me n t M e t a d a t a

O b s e rv a t io n s S c h e ma

I1

Prep ar e O b s erv at io n s


2

C le a n O b s e rv a t io n s

M ain t ain O b s e rv at io n s

S a v e d O b s e rv a t io n s

O2

3

M 1 O b s e rv a t io n P ro c e s s o r

P age:

A211

Title:

Save Observations

M 2 Da t a b a s e E n g in e

Number:

AKB24

P . 10

Diagram 41. ATP/A211 (Save Observations)

Not surprisingly, we observe that the structure of activities within A211 and A212 are topologically the same when these activities are decomposed. We also note the reader notes (supplied by the modeler but not part of the model) A211.1(1) and A212.1(1). These notes suggests that a human agent should be identified as a mechanism for these activities in the next step of analysis, that is, when we identify internal stakeholders, human and organizational agents of the prospective system. A similar reader note with similar implications will also be found on diagram A213.

67


Used at:



x

01/05/2002


Reader

Date

Context:

A21

C 1 M e t e o ro lo g y Da t a S t a n d a rd s C 2 M e t e o ro lo g y Da t a Re q u ire me n t s

1

A212.1 seems to be an activity which will require active involvement of human intelligence, with skill and expertise in specification and application of meteorology data standards.

S p e cify D at as et D at a S t an d ard s

Da t a s e t S p e c if ic a t io n s

1

I1

O1

Da t a s e t M e t a d a t a

Da t a s e t S c h e ma

Pre p ar e D at as e t s


2

M ain t ain D at as et s


O2

3

M 1 Da t a s e t P ro c e s s o r

P age:

Title:

A212


Number:

Create Datasets

AKB25

P . 11

Diagram 42. ATP/A212 (Create Datasets)

Used at:


Date Rev: Archite cture TO -B E Products (ATP) 1 2 3 4 5 6 7 8 9 10

01/05/2002

x


Reader

Date

Context:

A21

C 1 Da t a s e t Re q u e s t s C 2 Re c e iv e d Re q u e s t s

1

C a t a lo g

I1


A 213.1 seems to be an activity which will require active involvement of human intelligence, with skill and expertise in specifying and crafting meteorological data products.

S p e cify Pr o d u ct s

T a s kin g

O1

1 Da t a s e t S e le c t io n

P ro d u c t C o n s t ru c t io n Ru le s

P ro d u c t P ro p e rt ie s

R e t r ie ve D at a s et s 2 Re t rie v e d Da t a s e t s

Pack age D at as et s

U n f ilt e re d Da t a s e t s

3


P age:

68

A213

Title:

Retrieve Datasets

M 1 P ro d u c t P ro c e s s o r

Number:

P . 12

O2


Diagram 43. ATP/A213 (Retrieve Datasets)

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


12/21/2001


x

W orking Draft

Reader

Date

Context:


C 1 M e t e o ro lo g y D a t a R e q u ire m e n t s

A2 C 3 M e t e o ro log y D a t a S t a n d a rd s C 5 I m a g e S t a n d a rd s

C 2 R e c e iv e d R e q u e s t s C 4 S c h e d u le s

I1


Ru n W e a t h e r Mo de ls

W eath er D ata D ataset R eq u ests

O1

2 W ri t e W eather Scri p t


O3

O c e an O v e rla y s

1 G e n e ra t e Sym b o l i c Im a ge s

3

Co m b i n e Im a ge s

I2


S a t e llit e I m a g e ry W e a t h e r M o d e ls

W e a t h e r V ie w e r

I m a g e G e n e ra t o r

O2

4 I m a g e P ro c e s s o r

M2

P age:

A23

T itle:


Forecast Weather

M 1 S a n t a N a rid a B u oy S y s t e m

Number:

AKB21

P . 10

Diagram 44. ATP/A23 (Forecast Weather)

Again we have stopped decomposition at this level because each activity could be allocated to a single abstract component that could be unbundled from the prospective system. As before, the gray box signifies an activity performed by an external actor outside the boundaries of our system. In contrast, this diagram now affirmatively asserts that Weather Models used to generate weather forecasts using buoycollected data are indeed part of the Santa Narida Buoy System. (We might want to retain some residual skepticism about this assertion.) Now we look at the allocation of mechanisms for the A3 activity, Distribute Products. In the A3 diagram, we can see that dual mechanisms have been allocated to three of the four activities in A3. In consequence, the architecture model decomposes beyond the requirements model for further understanding; every activity in the A3 diagram has been decomposed in the architecture model, as shown in the next diagram.

69


Used at:



x

01/05/2002

Reader



E ma il P ro t o c o ls

P ro d u c t C a t a lo g

I2

W e b P ro t o c o ls

P ro d u c t O rd e r

F u lf ill O rd e rs


Context:

A0



Date

Re c e iv e d Re q u e s t s

O1

1 S t a g e d P ro d u c t s Stage P ro d u c t s

M e t eo ro lo g y P ro d u c t s

O2

W e b Re q ue s t s

2

Post P ro d u c t s I1

Re a d y S p e c if ic a t io n s 3

E ma il P ro d u c t s Lo c a l A re a Ne t w o rk 4 W e b s it e O rd e r De s k

P ro d u c t io n S e rv e r

W e b S e rv e r

M a il C o mp o s e r M a il S e rv e r


P age:

A3

Title:

Distribute P roducts

Number:

AKB23

P . 14

Diagram 45. ATP/A3 (Distribute Products)

The new decomposition diagrams are shown as the next four diagrams. Note that the single mechanism attached to A3.1 is disaggregated in diagram A31. Diagrams ATP/31 and ATP/32 contain only two boxes. This is allowed by IEEE 1320.1, wherein the allowable number of boxes in a decomposition diagram is established as between 2 and 9. In general we should note that best IDEF0 modeling practices still follow the original FIPS PUB 184 limits: at least three boxes but no more than six boxes. Here we have invoked the less restrictive IEEE 1320.1 rule because our immediate interest is to match mechanisms to activities. The presence of only two boxes in these diagrams is a flag to other systems engineers that we are have not yet really completed our analysis of these activities.

70


Used at:


Date AKBocast OOASIS SE Rev: Archite cture TO-B E Products (ATP) 1 2 3 4 5 6 7 8 9 10

01/05/2002

x


Reader

Date

Context:

A3

C 1 S c h e d u le s C 2 P ro d u c t Re q u e s t s C 3 W e b Re q u e s t s

I1

C o lle ct R e q u es t s



1

1

O1

O rd e r S p e c if ic a t io n

C ollect Requests should be done across a variety of modalities, from face-to-face conversation, telephone, FA X, email, etc. A t a later point in analysis, these should be explored by diagrams invoked by a call arrow. O r d er Pro d u ct s


O2

2

Re q u e s t L o g g e r

O rd e r L o g g e r

M1

P age:

Title:

A31

O rd e r De s k

Number:

Fulfill Orders

AKB29

P . 15

Diagram 46. ATP/A31 (Fulfill Orders)

Used at:


Date AKBocst OOASIS SE Rev: Archite cture TO-B E Products (ATP) 1 2 3 4 5 6 7 8 9 10

01/05/2002

x

C 1 P ro d u c t O rd e r

I1

Reader


Date

Context:

A3


S t ag e R e ad y Pro d u ct s


2

Ne t w o rk Re a d y P ro d u c t s

Pro v id e Pr o d u ct A cces s

S t a g e d P ro d u c t s

O1

3

M 2 P ro d u c t io n S e rv e r

P age:

A32

Title:

Stage P roducts

M 1 L o c a l A re a Ne t w o rk

Number:

AKB28

P . 16

71


Diagram 47. ATP/A32 (Stage Products) Used at:


Date AKBocast Rev: OOASIS SE Archite cture TO-B E Products (ATP) 1 2 3 4 5 6 7 8 9 10

01/05/2002

x


C 1 P ro d u c t O rd e r

Reader

Date

Context:

A3 C2

P ro d u c t Re q u e s t s C 3 W e b P ro t o c o ls


I1


S e le ct W e b Pr o d u ct s 1

I2

W e b Re q u e s t s

O1

F u lf illme n t A n o ma lie s

P ro d u c t S e le c t io n s

Pu b lis h Pag e

Re a d y S p e c if ic a t io n s

2 A v a ila b le U RL

S e rv e Pag e

M e t e o ro lo g y P ro d u c t s

3

M 1 W e b s it e

P age:

A33

Title:

P ost P roducts

M 2 W e b S e rv e r

Number:

Diagram 48. ATP/A33 (Post Products)

72

AKB27

P . 17

O2


Used at:


Date AKBocast OOASIS SE Rev: Archite cture TO-B E Products (ATP) 1 2 3 4 5 6 7 8 9 10 C1

1

01/05/2002

x


Date

Context:

A3 C 2 E ma il P ro t o c o ls


A Fulfillment Technician may be an appropriate mechanism for A34.1.

Reader

E ma il P ro p e rt ie s

S p e cify E m ail Pr o d u ct 1

E ma il C o n t e n t S p e c if ic a t io n

E ma il De liv e ry S p e c if ic a t io n

E ma il M e s s a g e s

I1

C o n s t ru ct E m ail Pro d u ct M e s s ag e


2

E m ail Pro d u ct Mes s a g e


O1

3

M 1 M a il C o mp o s e r

P age:

A34

Title:

Email P roducts

M 2 M a il S e rv e r

Number:

AKB26

P . 18

Diagram 49. ATP/A34 (Email Products)

At this point, our architecture model has been decomposed to the point at which the behavior of any given activity may be allocated to a mechanism representing a single abstract component. Our next iteration through this architecture model will focus on identifying internal stakeholders who might become actors in OOASIS use case analyses. To identify such stakeholders, we work from leaf nodes back up to the A0 diagram. Our analysis suggests that several activities in this model seem to uniquely call for the participation of human roles. We see all these participants identified in our A0 diagram; later we see that the Product Engineer role bundles a Data Engineer role.

73


Used at:



x

01/06/2002

Reader



A-0 C 3 S c h e d u le s


I1

M e a s u re O c e a n O b s e rv a b le s

Context:




Date



O1



I2


Ge n e ra t e M e t e o ro lo g y P ro d u c t s 2 Re a d y S p e c if ic a t io n s

B uoy

Sy s t e m C o n t ro lle r


Dis t rib u t e P ro d u c t s M e t eo ro lo g y P ro d u c t s

P ro d u ct E n g in e e r

3 Fu lfillm e n t Te ch n icia n


P age:

A0

Title:

M3




Number:

AKB15

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

We see where these internal stakeholders are mechanisms in the following sequence of diagrams:

74

P. 3

O2


Used at:


Date AKBocast OOASIS SE Rev: Archite cture TO -B E Products (ATP) 1 2 3 4 5 6 7 8 9 10

x

01/06/2002



Reader

Date

Context:

A1 C 3 C o mmu n ic a t io n s P ro t o c o ls

C 2 T a s kin g


In t e rn e t P ro t o c o ls Ge n e rat e C o mma nd s

1 U n se n t C o mma n ds S end C o mma nd s

2 S e n t C o mma n d s Re la y C o mma n d s

3 C o n t ro l P a n e l

Bro w s e r Re la y e d C o mma n d s Re c e iv e C o mma n d s

Da t a C o lle c t io n C o mma n d s

O1

4

M 1 S y s t e m C o n t ro lle r


M 4 Bu o y Re c e iv e r


P age:

Title:

A11

Number:


AKB17

P. 5

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

Used at:



x

01/06/2002



Reader

Date

Context:

A1 C 1 C o mmu n ic a t io n s P ro t o c o ls C 2 M e t e o ro lo g y Da t a S t a n d a rd s

In t e rn e t P ro t o c o ls

S e n d Dat a I1

C o lle c t e d Da t a 1

S e n t Da t a Re la y Da t a

2

Re la y e d Da t a

Re c e i v e Da t a O c e a n O b s e rv a t io n s

O1

3

Bro w s e r

M 1 S y s t e m C o n t ro lle r M 4 Bu o y T ra n s mit t e r

P age:

A13

Title:

Transmit Collected Data



Number:

AKB19

P. 7

75


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



x

01/06/2002


Reader

Date

Context:

A21


S p e cify O b s e r v at io n D at a S t an d ar d s 1


O1

Da t a E le me n t M e t a d a t a

O b s e rv a t io n s S c h e ma

I1

Pr ep ar e O b s e rv at io n s


2

C le a n O b s e rv a t io n s

M ain t ain O b s e rv at io n s


3

M 1 Da t a E n g in e e r

P age:

A211

Title:

Save Observations

M 2 O b s e rv a t io n P ro c e s s o r


Number:

AKB24

P . 10

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

76

O2


Used at:




x

01/06/2002

Reader

Date

Context:

A21

C 1 M e t e o ro lo g y Da t a S t a n d a rd s C 2 M e t e o ro lo g y Da t a Re q u ire me n t s

S p e cify D at as et D at a S t an d ard s

Da t a s e t S p e c if ic a t io n s

1

I1

O1

Da t a s e t M e t a d a t a

Da t a s e t S c h e ma

Pre p ar e D at as e t s


2

M ain t ain D at as et s


O2

3

M 1 Da t a E n g in e e r

P age:

Title:

A212

M 2 Da t a s e t P ro c e s s o r


Number:

Create Datasets

AKB25

P . 11

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


Date Rev: Archite cture TO -B E Products (ATP) 1 2 3 4 5 6 7 8 9 10

01/06/2002

x


Reader

Date

Context:

A21

C 1 Da t a s e t Re q u e s t s C 2 Re c e iv e d Re q u e s t s

C a t a lo g

I1


S p e cify Pr o d u ct s

T a s kin g

O1

1 Da t a s e t S e le c t io n

P ro d u c t C o n s t ru c t io n Ru le s

P ro d u c t P ro p e rt ie s

R e t r ie ve D at a s et s 2 Re t rie v e d Da t a s e t s

Pack age D at as et s

U n f ilt e re d Da t a s e t s

O2

3

M 1 P ro d u c t E n g in e e r

P age:

A213

Title:

Retrieve Datasets


M 2 P ro d u c t P ro c e s s o r

Number:

P . 12

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

77


Used at:


Date AKBocast Rev: OOASIS SE Archite cture TO -B E Products (ATP) 1 2 3 4 5 6 7 8 9 10 C 2 S c h e d u le s


x

01/06/2002

Reader


E ma il P ro t o c o ls W e b P ro t o c o ls


F u lf ill Re a d y P ro d u c t s

Context:

A0



I2

Date


O rd e rs

O1

1 S t a g e d P ro d u c t s Stage P ro d u c t s


O2

W e b Re q ue s t s

2

Post P ro d u c t s I1


E ma il P ro d u c t s L o c a l A re a Ne t w o rk

O rd e r De s k

P ro d u c t io n Se rv e r

W e b s it e

4

W e b S e rv e r


M 2 S a n t a Na rid a Bu o y S y s t e m M 1 F u lf illme n t T e c h n ic ia n

P age:

A3

Title:


Number:

AKB23

P . 14

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

When we turn to developing the requirements model for operations (RTO), we have already the advantage of the work we have done to develop the RTP and ATP models. We have deliberately given the RTO model the same Viewpoint and the same Purpose as the RTP models. This should allow us to reuse significant portions of the structure and content of our Product models. As we did before, we begin by assigning helpful names to our A-1 functions, regularizing the box numbers, and naming the A-1 diagram itself:

78


Used at:



12/21/2001

x

W orking Draft

Reader

Date

Context:

NO NE


C o m m u n ic a t io n s P ro t o c o ls

M in is t e ria l Q u e s t io n s




C o n t rol O p e ra t ion s B u o y Te c h n ic a l D a t a

14

R o u t in g D e c is io n s

M i n i s t e ri a l R e q u e s t s

Se rvi ce A g re e m e n t s

R ou t e P la n n in g R e q u ire m e n t s

S y s te m S t a tu s

M a in t e n a n c e R e q u e s t M a in t e n a n ce N o t ific a t io n S u p p ly C a p it a l R es o u rc e s 2


P ro vi d e O b s e rva b l e s

3 O c e a n O b s e rv a b le s

ra t e CGoennt e xt of R o utin g PPro rodduuct cts

M e a s u r e d O b s e rv a b le s M in is t e ria l R e p o r t s

G e n e ra t i o n

x x

00

b ro k e n b u oy

P la n Sh i p p i n g Routes

C o m m u n ic a t io n s S a t e llit e s

R o u t e P la n

x

5 R ou t in g P ro d u c t s re p a ire d b u oy A rg o s N W S G e n e ra l M a n a g e r

P age:

A-1

R o u t e P la n n e r E n vi ro n m e n t

N OA A

T itle:

Stakeholder Context of Routing P roduct Generation

Sa n t a N a ri d a B u o y Sys t e m

Number:

AKB5

P. 1

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

The corresponding A-0 diagram is:

79


Used at:


x

Date 12/26/2001 AKBocast Rev: OOASIS SE Re quire me nts TO -B E O pe rations (RTO ) 1 2 3 4 5 6 7 8 9 10


Reader

Date

Context: Top

TOP


M a in t e n a n c e No t if ic a t io n Ro u t e P la n n in g Re q u ire me n t s M in is t e ria l Re q u e s t s Ro u t in g De c is io n s P ro d u c t Re q u e s t s C o mmu n ic a t io n s P ro t o c o ls

S y st e m S t a t us O c e a n O b s e rv a b le s

O cean

G en erat e R o u t in g Pro d u ct s

M e a s u re d O b s e rv a b le s M in is t e ria l Re p o rt s Ro u t in g P ro d u c t s

00

S y ste m M ea s u r e d M i n is te r ia l R o u ti n g

A rg o s S y s t e m Ro u t e P la n n e r S a n t a Na rid a Bu o y S y s t e m

P age:

A-0

Title:

Context of Routing P roduct Generation

Number:

AKB1

P. 2

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

We decompose the A0 function in the following diagram. In this diagram, we have made some assumptions and refracted them as system requirements: •

A-1 shows routing decisions fed back into the system. However, here we capture such decisions as routing products -- these products in this view include the decisions made by the shipping router, i.e., document the decision by a downloaded itinerary.

•

We already know what activities are needed to measure ocean observables, so we will not decompose this activity again. We show no tasking because we assume that routing products will use standard datasets. Buoy status is unbundled from ocean observations; buoy status should be provided by the system controller.

•

We will not decompose either A3 or A4. Informed intuition suggests that these are conventional reporting functions with nothing much interesting for a systems perspective to be revealed by decomposition.

In the A0 diagram, A2 (Generate Routing Products) has the same structural position as Generate Products and Distribute Products together have in the Products model. Here the two reporting activities have been

80


represented, one for routine administrative reporting and the other for reporting system performance and goal attainment to the Santa Narida government. Used at:


x

Date 12/26/2001 AKBocast Rev: OOASIS SE Re quire me nts TO -B E O pe rations (RTO ) 1 2 3 4 5 6 7 8 9 10 C6

Date

Context:

A-0 C3

M in is t e ria l Re q u e s t s C4

Ro u t e P la n n in g Re q u ire me n t s C5

Ro u t in g De c is io n s

P ro d u c t Re q u e s t s C1

M a in t e n a n c e No t if ic a t io n

Bu o y S t a t u s

O c e a n O b e rv a t io n s


Reader

C o mmu n ic a t io n s P ro t o c o ls C2

I1


M ea s u re Oc e an


O2

O b s e rv a b le s 1

2

W e already know what activities are needed to measure oc ean observables , so we will not decomp ose this activity agai n. W e show no tasking b ecause we assume tha t routing products will use standard da tasets. B uoy status is unb undled from ocean obse rvations; buoy status should be provided by the system controller.

Ge n e ra t e Ro u t in g P ro d u c t s

A0

Ro u t in g P ro d u c t s

O4

2 2 S t a t u s Re q u e s t

A c t iv it y S t a t u s

Re p o rt S y s t em S t a t us

Sy st em St at us

O1

3

1

M3

P age:

Ro u t in g Dec is io n s

Ro u t in g P ro du c t s

A -1 shows routing decisions fed back into the system. However, here we capture such decisions as routing products -- these products are in this view to include the decisions made by the shipping router, i.e., document the decision by a donwloaded itinerary.

A rg o s S y s t e m

Title:

M2


Re p o rt S y s t e m A c c o mp lis h me n t s M in is t e r ia l Re p o rt s

O3

4

3

W e will not decompo se either A 3 or A 4. Informed intuition sug gests that these are conventional reporting functions with nothing much interesting to be revealed by decomposition.

Generate Routing P roducts

Number:

AKB7

P. 3

Diagram 59. RTO/A0 (Generate Routing Products)

We decompose A2 (Generate Routing Products) as shown in the following diagram. Not surprisingly, this diagram shows the same general structure for product development we explored in the Products model: generate datasets, filter datasets, produce final products. It is the A23 (Propose Itineraries) where we expect to see requirements that may be significantly different from those seen in the Products model. The structure of the decomposition of A23 should seem familiar. It is based upon the stakeholder model for a shipping route planner. We have incorporated the logic of SRP/A0 within the scope of the prospective system because the capabilities to be used by the route planner are to be provided by the Santa Narida Buoy System. In the next step we transform our Operations requirements model into an architecture model by allocating system behaviors to hardware and software components. As with our Products model, we will allocate system behaviors to agents after we have examined this allocation to hardware and software.

81


Used at:


Date AKBocast 12/26/2001 OOASIS SE Rev: Re quire me nts TO -B E O pe rations (RTO ) 1 2 3 4 5 6 7 8 9 10

x


Reader

Date

Context:

A0 C2


P ro d u c t Re q u e s t s C1

C o mmu n ic a t io n s P ro t o c o ls

Da t a s e t Re q u e s t s G e n e rat e I1



D a t a s et s

O2

1

U n f ilt e re d Da t as e t s

F ilt e r Da t a s e t s

2

P ro p o s e

F ilt e re d Da t a s e t s

It in e ra rie s Ro u t in g P ro du c t s 3 3

M1

P age:

Title:

A2

Ro u t e P la n ne r

Number:


O1

AKB9

P. 6

Diagram 60. RTO/A2 (Generate Routing Products)

Used at:


Date AKBocast 12/26/2001 OOASIS SE Rev: Re quire me nts TO -B E O pe rations (RTO ) 1 2 3 4 5 6 7 8 9 10 C2

x


P ro d u c t Re q ue s t s

C1

Reader

Date

Context:

A2



F e a s ib le Ro u t e s De t e rmin e I1


A c t iv it y St a t u s

F e a s ib le Ro u t e s


O2 O3

1 Ro u t e F o re c a s t s F o re c a s t Ro u t e W e at he r

Da t a s e t Re q u e s t s 2 E s t ima t e d It in e ra rie s E s t im a t e S h ip S c h e d u le s 3

S e le c t O p t imu m It in e ra ry 4 S e le c t e d It in e ra ry

M1

P age:

82

A23

Title:

P ropose Itineraries


Number:

AKB10

P. 7

O1


Diagram 61. RTO/A23 (Propose Itineraries)

Revisiting the A-0 diagram, we will see two changes. First, we have removed the tunnel from the mechanism arrow for our prospective system. Second, we have removed the control Routing Decisions, in keeping with the observations we made while developing the requirements model.

Used at:


AKBocast Date: OOASIS SE Rev: Architecture TO-BE Operations (ATO) 1 2 3 4 5 6 7 8 9 10

12/26/2001

x


Reader

Date

Context: Top

TOP


M a in t e n a n c e Not if ic a t io n Ro u t e P la n n in g Re q u ire me n t s M in is t e ria l Re q u e s t s P ro d u c t Re q u e s t s C o mmu n ic a t io n s P ro t o c o ls

Sy st em St at us O c e a n O b s e rv a b le s

O cean

G en er at e R o u t in g Pr o d u ct s

M e a s u re d O b s e rv a b le s M in is t e ria l Re p o rt s Ro u t in g P ro d u c t s

00

S y s te m M e a sure d M in is te r ia l R o u tin g

Argos Syst em Ro u t e P la n n e r S a n t a Na rid a Bu o y S y s t e m

P age:

A-0

Title:

Context of Routing P roduct Generation

Number:

AKB1

P. 2

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

Our A0 decomposition with abstract components allocated now looks like the next diagram. Note that we have simply denoted our system components that Measure Ocean Observables as Buoys, because we are adding nothing new to our understanding of requirements for the sensors, their platforms, or their communications. For the two reporting functions, we have ascribed a System Status Reporter component and a System Performance Reporter component as mechanisms. When we decompose the A2 activity, we determine that new requirements are not raised for A2.1 (Generate Datasets). Instead of decomposing this activity, we bundle the individual “processors” of our requirements model under the label Processing Engines to remind us that several abstract components have been previously allocated to carry out A21.

83


Used at:


Date: AKBocast Rev: OOASIS SE Architecture TO-BE Operations (ATO) 1 2 3 4 5 6 7 8 9 10

x

12/26/2001


Reader

Date

Context:

A-0


C 3 M in is t e ria l Re q u e s t s

C 2 Ro u t e P la n n in g Re q u ire me n t s C 4 P ro d u c t Re q u e s t s C1 O c e a n O b e rv a t io n s

I1



Bu o y S t a t u s

M ea s u re Oc e an


O2


Ge n e ra t e




Ro u t in g

O4

P ro d u c t s 2 2 S t a t u s Re q u e s t


Re p o rt S y s t em S t a t us

S y st e m S t at us

O1

3 Re p o rt S y s t e m A c c o mp lis h me n t s M in is t e r ia l Re p o rt s Bu o y s

O3

4

S y s t e m S t a t u s Re p o rt e r

S y s t e m P e rf o rma n c e Re p o rt e r


P age:

Title:

A0

M 2 Ro u t e P la n n e r


Number:


AKB7

P. 3

Diagram 63. ATO/A0 (Generating Routing Products)

Used at:


Date: AKBocast Rev: OOASIS SE Architecture TO-BE Operations (ATO) 1 2 3 4 5 6 7 8 9 10

12/26/2001

x


Reader

Date

Context:

A0 C 2 Ro u t e P la n n in g Re q u ire me n t s C 3 P ro d u c t Re q u e s t s C 1 C o mmu n ic a t io n s P ro t o c o ls

Da t a s e t Re q u e s t s G e n e rat e I1



D a t a s et s

O2

1



2


P ro p o s e It in e ra rie s Ro u t in g P ro du c t s 3 3

Pr o ce s s in g E n g in e s

O1

It in e ra ry E n g in e

Da t a b a s e E n g in e

F ilt e r P ro c e s s o r

W e b S e rv e r

Bro w s e r M 1 Ro u t e P la n n e r


P age:

84

A2

Title:


Number:

AKB9

P. 6


Diagram 64. ATO/A2 (Generating Routing Products) Used at:


AKBocast Date: OOASIS SE Rev: Architecture TO-BE Operations (ATO) 1 2 3 4 5 6 7 8 9 10 C2

12/26/2001

x


P ro d u c t Re q ue s t s

Reader

Date

Context:

A2

C 1 Ro u t e P la n n in g Re q u ire me n t s C 3 C o mmu n ic a t io n s P ro t o c o ls

F e a s ib le Ro u t e s

I1


De t e rmin e F e a s ib le Ro u t e s

A c t iv it y St a t u s Ro u t in g P ro d u c t s

O2 O3

1 Ro u t e F o re c a s t s F o re c a s t Ro u t e W e at he r

Da t a s e t Re q u e s t s 2

O1

E s t ima t e d It in e ra rie s E s t im a t e S h ip S c h e d u le s 3 S e le c t O p t imu m It in e ra ry 4 S e le c t e d It in e ra ry

M 3 Bro w s e r M 2 It in e ra ry E n g in e M 1 W e b S e rv e r

P age:

A23

Title:

P ropose Itineraries

Number:

AKB10

P. 7

Diagram 65. ATO/A23 (Propose Itineraries)

We also do not readily see that new requirements are raised for A2.2 (Filter Datasets), so as before we will not decompose this activity. However, we have modified the name of the mechanism for this activity from Filter to Filter Engine, in part for symmetry and in part to convey more directly than previously that we do not expect this component to be necessarily trivial. The mechanisms for A23 have been unbundled before being attached to A2.3 (Propose Itineraries). The import of this unbundling is seen in the decomposition diagram A23. In diagram A23, all controls and mechanisms branch undifferentiated from their boundary ICOM codes to each of the four boxes in the diagram; these arrows are all grayed-down to emphasize this point. From the perspective of the systems engineer, the four activities represented in A23 appear thus to be sequential behaviors of just one component. This suggests that our architectural decomposition has here driven down one level too far; unless otherwise indicated, the next iteration of our architecture model, which will focus on the allocation of behavior to internal system agents, will likely dispense with this decomposition. But this conclusion is at odds with our stated stopping rule for decomposition for an architecture model: that only one non-agent mechanism arrow attributable to the prospective system is to be attached to a leaf box, i.e., an activity that is not decomposed. We could return to the parent diagram and, noting that

85


Internet Protocols would remain a control on A2.3 (Propose Itineraries), we might simply remove the mechanism Web Server. But we intuitively sense that this is not a very satisfactory response for an architecture model. Instead we consider the relationship between Web Server and Itinerary Engine in the sense of OOASIS nodes and devices. In this sense, it is easy to see the Web Server as the infrastructure for the Itinerary Engine; the Web Server seems like an OOASIS device while the Itinerary Engine seems to be an OOASIS node. The Web Server provides the platform to exercise the Itinerary Engine, so these two mechanisms are really inextricably bound for any activity that they support. In this light, we have two choices: (1) we can bundle the device and the node together into a higher-level abstraction such as Web Itinerary Engine or (2) we can claim an exception to the 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:



x

12/26/2001


Reader

Date

Context:

A-0



C 2 Ro u t e P la n n in g Re q u ire me n t s C 4 P ro d u c t Re q u e s t s C1

I1



M ea s u re Oc e an


Bu o y S t a t u s M e a s u re d O b s e rv a b le s

O2


Ge n e ra t e Ro u t in g P ro d u c t s




O4


A c t iv it y S t a t u s Re p o rt S y s t em S t a t us

Sy st em St at us

O1

3 Re p o rt S y s t e m A c c o mp lis h me n t s M in is t e r ia l Re p o rt s Bu o y s

4

S y s t e m S t a t u s Re p o rt e r

S y s t e m P e rf o rma n c e Re p o rt e r Ad m in is t ra t o r


P age:

A0

Title:

M 2 Ro u t e P la n n e r



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

86

Number:

AKB11

P. 3

O3


In this version of ATO/A0, we introduce the Administrator6 role to support A3 (Report System Status) and A4 (Report System Accomplishments). When we revisit diagram A2, we now identify the Database Administrator role to support the generation of meteorological datasets, as shown in the next diagram. We now can dispose of the third requirements model for our purpose of identifying information needed by the OOASIS software practitioner by observing that, while critical from a systems engineering perspective, identifying and providing trained, competent personnel is beyond the scope of the software of our prospective system. We are now ready to identify, translate, and/or transform the information gathered from our systems perspective into the specific software information artifacts needed by the OOASIS method. Used at:


12/26/2001


x

Reader


Date

Context:


Da t a s e t Re q u e s t s

I1


G e n e rat e D a t a s et s


O2

1



2

F ilt e re d Da t a s e t s D a t a b a s e Ad m in is t ra t o r

P ro p o s e It in e ra rie s Ro u t in g P ro du c t s 3 3

Pr o ces s in g E n g in es

O1




W e b S e rv e r

Bro w s e r M 1 Ro u t e P la n n e r


P age:

A2

Title:


Number:

AKB9

P. 6

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-ofhand. If literal, this would violate the IEEE 1320.1 standard, because a label may be attached to only one arrow segment. Here, there are actually two Administrator labels, one centered on top of the other. 87


Step 7. Developing System Use Case Diagrams We will now build a family of system use case models. These system use case models partition and coalesce the architecture models to specify software system boundaries and actors in a way that may be translated directly into use case notation. We start with a fresh copy of each of our architecture models. The strategy is to track into the decomposition hierarchy of the model until a significant stakeholder, internal or external, is encountered as a mechanism. We basically ignore allocated components at this stage; we may return to identify components as use case actors, but we are now looking for stakeholders who may be seen as benefiting actors. Starting with the Products model, the first stakeholder we encounter is the System Controller for activities A111 and A112. These activities generate the commands that are sent to the buoys and their sensors. As seen in A11, activity A113 is actually external to the model, that is, an interchange with an external actor, the Argos System. This introduces a potential external actor with a bi-directional relationship with our tentative use case, but does not give us a good feeling of closure for this use case. We also note that Schedules and Tasking are controls on A11.1 (Generate Commands). While the source of Schedules is exogenous, the source of Tasking is endogenous; if this source is not within the use case we are currently developing, then we must ensure a natural and intuitively plausible relationship between this use case and other use cases to maintain this relationship. Our System Controller reappears with activity A131 (Receive Data), which produces the Ocean Observations used directly or indirectly by all external stakeholders. This seems to be a good point to suggest the bounds of one set of behaviors for use case analysis. We mark the activities that we feel are encompassed by this possible use case by graphical annotation of the activity boxes. Because we may find that one box may seem to cohere within more than one use case during our initial analysis, simple color-coding of boxes will not suffice. Our modeling tool gives us the option of diagonal striping in different colors, so we begin with this convention: A c t iv it y in Re d U se C ase 1F

A c t iv it y in B lu e Us e C ase 2F

A c t iv it y in B o t h B lu e a n d Re d U s e C a se s 3F

Figure 5. Conventions for Marking Activities WRT Use Cases

Then we raise the involved actors to the outermost box that encompasses the activities of the use case. Here, this is quite simple, for the original partitioning of behavior neatly matches our initial use case considerations:

88


Used at:


Date AKBocast OOASIS SE Rev: O O ASIS Sys te m Us e Cas e s (O SU) 1 2 3 4 5 6 7 8 9 10

x

01/08/2002

C5


M e t e o ro lo g y Da t a Re q u ire me n t s C6

Reader

I1

Context:

A-0 C1 C o mmu n ic a t io n s P ro t o c o ls


C 3 S c h e d u le s C4 P ro d u c t Re q u e s t s



Date

T a s kin g

M e a s ur e O c e a n O bs e r v a b le s


O1



I2


G e ne r a te M e te o r o lo g y P r o d uc ts

2 Re a d y S p e c if ic a t io n s

Sy s te m C o n t ro lle r

Dis t rib u t e Re a d y P ro d u c t s

P ro d u c t s M e t eo ro lo g y P ro d u c t s


O2

3

Bu o y s

Fu lfillm e n t Te ch n icia n

M 2 Arg o s Sy s te m

P age:

A0

Title:

M 3 W e a t h e r Fo re ca s te r


Number:


AKB25

P. 3

Diagram 68. ASU/A0 (Generate Meteorological Products)

In use case notation, this might be represented as:

Environment

System Controller


Argos System

Figure 6. Use Case Analysis: Measure Ocean Observables

Note that the Environment is shown as an actor in the Measure Ocean Observables use case because the Environment is the source of the ocean observables that are to be measured. When we move to A2, we view both the Weather Forecaster and the Product Engineer as potential actors. When we examine diagrams A2 and A21, we see that the Product Engineer is rather neatly associated with the activities Generate Datasets and Filter Datasets. However, the Product Engineer is not a primary actor but rather an agent of the prospective system. Continuing to track into the decomposition hierarchy, we find the next actor/behavior boundary at A232 (Run Weather Models). This leaves the behavior of A234 and A235 to be associated with another use

89


case. We use a lighter blue diagonal to signal that here there is not a neat overlap between activity analysis and use case analysis. Our A0 diagram now looks like:

Used at:



x

01/08/2002

C5



Reader


Context:





I1

Date

T a s kin g



O1



I2








O2

3

Bu o y s



P age:

A0

Title:



Number:


AKB25

P. 3

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

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

Environment

System Controller


Argos System

Weather Forecaster

Run Weather Models

Product Engineer

Figure 7. Use Case Analysis: Run Weather Models

90


Picking up with A234, we continue our traversal of the decomposition hierarchy, looking for the next potential actor while following the trail of artifacts that appear destined for Televisio Santa Narida. This trail takes us to function A32, which is controlled by A31, to which the agent mechanism Fulfillment Technician has been assigned. A32 (Stage Products) is the activity that makes available weather forecast artifacts for Televisio Santa Narida; the additional activities A33 and A34 appear to be extensions to the use case that incorporates A32. This is shown in the following diagram: Used at:


Date AKBocast Rev: OOASIS SE O O ASIS Sys te m Us e Cas e s (O SU) 1 2 3 4 5 6 7 8 9 10 C2

C3

S c h e d ule s


x

01/08/2002

Reader

Date

Context:

A0

P ro d u c t Re q u es t s

C1



F ulfill O rde rs


O1

1 S t a g e d P ro d u c t s

I2

S ta g e P r o d uc ts



O2

W e b Re q ue s t s

2

P ost P r o d ucts

I1


E m a il P r o d uc ts

M a il C lie n t

L o c a l A re a Ne t w o rk 4 W e b s it e O rd e r De s k

P ro d u c t io n S e rv e r

W e b S e rv e r


M2


M 1 Fu lfillm e n t Te ch n icia n

P age:

A3

Title:


Number:

AKB26

P . 11

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

We are slightly uncomfortable with grouping together A234, A235, A31, and A32 for one use case, because A31 and A32 are more general behaviors than A234 and A235; thus we are prepared to revisit this decision before we complete our use case analysis. Meanwhile, our mapping now looks like:

91


Used at:



x

01/08/2002

C5



Reader

I1


Context:






Date


O1



I2








O2

3

Bu o y s



P age:

A0

Title:




Number:

AKB25

P. 3

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

and the expanded system use case diagram looks like the following figure. Note that the system use cases we have identified in this use case diagram associate with all stakeholders addressed by our Products architecture model. Using the same approach, we analyze our Operations architecture model to enhance our system use case understanding. The external stakeholders specifically addressed by the Operations model that have not already been addressed are NOAA as buoy maintenance, NWS as General Manager, and the Shipping Route Planner. Our additional internal stakeholders are the System Administrator and the Database Administrator. We have already encompassed activity A1 within the system use case Measure Ocean Observables. Thus we begin our traversal with the A2 activity. In the A2 diagram we find our Database Administrator as mechanism to A2.1 (Generate Datasets), which was previously subsumed under the use case Stage Products. We also see again the Route Planner as mechanism to A2.3 (Propose Itineraries). The Route Planner uses the prospective system to gain a benefit but the Database Administrator is an agent of the system itself; the Database Administrator does not have an autonomous purpose as does the Route Planner.

92


Environment

System Controller


Product Engineer

Argos System

Maintain Meteorological Data

Database Administrator

Run Weather Models

Weather Forecaster

Fulfillment Technician

Stage Products

Post Products

Institute Scientist

Weather Broadcaster

Email Products

Tsunami Warning Center

Figure 8. Use Case Analysis: Stage Products

Because the Database Administrator does not have an autonomous purpose, we will give this administrator a bi-directional relationship with a use case. However, as we reconsider the use cases Stage Products and Run Weather Models, we realize that Run Weather Models was derived from a set of activities that included Generate Datasets and Filter Datasets; as we then observed, these activities serve broader purposes than just running weather models. We need to break up Run Weather Models so that the dataset database activities can support these broader purposes, as shown in the next, revised OOASIS System Use Case diagram, which is based upon the markup of the OSC/A2 diagram that follows it. The next use case we introduce is of course based upon the requirements of the Shipping Route Planner, and is shown in the next use case diagram.

93


Environment

System Controller


Argos System

Product Engineer



Run Weather Models

Weather Forecaster

Stage Products


Weather Broadcaster

Post Products

Email Products

Institute Scientist


Figure 9. Use Cases Analysis: Maintain Meteorological Data Used at:


Date: AKBocast Rev: OOASIS SE OOASIS System Use Cases (OSC) 1 2 3 4 5 6 7 8 9 10

12/30/2001

x

Reader


Date

Context:


Da t a s e t Re q u e s t s

I1


G e ne r ate D a ta s ets

A c t iv it y St a t u s

O2

1

U n f ilt e re d Da ta s e t s

F ilte r D a ta s e ts

2

F ilt e re d Da t a s e t s D a t a b a s e Ad m in is t ra t o r

P rop ose Itine r a r ie s

Ro u t in g P ro d u c t s 3 3

Pro ces s in g E n g in es

O1




W e b S e rv e r

Bro w s e r M 1 R o u t e P la n n e r


P age:

A2

Title:


Number:

AKB9

P. 6

Diagram 72. OSC/A2 (Generate Routing Products)

94


Environment

System Controller


Argos System

Product Engineer


Run Weather Models


Propose Itineraries

Weather Forecaster


Stage Products

Weather Broadcaster

Post Products

Email Products

Institute Scientist


Route Planner

Figure 10. Use Case Analysis: Propose Itineraries

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

95


Used at:


AKBocast Date: OOASIS SE Rev: OOASIS System Use Cases (OSC) 1 2 3 4 5 6 7 8 9 10

x

12/30/2001


Reader

Date

Context:

A-0



C 2 Ro u t e P la n n ing Re q u ire me n t s C 4 P ro d u c t Re q u e s t s C1

I1


M e as u re O ce a n O b s e rv ab le s



Bu o y S t a t u s M e a s u re d O b s e rv a b le s

O2

1

G e n e r a te R o u tin g P r o d u c ts




O4


A c t iv it y S t a t u s R e p o r t S y s te m S ta tus

S y st em S t at us

O1

3 R e p o r t S y s te m A c c o m p lis hm e nts

M in is t e r ia l Re p o rt s Bu o y s

S y s t e m S t a t us Re p o rt e r

O3

4

S y s te m A d m in is tr a to r S y s t e m P e rf o rma n c e Re p o rt e r

M 3 Arg o s Sy s t e m

P age:

A0

Title:

M 2 R o u t e P la n n e r



Number:

AKB11

P. 3

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


Environment

Argos System

System Controller


Product Engineer



Generate Reports

Run Weather Models

Weather Forecaster

System Administrator

Propose Itineraries

Stage Products


Weather Broadcaster

Route Planner Post Products

Institute Scientist

Email Products


Figure 11. OOASIS System Use Case Diagram

Step 8. Develop Node-Device-Connector (NDC) Diagram. We evolve our NDC diagram from our IDEF0 models in several steps or tasks, as described in this section. (The OOASIS description of an NDC diagram is reiterated here as Appendix C.) While we will still be working within the IDEF Standard Diagram Frame as we transform our IDEF0 models into NDC information, all diagrams in this model should be considered FEO (For Exposition Only) diagrams. We will make these transformations to our IDEF0 diagrams: •

Controls that represent exogenous information constraints (e.g., Communications Protocols) rather than communications (e.g., Tasking) will be removed from a diagram.

•

Each mechanism will be assessed to determine whether it represents an agent, a device, or a process to be run on a node. Depending upon its nature, mechanisms other than agents will be treated as follows: device — The box for which the device is mechanism will be shaded light blue. The token DEVICE and the mechanism label will be prefixed to the box name. The activity name will be

97


grayed-down. The mechanism arrow will be removed. (Exception: a box representing an activity performed by an external actor should already be shaded light gray; this shading will process — The box for which the process is mechanism will be shaded light green. The token NODE and the mechanism label will be prefixed to the box name. The activity name will be grayed-down. The mechanism arrow will be removed. •

Labels for input and output arrows connecting DEVICE and NODE boxes will be removed.

•

Redundant paths between two boxes will be bundled into a single arrow.

•

Applying these transforms to ONA/A11, we obtain:


C 2 T a s k in g

NO DE B r o w se r --Se n d Com m a nds

NODE C on tr o l P ane l --G e ne ra t e C o mm a n d s

1

D E V IC E Argo s S y s te m --R e la y Commands

2

D E V IC E Buoy R e ce iv e r --R e c e i ve Commands

3

D a t a C o ll e c t io n C o m m a n d s

O1

4


Figure 12. First NDC Transform on ONA/A11

Next we apply these transforms: •

Coalesce boxes by recognizing likely software components that are likely to instantiate on a single node rather than separate nodes. Because System Controller is attached to both boxes 1 and 2, and because Browser is likely to be realized as COTS software, we coalesce boxes 1 and 2, assigning the name Controller Workstation to the coalesced node.

•

Convert arrows to connection lines between transformed boxes.

Applying these transforms to ONA/All, we obtain:

98



C 2 T a s k in g

NO DE C o n tr o lle r W o r k s ta tio n --C o n t ro l P a ne l, B ro w s e r --G e n e ra t e Com mands

D E V IC E Buoy R e c e iv e r --R e c e ive Comm ands

D E V IC E Argo s S y s te m --R e la y Comm ands

D a t a C o lle c t io n C o m m a n d s

O1

4

3

1


Figure 13. Second NDC Transformation on ONA/A11

When we complete these transformations within diagrams A11, A12, and A13, we raise the decomposed elements to the parent diagram A1. The A1 diagram now looks like: C 1 S c h e d u le s C 2 T a s kin g

NO DE C o n tr o lle r W o r k s ta tio n --C o n t ro l P a n e l; B ro w s e r --G e n e ra t e C om m a n ds

DE V IC E Argos Sy s te m --R e la y C om m a n ds

D E V IC E B uoy R e c e iv e r --R e ce iv e C o m m a n ds

72F

83F

61F

I1


D E V IC E B uo y S e nsor s -- Sen s e O bs e rv a ble s


O1

44F

NO DE B uoy P roce ssor --M e a s u re m e n t P ro ce s s o r --G ath er M e a s u re m e n t s ; P a c k a ge D a t a

D E V IC E B uoy T r a n s m itte r -- Sen d Dat a

16F

D E V IC E Argos S y s te m --R e la y D a t a

NO DE C o nt r o lle r W o r k s ta tio n - -B ro w s e r


- -R e ce iv e D a t a

27F

O2

38F

55F


Figure 14. First NDC Transformation on ONA/A1

Our next transformation requires two things: •

Because there are no NDC semantics adhering to which side of a box a connector is attached to, we prefer to attach connectors to the sides of boxes in our NDC development. 99


•

Coalesce boxes that represent the same devices or nodes. Boxes 1 and 8 represent the same node and boxes 3 and 6 represent the same device.

These transformations lead to this revision: C 1 S c h e d u le s C 2 T a s kin g

I1 NO DE C o n tr o lle r W o r k s ta tio n --C o n t ro l P a n e l,


B ro w s e r --G e n e ra t e C o m m a n ds



O1

44F

O2

D E V IC E Argos S y s te m --R e la y C o m m a n ds ; R ela y D a t a

11F

D E VIC E B u o y S e n so r s --S en s e O bs e rv able s

NO DE B uoy P roce sso r --M e a s u re m e n t P ro ce s s o r --G a th e r M e a s u r e m e n ts ; P a c k a g e D a ta

D E V IC E B uoy R e c e iv e r --R e ce iv e C o m m a n ds

66F

33F

22F

D E V ICE B uoy T r a n s m itte r --S e n d D at a

55F



This is as good a time as any to introduce two grouping concepts that we will use in developing our NDC information. The first is physical grouping, which is represented by a red-bordered box; the second is logical grouping, which is represented by a blue-border box. A logical groupings may overlay a physical grouping, thus showing an interesting relationship between nodes and devices in different physical places. Our third transformation of ONA/A1 uses a physical grouping to emphasize the collocation of buoy components: C1

S c h e d u le s C2

T a s kin g

B u oy I1

NO DE C o n t ro lle r



--Ge n e r a t e Com m ands 1


O1

S e n s o rs ---

O2

Se n s e O b s e r v a b le s

W o rks t a t io n --C o n t ro l P a n e l, Bro w s e r

D E V IC E B uo y

NO DE

7

D E V IC E A rg o s Sy s te m

D E V IC E B uo y

--Re la y

Re c e iv e r -- -

Com m ands; Re la y Da t a

Re c e iv e C o m m a nd s

3

B uoy P ro c e s s o r

D E V IC E Buoy

--M e a s u re me n t

5

Tra n s m it te r ---

P ro c e s s o r --Ga t h e r M e a su re m e nt s;

Se n d Dat a 4

Pa c ka g e Da t a 2

M1

S y s t e m C o n t ro lle r

Figure 16. Third NDC Transformation on ONA/A1

Applying the same transformation logic to the child diagrams of ONA/A21 and then raising the boxes of these decomposition back up to the A21 diagram gives a figure like this:

100



C 2 Dataset R eq u ests

R e a d y S p e c ific a t io n s

C 1 R e ce iv e d R e q u e s t s

O2

D a t a s e t S p e c ific a t io n s I1


NO D E O b s e r v a tio n P r o ce s s o r --Sp e cify O b se rv a tio n D a ta S ta n da r d s; P re p a r e O b se r va tio n s

D EV ICE D a ta b a s e E n g in e --M a in ta in O b se r v a tio n s

1

2

NODE D a ta s e t P roc e ss or --S p e cify D a ta se t D a ta S ta n d a r d s; Prepar e D a ta se ts

NODE Prod u c t P roc e ssor --S p e cify P r o d u cts; P a ck a g e D a ta se ts

D EV IC E D a ta b a s e E n g in e -- M a in ta in D a ta se t s 4

3

T a s k in g

O1


O3

D EV IC E D a ta b a s e E n g in e --R e tr ie v e D a ta se ts

5

6 D a t a E n g in e e r


Figure 17. First NDC Transformation on ANA/A21

Because the Database Engine device appears three times in this diagram, our next task is to coalesce these boxes: O b s e rv a t io n S p e c ific a t io n s R e a d y S p e c ific a t io n s

O2

D a t a s e t S p e c ific a t io n s

I1


NODE O b s e rv a tio n P r oc e s s o r --S p e cify O b ser v a tio n D a ta S ta nd a r d s; Pr e p a r e O b se rv a tio n s 1

D EV ICE D a ta b a s e E n g in e --M a in ta in O b se r v a tio n s; M a in ta in D a ta se ts; R e tr ie v e D a ta se ts

2

NODE D a ta s e t P r o ce s s o r --S p e cify D a ta se t D a ta S ta nd a r d s; Pr e p a r e D ata se ts

C2 D a t a s e t R e q u e s t s C 1 R e c e iv e d R e q u e s t s

3

NODE P rod u c t P roc es s or --S p e cify P r o d u cts; P a ck a g e D a ta se ts

T a s k in g U n filt e re d D a t a s e t s

O1 O3

5

D a t a E n g in e e r



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

101


C 1 R e c e iv e d R e q u e s t s


I1

NO DE W e a th e r M a ch in e --Ru n W e a t h e r M o d e ls



NO DE F o r e ca ste r W o r k sta tio n --W eathe r V ie w e r --W rit e Weathe r Sc ri p t

1

F o re c a s t T e x t

NO DE Im a g e M a c h in e --Im a ge G e n e ra t o r; Im a ge P ro ce s s o r --G e n e ra t e Sy m b o l i c I mages; Co m bine Images

2

I2



O1

O3

O2

3

M1


Figure 19. First NDC Transformation of ANO/A23

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

I1


NO DE O b s e rv a t io n P ro ce s s o r --S p e c if y O b s e rv a tio n D a ta S t a n d a rd s ; P re p a re O b s e rv a tio ns

1


R e a d y P ro d u c t s R e a d y S p e c ific a t io n s

D E V IC E D atabas e E n g in e --M a int a in O b s e rv a tio n s ; M a int a in D a ta s e ts ; R e trie v e D a ta s e ts

2

NO D E Dat aset P ro ce s s o r - -S p e c if y D a ta s e t D a ta S ta n d a rd s ; P re p a re Data sets

O2 U n filt e re d D a t a s e t s


F o re c a s t P ro d u c t s NO DE F o r e ca s te r W o r ks ta tio n --W eathe r V ie w e r --W rit e Weather Sc ri p t

D a t a s e t S p e c ific a t io n s

C 2 R e c e iv e d R e q u e s t s


3 NOD E P ro du ct P ro ce ss o r --S pe c ify P ro d uc t s ; P a c ka g e D a tas e t s

T a s k in g

O3


NO DE F ilte r E n g in e --F il t e r Datase ts

NO DE W e a th e r M a c h in e --Run Weath er M o de ls

5

6

O1


7

4

I2


NO DE Im a g e M a ch in e --Im a g e G e n e ra t o r; Im a g e P ro ce s s o r --G e n e ra t e Sym b o l ic I mages; Co m bine Images


8

M2 P ro d u c t E n g in e e r

M 1 W e a t h e r F o re c a s t e r

D at a E n g in e e r

Figure 20. First NDC Transformation of ONA/A2

We observe in this diagram some patterns of coupling that suggest we consider coalescing nodes:

102

•

Boxes 1, 3, and 4 each has a connection to box 2.

•

Boxes 1 and 3 each contributes one part of the output bundle Ready Specifications.

•

Boxes 4 and 5 each contributes one part of the output bundle Dataset Products. Boxes 4 and 5 also share the control Received Requests.

•

Boxes 1 and 3 share the specific agent Data Engineer, a subset of Product Engineer. Together, Boxes 1, 3, 4, and 5 all share the more general agent concept Product Engineer.


Taken together, these observations seem to indicate that it may be reasonable to assert either (1) one common node for the processes represented by boxes 1, 3, 4, and 5 or (2) coalescing boxes 1 and 3 into a common node and coalescing boxes 4 and 5 into another common node. Since it is often safer to coalesce incrementally, we will take the second option, as shown in the next figure. The coalescing of boxes 4 and 5 also allows us to identify the connection between box 6 and box 4 as a redundant connection, thus further simplifying this diagram. C 2 R e c e iv e d R e q u e s t s C 1 S c h e d u le s

D a t a s e t P ro d u c t s R e a d y P ro d u c t s

I1


NO DE Data M a ch ine -- O b s e rv a t io n P ro ce s s o r ; Da tas e t P ro ce s s o r -- S p e c if y O b s e rv a t io n Data S t a n d a rd s ; P re p a re O b s e rv a tio ns ; S p e c if y D a ta s e t D a ta S t a n d a rd s ; P re p a re Datase t s


O2

DE V IC E D ata bas e E ng in e - -M a in t a in O bs e rv a t io n s ; M a in t a in D a ta s e t s ; R e tr ie v e D a ta s e t s

2

1

O3


NO DE P ro d uct M a ch ine --P ro d uc t P ro c e s s o r; F ilte r E ng in e --S p e c ify P ro d uc t s ; P a ck a ge D a ta s e t s ; F ilt e r D a t a s e ts


NO DE F o r e c a ste r W o r k sta tio n --W ea ther V ie w e r --W ri t e We athe r Sc rip t

NO DE W e a th e r M a c h in e --Run Weath er M o d e ls


5

4

T a s k in g

O1

3

I2


NO DE Im a g e M a c h in e --Im a g e G e n e ra t o r; Im a g e P ro ce s s o r --G e n e ra t e Sy m b o l i c Images; Co m bine Images


6

M 1 W e a t h e r F o re c a s t e r


Figure 21. Second NDC Transformation of ONA/A2

Continuing in the same way, we create an NDC transformation of ONA/A3: C2 P ro d u c t R e q u e s t s

C1 S c h ed u le s

I2

R e a d y P ro d u c t s

NO DE F ulfillm e nt W o rk s t a t io n --O rd e r D e s k : R e q u e s t L o g g e r; O rd e r L o g g e r --C o lle c t R e q u e s t s ; O rd e r P ro d u c ts

1

R e c e iv e d R e q u e s t s

O1

N O DE Pro d u ct io n S e rv e r --Sta g e R e a d y P ro d u c ts

D E VIC E L o ca l A re a N e t w o rk --P ro v id e P ro d u c t Access

2

I1


3


NO DE P ro d u ct W e b s it e --S e le c t W e b P ro d u c ts ; P u b lis h P a g e

O2

D E VIC E W eb S erver --S e rv e P age

6

4

NO DE M ail C o m p os e r - -S p e c if y E m a il P ro d uc t; C o n s tru c t E m a il P ro d u c t M essage

D E VIC E E m a il S e rv e r --E m a il P ro d u c t M e ssa ge

7

5

M 1 c F u lfillm e n t Te c h n ic ia n

Figure 22. First DNC Transformation of ONA/A3

And now we can raise all our transformations to the A0 level, as shown in the following diagram:

103


Buoy I1

D E V IC E A rgo s S ys te m --Re la y Com m ands; R e la y D a t a

D E V IC E Buo y Se nso rs --Se n s e O b s e rv a b l e s

O c e an O b s e rv ab le s

D E V IC E B uoy R e ce iv e r --R e c e i ve Com m a nds

M e a s u re d O b s e rv ab le s

O1

N O DE B u oy P ro ce sso r --M e a s u re m e n t P ro ce s s o r --G a t he r M e a s u re m e n t s ; P a c ka g e D a t a

6

4 2

D E V IC E B uoy T r a n sm itte r --Se n d D a t a

10

8

NO DE C o n tr o lle r W o r k sta tio n --C o n t ro l P a n e l, B ro w s e r --G e n e ra t e Co m m a n ds

1

NO DE D a ta M a ch in e --O b s e rv a t i o n P ro ce s s o r; D a ta se t P ro ce s s o r --Sp e c i f y O b s e rv a t i o n Data St a n d a rd s ; P re p a re O b s e rva t i o n s ; Sp e c i f y D a ta se t Data St a n d a rd s ; P re p a re

System Controller

DE VIC E D a ta b a s e E ng ine -- M a inta in O bs e rv a t io n s ; M a inta in D a ta s e ts ; Re trie v e D a ta s e ts

NO D E P ro d u ct M a chin e -- P ro d uc t P ro c e ss o r; F ilte r Eng ine -- S pe c ify P ro du c ts ; P a c k a ge D a ta s e ts ; F ilt e r D a ta s e t s

NO DE W e a th e r M a c h in e --R un W e a t he r M o de ls

NO D E M a il C o m pos er -- Spe c if y Em a il P ro du c t; Co ns tru c t Em a il P ro duc t M es s age

13

11

9

7

5

NO DE F u lfillm e nt W o rk s t a t io n -- O rde r D e s k : R e qu e s t Lo g ge r; O rde r Lo gg e r -- C o lle c t Re que st s ; O rde r P ro du c ts

NO DE F o r e ca s te r W o r ks ta tio n --W e a t he r V ie w e r --W ri t e We a the r Sc ri p t

I2

S at e llit e I m a g e ry

N O DE Im a ge M a ch ine --I m a ge G e n e ra t o r; I m a ge P ro ce s so r --G e n e ra t e Sym b o l ic I m a g es ; C o m b i ne I m a ge s

12

3

19

17 NO D E P ro d u ct W e b s it e -- S e le c t W e b P ro d uc t s ; P ublis h P a g e NO DE P ro du ct io n S e rv e r -- S ta g e R e a d y P ro duc ts

14 M3

D E V IC E E m a il S erv e r --E m a il P ro duc t M e s s ag e

DE VIC E L o ca l A rea N e tw o rk - -P ro v ide P ro duc t Acce ss

D E V IC E U se r W o r k sta tion --L o ca l A re a N e t w o rk; B ro w s e r; E m a i l C l i e nt

D E VIC E W e b S e rv e r -- S e rv e

20

P age

18

16

15

W e at h e r F o re c a s t e r

D a t a E n g in e e r P ro d u c t E n g in e e r

F u lfillm e n t T e c h n ic ia n

Figure 23. First NDC Transformation for ONA/A0

We are now ready for the finishing touches:

104

•

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.


•

Apply logical and physical grouping to visually annotate these relationships among nodes and devices.

•

Uncross as many crossing connections as is topologically feasible within the groupings that have been applied.

These final transformations give us our final NDC representation of the ONA/A0 diagram: B uoy I1



D E V IC E Bu oy S e n s o rs

D E V IC E A rg o s Sy st e m -- Re la y Com m ands; Re la y Da t a

- -Se n s e O b s e r v a b le s

D E V IC E Bu oy Re c e iv e r -- Re c e iv e Com m ands 5

3

7

NO DE B uoy P ro c e s s o r --M e a s u re me n t P ro c e s s o r --Ga t h e r M e a sure m e nt s; Pa c ka g e Da t a

O1

DE V IC E Buoy T ra n s m itte r --Se n d Dat a 11

9

N WS D ata C enter NO D E C o n t ro lle r W o rks ta t io n --C o n t ro l P a n e l, Bro w s e r --Ge n e r a t e Com m ands 1

NO DE D a ta M a c hine --O b s e rv a t io n P ro c e s s o r ; D a ta s e t P ro ce s s o r --S pe cify O bs e rv a t ion D ata S t a n da rd s ; P re p a re O bs e r v a t ion s ; S pe cify D atas et D ata S t a n da rd s ; P re p a re D atas ets

D E V IC E D a ta b a s e E ng ine --M a in t a in O bs e rv a t io n s ; M a in t a in D atas ets ; R e t rie v e D a tas et s

NO D E F o re c a s t e r W o rks t a tio n --W e at he r V ie w e r --W r it e We at he r Sc r ip t

NO DE P r o d uc t M a c hine --P ro d u c t P ro c e s s o r; F ilt e r E n g in e --S p e cify P ro d u ct s ; P a ck a g e D a ta s e t s ; F ilt e r D a t a s e ts

L o g g e r; O rd e r Lo gge r --C olle ct R e qu e s t s ; O r de r P r odu ct s

10

NO DE W e a th e r M a c h in e --Ru n W e a t h e r M o d e ls

NO DE Im a g e M a c h in e --Ima g e Ge n e ra t o r; Ima g e P ro c e s s o r --Ge n e r a t e Sy m b o lic Im a g e s ; C o m b in e Im a g e s

8

6

4

NO DE P r o d uct W e b s ite --S e le ct W e b P r o du cts ; P u b lis h Pa ge

NO D E F ulfillm e nt W o r k s ta tio n --O rd e r D e s k: Re q u e s t

12

2

D ata E ngineer

P roduct E ngineer

M3

17

16 NO D E M a il C om pose r --S pe c ify E m a il P r o du ct ; C on s t ru ct E m a il P rod u ct M e s s a ge

13

D E V IC E E m a il S e r v e r --E m a il P r odu ct M e s s a ge

D E V IC E Us e r W o rk s ta tio n --Lo c a l A re a Ne t w o rk; Bro w s e r; E ma il C lie n t 20

19

18

NO DE P r o d uc tio n S erver --S t a ge R e a dy P ro d u ct s

14

S ystem C ontro ller

D E V IC E W e b S e rv e r --S e rv e Page

D E V IC E L oca l A re a N e tw o r k --P r o v ide P ro du c t A cc e s s

15



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:


AKBocast OOASIS SE OOASIS NDC B (ONB) 1 2 3 4 5 6 7 8 9 10

01/10/2002

Date: Rev :

x

W orking Draft

Reader

Date

Context:


A0 C 1 P ro d u c t R e q u e s t s

D ataset R eq u es ts

I1


Ge n e ra t e Da t a s e t s


O2

1


Filte r D at a s e t s

2

F ilt e re d D a t a s e t s D a t a b a s e A d m in is t ra t o r

P ro po s e I t i n e rari e s

R o u t in g P ro d u c t s 3

P r o ce ssin g E n g in e s

O1

I t in e ra ry E n g in e

D a t a b a s e E n g in e


W e b S e rv e r

B ro w s e r M 1 R o u t e P la n n e r

M 2 S a n t a N a rid a B u o y S y s t e m

P age:

A2

T itle:


Number:

AKB9

P. 6

Figure 25. First NDC Transformation of ONB/A2

Second, our transformation of box A23.1 will be different from previous box transformations because we allowed two mechanisms to be attached to this box. Here we will generate a pair of NDC boxes to replace the single present activity box, one for each mechanism. Third, in the Operations model we had attached the label Browser to the Route Planner mechanism arrow to indicate that it is expected that the route planner would use a browser to work with the Propose Itineraries facility. Based on our work developing NDC information from the Products architecture model, we are now fairly confident that the User Workstation we have identified, loaded as it is with a browser and a mail client, will fulfill this requirement. These transformations are shown in the next diagram:

106


D at a s e t R e q u e s t s

O cean O bervations

C 1 P ro d u c t R e q u e s t s



O2

Filt e r Datasets

1

2 U n filt e re d D a t a s e t s F ilt e re d D a t a s e t s

NO DE Itin e r a r y E n g in e --P ro p o s e I t i n e ra ri e s

D a t a b a s e A d m in is t ra t o r DE V IC E W eb Se rve r --P ro p o s e I ti n e ra ri e s

3 F ilt e r E n g in e P ro c e s s in g E n g in e

Routing Products

D a t a b a s e E n g in e

4

M 1 R o u t e P la n n e r M 2 S a n t a N a rid a B u o y S y s t e m

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: C 1 P ro d u c t R e q u e s t s

I1





O2

Filt e r Datasets

1

2

D a t a b a s e A d m in is t ra t o r

M 2 S a n t a N a rid a B u o y S y s t e m

NO DE Itin e r a r y E n g in e --P ro p o s e I t i n e ra r i e s

3

M 1 R o u t e P la n n e r

D E V IC E W e b Se rve r --P ro p o s e I t i n e ra ri e s

R o u t in g P ro d u c t s

O1

4

Figure 27. Third NDC Transformation for ONB/A2

When the A2 diagram information is raised to the A0 diagram level, we obtain a view like this:

107


B uo y S ta t u s

M e a s u re Ocean O b s e rv a b le s

C 1 M a in t e n a n c e N o t ific a t io n

C4 P ro d u c t R e q u e s t s

C 3 M in is t e ria l R e q u e s t s

1 D a t a s e t R e q u e s ts

G e n e ra t e Datasets

5

Filt e r Datasets

6

D a t a b a s e A d m in is tra t o r

NO DE Itin e r a r y E n g in e --P ro p o s e I t i n e ra r i e s

4

A c tiv it y S t a t u s D E V IC E W e b Se rve r --P ro p o s e I t i n e ra ri e s

R o u t in g P ro d u c t s

O4

7

M 2 R o u te P la n n e r

NO DE A d m in istr a to r W o r ksta tio n --Sy s t e m St a t u s R e p o rt e r; Sys t e m P e rfo rm a n ce R e p o rt e r --R e p o rt Sys t e m

S y s te m S t a t u s

M in is t e ria l R e p o rt s

O1

O3

3

A d m in is t ra t o r

Figure 28. First NDC Transformation for ONB/A0

In the next step, we integrate what we have described in the Operations NDC model with the Products NDC model. This entails adding the nodes and devices from the Operations NDC model and establishing appropriate connections between these nodes and devices and existing nodes and devices. Our integration diagram looks like the following figure.

108


Buoy I1

O ce a n O b s e r v a b le s

D E V IC E S a te llite C o mms --A rg o s Sys t e m --R e la y Com mands, R e la y D a t a

D E V IC E Buoy S e n so rs -- Se n s e O b se rv a b l e s

D E V IC E B uo y R e c e iv e r --R e c e iv e Comm ands

7

5

M e a s u r e d O b se r v a b le s

NO DE Buoy P r o c e sso r --M e a s u re m e n t P ro c e s s o r --Ga t he r Me a s u re m e n t s , P a c ka g e D a t a

3

O3

D E VIC E Bu o y T ra n smitte r --Se n d D a t a

11

9

R o u t e P la n n e r

A d m in is t ra t o r

NW S Data Center NO DE A d m in istr a t o r W o r ksta tio n --Sys t e m St a t u s R e p o rt e r; Sys t e m P e rf o rm a n c e R e p o rt e r --R e p o rt Sy s t e m St a t u s ; R e p o rt Sy s t e m A c c o m p li s h m e n t s

S yste m S t atu s R ep orts

M ini st e ria l R e p o r t s

O1

O2

31 NO DE It in e ra ry E n g in e --P ro p o s e I t i n e ra ri e s

30

D EVIC E W e b S e rv e r --S e rv e P a ge

NO DE C o n t ro lle r W o rksta tio n --C o n t ro l P a n e l , B ro w s e r --G e n e ra t e Com mands

1

NO D E D a ta M a chine --O b s e rv a tio n P ro c e s s o r; D a ta s e t Pro c e s s o r --S pe c if y O b s e rv a tion D a ta S ta n d a rd s ; P re pa re O b s e rv a tio n s ; S pe c if y D a ta s e t D a ta S ta n d a rd s ; P re pa re D a ta s e ts

D E V IC E D a ta ba se E ng ine --M a in ta in O bs e rv a tio n s ; M a in ta in D a ta s e ts ; R e trie v e D a ta s e ts

NO DE P ro d uct M a chine - -P ro du c t P ro c e s s o r; F ilte r En g in e - -S pe c ify Pro d u c ts ; Pack age D a ta s e ts ; F ilte r D a ta s e ts

6

NO D E P ro d u ct W e b s it e --S e le c t W e b P rod u c t s ; P u b lis h P a g e

NO DE F o r e c a ste r W o rk st a tio n - -W eather Vie w e r - -W ri t e W e ather Sc ri p t

10

NO DE W e a th e r M a c h in e --Run W eather Mode ls

NO DE Im a g e M a c h in e -- Im a ge G en e ra t o r; Im a ge P ro c e s s o r -- Ge n e ra t e Sy m b o li c Im a ge s ; Co m b i n e Im ages

8

4

12

2

NO D E F ulfillm e nt W o rk s t a t io n --O rd e r D e s k : R eque st Lo g g e r; O rd e r Lo gg e r --C o lle c t R e q u e s ts ; O rd e r P ro d uc ts

16 D E V IC E U se r W o r ksta t io n - -L o ca l A re a N e t w o rk; B ro w s e r; E m a il C li e n t D E V IC E E m a il S e rv e r --E m a il P ro d uc t M e s s a ge

13

NO DE P ro d uct ion S e rv e r --S ta ge R e a dy Pro d u c ts

D E VIC E L o ca l A r e a N e t w o rk --P rov ide P ro du c t Access

14

S y s t e m C o n t r o lle r


D a t a b a s e A d m in is t ra t o r

P r o d u ct E n g in ee r

M3


17

N O DE M a il C om p o se r -- S p e c if y E m a il Pro d u c t; C on s truc t E m a il P ro du c t M e s s age

20

19

18

15

F u lfillm e n t Te c h n ic ia n

Figure 29. First NDC Information Integration

It is now quite straightforward to translate this into a UML deployment diagram for OOASIS software practitioners: there could be a one-to-one correspondence between the nodes, devices, and connectors in our NDC integration diagram and the nodes, devices, and connectors of a UML diagram. However, as this diagram is rather complex, we consider that the OOASIS practitioner looks to the NDC diagram not as a specification of the hardware architecture but rather as a guide to constraints that hardware architecture might impose on the design of software for the prospective system. Our first NDC information integration view incorporates a number of boxes that rather than impose constraints would allow the software designer to influence the selection of hardware upon which the software would run. Perhaps a Weather Machine should run on a supercomputer; perhaps all application logic that accesses the database should be run on one mainframe computer rather than on distributed machines throughout the NWS Data Center. Rather than proceed directly to the OOASIS NDC diagram, we first attempt to coalesce processor nodes where the individual nodes of processor capability do not appear to impose constraints on software design. In this sense, this reduction assumes that at this time it does not really matter to the system concept what the eventual platform will be for these coalesced nodes. Such a reduction is conveyed in the following figure. In this reduction, we have coalesced: •

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

•

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

109


•

The Data Machine, Product Machine, and Production Server into the Product Data Machine. E n v iro n m e n t

Buoy I1



D E V IC E Buoy S e n so r s

D E V IC E S a te llite C o m ms

D E V IC E Buoy R e ce iv e r

3

NODE B uo y P r o ce sso r

7

5

O3

D E V IC E Buoy T r a n sm itte r

9

11

F u lfillm e n t T e c h n ic ia n S y s t e m C o n t rolle r A rg u s S y s t e m

A d m in is tra t o r

NW S Data Center N ODE Sys tem W o rk s t a t io n S y s t e m S t a t u s R e p ort s M in i s t e ria l R e p ort s

O1 O2

D E V IC E E m a il S e r ve r

NO DE Web S e rv ice s M a chine

19

1 D E V IC E Are a N e tw o r k

30

D E V IC E W e b S e r ve r

D EVIC E R em ot e User W o rk s t a t io n

DEVIC E N e t w o rk User W o rk s t a t io n

20

2

17

I n s t it u t e S c ie n t is t

15

W e a t h e r P re s e n t e r NO DE P r o d u ct D a ta M a ch in e

NO DE F o r e ca s te r W o r ksta tio n

R o u t e P la n n e r Tsu n am i C en ter

6

NO DE W e a th e r M a ch in e

N O A A ( B u o y M a in t e n a n c e )

10

8

NO DE Im a g e P r o ce s s in g M a ch in e

D E V IC E D a ta b a se E n g in e

12

4

W e a t h e r F ore c a s t e r

Figure 30. Second NDC Information Integration

We refrained from coalescing the weather 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. Environment 5-10 sensors on each buoy

Buoy Sensors plans are for 1000 buoys

Buoy Receiver

Buoy Processor

Buoy Transmitter

Satellite Communication

Argos System

Tsunami Warning Center Internet

Shipping Route Planner Email Server

Remote User Workstation

System Workstation

System Administrator System Controller

NOAA Maintenance

Weather Presenter


Web Services Machine

Web Server

Network User Workstation

Institute Scientist

Product Data Machine

Area Network

Forecaster Workstation

Database Engine

Weather Forecaster

Image Processing

Weather Machine

Figure 31. OOASIS NDC Diagram

A.2 A.2.1

RESULTS OF THIS METHOD STAKEHOLDERS

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


•

A minimalist stakeholder model

•

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

For each internal stakeholder we have identified a role in one or more decomposition diagrams of one or more architecture models. For each stakeholder we have concepts indicating the role they play with respect to the prospective system, the behaviors expected of that role, the facilities (if any) provided by the prospective system for that role, the inputs needed by the stakeholder to fulfill that role, the results of carrying out that role, and the guidance required to successfully execute that role. In addition to the environment, the identified external stakeholders are: •

Weather Forecasters

•

Weather Scientists

•

Weather Showmen

•


•

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

•


•

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:

x

AUTH O R: AK B ocas t DATE 12/27/2001 PRO JECT: O O ASIS SE REV M O DEL: O O ASIS Conte xt Diagram (O CD) NO TES: 1 2 3 4 5 6 7 8 9

WORKING

READER

DATE

C O NTEXT:

DRAFT

To p

RECOMMENDED

TOP

PUBLIC AT ION

M a in t e n a n c e No t if ic a t io n Ro u t e P la n n in g Re q u ire me n t s M in is t e ria l Re q u e s t s P ro d u c t Re q u e s t s S c h e d u le s C o mmu n ic a t io n s P ro t o c o ls Ima g e S t a n d a rd s M e t e o ro lo g y Da t a S t a n d a rd s M e t e o ro lo g y Da t a Re q u ire me n t s

S y st e m S t at us M e a s u re d O b s e rv a b le s

x O c e a n O b s e rv a b le s

M in is t e ria l Re p o rt s

G en erat e M et eo ro lo g y Pro d u ct s


S at ellit e I m ag er y x

M e t e o r o lo g y Pr o d u c t s

x x x x x

0

A rg o s S y s t e m Ro u t e P la n n e r W e a t h e r F o re c a s t e r Na t io n a l W e a t h e r S e rv ic e S a n t a Na rid a Bu o y S y s t e m

PAGE:

A-0

TIT LE:

Context of Meteorology Produc t Generation

NUMBER:

AKB1

P. 1

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

As-Is Process We deliberately sidestepped the need for an as-is process model in this case study by calling for a de novo prospective system. To-Be Process The architecture and requirements models, from stakeholder context A-1 diagrams through their leaf decomposition diagrams, specify the to-be process. No transformation should be required for OOASIS application. Summary Use Case Progenitors Look to the stakeholder context diagrams and the system backstory for information upon which to create summary use cases for OOASIS.

113


System Use Case Progenitors Left-branch traversal, stopping at stakeholder mechanisms, of our architectural models’ decomposition diagrams gives us this system use case diagram for our case study:

Environment

Argos System

System Controller


Product Engineer



Generate Reports

Run Weather Models

Weather Forecaster

System Administrator

Propose Itineraries

Stage Products


Weather Broadcaster

Route Planner Post Products

Institute Scientist

Email Products


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

System NDC Diagram Progenitors Our NDC transformations of our IDEF) architectural models lead to this system NDC diagram for our case study:

114


Environment 5-10 sensors on each buoy

Buoy Sensors plans are for 1000 buoys

Buoy Receiver

Buoy Processor

Buoy Transmitter

Satellite Communication

Argos System

Tsunami Warning Center Internet

Shipping Route Planner Email Server

Remote User Workstation

System Workstation

System Administrator System Controller

NOAA Maintenance

Weather Presenter


Web Services Machine

Web Server

Network User Workstation

Institute Scientist

Product Data Machine

Area Network

Forecaster Workstation

Database Engine

Weather Forecaster

Image Processing

Weather Machine

Figure 33. OOASIS NDC Diagram for Buoy Case Study

Future Method Enhancements Future releases of this method will include treatment of alternative, anomalous, and enumerated behaviors to support OOASIS Use Case elaboration.

115



116

B. SANTA NARIDA BACKSTORY B.1

SANTA NARIDA AND THE SANTA NARIDA OCEAN OBSERVATION REGION

Santa Narida is an equatorial archipelago nation. Santa Narida is located on the equator due south of Los Angeles. Santa Narida is roughly equidistant from the major Pacific Rim shipping destinations of Los Angeles, Honolulu, the Panama Canal, and Guayaquil, Ecuador. Unusual for the Pacific Ocean, the Santa Narida Islands form a rough circle around the central Baia del Handico. As a result, Puerta Oveida, Santa 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 tobe-built system.

•

Actors interfacing to devices (or, in the case of actors representing external systems, they may be shown as residing on a node).

•

Optionally, the NDC Diagram may be augmented with deployment information, especially for OTS Software Components.

Its purpose is to provide a high-level view of hardware architecture sufficient to drive development of the System software Deployment Model (i.e., support decisions concerning elaboration and deployment of the System Software Architecture), and the Elaborated System Use Cases. Otherwise, it is probably too abstract by itself to support any hardware-oriented analyses or decisions, but should serve as a common point of reference across disciplines. A node is a computer processor (bundled with rapid-access memory) that will host to-be-built software. A group of interconnected nodes is treated as only one significant node group (or just "significant node") when there are no constraints upon the freedom to deploy software objects across that group of nodes. That is: •

Interconnections among the nodes are of sufficient bandwidth and speed compared to desired data size and transfer rates that internode communications has negligible engineering impact.

•

Load balancing across the nodes need not be explicitly engineered (e.g., due to use of a commercial object request broker or operating system in a multiprocessor environment that performs automatic load balancing).

A further implication is that significant node groups may be scaled freely; that is, the group can be engineered as a single (logical) node, the power of which is easily increased simply by adding additional

123

C. OOASIS Node-Device-Connector Diagram

nodes (at least up to the point where conditions of deployment freedom no longer apply). Moreover, all nodes in a significant node group must have equal access to any abstract devices. Note that a computer processor that figures into the system physical architecture — the physical pieces (in particular, computer hardware and devices) of the system and how they are connected — but does not host to-be-built software (i.e., it hosts only OTS Software Components) is represented as a device, not a node. Abstract devices are simply an abstraction of the hardware devices with which the software must interact or which otherwise impact the software indirectly (e.g., software interacts with a transceiver directly, but the software is also constrained to employ the protocol demanded by a satellite with which the software must communicate through the transceiver). The device is abstract because initially you need know only its general nature (e.g., transceiver, printer, monitor, sensor, type of sensor), not its particular hardware model number or full specification. Connectors are merely that; initially, they may show no more than which nodes have access to which other nodes and devices. These connections may represent any kind of a by-wire or wireless communication mechanism (e.g., the Internet, local area network, microwave). Important attributes of nodes, devices, and connectors can be added to the NDC Diagram as they become known or are posited for a feasibility study; for example: amount of memory attached to a node, the maximum data rate of a device or connector. Of course, you will eventually need complete specifications for nodes, devices, and connectors for Implement Software and, perhaps, to complete detailed failure scenarios in the Elaborated System Use Cases. Also track any associated volatilities within the NDC Diagram (e.g., alternative nodes, devices, connectors) and similarly their attributes (e.g., denote the range of possible values for a volatile attribute). Capturing uncertainty and volatility The NDC Diagram can be augmented to show deployment information as well. This is particularly convenient for OTS Software Components deployed on devices (that is, processors that do not otherwise host any to-be-built software, as is frequently the case with legacy systems or large components such as database management systems) because their deployment is not captured in the System Software Deployment Models. Moreover, the System Software Deployment Models can be built as an extension of the NDC Diagram, although this may be too cluttered in many cases. Tool Hint: You can capture the NDC Diagram as a UML deployment diagram (without adding processes, components, or objects). Actors and their associations to nodes and devices, as well as more detailed specifications (e.g., node multiplicity), may be added with attached annotations (that UML modeling tools usually support). You may find it helpful to define a special stereotype for devices representing OTS components.

— Source: OOASIS Web Site

124

D.NATIONAL DATA BUOY CENTER National Data Buoy Center Measurement Descriptions and Units STATION ID

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

DATE

in UTC

TIME

To the nearest hour, UTC.

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

D.1

STANDARD METEOROLOGICAL DATA

ATMP

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

WTMP

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

DEWP

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

PRES

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

WSPD

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

WDIR

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

GST

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

WVHT

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

APD

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

DPD

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

125

D. National Data Buoy Center

MWD

Mean wave direction (degrees) corresponding to energy of the dominant period (DOMPD). See the Wave Measurements section.

VIS

Station visibility (statute miles).

PTDY

Pressure Tendency is the direction (plus or minus) and the amount of pressure change (hPa) for a three-hour period ending at the time of observation.

TIDE

The periodic rising and falling of the earth's oceans. Tide is measured in feet.

D.2

DETAILED WAVE SUMMARY

HO

Significant Wave Height is the average height (meters) of the highest one-third of the waves during a 20-minute sampling period.

SWH

Swell height is the vertical distance (meters) between any swell crest and the succeeding swell wave trough.

SWP

Swell Period is the time (usually measured in seconds) that it takes successive swell wave crests or troughs to pass a fixed point.

SWD

Swell Direction is the compass direction from which the swell waves are coming from.

WWH

Wind Wave Height is the vertical distance (meters) between any wind wave crest and the succeeding wind wave trough (independent of swell waves).

WWP

Wind Wave Period is the time (in seconds) that it takes successive wind wave crests or troughs to pass a fixed point.

WWD

Wind Wave Direction is the compass direction (degrees) from which the wind waves are coming.

Steepness

Wave steepness is the ratio of wave height to wave length and is a indicator of wave stability. When wave steepness exceeds a 1/7 ratio the wave becomes unstable and begins to break.

AVP

Average Wave Period is the average period (seconds) of the highest one-third of the wave observed during a 20-minute sampling period.

D.3

ACOUSTIC DOPPLER CURRENT PROFILER (ADCP)

E01, E02, … ,E20

Eastward directed current velocity measurements (cm/s) for twenty depth levels separated by 16 meters of water. For station 46053, the first depth level begins at 24 meters below the water surface and the last level begins at 328 meters. For stations 46023 and 46054, the first level begins at 25 meters and the last level begins at 329 meters.

N01, N02, … ,N20

Northward directed current velocity measurements (cm/s) for the twenty depth levels described previously.

For more information, see the ADCP help section.

D.4

CONTINUOUS WINDS

DIR

Ten-minute average wind direction measurements in degrees clockwise from North.

SPD

Ten-minute average wind speed values in m/s.

GDR

Direction, in degrees clockwise from North, of the GUST, reported at the last hourly 10minute segment.

126


GSP

Maximum 5-second peak gust during the measurement hour, reported at the last hourly 10-minute segment.

GMN

The minute of the hour that the GUST occurred, reported at the last hourly 10-minute segment.

For more information on continuous winds and the timing of these measurements, see the continuous winds help section.

D.5

SPECTRAL WAVE DATA

Spectral wave density

Energy in (meter*meter)/Hz, for each frequency bin (typically from 0.03 Hz to 0.40 Hz).

Spectral wave direction

Mean wave direction, in degrees, for each frequency bin. A list of directional stations is available.

Directional Wave Spectrum = C11(f) * D(f,A), f=frequency (Hz), A=Azimuth angle measured clockwise from true North to the direction wave is from. D(f,A) = (1/PI)*(0.5+R1*COS(AALPHA1)+R2*COS(2*(A-ALPHA2))), in which R1 and R2 are nondimensional and ALPHA1 and ALPHA2 are respectively mean and principal wave directions. In terms of Longuet-Higgins Fourier Coefficients R1 = (SQRT(a1*a1+b1*b1))/a0, R2 = (SQRT(a2*a2+b2*b2))/a0, ALPHA1 = 270.0ARCTAN(b1,a1), ALPHA2 = 270.0-(0.5*ARCTAN(b2,a2)+{0. or 180.}). For more information on the mathematics behind the measuring of surface water waves, see the waves help section.

D.6

WATER LEVEL

TG01, TG02, … ,TG10

D.7

Six-minute water levels representing the height, in feet, of the water above or below Mean Lower Low Water (MLLW). Please subtract 10 ft. from every value to obtain the true water level value.

MARSH-MCBIRNEY CURRENT MEASUREMENTS

DIR

Direction the current is flowing TOWARDS, measured in degrees clockwise from North.

SPD

Current speed in cm/s.

127



128

E. APPLYING SADT ACTIVATION RULES TO IDEF0 ACTIVITY ANALYSIS This discussion expands and elaborates the introduction to activation rules given by Marca & McGowan7. Changes have been made to make the expression of activation rules consistent with the IEEE 1320.11998 IDEF0 standard. Unfortunately, activation rules are not treated by either the IEEE or the rescinded FIPS PUB 183 IDEF0 standards.

E.1

ACTIVATION RULES

Activation rules are written to clarify which combinations of input, control, and mechanism produce which combinations of output from a given activity. The general form of an activation rule is: model/activity*rule : preconditions → postconditions

comment

where: model activity rule

- the abbreviated name of the model containing the box (optional) - the node number of the activated activity - an ordinal digit identifying the position of this rule in the set of activation rules for this activity preconditions - an expression involving inputs and controls and possibly mechanisms postconditions - an expression involving outputs and possibly inputs and controls comment - a comment (optional). One important use of this comment field is to identify the appropriate called diagram when an activity is decomposed via call references rather than by a direct decomposition diagram. Example: MDL/A324*3 : C3 and I1 and I2 → O2 and O3

normal execution

FOO/Z6*5 : C1 and C2 and I3 and I4 → O1 and O5

E.2

See SUB/D32.

CONDITIONAL EXPRESSIONS

These comments apply to both precondition and postcondition expressions.

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.

130

•

Control, input, and mechanism resources are specified by their ICOM codes.

•

A precondition may not include output ICOM codes.

•

The presence of an ICOM code in a precondition expression means that the object represented by that ICOM code must be present for the activation to occur, unless qualified by an OR operator.

•

If an OR operator links two ICOM codes in a precondition, one or the other of those resources must be present for that activation to occur.


•

The unary operator NOT may be used with an ICOM code to specify that this activation will occur only in the absence of that resource, i.e., the object represented by that ICOM code must not be present.

•

A precondition may not negate all controls on an activity. This would violate the basic IDEF0 semantic rule that every transformation must be constrained.

•

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

Cn … In … Mn … and written from left to write in increasing ordinal order within a role, as this precondition expression illustrates:

C1 and C3 and I2 and I5 and M2 and M3 •

ICOM codes that do not distinguish different activations may be omitted from a conditional expression.

•

Examples of preconditions:

A4*2 : C2 and ( I1 or I3 ) → O1 M32*4 : C1 and (I1 and NOT I4 ) → O2 E.4

POSTCONDITIONS

A postcondition expression specifies the output that results from a specific activation. •

Output, control, and input resources are specified by their ICOM codes.

•

A postcondition may not include mechanism ICOM codes. Mechanisms may not be negated in a postcondition.

•

An output ICOM code in a postcondition expression means that the object represented by that ICOM code must be produced by that activation, unless qualified by an OR operator. An output not represented by an ICOM code in a postcondition expression will not be produced by that activation.

•

If an OR operator links two output ICOM codes, one or the other of those outputs must be produced by that activation.

•

Within a postcondition expression, the logical NOT operator may be applied to control and input ICOM codes to indicate that such negated control or input has been completely consumed by the transformation. (Note that a control so negated must be a control by virtue of role bundling.)

131


•

Control and input ICOM codes may appear in a postcondition only if they are negated.

•

A resource negated in a postcondition must appear in the precondition for that activation rule.

•

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

On … ~Cn … ~In … and written from left to write in increasing ordinal order within a role, as this postcondition expression illustrates: •

O1 and O3 and ~C2 and ~C3 and ~I2 and ~I5

•

Examples of postconditions:

A11*1 : C1 and ~I2 → O1 and (O2 or O3) A3*3 : C1 and I1 and I2 → O1 and ~I2 E.5

WRITING RULE SETS

These rules apply to writing activation rule sets: •

Each precondition must be distinct.

•

Any given output of an activity must be expressed in the postcondition of at least one activation rule for that activity. That is, if we provide activation rules for an activity, we must account for all possible products of that transformation; our postconditions must identify all possible outputs.

•

An output of an activity may be specified in the postcondition of more than one activation rule. (For example, consider an activity status report.)

These considerations also apply to activation rules:

132

•

The default activation rule for an IDEF0 activity is that all controls, inputs, and mechanisms must be present for the activity to execute. If the presence of all controls, inputs, and mechanisms is required for activation, an explicit activation rule should not be provided.

•

If a control, input, or mechanism is required for all possible activations, then its ICOM code should be omitted from all activation rules for the activity. It is for this reason that typical activation rules do not include mechanisms.

•

If the postcondition of an activation rule for an activity contains OR operators, you should decompose the activity to disambiguate that postcondition.

•

In a sense, an activity always completely consumes its input because an activity always transforms its input into its output. The concept of negation should be judicially used to clarify an activity. For example, consider this fragment:


blueprint

table legs table top

A s s e m b le T a b le

table 2

It would be silly to write:

A2*1 : C1 and I1 and I2 → O1 and ~I1 and ~I2 However, in this case: spark

cold air

hot air

fuel 1

furnace

it might well be useful to specify:

A1*1 : C1 and I1 and I2 → O1 and ~I2 because the expended fuel has not been transformed into the hot air. •

The OR operator in a precondition always signifies the conflation of otherwise distinct activation rules. Consider:

R5*1 : (C2 or C3) and (I1 or I4) → O1 and O2 This construction conflates these four distinct rules:

R5*1 : C2 and I1 → O1 and O2 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: order

m eat

h a m b u r g e r p a tty

bu n

p la in h a m b u r g e r

B u ild B u rger

co n d im e n ts

d r e sse d h a m b u r g e r

ch e e se

ch e e se b u r g e r 1

Activation Rules: 1 2 3 4

: : : :

C1 C1 C1 C1

and and and and

I1 I1 I1 I1

--> O 1 and I2 --> O 2 and I2 and I3 --> O 3 and I2 and I3 and I4 --> O 4

One kind of puzzlement is evidenced by questions like: “If I already have input 2 and then I get input 1, how do I know that rule 1 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

E.6

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 → 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: → O1 2 : I2 → O2 3 : I2 and I3 → O3 4 : I2 and I3 and I4 → O4

precedence puzzles; precondition anomaly

L

H

H


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 2 : C2 and I1 3 : C3 and I1 4 : C4 and I1

→ O1 → O2 → O3 → O4

1 : C1 → O1 2 : C2 → O2 3 : C3 → O3 4 : C4 → O4

this is OK, I think; I’m not quite sure why the difference in levels of abstraction doesn’t appear to pose a problem here…

H

L

H


→ O1 → O1 → O1 → O1

1 : C1 or C2 or C3 or C4 → O1

different ways of doing or triggering the same thing; possibility of “ladder” decomposition diagram

H

H

L


→ O1 → O2 → O3 → 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

INCORPORATING ACTIVATION RULES IN A DIAGRAM

A set of activation rules for an activity should be treated as a model note in the IDEF0 diagram that contains the box that models that activity. If there is sufficient room in the diagram, the activation rules may be fully expressed directly in the diagram as a model note. Otherwise, the model note should direct the reader to the appropriate text page. Examples:

135


Schedule Blueprint

Table Legs Table Top

Parts Request Production Status Table

A s s e m b le T a b le 1

Acti vation rules for A421:

3 1: I1 and I2 Æ O2 and O3 2: ~I1 or ~I2 Æ O1 and O2

Note that the model/node elements of the rule statement have been omitted because the context unambiguously identifies these rules. Schedule Blueprint

Table Legs Table Top

Parts Request Production Status Table

A s s e m b le T a b le 1

3

See A42T2 for activation rules.

C a rp e n t e r

In this example, the model note directs the reader to the second text page accompanying diagram page A42.

E.7

REVISITING MARCA AND MCGOWAN’S EXAMPLE

Marca and McGowan provide this example to illustrate activation rules:

136


Job p lans Job Plans

Unfinis hed Jobs

Unfinished Jobs

E v a lua te Jo b P r o g re ss

Job Status Finished or Unfinished Job Next Job O rder Step

Job S tatus Finis hed or Unfinis hed Job Nex t Job Order S tep

1

J 21*2: I1 and C1 J 21*3: I1 and C1 J 21*4: I1 and C1 J 21*1: I1 and C1

O3

(Job start.)

O 2 and O 3

(Next job step.)

O2

(Inspection time.)

O1

(Status request.)

Figure 19-3 An Activity w ith Several Activation Rules M arca & M cG ow an, SADT, page 126.

Ignoring semantic and syntactic errors as well as style anomalies in this diagram, we would recast these activation rules as:

A21*1 : C1 and I1 → O3 A21*2 : C1 and I1 → O2 and O3 A21*3 : ~C1 and I1 → O2 A21*4 : C1 and I1 → O1

job start next job step inspection time status request

However, in light of IEEE 1320.1, some comments on the activation rules in this figure should be made. Attached to the box of Figure 19-3 are one input, one control, and three outputs. There are only four possible logical combinations of input and control presence for a box with only two resource ICOMs:

1. 2. 3. 4.

I1 and C1 I1 and ~C1 ~I1 and C1 ~I1 and ~C1

First, IDEF0 semantics require at least one control on each transformation. Combinations 2 and 4 violate basic IDEF0 semantics. Only combinations 1 and 3 could be valid IDEF0 preconditions. Second, activation rules 1, 2, and 4 in the example all express the same precondition. Therefore, these rules are ambiguous; we cannot tell whether activation rule 1, 2, or 4 will activate the transformation. Thus, we find: •

There is only one valid activation rule here:

137


A21*1 : C1 and I1 → O1 or (O2 and O3) or O3 The only other possible activation rule would have the precondition:

A21*2 : C1 and ~I1 → ??? In other words, this second activation rule would specify what this activity would produce if there were no unfinished jobs. •

If it is true that producing O2 all by itself requires the absence of C1, then at least one control is missing from the diagram. If we assume at least one another control (e.g., C2) for the activity, then and only then may we write:

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

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

A21*1 : C1 → O1 or (O2 and O3) or O3 A21*2 : ~C1 → O2 which implicitly states that C2 and I1 are both required for all activations.

138

LIST OF ABBREVIATIONS AND ACRONYMS NDC

Node-Device-Connector

OOASIS

Object-Oriented Approach to Software-Intensive Systems

OMG

Object Management Group

OTS

Off-The-Shelf

PCE

Prioritizable Concurrent Element

SE

Systems Engineering

SW

Software

UML

Unified Modeling Language

139

List of Abbreviations and Acronyms


140