Mlearning 2009

Towards a software architecture
for adaptive and mobile
learning

Antoine Beugnard and
Jean-Marie Gilliot

Context and Goals

Summer school context
M-learning context
Semantics (???)
Infrastructure

Goals
Think (architecture) different !
Introduce Model Driven Engineering (MDE)
Work on an example

page 2 Mlearning 2009 A. Beugnard & J.-M. Gilliot

Outline

The example
Some needs in mobile and adaptable learning
A certain idea of software architecture
Specifying components
Designing components
Adaptation
Conclusion


The example

A video-conferencing session with votes and a
whiteboard
The client view
An architectural view
Introduces different roles
Prototypes with mashups
Videos + localization
Votes
Shared documents


The client view

Prototypes with mashups
Videos + localization @Paris @New Dehli
Votes
Shared documents
Choregraphy ?
question?

yes

no


The architectural view

Light client?
Heavy client?
Do we need to choose early?

video

modularize sharedspace
The System

vote

What about module interaction?
- at client level? Architecture
- new structure?


Protype with
Mashups, Plugins, Widgets ?

Mashup : a web application that combines data
and/or functionality from more than one source
Widget : a component of a graphical user interface
with which a user interacts
Plug-in : a computer program that interacts with a
host application
Applications support plugins for many reasons.
to enable third-party developers to create capabilities to
extend an application
Source : to support features yet unforeseen
to reduce the size of an application
to separate source code from an application because of
incompatible software licenses.


Web Objects – Web Components

Access Object

+
Function name Data
Parameters API

display


Mashups

A User view of components
How to use Mashups ?
Video : What is a mashup? - ZDNet

Using and assembling services
Vote
Video
Document sharing

Who proposes/designs services?


How to make the glue ?
(another view for 3-tier architecture)

Object
Client side
Data
Combination of data
Server Side
Seed Site Object

Intermedary site Data

Object Object
+
Data Data


Outline

The example
Adaptation
Conclusion


Adaptability

Adaptability is the quality of being adaptable; a
quality that renders adaptable
What could be changed?
GUI (user interface)
Network/Architecture
Multi-Cultural issues
Scale
Confidentiality


Scalability

Scalability is a desirable property of a system, a
network, or a process, which indicates its ability to
either handle growing amounts of work in a
graceful manner, or to be readily enlarged.
Scalability is highly architecture dependent.
Scalability cannot (usually) be improved without
large re-engineering.


Dependability

Dependability is defined as the trustworthiness of a
computing system which allows reliance to be
justifiably placed on the service it delivers. It
encompasses:
Availability - readiness for correct service
Reliability - continuity of correct service
Safety - absence of catastrophic consequences on the
user(s) and the environment
Integrity - absence of improper system alteration
Maintainability - see later
Many factors influence dependability: architecture,
design, implementation, even hardware.

Confidentiality

Confidentiality is the property of preventing
disclosure of information to unauthorized
individuals or systems.
Confidentiality is highly design dependent.
Localization is crucial.


High Availability

High Availability is defined as « Always available »
Always means less than a few minutes/seconds a year
Even during evolution


Maintainability

Maintainability is defined as the ease with which
maintenance of a functional unit can be performed
in accordance with prescribed requirements.

Maintainability is highly design dependent.

Maintainability cannot (usually) be improved without
trace of the design process.


Consequences

Localization is important for confidentiality and
scalability
We need adaptability, hence architecture and design
choices must be explicit

=> What consequences on component models?


Outline

The example
Adaptation
Conclusion


Non functional properties and architecture

Modifiability Performance

Process Function
modifiability modifiability Space Time
Data performance performance
modifiability
-- +
Dependencies between
+ ++
+ NFP and architecture
(qualitative)
-- -

Shared Data Pipe & Filters



Not so different;
3 roles see mashups
Technical expert - furnishes pieces
Architect - deﬁnes assemblies
User - adapts, conﬁgures, specializes
2 levels
Logical/functional
Physical/implementation
Adaptable architecture allows other NFP changes
Adaptable for mobiles systems


Outline

The example
Adaptation
Conclusion



The classical approaches
Functional components match physical architecture
Physical architecture guides functional choices
Our approach
Abstract components
Model Driven Architecture

Mlearning 2009 A. Beugnard & J.-M. Gilliot

