Oasis – Open architecture for Accessible Services Integration and Standardization
Download 1.2 Mb.
|
- Navigate this page:
- Abbreviations List
- Executive Summary
- 1.Introduction
List of TablesTable 1: Linkage of end-user profiles with OASIS SP3 services and priority use cases per user group. 150 Table 2: Linkage of SP3 use cases to the interview findings. 154 Abbreviations List
Executive SummaryOASIS introduces an innovative, Ontology-driven, Open Reference Architecture and System, which will enable and facilitate interoperability, seamless connectivity and sharing of content between different services and ontologies in all application domains relevant to applications for the elderly and beyond. In Chapter 1 there is an introduction of the scope of this documentation. It provides the steps and relevant work before the definition of the use cases and application scenarios of SP3 ‘Autonomous Mobility and Smart Workplaces’. In Chapter 2, the description of the on-line database is provided, which contains the state of the art of systems, projects and services in the area of Autonomous Mobility and Smart Workplaces. Chapter 3 presents the on-site interviews results that were performed in 5 countries, leading to the user requirements extraction. Chapter 5 presents the use cases definition and clustering prior to the analytical description of the actual SP3 use cases and their scenarios. In total, there are 38 different UCs defined for SP3. Also, in Chapter 6, three more use cases are analysed, the cross-SP ones, as these bind together all the SPs. Chapter 6 presents the linkage of the SP3 services and use cases with the end-user profiles and the interviews results. Chapter 7 contains the conclusion of this Deliverable. Finally, in Annex 1 the benchmarking template is provided, while in Annex 2 the analytical database manual is given. The last Annex, Annex 3, contains the Use cases template that was used commonly for the description of SP2 and SP3 use cases. 1.IntroductionWhen starting a system development project, the system to be developed is the putative solution to some problem in the user's environment (the "application domain"). Naturally, the problem-solving method is composed of the following steps:
A Use Case, as a description of an actor's interaction with the system to be developed is both a description of the system's user interface and an indirect description of some function that the system will provide. In short, as descriptions of the new system, Use Cases belong in step 2 above, describing the proposed solution to the problem. So the development of Use Cases has a place in the problem solving process, but that place is not as the first step, and it is not as the only step. Thus, although UCs constitute an essential work towards the innovative OASIS system development, other factors contribute also to the system success. More definitions and discussions about them can be found in section 1.1. The first activity in the requirements-gathering process must be the study and description of the problem-environment, the application domain. To put it bluntly, the initial step is the studying and understanding of the system to be developed, and not to jump right in and start proposing a solution (Ferg, 2003). Thus, the partners that lead the development of a specific module/system (as part of the OASIS SP3 services) proposed the appropriate UCs relevant to their module/system. However, these were correlated to the benchmarking and user needs activities findings, to verify them and furthermore, define their proposals, characteristics and priorities.
|