d2.6 daphne system architecture first designdaphne-fp7.eu/sites/default/files/d2.6 daphne system...

DAPHNE Data-as-a-service platform for healthy lifestyle and preventive medicine

610440

D2.6 Daphne System Architecture first

design Lead Author: Carlos Marcos (Atos)

With contributions from: Reviewer: Roni Ram (IBM)

Deliverable nature: R

Dissemination level: (Confidentiality)

Consortium (CO)

Contractual delivery date: 31/10/2014

Actual delivery date: 31/10/2014

Version: 11

Total number of pages: 28

Keywords: “System Architecture”, “ISO/IEC/IEEE 42010 standard”

DAPHNE Deliverable D2.6

610440 of 28

Abstract

The present document describes Daphne System Architecture from a more formal point of view than the

previous Architecture Deliverable. It introduces the standard ISO 42010 with its most relevant concepts and

applies them to the concrete case of the project. It does not make use of all the ideas expressed on the

standard, as this will be done on the next Architecture Deliverable, which will present the final and definitive

view of the system.

Deliverable D2.6 DAPHNE

610440 of 28

Executive summary

According to the literature, a key factor of successful IT (and sometimes non-IT) projects is the correct

definition of the System Architecture. Evidence shows that having this definition completed on time helps

other instances of the project, from the Functional Analysts and Programmers to the Steering Committee of

the project, to provide early feedback about what it is expected from the project so improving the Software

Cycle and thus enhancing further communication during the development. A well-defined Architecture also

helps the different stakeholders involved in the project to fix their roles on the project and to understand what

will be produced for them at the end, which enables to adapt in advance their systems for the interoperability

when the system is set in production stage.

This document aims to describe a first version of Daphne system architecture so getting the benefits

described before. In order to do so, the standard ISO/IEC/IEEE 42010 will be used. Such standard, whose

last version was released on 2011, aims to ease the process of Architecture definition by defining key

concepts that must be addressed during it, like Stakeholders, System Concerns, Views and Viewpoints, etc.

Current deliverable is the result of applying such process to the concrete case of Daphne System. Being the

first version, it is not aimed to be a complete definition of the future system, but it will include at least the

core components of the Daphne platform, the main stakeholders and the key relationships among them, as

detailed as possible and providing references to the deliverables where they are fully described.

The deliverable is also aimed to serve as a reference for Daphne developers, where they can quickly find the

components they interact with and under which circumstances.


610440 of 28

Document Information

IST Project

Number

610440 Acronym DAPHNE

Full Title Data-as-a-service platform for healthy lifestyle and preventive medicine

Project URL http://www.daphne-fp7.eu/

Document URL

EU Project Officer Mr. Benoit Abeloos

Deliverable Number D2.6 Title Daphne System Architecture first design

Work Package Number WP2 Title Business models definition and platform

design

Date of Delivery Contractual M12 Actual M12

Status version 0.11 final ■

Nature prototype □ report ■ demonstrator □ other □

Dissemination level public □ restricted ■

Authors (Partner)

Responsible Author Name Carlos Marcos E-mail [email protected]

Partner Atos Phone carlos.marcos.skype

Abstract

(for dissemination)

The present document contains the first version of the Architecture definition

for the future Daphne System according to the ISO/IEC/IEEE 42010 standard

Keywords “System Architecture”, “ISO/IEC/IEEE 42010 standard”

Version Log

Issue Date Rev. No. Author Change

27/05/2014 V0.1 Carlos Marcos (Atos) Table of Contents

07/07/2014 V0.2 Carlos Cavero (Atos) Added background about ISO42010

22/07/2014 V0.3 Carlos Marcos (Atos) Reshape according ISO42010

19/09/2014 V0.4 Miriam Quintero (Atos) Stakeholders first version

25/09/2014 V0.5 Carlos Marcos (Atos) Contributions on Stakeholders part

07/10/2014 V0.6 Carlos Cavero (Atos) Contributions about View and

Viewpoints

07/10/2014 V0.7 Carlos Marcos (Atos) Added some figures to sections 3 for

clarification

09/10/2014 V0.8 Carlos Marcos (Atos) General corrections and

contributions across the whole

document

10/10/2014 V0.9 Carlos Marcos (Atos) Version ready for review

23/10/2014 V0.10 Roni Ram (IBM) Review of the deliverable

29/10/2014 V0.11 Carlos Marcos (Atos) Final version


610440 of 28

Table of Contents

Executive summary ........................................................................................................................................... 3 Document Information ...................................................................................................................................... 4 Table of Contents .............................................................................................................................................. 5 List of figures .................................................................................................................................................... 7 Abbreviations .................................................................................................................................................... 8 1 Introduction ................................................................................................................................................ 9

1.1 Scope and expiration of the deliverable .............................................................................................. 9 1.2 Methods for describing a System Architecture ................................................................................... 9

1.2.1 ISO/IEC 42010:2011 ................................................................................................................... 9 1.2.2 TOGAF ........................................................................................................................................ 9 1.2.3 Discussion .................................................................................................................................... 9

1.3 Basics of ISO/IEC/IEEE 42010 ........................................................................................................ 10 2 Architecture Description Overview.......................................................................................................... 12 3 Stakeholders ............................................................................................................................................. 13

3.1.1 Patient ........................................................................................................................................ 13 3.1.2 Physician .................................................................................................................................... 15 3.1.3 Big Data User ............................................................................................................................ 15 3.1.4 IT Administrator ........................................................................................................................ 15 3.1.5 Law/Policy makers .................................................................................................................... 16 3.1.6 Daphne developers ..................................................................................................................... 16

3.2 System concerns ................................................................................................................................ 16 3.3 Environment ...................................................................................................................................... 17

4 Architecture view ..................................................................................................................................... 19 5 Architecture viewpoints ........................................................................................................................... 20

5.1 “Mobile User” viewpoint .................................................................................................................. 20 5.1.1 Overview .................................................................................................................................... 20 5.1.2 Concerns .................................................................................................................................... 20 5.1.3 Typical stakeholders .................................................................................................................. 20 5.1.4 Description ................................................................................................................................. 21

5.2 “Monitored Patient” viewpoint ......................................................................................................... 21 5.2.1 Overview .................................................................................................................................... 21 5.2.2 Concerns .................................................................................................................................... 21 5.2.3 Typical stakeholders .................................................................................................................. 21 5.2.4 Description ................................................................................................................................. 22

5.3 “Portal User” viewpoint .................................................................................................................... 22 5.3.1 Overview .................................................................................................................................... 22 5.3.2 Concerns .................................................................................................................................... 22 5.3.3 Typical stakeholders .................................................................................................................. 22 5.3.4 Description ................................................................................................................................. 23

5.4 “IT Administrator” viewpoint ........................................................................................................... 23 5.4.1 Overview .................................................................................................................................... 23 5.4.2 Concerns .................................................................................................................................... 23 5.4.3 Typical stakeholders .................................................................................................................. 23 5.4.4 Description ................................................................................................................................. 24

5.5 “Physician” viewpoint ....................................................................................................................... 24 5.5.1 Overview .................................................................................................................................... 24 5.5.2 Concerns .................................................................................................................................... 24 5.5.3 Typical stakeholders .................................................................................................................. 24 5.5.4 Description ................................................................................................................................. 25

5.6 “Big Data User” viewpoint ............................................................................................................... 25 5.6.1 Overview .................................................................................................................................... 25 5.6.2 Concerns .................................................................................................................................... 25 5.6.3 Typical stakeholders .................................................................................................................. 25 5.6.4 Description ................................................................................................................................. 26


610440 of 28

6 Conclusion ................................................................................................................................................ 27 References ....................................................................................................................................................... 28


610440 of 28

List of figures

