3.1 Module Generalization View Packet 1: The Science Data Processing Segment (SDPS)
3.1.1 Primary Presentation
3.1.2 Element Catalog
3.1.2.1 Elements and Their Properties
Properties of SDPS modules are
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. |
3.1.2.2 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.
3.1.2.3 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).
3.1.2.4 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
None.
3.1.5 Architecture Background
3.1.5.1 Design Rationale
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.]
3.1.5.2 Results of analysis
None.
3.1.5.3 Assumptions
[omitted]
3.1.6 Other Information
[omitted]
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.
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
References