Mlearning 2009

  • 464 views
Uploaded on

Mobile Learning Summer School …

Mobile Learning Summer School
http://conferences.telecom-bretagne.eu/mlearning09/

Slides of course :
software architecture for adaptive and mobile learning

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
464
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
25
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Towards a software architecture for adaptive and mobile learning Antoine Beugnard and Jean-Marie Gilliot
  • 2. 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
  • 3. Outline The example Some needs in mobile and adaptable learning A certain idea of software architecture Specifying components Designing components Adaptation Conclusion page 3 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 4. 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 page 4 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 5. The client view Prototypes with mashups Videos + localization @Paris @New Dehli Votes Shared documents Choregraphy ? question? yes no page 5 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 6. 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? page 6 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 7. 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. page 7 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 8. Web Objects – Web Components Access Object + Function name Data Parameters API display page 8 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 9. 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? page 9 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 10. 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 page 10 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 11. Outline The example Some needs in mobile and adaptable learning A certain idea of software architecture Specifying components Designing components Adaptation Conclusion page 11 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 12. 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 page 12 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 13. 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. page 13 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 14. 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. page 14 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 15. Confidentiality Confidentiality is the property of preventing disclosure of information to unauthorized individuals or systems. Confidentiality is highly design dependent. Localization is crucial. page 15 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 16. High Availability High Availability is defined as « Always available » Always means less than a few minutes/seconds a year Even during evolution page 16 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 17. 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. page 17 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 18. Consequences Localization is important for confidentiality and scalability We need adaptability, hence architecture and design choices must be explicit => What consequences on component models? page 18 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 19. Outline The example Some needs in mobile and adaptable learning A certain idea of software architecture Specifying components Designing components Adaptation Conclusion page 19 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 20. 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 page 20 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 21. A certain idea of software architecture Not so different; 3 roles see mashups Technical expert - furnishes pieces Architect - defines assemblies User - adapts, configures, specializes 2 levels Logical/functional Physical/implementation Adaptable architecture allows other NFP changes Adaptable for mobiles systems page 21 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 22. Outline The example Some needs in mobile and adaptable learning A certain idea of software architecture Specifying components Designing components Adaptation Conclusion page 22 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 23. Specifying components 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
  • 24. 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 page 24 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 25. Abstract Component : Medium A logical component must ignore physical borders page 25 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 26. 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 page 26 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 27. 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 ... page 27 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 28. Medium specification <Role>ComponentServices <Role>MediumServices implements implements use ? <Role> <Medium> UML page 28 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 29. Vote example VoterMediumServices VoterComponentServices + vote(int) * Voter VoteMedium * VoteProposer VoteProposerComponentServices VoteProposerMediumServices page 29 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 30. 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 ;-) page 30 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 31. Outline The example Some needs in mobile and adaptable learning A certain idea of software architecture Specifying components Designing components Adaptation Conclusion page 31 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 32. Designing components 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 page 32 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 33. Our process Identify preoccupations Identify the target Model, model and models Define transformation Cumulate know-how => Model Driven Engineering page 33 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 34. 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. page 34 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 35. 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 page 35 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 36. Vote example VoterMediumServices VoterComponentServices + vote(int) * Voter VoteMedium * VoteProposer VoteProposerComponentServices VoteProposerMediumServices page 36 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 37. Vote example (transformation add managers) VoterMediumServices VoterComponentServices + vote(int) * Voter VoterManager VoteMedium * VoteProposer VoteProposerManager VoteProposerComponentServices VoteProposerMediumServices page 37 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 38. Vote example (centralized) VoterMediumServices VoterComponentServices + vote(int) * Voter VoterManager All data here VoteMedium * VoteProposer VoteProposerManager VoteProposerComponentServices VoteProposerMediumServices page 38 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 39. Vote example (distributed) VoterMediumServices VoterComponentServices + vote(int) * Voter VoterManager Nothing here Data distributed among managers VoteMedium * VoteProposer VoteProposerManager VoteProposerComponentServices VoteProposerMediumServices page 39 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 40. 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 page 40 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 41. 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 page 41 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 42. 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 page 42 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 43. Outline The example Some needs in mobile and adaptable learning A certain idea of software architecture Specifying components Designing components Adaptation Conclusion page 43 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 44. Towards architectural adaptivity Instead of a single variant, a component is an embed of many va observations Decider Planner Manager variants Executor page 44 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 45. 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 page 45 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 46. Challenge 1 How to ensure the correctness of the collaboration between distributed components after transitions? (How to build “correct” variants?) page 46 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 47. Challenge 2 How to plan dynamic transitions, including distributed architecture variants transitions and data transitions? page 47 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 48. 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 page 48 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 49. 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 page 49 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 50. Example Abstraction  Refinement + Planning  Composition 1 Citizen 2 Middleware State Adapt manager Decider Planner Citizen 1 Executor Manager variants Adapt-medium Adapt-manager architecture page 50 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 51. 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 page 51 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 52. Outline The example Some needs in mobile and adaptable learning A certain idea of software architecture Specifying components Designing components Adaptation Conclusion page 52 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 53. 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? page 53 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 54. What remains to be done? A lot! Valuating preocupation solutions in regards of non- functional properties page 54 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 55. ANNEX I Software Architecture Survival Kit page 55 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 56. Software Architecture – the art of boxology Entities (boxes) Connectors (lines) Configurations (assembly) page 56 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 57. 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. page 57 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 58. ANNEX II UML Survival Kit page 58 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 59. 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 page 59 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 60. 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 page 60 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 61. ANNEX III MDE Survival Kit (Model Driven Engineering) page 61 Mlearning 2009 A. Beugnard & J.-M. Gilliot
  • 62. 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 page 62 Mlearning 2009 A. Beugnard & J.-M. Gilliot