Logical/physical mapping

Site 2
Site 1
Site 2
Site 1

Site 3

Site 3

Site 2
Site 1

Site
Site 3 Site 2
Site 1
Componen
t

Interface

Site 3 part

Localization properties expressed and implemented by a component

Abstract Component : Medium

A logical component must ignore physical borders


Medium features

Mediums can have distributed interfaces

Medium implementation is naturally distributed

Many design variants can be imagined

More, many design variants can coexist

Design is realized thanks to model transformations


Medium examples

Vote : proposers start polls, voters vote
Reservation : a set of things can be reserved by
users
Publish subscribe
Broadcasting (messages, video or audio)
Consensus
...


Medium specification

<Role>ComponentServices <Role>MediumServices

implements
implements
use

?
<Role> <Medium>

UML


Vote example

VoterMediumServices
VoterComponentServices
+ vote(int)

*
Voter

VoteMedium
*
VoteProposer

VoteProposerComponentServices VoteProposerMediumServices


Specification to be continued...

UML class Diagrams can only describe the
structural part of a system.

We also add :
Collaboration Diagram
Sequence Diagram
Constraints
And a lot of notes ;-)


Outline

The example
Adaptation
Conclusion



The classical approaches
UML Components by John Cheesman and John
Daniels
Structural decomposition (assembling)
System metaphor (architectural style)

Our approach
Model (and transformation) based

MDE


Our process

Identify preoccupations

Identify the target

Model, model and models

Deﬁne transformation

Cumulate know-how

=> Model Driven Engineering


Some preoccupations

How implementing an association?
List, set, ...
One way, bidirectional?
How distributing data?
None
Without replication but a placement strategy
With a replication strategy and a consistency protocol
management
How observing context/environment ?
etc.


Designing = making choices among
preoccupations
Initial medium Specification

Distributed Target for Medium

set list tree other 1st preoccupation :
Abstract type selection

2nd preoccupation :
Tapestry Chord Pastr other
Distributed protocol selection
y

3rd preoccupation :
Hastable File Data Base other Internal data representation

Implementation Variants


Vote example

VoterMediumServices
+ vote(int)

*
Voter

VoteMedium
*
VoteProposer



Vote example
(transformation add managers)

VoterMediumServices
+ vote(int)

*
Voter VoterManager

VoteMedium
*
VoteProposer VoteProposerManager



Vote example (centralized)

VoterMediumServices
+ vote(int)

*
Voter VoterManager
All data here

VoteMedium
*



Vote example (distributed)

VoterMediumServices
+ vote(int)

*
Voter VoterManager Nothing here

Data distributed among managers VoteMedium
*



Mediums deployment

Logical component
Voter 1
VoteProposer votes
id

Voter 2

id
VoteProposer Middleware
Voter 2
id

id

Physical component Managers
Voter 1
id Data


Transformations

Design choices are implement with
Model transformations

For each preoccupation
Input: the current level of specification
Input: a model of the choice made
Output: the new level of specification

Note that the model of the choice is conformant to a
preoccupation description


Cumulation, reuse

Business know-how Design choices

MMmédium Mréservation Mvote Mvidéo Extension

MMAbstract Type TTA Mset Mlist Mtree Extension

MMDistributed Protocol TPR Mchord Mpastry MTapestry Extension

MMDataFormat TFD Mtable Mhactablee MMfile Extension

Extension Extension Extension Extension Extension Extension

MMdistributedmédium Mréservation Mréservation Mvidéo
Variant 1 Variant 2 Variant 1


Outline

The example
Adaptation
Conclusion


Towards architectural adaptivity

Instead of a single variant, a component is an embed of many va

observations

Decider

Planner

Manager variants
Executor


Context

Dynamic adaptation: in the presence of execution environment
changes, applications need to change behaviors dynamically
Dynamic adaptations of distributed applications [Figure]
Architecture-based adaptation: Application moves from a consistent
architecture to another one

Some NFP
Variant 1

Variant 2
Other NFP


Challenge 1

How to ensure the correctness of the collaboration
between distributed components after transitions?
(How to build “correct” variants?)


Challenge 2

How to plan dynamic transitions, including
distributed architecture variants transitions and
data transitions?


