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

1.1. Goals

• 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

3. deegree3 architecture

---

CategoryDeegree3