Deliverable D3.1: SPIKE system architecture

Abstract

This report outlines the overall architecture of the SPIKE system. The process of architecture design was governed by user requirements collected during the previous project phase. It has resulted in the definition of functional as well as structural boundaries of the system. In addition, a coarse-grained architecture break-down into software managers playing the role of main system constituents is presented. The architecture description provides different views and perspectives representing different architecture aspects –both functional as well as nonfunctional.

The architecture is complemented by an illustration how the architecture can be employed to support various use cases defined within the project's application pilots.

The presented report is the first document in a series of documents describing a system to be designed and implemented within the SPIKE project. This report is an architectural report – it outlines ideas of the consortium of developer partners how the SPIKE system is going to be built regarding its internal module structure. Thus, it represents a link between a birds-eye view of the system as given in the project's Description of Work [DOW] and a description of the system's components to be provided in the upcoming deliverable D3.2 (SPIKE system components functional descriptions).

The aim is to define system boundaries, to break the system down into architectural pieces (so called managers), and to define their mutual dependencies. This deliverable forms one of the pillars on which the work to be accomplished in the work packages 4 and 5 will be based.

The deliverable itself consists of four basic parts (some of which span across one or more document sections):

• Methodology
• Overall architecture and system boundaries
• Architectural views and perspectives
• The first part defines a few basic terms and their relationships and introduces the approach used to present an architectural description of the SPIKE system. For the overall architectural design process we have used an approach which is based on the work of Rozanski and Woods [NREW] and the architectural description is in line with the IEEE 1471 standard [IEEE].

The second part is dedicated to the system as a whole. The system is considered as a grey box Architecture validation on the system architecture) of its internal structure is presented. The focus is on defining system boundaries. The scope of the system serves to identify functional boundaries – which functionality is expected to be covered by the system and which functionality is out of the scope of the SPIKE project. The context of the system provides structural boundaries – a list of external entities the system will communicate with and data flows communicated between the system and these entities.

The third part of the document represents the main and most comprehensive part of the report. It is dedicated to the internal architecture of the SPIKE system. In order to present architectural description, a “divide and conquer” principle has been employed – to partition the description and to attack it from different points of view simultaneously. The description uses two descriptive forms:

• the architectural views and perspectives characteristics of the system, the following views have been employed: functional, information, concurrency, deployment, and operational view. All views follow the same structure which includes also user requirements relevant to the view, design considerations and principles employed within the view, and view specific parts.
• The architectural views represent particular aspects of the architecture. Based on The following perspectives have been selected as relevant for the system: security, conceptual, availability and resilience, accessibility, internationalisation, and usability perspective. The perspectives follow the same structure as views do. Since they are orthogonal to views (and can be applied to views), their structure incorporates this topic as well.

The last part of the report tries to demonstrate how application cases defined by user project partners [D2.2] can be mapped onto the architecture (i.e. it tries to prove that the architecture is able to support the pilot applications). The mapping is twofold –context of the applications is mapped onto the context of the system and a set of use cases defined for each application is mapped onto a set of sequence diagrams demonstrating how cooperation among architectural constituents is able to meet the use cases.

You can download a short version of this document here:

D.3.1. Spike system architecture

In order to obtain the full content of this document, please use the contact form below: