Luca Berardinelli [email protected] Dep. of Computer Science University of L’Aquila (ITALY) Vittorio Cortellessa [email protected]

Luca Berardinelli [email protected]. of Computer ScienceUniversity of L’Aquila (ITALY)

Vittorio [email protected]. of Computer ScienceUniversity of L’Aquila (ITALY)

Antinisca Di [email protected]. of Computer ScienceUniversity of L’Aquila (ITALY)

PACO Meeting(Camerino)

EXTRA-FUNCTIONAL MODELING & ANALYSIS

OF CONTEXT-AWARE MOBILE SOFTWARE SYSTEMS

mailto:[email protected]



MOTIVATION

• Pervasiveness of software systems running on resource constrained, portable devices

• Providing the best QoS (intended as a combination of non-functional properties) despite– limited and variable amount/types of hw resources

– physical mobility of nomadic users

– logical mobility of software components

• Need to analyze context-aware software systems from a extra-functional viewpoint

21/04/23 2Non-Functional Modeling and Analysis of Mobile Context-Aware Sw Systems

• Introduction: Context, Mobility and Context-Awareness

• Our framework:– Awareness Managers,

– Adaptation driven by “if context is” conditions,

– Context Manager

– Non-Functional Analyses: Performance, Reliability…

– Tool support: MOSQUITO and COBRA

• Conclusions and Future Work

21/04/23 3

OUTLINE

Non-Functional Modeling and Analysis of Mobile Context-Aware Sw Systems

Context…

for us is a combination of information about

PHYSICAL LOCATION of system users (i.e. real world places such as our home)

LOGICAL LOCATION of software components (i.e. the current deployment of sw components on execution hosts)

HARDWARE PLATFORM CONFIGURATION of resources (i.e. BATTERY charge level, CPU frequency…)

21/04/23 4

INTRODUCTION: CONTEXT & MOBILITY

may rapidly change:

PHYSICAL MOBILITY : the users move with their portable devices across physical locations

LOGICAL MOBILITY : software components are redeployed on different execution hosts

HARDWARE CONFIGURATION CHANGE: BATTERY charge level decreases


INTRODUCTION: CONTEXT AWARENESS

Context Awareness: property of software to sense knowledge related to the context

PHYSICAL LOCATION AWARENESS: capability to “sense” the current Physical Location

LOGICAL LOCATION AWARENESS: capability to “sense” the current Logical Location

HARDWARE PLATFORM AWARENESS: capability to “sense” the current Hardware Platform Configuration

04/21/23 5

This is a context definition that fits our purposes• It CAN BE EXTENDED by adding other context dimensions• It CAN BE RESTRICTED for those cases where only few context attributes are necessary (e.g. logical mobility not allowed)

Without modifying the framework structureNon-Functional Modeling and Analysis of Mobile Context-Aware Sw Systems

• UML-based Modeling of (i) Users and Services

(ii) Software Architecture,

(iii) Behaviors,

(iv) Hardware Platform

(v) Extra-functional parameters

21/04/23 6

THE FRAMEWORK

Context, a cross cutting concern

Adaptable

Mobile

Configurable

Mobile

Context-specific


A LEADING EXAMPLE: E-HEALTH SYSTEM

The eHealth System supports the doctor’s everyday activities providing distributed services, such as the retrieval of information about patients.

The doctor invokes the service using a resource-constrained PDA.

He can move across different locations: his home, the surgery, the patient’s home.

The system performance can be affected by the doctor’s physical location and by the hardware configuration of the doctor’s PDA.

04/21/23 7

The system performance is affected by the context


E-HEALTH: UML DESIGN MODEL AT A GLANCESoftware Architecture (Component Diagram)

Hardware Platform (Deployment Diagram)

Service Behavior (Sequence Diagram)

Services (Use Case Diagram)

Static <<deployment>>

The doctor can display the medical

history of a patients (text and images)

hw configurations


DESIGN MODEL

THE FRAMEWORK: CONTEXT MODELING

The proposed framework introduces statecharts to manage the context evolution

