Difference between revisions of "Mobile eHealth MeH (PESOS 2012)"

From Scube-casestudies
Jump to: navigation, search
(→‎Scenarios)
 
(13 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
This page describes the artifacts of the Mobile eHealth case study.
  
−
==Business Goals and Domain Assumptions==
+
== Description ==
  
−
In this page we briefly describe a case study,
+
[[File:process.png]]
−
i.e. the Mobile eHealth (MeH), developed in the context of the
 
−
IST PLASTIC project aimed at supporting self-adapting and
 
−
context-aware services. The goal of the case study is to show
 
−
how to model a service-based application and to demonstrate
 
−
that model-based solutions are suitable to generate Quality of
 
−
Service (QoS) models and adaptable code from service models.
 
  
 +
Figure 1 shows the PLASTIC Development Process and the related artifacts.
  
−
In the following sections will be reported the Business Goals and the  
+
The '''MeH UML Model''' has been created using the MagicDraw UML modeling tool that can be downloaded here [www.magicdraw.com/]. MagicDraw UML can be seamlessly integrated with the Eclipse Modeling Project [http://www.eclipse.org/modeling/]. For this reason, the MeH UML Model can be opened both in MagicDraw and in any Eclipse UML compliant plugin of the Eclipse platform.
−
Domain Assumptions for the current case study.
 
  
−
=== Business Goals ===
+
The '''MeHQnmodel.jsimg''' is a queuing Network model that has been created using the Java Modeling Tool [http://jmt.sourceforge.net/]. The QN model has beed derived from the MeH UML Model following the PRIMAUML model-based performance methodology [http://dl.acm.org/citation.cfm?id=607042]. The '''MeHQnmodel.jsimg''' can be opened in JMT and it can be executed to derive the performance indeces of interest.
 +
It's worth noting that the transformation from UML2JMT has not been implemented. However a similar UML2PMIF transformation has been implemented in MOSQUITO starting from PLASTIC UML Model (see [http://sealabtools.di.univaq.it/tools.php]).
  
−
{| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
+
'''UML2wsdl'''_1.0.0. jar is an archive containing a model transformation from a PLASTIC Service UML Model to WSDL. It has been implemented in ATL. For additional information see the User Guide that can be downloaded from the Download Section.
−
|+ Table BG1. Business Goal EH-BG-01
 
−
!Field !! Description
 
  
−
|- style="background:#f0f0f0; color:black"
+
The RD Adaptable Midlet is a code artifact that uses an extended Java grammar as proposed by the CHAMELEON Framework.
−
! UniqueID
+
It's worth noting that the case study proposes a possible implementation of the MeH MIDlets while a running example of the MeH System was implemented by Telefonica [http://www.ist-plastic.org/] and it is not available here. However an excerpt of the adaptable JAVA code for the MeH case study is shown in the paper published at PESOS 2012 [http://www.s-cube-network.eu/pesos-2012].
−
||EH-BG-01
 
  
−
|- style="background:white; color:black"
 
−
! Short Name
 
−
| Patient Data Retrìeval (PDR)
 
  
−
|- style="background:white; color:black"
 
−
! Type
 
−
| Business Goals.
 
  
−
|- style="background:white; color:black"
+
== Basic technology ==
−
! Description
 
−
| By invoking the PDR service, the doctors retrieve mixed media information of their patients that combines text with or without different kinds of images referring to their personal data, their medical histories and patient-related diseases. The results can be displayed on the doctors’ handheld device. A more detailed description of this service is provided in [http://www.sti.uniurb.it/paco/Products/fase_2010b.pdf].
 
  
−
|- style="background:white; color:black"
+
WSDL, UML, Java, Queuing Network
−
! Rationale
 
−
| Provide the service that is tailored to a certain execution context.
 
  
−
|- style="background:white; color:black"
+
== How to install ==
−
! Involved Stakeholders
 
−
| Doctors, Patients, MeH System
 
  
−
|- style="background:white; color:black"
+
All the artifacts and detailed procedures to install tools and case studies are provided here [http://code.google.com/a/eclipselabs.org/p/mobile-ehealth-case-study/]
−
! Conflicts
 
−
| None
 
  
−
|- style="background:white; color:black"
+
== Download ==
−
! Supporting Materials
 
−
| [http://code.google.com/a/eclipselabs.org/p/mobile-ehealth-case-study/]
 
  
−
|- style="background:white; color:black"
+
[http://code.google.com/a/eclipselabs.org/p/mobile-ehealth-case-study/] Mobile eHealth Case Study. The archive.
−
! Priority of accomplishment
 
−
| Must have.
 
−
|}
 
  
  
−
{| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
+
== Additional info ==
−
|+ Table BG2. Business Goal EH-BG-02
 
−
!Field !! Description
 
  
−
|- style="background:#f0f0f0; color:black"
+
[http://dl.acm.org/citation.cfm?id=607042] Vittorio Cortellessa, Raffaela Mirandola: PRIMA-UML: a performance validation incremental methodology on early UML diagrams. Sci. Comput. Program. 44(1): 101-129 (2002)
−
! UniqueID
 
−
||EH-BG-02
 
  
−
|- style="background:white; color:black"
+
[http://www.di.univaq.it/chameleon/publications.php] The CHAMELEON Framework
−
! Short Name
 
−
| Remote Diagnosis
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Type
 
−
| Business Goals.
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Description
 
−
| By invoking the RD service, the patients update some vital parameters (e.g. heart rate) thus to provide the knowledge aimed at monitoring their health. On the basis of such data an alarm is sent in case of warning conditions that can be forwarded to his/her relatives, rural doctors and social workers. A more detailed description of this service is provided in [http://plastic.paris-rocquencourt.inria.fr/test-1/uda_icsoc2007.pdf].
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Rationale
 
−
| Improve the effectiveness and reliability of healthcare activities. Reduce costs of healthcare activities.
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Involved Stakeholders
 
−
| Doctors, Patients
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Conflicts
 
−
| None
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Supporting Material
 
−
| [http://code.google.com/a/eclipselabs.org/p/mobile-ehealth-case-study/]
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Priority of accomplishment
 
−
| Must have.
 
−
|}
 
−
 
 
−
=== Domain Assumptions ===
 
−
 
 
−
{| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
 
−
|+ Table DA1. Assumption EH-DA-01
 
−
!Field !! Description
 
−
 
 
−
|- style="background:#f0f0f0; color:black"
 
−
! UniqueID
 
−
| |EH-DA-01
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Short Name
 
−
| Context/Resource Awareness
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Type
 
−
| Domain assumption
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Description
 
−
| The MeH system shall be a context-aware and adaptable service. Context is a set of heterogeneous information that can be sensed by and influence the system behavior. At design time, it results in artifacts (i.e., models) where structural and behavioral descriptions of the MeH System can be combined with a context model. At run time, it corresponds to the availability of an appropriate middleware that is capable to monitor the execution context and to adapt the system behavior accordingly.
 
−
 
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Rationale
 
−
| Provide the best QoS in an ubiquitous environment despite a continuosly evolving execution context.
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Involved Stakeholders
 
−
| Doctors, Patients
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Conflicts
 
−
| None
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Supporting Material
 
−
| [http://code.google.com/a/eclipselabs.org/p/mobile-ehealth-case-study/]
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Priority of accomplishment
 
−
| Must have.
 
−
|}
 
−
 
 
−
 
 
−
== Domain Analysis ==
 
−
 
 
−
=== Strategic Dependency Model and Context Diagram ===
 
−
 
 
−
The SDD figure illustrates the strategic dependency diagram of the case study. The diagram puts in evidence
 
−
the business goals shared among the related actors. For example, in the diagram we can note that the
 
−
Doctor makes a remote diagnosis for the Patient. He/She can also retrieve multimedia data (text and images) about the assisted patients by accessing databases from the MeH System.
 
−
 
 
−
[[File:sdd_meh.png]]
 
−
 
 
−
 
 
−
The following figure illustrates the context diagram of the current case study. In the context diagram, all the actors that appear in the business goals and scenarios are agents.
 
−
 
 
−
[[File:contextdiagram_meh.png]]
 
−
 
 
−
=== Domain Model===
 
−
 
 
−
The figure below illustrates the domain model of the current case study. The model is represented using a UML notation. In particular the model shows the entities of the scenario, the actors and the relationship among them.
 
−
 
 
−
 
 
−
[[File:Use Case Service Diagram1.png]]
 
−
 
 
−
== Scenarios==
 
−
 
 
−
In this section the Business Goals, namely Remote Diagnosis and Patient Data Retrieval, are further detailed using UML Sequence Diagrams
 
−
 
 
−
 
 
−
{| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
 
−
|+ Table S1: Scenario EH-S-01
 
−
!Field !! Description
 
−
 
 
−
|- style="background:#f0f0f0; color:black"
 
−
! UniqueID
 
−
| |EH-S-01
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Short Name
 
−
| Remote Diagnosis
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Related To
 
−
| EHEALTH-BG-01
 
−
 
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Involved Actors
 
−
| Doctor, Patient, MeH System
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Detailed Operational Description
 
−
| [[File:RemoteDiagnosis.png]]
 
−
The behavioral description of the Remote Diagnosis service is illustrated in the above figure. A  multi-radio  networking  service provided by a context-aware middleware (MRNAPI  instances  mrn-patient and  mrn-doc), choose the best networks available (MRNAPI::activateBestNetworks()) before establishing  either  a  multicast  or  a  point-to-point  communication  among  patients’ and doctors’ devices. In particular, the former communication protocol is used to send alarms from patients to any of their supervising doctors. In order to execute the sendAlarm() operation a networks with low bitrate and power consumptions is required. Indeed, the alarm message is usually very small (few bytes) and sent from a safety critical and possibly battery-powered device (e.g., a panic button). In this case a GPRS network satisfies the requirements as modeled by the QoSProfile01. On the doctor’s side, when the alarm is
 
−
received,  the  visualcheck() service  available  on  the  patient’s  side  is  invoked.
 
−
 
 
−
A point-to-point communication needs to be established from the doctor to the patient: the adopted middleware is in charge of selecting the best network  available  according  to  certain quality profile.  For example, a quality profile may require a free network with very high bitrate to transmit a video stream from the patient’s side. In this case the context-aware middleware (named ubiSOAP) ignores GPRS and switches to a WiFi network.
 
−
 
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Problems and Challenges
 
−
|
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Additional Material
 
−
| [http://code.google.com/a/eclipselabs.org/p/mobile-ehealth-case-study/ ]
 
−
[http://gforge.inria.fr/frs/?group_id=699 PLASTIC Middleware (download)]
 
−
|}
 
−
 
 
−
{| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
 
−
|+ Table S1: Scenario EH-S-02
 
−
!Field !! Description
 
−
 
 
−
|- style="background:#f0f0f0; color:black"
 
−
! UniqueID
 
−
| |EH-S-02
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Short Name
 
−
| Remote Diagnosis
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Related To
 
−
| EHEALTH-BG-02
 
−
 
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Involved Actors
 
−
| Doctor, Patient, MeH System
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Detailed Operational Description
 
−
| [[File:Pdr.png]]
 
−
The behavioral description of the Remote Diagnosis service is illustrated in the above figure. A  multi-radio  networking  service provided by a context-aware middleware (MRNAPI  instances  mrn-patient and  mrn-doc), choose the best networks available (MRNAPI::activateBestNetworks()) before establishing  either  a  multicast  or  a  point-to-point  communication  among  patients’ and doctors’ devices. In particular, the former communication protocol is used to send alarms from patients to any of their supervising doctors. In order to execute the sendAlarm() operation a networks with low bitrate and power consumptions is required. Indeed, the alarm message is usually very small (few bytes) and sent from a safety critical and possibly battery-powered device (e.g., a panic button). In this case a GPRS network satisfies the requirements as modeled by the QoSProfile01. On the doctor’s side, when the alarm is
 
−
received,  the  visualcheck() service  available  on  the  patient’s  side  is  invoked.
 
−
 
 
−
A point-to-point communication needs to be established from the doctor to the patient: the adopted middleware is in charge of selecting the best network  available  according  to  certain quality profile.  For example, a quality profile may require a free network with very high bitrate to transmit a video stream from the patient’s side. In this case the context-aware middleware (named ubiSOAP) ignores GPRS and switches to a WiFi network.
 
−
 
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Problems and Challenges
 
−
|
 
−
 
 
−
|- style="background:white; color:black"
 
−
! Additional Material
 
−
| [http://code.google.com/a/eclipselabs.org/p/mobile-ehealth-case-study/ ]
 
−
[http://gforge.inria.fr/frs/?group_id=699 PLASTIC Middleware (download)]
 
−
|}
 

Latest revision as of 12:25, 31 May 2012

This page describes the artifacts of the Mobile eHealth case study.

Description

Process.png

Figure 1 shows the PLASTIC Development Process and the related artifacts.

The MeH UML Model has been created using the MagicDraw UML modeling tool that can be downloaded here [www.magicdraw.com/]. MagicDraw UML can be seamlessly integrated with the Eclipse Modeling Project [1]. For this reason, the MeH UML Model can be opened both in MagicDraw and in any Eclipse UML compliant plugin of the Eclipse platform.

The MeHQnmodel.jsimg is a queuing Network model that has been created using the Java Modeling Tool [2]. The QN model has beed derived from the MeH UML Model following the PRIMAUML model-based performance methodology [3]. The MeHQnmodel.jsimg can be opened in JMT and it can be executed to derive the performance indeces of interest. It's worth noting that the transformation from UML2JMT has not been implemented. However a similar UML2PMIF transformation has been implemented in MOSQUITO starting from PLASTIC UML Model (see [4]).

UML2wsdl_1.0.0. jar is an archive containing a model transformation from a PLASTIC Service UML Model to WSDL. It has been implemented in ATL. For additional information see the User Guide that can be downloaded from the Download Section.

The RD Adaptable Midlet is a code artifact that uses an extended Java grammar as proposed by the CHAMELEON Framework. It's worth noting that the case study proposes a possible implementation of the MeH MIDlets while a running example of the MeH System was implemented by Telefonica [5] and it is not available here. However an excerpt of the adaptable JAVA code for the MeH case study is shown in the paper published at PESOS 2012 [6].


Basic technology

WSDL, UML, Java, Queuing Network

How to install

All the artifacts and detailed procedures to install tools and case studies are provided here [7]

Download

[8] Mobile eHealth Case Study. The archive.


Additional info

[9] Vittorio Cortellessa, Raffaela Mirandola: PRIMA-UML: a performance validation incremental methodology on early UML diagrams. Sci. Comput. Program. 44(1): 101-129 (2002)

[10] The CHAMELEON Framework

Retrieved from "https://scube-casestudies.deib.polimi.it/index.php?title=Mobile_eHealth_MeH_(PESOS_2012)&oldid=134999"