Proposed approach:
Abstraction (1) + Refinement (2) + Composition (3) +
Planning (4)
Communication (1)
Design decisions abstraction
(medium)
(2) Info. for planning
Refinement
(4)

(1), (2) ensure the Compositio
correctness of variants (3)
n
(3) supports dynamic
transition
(4) allows planning
transitions


Example
Abstraction  Refinement + Planning  Composition

Abstraction: vote medium
A (reusable) medium offering vote services to the citizens, initialize
service to the state.
The medium is the abstraction of communication between state and
citizens)

Service: vote
Service: initialize
Citizen 1

Voter
vote State
medium
Voter VoteProposer

Citizen 2


Example
Abstraction  Refinement + Planning  Composition

1

Citizen 2 Middleware State

Adapt
manager
Decider

Planner
Citizen 1

Executor
Manager variants
Adapt-medium

Adapt-manager architecture


Model-based framework automating the
development process
UML Medium model

Developer Design Kermeta
Model
decision models transformations metamodeling

UML
Adaptable
application model
UML
Medium
Java functions’
implementations Java
Composition
Fractal +Java Adapt-manager
implementation Fractal
Adapt-medium
+ Java


Outline

The example
Adaptation
Conclusion


Key ideas

Components can overpass (physical) borders
Know-how can be cumulated thanks to models and
transformations
Large scale applications need adaptivity
With adaptivity all NFP can be tackled

What about mobile learning ?
Need scalability
Need adaptivity

What specific mediums for mobile learning?


What remains to be done?

A lot!

Valuating preocupation solutions in regards of non-
functional properties


ANNEX I

Software Architecture
Survival Kit


Software Architecture – the art of boxology

Entities
(boxes)

Connectors
(lines)

Configurations
(assembly)


Styles of architectures

Pipe and Filters Layered

Knowledge Knowledge
source source Blackboard

Knowledge Knowledge
source source
BlackBoar
d

Client server REST, P2P, Publish/Subscribe, etc.
request
Good/Bad properties wrt:
CLIENT answer SERVEUR
Scalability, evolutivity, maintainability, aso.


ANNEX II

UML Survival Kit


UML survival kit - ½ (class diagram only)
© G. Nomitch- BK consulting
Named area containing items.
A package can contain packages and classes (including the relationships with each others)
Package Inheritance Ex :
Car
Class Concept
Data structure with services (ie methods/functions)
Class An object is a class instanciation.
Ex : int i = 5 Peugeot
ClassObjectValue
AnotherClass Concrete
Abstract class « 104 »
Class that can not be instanciated.
It represents a functional or a technical concept.

AssociationNo ownership concept
Ex : I see the moon

cont Element
Shared aggregationShared ownership List
Relations Ex : Two people own the same bank account 0..n

AggregationExclusive ownership
Ex : Me and my head (I own my head !). /cont
CarList Car
1 0..n
0..1
Cardinality 0 or 1 A list contains elements. A carList is a List that only contains Elements specialize
0..n
0 to many Note that a relation specialization can also change the relation type and the cardi

Specialized relation /role


UML survival kit - 2/2 (class diagram
example) © G. Nomitch- BK consulting
Cardinality is 0 to many

0..n
General functional concept
cont AbstractActor

Aggregation Inheritance (also called specialization)

Cont relation specialization
Technical class corresponding to a list of concept Role concept.
ActorList
A role is an actor.

/cont 0..n
Model core Person AbstractRole
refPerson
Physical role

The role knows the person it refers to.
hysical actor with roles. A person can be a driver and/or a player.get the person name !
When you ask for the role name, you
Driver Player

Nice association

Car Ball
A driver and only a driver use a car Back


ANNEX III

MDE Survival Kit
(Model Driven
Engineering)

MDA: The OMG presentation

(
(a)
(b) (c)

Y
UM MO MO
L F F
Business Technical
aMode UM UM SPE CW Etc Logic Architecture
l L L M M . (PIM) (PDM)
aMod aMo
el del
Everything (software artefact) is a Model System (PSM)

Transformations are
operations on models An De
that automatizes choices Cod
aly sig
e Back
sis n


Mlearning 2009

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Mlearning 2009

Similar to Mlearning 2009 (20)

More from Jean-Marie Gilliot

More from Jean-Marie Gilliot (20)

Recently uploaded

Recently uploaded (20)

Mlearning 2009