Awareness MANAGER:Is associated to a model element that is “context-related”

Is a stochastic statechart where

A state represents the (set of) attribute(s) value(s) of the context-related model element

Transitions represent the events triggering changes in attribute values

Probabilities are associated to transitions

Is able to interact with other managers through remote firing

Defines a Variable that indicates its current state (e.g. $manager = ‘A’ , $manager = ‘B’)

04/21/23 9

MANAGER

A Bp

1-p


E-HEALTH: CONTEXT MODELING

Component Diagram Services (Use Case Diagram)Client :: LOGICAL

MOBILITYDoctor :: PHYSICAL MOBILITY

Deployment Diagram

Dynamic

BATTERY :: HW CONFIGURATION

CPU:: HW CONFIGBinding between hardware resources

and physical placesBinding between software resources

and hardware platform

10

homesurgery

remote firing

Hw platform

Physical Places

Non-Functional Modeling and Analysis of Mobile Context-Aware Sw Systems04/21/23

DESIGN MODEL

THE FRAMEWORK : BEHAVIOR ADAPTATIONAdaptation:

capability to change software behavior w.r.t. changes in the sensed context.

We enable adaptation by allowing the system to choose among different implementations j of the same service i

04/21/23 11

Given the context description, how to represent “if context is” conditions?

Si,1 Si,j Si,m

“If context is” condition“If context is” condition “If context is” condition“If context is” condition “If context is” condition“If context is” condition

Service i

Start (i.e. service i invocation)


E-HEALTH: BEHAVIOR ADAPTATION (1)

Behavior Choice for each Service

Start RequestPatientInfoPage

IMG NO IMG

cond

cond

“If context is” condition

DISPLAY::$HwConfig==‘Color‘ AND DOCTOR::$PhyLoc==‘Surgery’

“If context is” condition

We specify “if context is” conditions using manager variablesin logical predicates to relate alternative behavior descriptions

to the modeled context

04/21/23 12

DISPLAY::$HwConfig==‘B/W‘ AND DOCTOR::$PhyLoc==‘OpenAir’


DESIGN MODEL

E-HEALTH: CONTEXT-SPECIFIC ANNOTATIONS

Behavior Choice for each Service (Interaction

Overview Diagram)


IMG NO IMG

Standard BehaviorThe doctor can download

images related to patient medical histories

04/21/23 13

<<GaAcqStep>>{acqRes = Instr, Msg, DbAxresUnit=“(5,2,2)”}


<<GaWorkloadEvent>>{pattern=closed,population=200, extDelay=(0.5, sec)}

MARTE Profile

- estimated software resource demand for each message

- workload specification


DESIGN MODEL

E-HEALTH: CONTEXT-SPECIFIC ANNOTATIONS

Behavior Choice for each Service (Interaction

Overview Diagram)


IMG NO IMG

Resource ConstrainedBehavior

The doctor doesn’t dowload images

THENThere is a different

resource usage



<<GaWorkloadEvent>>{pattern=closed,population=200, extDelay=(0.5, sec)}


DESIGN MODEL

THE FRAMEWORK: THE CONTEXT MANAGEROur framework introduces CONTEXT MANAGER as a combination of Awareness

MANAGERs to model the whole context evolution:

is not mandatory! It is necessary only if we are interested in combining different context dimensions

is associated to the whole system (model)

is a stochastic statechart where

04/21/23 15

(super) Transitions model the events triggering context changes in one or more (thanks to remote firing mechanism) awareness managers

Probabilities of context changes are associated to transitions and are synthesized from probabilities in awareness managers

LOG

PHY HW

services

p

1-p

LOG

PHY HW’

services

A (super) State models the combination of awareness manager states


THE FRAMEWORK: THE CONTEXT MANAGER

04/21/23 1616

Design Model

Context Manager(PHY-HW)

<Dimension> Managers

…LOGPHY HW ?

?


Context Manager(HW-?)

Service Behavioral Specs

S1S2

S3


S2S1

UCD, CD, DDs

IOD, SDs


* * *

1..* 1..* 1..*

CONTEXT MANAGER

E-HEALTH: THE CONTEXT MANAGER

DISPLAY :: HW CONFIGDoctor :: PHYSICAL MOBILITY

Each superState represents a context for service provisionSR = @Surgery the Resource Constrained service implementation is invoked, i.e. NO IMAGES

04/21/23 17

truetruefalsefalse



DOCTOR::PHYSICAL MOBILITYHOME OPEN AIR SURGERY PATIENT

HOME 0.1 0.9 - -OPEN AIR 0.1 0.1 0.7 0.1SURGERY - 0.1 0.9 -PATIENT - 0.9 - 0.1

DOCTOR::PHYSICAL MOBILITYHOME OPEN AIR SURGERY PATIENT

HOME 0.5 0.5 - -OPEN AIR 0.25 0.25 0.25 0.25SURGERY - 0.5 0.5 -PATIENT - 0.5 - 0.5

DISPLAY::HW CONFIGURATION

COLOR B/W

COLOR 0.5 0.5B/W 0.5 0.5

Basic High Mobility

GOALExtra-Functional Analysis: Response Time in 2 different scenarios:

i) Basic Scenario, ii) High Physical Mobility Scenario

04/21/23 18

The Scenarios differ for transition probabilities of Physical Mobility Manager




Context Manager(PHY-HW)

PHY HW


S1S2

S3

UCD, CD, DDs


1..* 1..*

PHY

Basic High Mobility

S1S2

S3

IOD, SDs


CONTEXT MANAGER (Steady State Prob)HS OS SS PS HR OR SR PR

0.0067 0.0608 0.4250 0.0067 0.0067 0.0608 0.4250 0.0067

CONTEXT MANAGER (Steady State Prob)HS OS SS PS HR OR SR PR

0.1 0.2 0.1 0.1 0.1 0.2 0.1 0.1

@SURGERY = 0.85@OPEN AIR= 0.1216

@OPEN AIR = 0.4@every other place = 0.2

Basic High Mobility

04/21/23 20

For each superstate we generate and solve a different Analysis Model and weigh the resulting indices with the steady state probabilities

Basic and High Mobility scenarios induce the same superstates and supertransitions but different transition probabilities that lead to different steady state probabilties


CONTEXT MANAGER CONTEXT MANAGER

THE FRAMEWORK: MODEL-DRIVEN ANALYSIS


performance analysis

Queuing Networks

Execution Graphs

Reliability AnalysisAvailability Analysis

Petri Nets

…

Fault Tree

LOG

PHY HW’

services

Steady StateProbability

m2m transformation

THE FRAMEWORK: PERFORMANCE ANALYSIS

SW resource demands

UML Model

+MARTE

sw2hw conversion factorssw2hw conversion factors

= Context–specific performance indices (e.g. Response Time)

Service Time of hw resources (e.g. CPU,DISK)

21/04/23 22

LOG

PHY HW’

services


Execution Graphs (no resource contention)

SDs ▶DD ▶

x

=HW resource demands

x

<<nfp>>ServiceTime : NFP_DataTxRate =1bit/μs


E-HEALTH: PERFORMANCE ANALYSIS

04/21/23 23

CONTEXT MANAGER

MAX Response Time82.07 sec

MAX Response Time82.07 sec

MIN Response Time1.17 sec

MIN Response Time1.17 sec

Average:Basic : 14.59 sec

High Mobility: 26.32 sec

Lower Average Response Time in Basic Scenario due to different Doctor’s Physical Mobility: more time spent @Surgery with faster internet connection


E-HEALTH: RELIABILITY ANALYSIS


• RELIABILITY : The probability of a system working within specs throughout an interval of time without system-level repair.

• RELIABILITY ON DEMAND : The probability of a system working within specs for a certain number of invocation without system-level repair.

THE FRAMEWORK: RELIABILITY ANALYSIS

UML Model

+MARTE

21/04/23 25

LOG

PHY HW’

services


UCD ▶CD ▶SDs ▶DD ▶


• Sk = service k•i = failure prob of component i •bpi= busy periods (i.e. activation) of component i •(i,j) = failure prob of connector among connectors i and j •int(i,j) = interactions (# of exchanged messages) between components i and j

Components Reliability in context

Connectors <i,j>Reliability in context

DD ▶

UCD ▶

CD ▶

SDs ▶



+ COMPONENT FAILURE PROBABILITY (DAM profile)+ IDENTIFICATION OF LOGICALLY MOBILE COMPONENTS (Context Profile)



DESIGN MODEL

CURRENT/ALLOWED locations CURRENT/ALLOWED locations

CURRENT/ALLOWED deployments CURRENT/ALLOWED deployments

ARTIFACT LEVELARTIFACT LEVEL

EXEC HOST LEVEL

EXEC HOST LEVEL

PHYS LOCATION LEVEL

PHYS LOCATION LEVEL

NET TYPE AVAIL

NET TYPE NOT AVAIL



Service Context Reliability

RequestPatientInfoPage

OpenAir/Color Display (OS, standard behav)

0.9386

RequestPatientInfoPage

OpenAir/BW Display (OR, reduced behav)

0.9557The Reliability increases reducing the number of involved components and their interaction.

CONTEXT MANAGERService Behavioral Specifications (SDs)

Web sErvice for Analyzing queueing networkS with multiplE soLvers

TOOL SUPPORT: PERFORMANCE ANALYSIS

PMIF Editor (WEASEL client)

MOSQUITO Server

WEASEL Server

@UnivAQ

@UnivAQ

MagicDraw® UML MOSQUITO client

ECLIPSE Platform

.uml

.spmif

.pmif

.pmif’

pmif

.uml

.*

.txt

Internet$pop

Response Time

6 0.748034489

7 0.789521871

8 0.832765210

9 0.879266880

10 0.930278346

MOdel driven conStruction of QUeuIng neTwOrks


http://sealabtools.di.univaq.it/SeaLab/MosquitoHome.html

TOOL SUPPORT: RELIABILITY ANALYSIS

COBRA Server

@UnivAQ

@UnivAQ

MagicDraw® UML COBRA client

ECLIPSE Platform

.uml

.xml.uml

Internet

RELIABILITY ON DEMAND : Probability of a system working within specs throughout for a certain number of invocations without system-level repair

COmponent-Based Reliability Analysis


Probability of System Failure (Reliability on Demand)

CONCLUSIONS AND FUTURE WORK

• We introduced a framework for modeling and analyzing performance of context-aware mobile systems

• Context-awareness is a composite/cross-cutting concern:– context dimensions can be added/removed/ignored using stochastic

statecharts and “if context is” conditions

• UML-based realization: extensible with (standard) profiles to other UML-based model-driven NFPs analyses

• [Future]: we are working on complex composition of managers

• [Future]: Modeling Adaptation@runtime where context state changes during service execution.


REFERENCES• L. Berardinelli, V. Cortellessa, and Antinisca Di Marco,

" An Unified Approach to Model Non-Functional Properties of Mobile Context-Aware Software ", Proc. of the 2nd International Workshop on Non-functional System Properties in Domain Specific Modeling Languages (NFPinDSML 09 @ MODELS 2009)

• L. Berardinelli, S. Bernardi, V. Cortellessa, and J. Merseguer, "UML Profiles for Non-Functional Properties at Work: Analyzing Reliability, Availability and Performance", Proc. of the 2nd International Workshop on Non-functional System Properties in Domain Specific Modeling Languages (NFPinDSML 09 @ MODELS 2009)

• L. Berardinelli, V. Cortellessa, and Antinisca Di Marco, " Performance Modeling and Analysis of Context-Aware Mobile Software Systems ", Fundamental Approaches to Software Engineering, 13th International Conference, FASE 2010, Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2010, Paphos, Cyprus, March 20-28, 2010. Proceedings (FASE 2010 @ ETAPS 2010, EASST Award Paper)


Documents

Luca Berardinelli [email protected] Dep. of Computer Science University of L’Aquila (ITALY) Vittorio Cortellessa [email protected]