Figure 1: IEEE 1471 and ISO 42010 ............................................................................................................... 10 Figure 2: Conceptual Realm on ISO 42010 ..................................................................................................... 10 Figure 3: Core Realm on ISO 42010 ............................................................................................................... 11 Figure 4: Functional Blocks Diagram ............................................................................................................. 12 Figure 5: Daphne stakeholders ........................................................................................................................ 13 Figure 6: Daphne categories of patient’s input data (taken from [3]) ............................................................. 14 Figure 7: Validations cycles of the system ...................................................................................................... 18 Figure 8: Mobile User Viewpoint .................................................................................................................... 21 Figure 9: Monitored Patient Viewpoint ........................................................................................................... 22 Figure 10: Portal User Viewpoint .................................................................................................................... 23 Figure 11: IT Administrator Viewpoint ........................................................................................................... 24 Figure 12: Physician Viewpoint ...................................................................................................................... 25 Figure 13: Big Data User Viewpoint ............................................................................................................... 26


610440 of 28

Abbreviations

AD: Architecture Description

DaaS: Data as a Service

EHR: Electronic Health Record

HL7: Health Level 7

ICT: Information and Communication Technologies

IEC: International Electrotechnical Commission

IEEE: Institute of Electrical and Electronics Engineers

ISO: International Organization for Standardisation

IT: Information Technologies

PHR: Personal Health Record

TOGAF: Open Group Architecture Network


610440 of 28

1 Introduction

It must be noted that the use of a standardized model like ISO 42010 for describing Architecture is not

enough for ensuring success of the project or even a good representation of Daphne system, but at least it

provides a common and representative metamodel for describing it.

The present deliverable will introduce the main Architecture Standards first, along with a description of the

most relevant items of the ISO/IEC42010. Next an overview of the Architecture already envisioned on

previous deliverable. Next the Stakeholders, Architecture View and Architecture Viewpoints for the concrete

case of the Daphne system will be presented on the following sections. At the end of the deliverable a

Conclusions part will resume the findings of the document.

1.1 Scope and expiration of the deliverable

This deliverable will focus on the high level description of the Daphne Architecture by introducing the

Standard ISO/IEC 42010:2011 and applying it to the main concepts on it found on previous deliverable [9].

This first approach will serve to check its further implementation for the entire full-described Architecture,

hence all contents on current deliverable will be probably superseded by next deliverable D2.7, where all

details of the components and the relationships among them will be provided.

1.2 Methods for describing a System Architecture

1.2.1 ISO/IEC 42010:2011

Heir from the former IEEE 1471:2000 1 Recommended Practice for Architectural Description of Software-

intensive Systems, the ISO 42010:2011 adds new refinements to it, widening the scope and making use of the

Architecture Frameworks and Architecture Description Languages.

The main goal of ISO/IEC 42010 standard is to describe [10] “the creation, analysis and sustainment of

architectures of systems through the use of architecture descriptions. A conceptual model of architecture

description is established”. It is then, an effort to set the requirements of the Architecture Descriptions, but

not to force one particular language or diagram to do so.

1.2.2 TOGAF

The Open Group Architecture Framework 2 (TOGAF) is a framework of Enterprise Architecture which

provides a guide for the design, schedule, implement and management of an Enterprise IT Architecture. The

“Open Group” behind this guide is a consortium of the most relevant worldwide actors in the field of IT

infrastructure, such as Capgemini, Fujitsu, Hitachi, HP, IBM, NASA and Atos.

1.2.3 Discussion

There can be as many methods for describing a System Architecture. Although ISO 42010 and TOGAF are

important contributions to the field, none has still raised as the de-facto standard for describing IT systems.

As in many others fields, it is easier to state what should not be done while describing architectures instead

of what should be done. There is certain consensus on the bibliography (see [13] for example) that for

complex systems like Daphne and assuming that there are enough resources, the Architecture descriptions

should not be done in a monolithic way, with a single mixture of formal and informal methods, just as it has

been done traditionally. Instead it is far more adequate to use a distributed approach, with different tools

describing each of the heterogeneous aspects of the system and the problem it is trying to solve. To enforce

this, the ISO 42010 provides topics like views and viewpoints thus giving the Architect the possibility of

looking at the system from different perspectives and so enriching the overall description of it.

1 http://www.iso-architecture.org/ieee-1471/cm/cm-1471-2000.html 2 http://www.opengroup.org/togaf/


610440 of 28

1.3 Basics of ISO/IEC/IEEE 42010

The ISO/IEC/IEEE 42010 (from now on, just ISO 42010 or “the Standard”) in its last version (2011) is an

evolution of the IEEE 1471, which was later adopted as international Standard by the ISO.

Figure 1: IEEE 1471 and ISO 42010

The ISO 42010 aims to provide a standardized way to describe a variety of System Architectures; thereof it

focuses on how these descriptions must be built by specifying the different elements that should be included

there. From the most conceptual point of view, one or more Architecture Descriptions or AD express the

Architecture of a due System (Daphne, in this case). Daphne system is affected by the environment where

it will be situated, that is, the influences it receives from external entities, including developmental,

technological, business, operational, organizational, political, economic, legal, regulatory, ecological and

social influences [6]. The Stakeholders of the system have certain interests in it, which can be materialized

on concrete System Concerns, some of whom can be driven by certain Purposes. To understand who each

of these entities are in the specific case of Daphne and how they interact will provide enough insights to start

the System Architecture definition on the following sections.

Figure 2 shows how these entities are related according to the Standard:

Figure 2: Conceptual Realm on ISO 42010

Architecture Descriptions or AD are the main concern of ISO 42010. These are the artifacts which express

the Architecture of a given System. For the case of current deliverable, this refers to the Daphne system and

sometimes also to the subsystems that will be connected to it in the future.


610440 of 28

To design the AD using the information extracted from the previous diagram, the standard proposes a set of

classes which annotate and complete the information around them. Each AD is supposed to express the

Architecture of some System of Interest, including requirements from the very beginning and its format is

completely open. Therefore, the exact nature of the AD is not fixed by the Standard: it can be a document, a

set of documents, written text, diagrams or any other form. By means of the AD, the Stakeholders of the

System are identified and their Concerns described in terms of View and Viewpoints. The Views are the

image of the Architecture that a Stakeholder has taking into account some specific Concerns, while the

Viewpoints are set of conventions for constructing, interpreting, using and analysing one type of

Architecture View. The Models Kinds are conventions for a type of modelling, as for example, class or data

flow diagrams and they leverage the Architecture Models by restricting the appropriate tools to be used

while defining each of the Architecture Views taking into accounts the Concerns. All these actors and their

relationships are summarized in Figure 3:

Figure 3: Core Realm on ISO 42010


610440 of 28

2 Architecture Description Overview

The starting point of the current deliverable will be the Functional Blocks Diagram depicted on the previous

deliverable D2.5 ([9]), which is shown in Figure 4.

Figure 4: Functional Blocks Diagram

For applying the standard in its most abstract form, some conventions will be followed in this deliverable:

the view and viewpoints depicted on the Standard will be identified with the actors views of the system,

which may not follow the stricter rules but it will accomplish the specific goal of describing Daphne from as

many different points of view as possible. The next deliverable D2.7 will be aimed at moving the

descriptions introduced on present deliverable to a more strict interpretation of the standard, making use, if

possible of other (more concrete) standards for Architecture like TOGAF.

Following the same idea, the description of the viewpoints will be made by using Sequence Diagrams so

focusing as much as possible on the concrete aspects of the project although in the process some of the

abstraction can be lost. A tradeoff between both concepts (abstraction and concretization) is necessary to

make the document useful for its use within the project and at the same time do not lose the essence of the

standard.


610440 of 28

3 Stakeholders

According to the Standard, Stakeholders are those individuals, teams, organizations or classes thereof,

having an interest in the system [6]. Such interests are coded into specific Concerns and are affected (and

affect themselves) the environment where the system is enclosed.

Figure 5: Daphne stakeholders

In the case of Daphne the following stakeholders have been identified:

3.1.1 Patient

This is the main object of health care and across the project it is a synonym of “user”. It is defined in

previous deliverables ([3]) as “the person upon which the data is based on”. For the case of Daphne

system, the target population will be of overweight/obese individuals ranging from early adolescents to

adulthood although the idea is to prepare the system so it can be extended to broader populations.

The patient interacts with the Daphne system in the following ways:

It provides data according to the five categories depicted in the User Profile Deliverables ([3] and

[4]):

PATIENT

IT ADMINISTRATOR PHYSICIAN

BIG DATA USER

DAPHNE DEVELOPERS

LAW/POLICY MAKERS


610440 of 28

Figure 6: Daphne categories of patient’s input data (taken from [3])

o Anthropometrics. This category includes date of birth, sex, weight and height and will

possible be introduced into the system during one of the daily patient’s visits to the

physician.

o Health Markers. This includes resting heart rate, which could be inserted by the sensors and

diastolic and systolic blood pressure, whether the patient is smoker, diabetic, is taking

antihypertensive treatment, HDL and cholesterol, which will probably be introduced into

Daphne during the patient’s regular visits to the physician.

o Psychological Wellbeing. This includes a variety of heterogeneous data coming from

questionnaires adapted to each type of patient. It will be inserted into the system by using the

patient’s portal.

o Physical Activity and Sedentary Behaviour. This includes processed data about the type of

activity the user is performing at each moment, which will be inserted automatically by the

sensors worn by him.

o Food Intake. This includes questionnaires, dietary assessment and food intake, presumably

inserted by using the patient’s portal and mobile GUI.

The patient also receives data from the system, in several ways:

o From the patient’s portal. This shows the patient views of his data, receives educational

material regarding healthy habits and reports about his behaviour.

o From the mobile app. The mobile app is the main interactive entity with the patient, as it will

show him a restricted view of his data, it will play a coaching role on monitoring his healthy

conduct and will show alerts and feedback related with several risk conditions.

Last but not the least, the patient is also a requirements provider mainly for the usability of both UIs

(portal and mobile app) and all their associate content (feedback, frequency of alerts, text of

coaching support, etc)


610440 of 28

3.1.2 Physician

The physician interacts with the system in several ways, mainly providing the medical background

and justification for the main features of Daphne use cases.

The physician also can check the patient’s data by means of the Physician Desktop Application

The physician can enter some data into the patients’ medical record. This data includes

anthropometric data (age, sex, weight and height), diastolic and systolic blood pressure and maybe

some other data like co-morbidities. Probably this data will be inserted during the visits of the patient

to the clinic.

The physician interacts with the patient helping him in defining the activity/nutrition plan

3.1.3 Big Data User

One of the main features of Daphne is the ability to provide sets of big data for different users that could be

interested for market or research reasons. According to [8], this can include insurance companies, dentists,

physiotherapists, nutritionists and universities performing big data research. An example of use is provided

on [2].

The main interactions between any of these Big Data Users and Daphne will be in the form of

massive downloads of data for processing. Deliverable 5.1 [11] shows a template of a possible Data

Costumer Portal which enables the user to access the system. Once logged in, different categories of

data are shown to the user and the user can select the most appropriate for his research/market study.

So far the relationship of Big Data Users and Daphne are only unidirectional, so no uploads are

allowed from the Big Data User side.

3.1.4 IT Administrator

Once it is put into production phase, a complex system like Daphne needs a constant supervision, which

must be done by IT experts, aware of the different parts of the system, how they interact and how to solve the

possible incidences that can rise during its execution. These are group under the generic role of IT

Administrator.

The IT Administrator must have the user/passwords to access the components and perform routine

checks on the components.

The only allowed manipulation of the IT Administrator should be at the lowest level for fixing

technical problems, as for example, surveillance of disk quotas or removal of logs files. In case of

error conditions across the project, the development team should be contacted to fix the concrete

bug.


610440 of 28

3.1.5 Law/Policy makers

The policy makers are in charge of setting the policies that must be followed on different areas. In the

concrete case of Daphne, the legal restrictions will come from both the EU directives and local laws. The

relationship of the Law/Policy makers with the project will materialize in two forms:

The project must take into account the existing laws regarding data protection and privacy applying

to the medical case. In this sense it requires from the project to be aware of such laws and know how

to apply them, and this is why specific tasks are devoted to it.

On second term, but also important, EU R&D projects like Daphne are encouraged to provide

feedback to policy makers regarding new cases on the concrete points of actuation that may not have

been taken into account in the current laws and so could be suitable to be included in future

amendments to them. This is usually done within the Dissemination tasks of such projects and these

reports are generally addressed to the Commission and not to specific Committees, which would be

indeed more convenient.

3.1.6 Daphne developers

The Daphne developers are the engine and the main supporters of the system. Their responsibilities [1]

generically include:

Gather the requirements for the Daphne system from patients, physicians, Big Data Users and

technical experts.

Develop the Daphne system ensuring interoperability across the entire platform.

Apply the appropriate security measurements.

Test and validate

For the specific work that each partner must perform the DoW ([1]) contains the scheduling at the level of

tasks.

3.2 System concerns

Each Concern of the system is held by one or many stakeholders (minimum one) and include the following:

functionality, feasibility, usage, system purposes, system features, system properties, known limitations,

structure, behavior, performance, resource utilization, reliability, security, information assurance,

complexity, evolvability, openness, concurrency, autonomy, cost, schedule, quality of service, flexibility,

agility, modifiability, modularity, control, inter-process communication, deadlock, state change, subsystem

integration, data accessibility, privacy, compliance to regulation, assurance, business goals and strategies,

customer experience, maintainability, affordability and disposability [10].

This document will not present all the system concerns exhaustively, as most of them will be disclosed

during further stages of the project. Instead it will show the most relevant (from the highest-level of

abstraction) for the current status of the project:


610440 of 28

1. Security. On systems dealing with sensible information, as medical data, the security must be a

priority. In Daphne, specific tasks will deal with the safety of this and other data by implementing

Privacy by Design and other Security principles according to the EU and local Laws. Such initiatives

will be aligned with the Care providers security strategies (see [6] and [7] for more information).

This concern is held by the patients, physicians and policy makers as main supporters and IT

administrator and Daphne developers as implementers.

2. Interoperability. One of the main goals of the project is to disclose anonymous data for a wide range

of different “Big Data” users. If the project wants to attract as many of these users as possible, the

data should be available making use of interoperability standards (see the Standarization Report

[12]) to ensure that the effort spent by the user to process that data is minimum. This concern affects

above all the Daphne developers and Big Data Users.

3. Business-oriented. This concern is held above all by the Industry partners of Daphne and Big Data

Users: As the market-driven strategy for the exploitation must affect the entire life-cycle of the

project, this has been included in the earlier deliverables ([5]).

4. Impact of the system beyond project life. One difference between Daphne and other EU projects is

that in Daphne there is a stronger focus on using it not only during the duration of the project itself,

but also after it has finished, as the platform will be widely available for research and market

purposes. The added value of the project comes partly from this extended life.

5. Scalability. The platform will be based on Standards not only for allowing different devices and

systems to plug easily into it (Interoperability), but also for enabling a seamless increment of the

system volume and data processing capabilities without affecting the functionality.

3.3 Environment

The environment of a system determines all the influences that such system receives during its entire life

cycle. According to the standard, this can include developmental, technological, business, operational,

organizational, political, economic, legal, regulatory, ecological and social influences. For the purpose of this

document, five main environments will be considered, each one of them covering different steps in the life-

cycle and maturity level of the components of the same Daphne base system (see Figure 7):


610440 of 28

Figure 7: Validations cycles of the system

1. Proposal environment. This phase is crucial for the good evolution of the project, as it is where the

requirements and scheduling are set. It covers both the proposal time and the tasks until the system is

finished and ready to be put into the pre-production or pre-pilot phase. During this phase, the

Daphne partners work shaping the future system according to the specifications given on the first

instance in the proposal document and later on the definitive DoW. The influences received by the

system come mainly from the high-level requirements that yield the proposal idea, including

healthcare, obesity prevention, interoperability, data-as-a-service and big data. The choice of Daphne

partners is a key step on this phase, as it will continue influence the system during its entire life-

cycle: Industry partners will heavily affect the market solutions and business models that will be

implemented, while Academic partners will strongly influence the areas which will be developed in

more extent.

2. Development environment. The system is really shaped in this stage, as the influences above all of

the developing partners help build it. Continuous evolution and the discovering of new requirements

may change the system beyond the scope initially set during the proposal, although a strong

guidance is necessary to stick to the main goals of the project.

3. Pre-pilot environment. Prior to the real deployment of the application and its use on real patients, a

short period of use with volunteers is envisioned, so it can serve as a test field for the entire system.

The volunteers will provide feedback on the usability of the tools (mainly the mobile app and

patient’s portal) and some bugs are expected to be raised, although no major changes in the

requirements are expected.

4. Pilot environment. During the real use of the system, Patients, Physicians and IT Administrators will

make use of the system.

5. Wide public environment. The final stage, when the project is published for the general public, the

Big Data services will be made available for the groups that may be interested in them.


610440 of 28

4 Architecture view

A view can be described on the Standard like the part of an Architecture Description that addresses a set of

related concerns held by certain stakeholders. For their use within this document, they will be mainly related

with the interfaces of the system with the different actors:

Mobile App view.

Sensor Device view.

Patient’s Portal view.

Administrator console view.

Physician Desktop Application view.

Data Consumer portal view.

In the Functional Blocks Diagram (Figure 4) the views correspond to the green areas and according to the

Standard will be described by specific viewpoints (see next section).


610440 of 28

5 Architecture viewpoints

The Architecture viewpoints frame particular concerns of the system stakeholders and consist of the

conventions of concepts, models, analysis techniques and visualizations for the construction, interpretation

and use of an Architecture view. If the view is what it is seen then the viewpoint is where it is being looked

from. According to the Standard, for each viewpoint the name, overview, concerns the viewpoint can be

applied to, and stakeholders addressed by it should be clearly specified.

5.1 “Mobile User” viewpoint

5.1.1 Overview

This viewpoint represents how the user sees the system from the perspective of the mobile application.

5.1.2 Concerns

This viewpoint applies to the Security and Business-oriented concerns described on previous sections,

although many others can also be included, like functionality, performance, cost, quality of service and

customer experience, for example.

5.1.3 Typical stakeholders

The archetypical stakeholder for this viewpoint is the patient. The Law/Policy makers are also influenced,

due to the restrictions regarding data use and distribution on an ever-changing environment as the mobile

app.


610440 of 28

5.1.4 Description

Figure 8: Mobile User Viewpoint

5.2 “Monitored Patient” viewpoint

5.2.1 Overview

This viewpoint corresponds to the case of a patient being monitored.

5.2.2 Concerns

The main concerns that apply on this case are Interoperability, Scalability, Security and also some others like

openness, concurrency, autonomy, cost, reliability or compliance to regulation.


The main stakeholder in this case is the Patient, although all the others (Physician, Big Data User and IT

Administrator) above are also affected.


610440 of 28

5.2.4 Description

Figure 9: Monitored Patient Viewpoint

5.3 “Portal User” viewpoint

5.3.1 Overview

This viewpoint represents how the patient access to the system by means of the patient’s portal.

5.3.2 Concerns

Similar to the mobile user, this viewpoint applies to the Security and Business-oriented concerns as well as

others like usage, performance, resource utilization, reliability, cost, quality of service for example.


The main stakeholder is the Patient.


610440 of 28

5.3.4 Description

Figure 10: Portal User Viewpoint

5.4 “IT Administrator” viewpoint

5.4.1 Overview

This viewpoint represents the access to the system by the IT administrators.

5.4.2 Concerns

The main concerns are Security and Impact of the system beyond the project lifetime and also control,

performance, maintainability, system properties and inter-process communication among others.


