Module Generalization View

3.1 Module Generalization View Packet 1: The Science Data Processing Segment (SDPS)

3.1.1 Primary Presentation


3.1.2 Element Catalog Elements and Their Properties

Properties of SDPS modules are

  • Name, given in the following table
  • Responsibility, given in the following table
  • Visibility: all elements are visible across the system
  • Implementation information: see Volume II, Chapter 9.
Element Name Responsibility
IngestData This class handles the data ingested into the EOSDIS site. This is the abstract superclass from which all ingest instances inherit the basic ingest-related characteristics.
DataTypeL0Data Ingester for raw instrument data (L0).
DataTypeNMCData Ingester for National Meteorological Center (NMC) data.
DataTypeAlgorithm Ingester for science algorithmbased data. Relations and Their Properties

The relation types of concern to this view are implementation and interface inheritance. All relations are shown in the primary presentation. Element Interfaces

Interfaces for the elements shown in this view are specified under the corresponding elements in the module decomposition view (Volume II, Chapter 1). Element Behavior

Not applicable.

3.1.3 Context Diagram

IngestData is a part of the Ingest subsystem of the Science Data Processing Segment. The context for this view packet is established by that for the Ingest subsystem, given in Module Decomposition View Packet 5: The Ingest Subsystem (Volume II, Section 1.5, page 422).

3.1.4 Variability Guide


3.1.5 Architecture Background Design Rationale

  • Handling the variety of data sources. The Ingest subsystem is responsible for the reception and storage of several types of sensor data. A specific Ingest subsystem needs to ingest a wide variety of data types that can be delivered via a wide variety of interfaces. Given the many sources for ingested data, it will not be possible to mandate a single interface approach. These diversities and the need to support extensibility and new data/interfaces lead to a design in which the ingest functionality is generalized in a top-level class with which the users of ingest functionality interface.

    IngestData is the top-level ingest type class. The users of ingest functionality interface with that class. Currently, DataTypeL0Data, DataTypeNMCData, and DataTypeAlgorithm are the subclasses for the specific data/interface that must be ingested.

    The diversity is exhibited in the following characteristics: volume, format, structure, metadata, periodicity, interface protocol/media, and action to be taken on ingestion in EOSDIS. This diversity means that the specific ingest subclasses will inherit some basic characteristics of IngestData, such as logging of data arrival, but considerable specialization for each subclass will be needed. It would be desirable to try and limit the diversity, and therefore the specialization, but this would significantly reduce the flexibility and extensibility to support changes and new interfaces, which would significantly reduce the flexibility of EOSDIS to support future science investigations.

    Because of the way the Ingest subsystem handles the variety of data, other ECS Science Data Processing subsystems can be designed and built to use a systemwide common data type, thus simplifying their design and obviating the need for them to require generalization/specialization.

[etc.] Results of analysis

None. Assumptions


3.1.6 Other Information


3.1.7 Related View Packets[13]

[13] IngestData is a class that is a part of the Ingest subsystem. Were there an overall "System" class that every other class inherits from, that view packet would be a parent of this one. Were there lower-level specializations of, for example, DataTypeL0Data, those would be shown in children view packets.

  • Parent: None in this view. Module Decomposition View Packet 5: The Ingest Subsystem (Volume II, Section 1.5, page 422) is a beyond views parent.
  • Children: None.
  • Siblings: None in this view. View packets in the Module Decomposition View (Volume II, Chapter 1) that deal with subsystems of the Science Data Processing Segment are beyond views siblings.

Software Architectures and Documentation

Part I. Software Architecture Viewtypes and Styles

The Module Viewtype

Styles of the Module Viewtype

The Component-and-Connector Viewtype

Styles of the Component-and-Connector Viewtype

The Allocation Viewtype and Styles

Part II. Software Architecture Documentation in Practice

Advanced Concepts

Documenting Software Interfaces

Documenting Behavior

Choosing the Views

Building the Documentation Package

Other Views and Beyond

Rationale, Background, and Design Constraints


Documenting Software Architectures(c) Views and Beyond
Documenting Software Architectures: Views and Beyond
ISBN: 0201703726
EAN: 2147483647
Year: 2005
Pages: 152 © 2008-2020.
If you may any questions please contact us: