Core API subsystems of deegree 3
1. What is a subsystem?
The motivation is to define and provide a modular set of functional units with specific responsibilities for various aspects of geoprocessing. The term "subsystem" is used to describe such a functional unit of deegree3. The needed overall functionality and thus the functional units are derived from the requirements of the software products that lat/lon and others built upon the deegree3 API (services as WFS, WMS, CSW; clients; tools; other geospatial applications).
- Modularization of the functionality into manageable parts.
- Designing a well-usable API that meets all approved requirements.
- API stability: after a subsystem has reached a stable state, client code can rely on interface stability of the subsystem API.
- Delegating development responsibilities: every subsystem has a primary maintainer.
- Defining pieces of work that need to be done.
1.2. Subsystem development process
A very involved task is to define good subsystems. They often have to be derived from "requirements clusters" first, i.e. from connected functional requirements. Compared to a "requirements cluster", a subsystem has a well-defined set of functionality and responsibilites. The following states are used in the development process of deegree3:
- requirements cluster: A set of requirements that have not been turned into well-defined subsystems yet.
- alpha: Some subsystem responsibilities and boundaries have been defined. Some functionality has been implemented, but the subsystem is still open for additional requirements and maybe for redefinition of its boundaries.
- beta: The subsystem responsibilities and boundaries have been defined and accepted. Most functionality has been implemented and the API has a reviewed design.
- stable: Implementation finished. Stable API. Only changes that don't affect the API compatibility are allowed from this point on.
2. Current status
Last update: 2010-08-03
3. deegree3 architecture
Last update: 2010-05-06