Repository Structure

Table of Contents Overview Wiki Page 1: "Introduction" Wiki Page 2: "General Design Decisions" Wiki Page 3+: Building Blocks Components Special Case: BB with only one Component

Overview

The basic components of the Runtime Support Platform are handled by seven Expert Groups (EG):

• Middleware
• Security
• Local Device Discovery and Integration
• Context Management (and Ontologies)
• Service Infrastructure
• User Interaction Management
• Remote Interoperability

Each EG is represented by one repository in GIT and offers information and reference about the group and its developments. This section describes how these Wiki pages are structured. The overall structure is depicted in the following figure. Please note that other projects (ontologies, porting to Android, tools, services..) may have a different structure.

Each EG is described in 2+n Wiki pages that describe the developments of the EG in a top-down manner. The first page presents some general information about the group (Introduction) and the second page presents some general design decisions for the whole group (or big parts of the group). The remaining Wiki pages describe the different Building Blocks (BB) as defined in the universAAL Concrete Architecture. Each BB is described in one Wiki page and provides information about the components (i.e. software artefacts) contained in this block. The components (as well as the BBs) are horizontally aligned, as shown in the figure above. That means that the structure of components is the same for all components making it easy to find the required information.

Wiki Page 1: "Introduction"

The first Wiki page presents some general information about the EG:

1. ID Card
   Provides information about how to run all the components and links to further information (e.g. SVN, tracker, forums, Javadoc).
2. Definition
   Provides an introduction to the EG; the scope may be further refined in a separate subsection.
3. Relationship to the Concrete Architecture
   Shows which parts of the Concrete Architecture are handled by the EG and how the BBs are distributed in the following Wiki pages.

Wiki Page 2: "General Design Decisions"

The second Wiki page presents some general design decisions for the whole group (or big parts of the group). Most of these decisions were taken during the consolidation phase of universAAL: It provides some general design decisions of the EG about how to realize the tasks described in definition and scope. The design decisions are based on a comparison of the related design decisions from the input projects as well as new argumentations and ideas resulted from the group internal discussions.

Wiki Page 3+: Building Blocks

The remaining Wiki pages describe the different BBs as they are separated in page 1, “Relationship to the Concrete Architecture”. Each BB is described in exactly one Wiki page. Generally, the structure for each BB Wiki page is as follows:

1. Black-box description
   Description of the BB as a black-box.
2. Design decisions
   Analysis of the building block based on the above two info items and in the context of the general design decisions from the consolidation process in order to derive a concrete set of software artefacts comprising the implementation of the building block, each with its own dedicated description
3. Component 1
   (see next section)
4. Component 2
   (see next section)

…

Components

Each component (in most cases a component is exactly one software artifact/bundle) is described in the following way:

1. Black-box description
   Equivalent to BB: describe the component as a black-box.
2. Bundles
   The bundle ID Card. Similar to the EG ID Card this provides information about how to run the component and links to further information.
3. Features
   A short list of all functionalities that this component provides.
4. Design decisions & Specification
   The design decisions that have led to the concrete implementation of the component. It may contain many subsections, e.g. class diagrams, overview of concepts..
   • .. some concept ..
   • Ontologies
     The ontology that the component defines or uses.
   • Configuration
     Configuration parameters, e.g. as property files or as parameters for the run configuration.
   • Extensions
     Information about how to extend the component, e.g. how to write plugins.
   • Provided services
     Provided service profiles (if the component acts as service callee); may contain code samples for service requests.
   • Provided context events
     Provided context events (if the component acts as context publisher); may contain code samples.
   • User Interaction
     Description of user interface; may contain code samples.
5. Implementation
   This section about the actual implementation is typically very short. Most information should be given in the design decisions and a detailed description about the API is available as Javadoc.

Special Case: BB with only one Component

In case the BB comprises only one component, the structure is simplified because the first three sections of the BB are basically equivalent to the sections of the component. Thus, the structure of the BB is the structure of the component. If this is the case, the black-box description should end with an appropriate comment, e.g. the Service Management BB consists only of the service bus, thus the comment could be: "This building block consists of a single component: the service bus."