The main stakeholder is the IT Administrator.


610440 of 28

5.4.4 Description

Figure 11: IT Administrator Viewpoint

5.5 “Physician” viewpoint

5.5.1 Overview

This viewpoint represents the access to the system by a Physician using the Desktop Application.

5.5.2 Concerns

This viewpoint applies mainly to the concerns of Security, Interoperability and Business-oriented and also to

data accessibility, compliance to regulation, usage, feasibility and functionality among others.


The main stakeholder is the Physician, although this viewpoint affects also the Patient and IT Administrator

stakeholders.


610440 of 28

5.5.4 Description

Figure 12: Physician Viewpoint

5.6 “Big Data User” viewpoint

5.6.1 Overview

This viewpoint represents how a Big Data User would see the system.

5.6.2 Concerns

The main concerns affected by this viewpoint are Interoperability, Security, Business-oriented, impact of the

system beyond project life and Scalability and also inter-process communication, known limitations, usage,

functionality, maintainability, compliance to regulation, business goals and strategies and disposability.


The main stakeholder is the Big Data User, although it affects all the others.


610440 of 28

5.6.4 Description

Figure 13: Big Data User Viewpoint


610440 of 28

6 Conclusion

The present document has introduced the Standard ISO 42010 for representing a System Architecture and

has mapped some of the concepts in Daphne to the concepts of the Standard. However, more detailed

descriptions are needed for all the components of the project, above all related with interoperability and the

relationships among them. As the standard does not specify clearly the granularity of the specifications that

should be done, they are subject to the interpretation of the Architect, thus resulting in a wide range of

possible descriptions for the same problem. For the current document, a more user-centric approach has been

chosen.

The next deliverable will focus on addressing these details as well as providing more insights about the

subsystems inside each one of the concepts.


610440 of 28

References

[1] Daphne Document of Work (2013). All Daphne partners.

[2] D1.1 Scenario definition report (2014). Catherine Gibbons, Graham Finlayson, John Blundell and all

Daphne partners. Daphne

[3] D1.3 User Profile (2014). Catherine Gibbons, Edith Dekel, Hadas Lewy, Gonzalo Bailador, Melania

Manco, Roni Ram, Alex Melament, Alberto Olmo. Daphne

[4] D1.4 Final User Profile (2014). Catherine Gibbons, Edith Dekel, Hadas Lewy, Gonzalo Bailador,

Melania Manco, Roni Ram, Alex Melament, Alberto Olmo. Daphne

[5] D2.1 State of the art of Business Models related with Healthcare Market (2014). Carlos Marcos,

Rosana Valle, Belén Gallego. Daphne

[6] D2.2 Privacy & Security Legal Issues Report (2014). Ross Little. Daphne

[7] D2.3 Privacy and Security Analysis (2014). Ross Little (ATOS), David O'Callaghan, Edith Dekel.

Daphne

[8] D2.4 Set of requirements of the future Daphne platform (2014). Carlos Marcos, Carlos Cavero,

Miriam Quintero, Susan van Wissen, Gonzalo Bailador. Daphne

[9] D2.5 Conceptual framework of the Project (2014). Carlos Marcos, Alex Melament, Roni Ram, Jose

Antonio Sánchez, Gonzalo Bailador, Susan van Wissen, Edith Dekel, Dana Kupinsky. Daphne

[10] INTERNATIONAL STANDARD ISO/IEC/IEEE 42010 Systems and software engineering —

Architecture description (2011). ISO/IEC/IEEE.

[11] D5.1 Market places and Cloud Services Analysis (ongoing). Tatiana Silva, Alberto Olmo, Carlos

Marcos, Roni Ram. Daphne

[12] D8.2 Standarization Report (ongoing). Roni Ram, Alex Melament, Carlos Marcos, Gonzalo Bailador,

Susan van Wissen. Daphne

[13] Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Nick

Rozanski, Eoin Woods. 2012

d2.6 daphne system architecture first designdaphne-fp7.eu/sites/default/files/d2.6 daphne system...

Documents