1. Towards a software architecture for adaptive and mobile learning Antoine Beugnard and Jean-Marie Gilliot

2. Context and GoalsSummer school contextM-learning contextSemantics (???)Infrastructure GoalsThink (architecture) different !Introduce Model Driven Engineering (MDE)Work on an example page 2 Mlearning 2009 A. Beugnard & J.-M. Gilliot 3. OutlineThe exampleSome needs in mobile and adaptable learningA certain idea of software architectureSpecifying componentsDesigning componentsAdaptationConclusion page 3Mlearning 2009 A. Beugnard & J.-M. Gilliot 4. The example A video-conferencing session with votes and awhiteboardThe client viewAn architectural viewIntroduces different rolesPrototypes with mashupsVideos + localizationVotesShared documentspage 4Mlearning 2009 A. Beugnard & J.-M. Gilliot 5. The client viewPrototypes with mashupsVideos + localization @Paris@New DehliVotesShared documentsChoregraphy ? question? yesno page 5Mlearning 2009 A. Beugnard & J.-M. Gilliot 6. The architectural view Light client?Heavy client?Do we need to choose early? video modularizesharedspaceThe System vote What about module interaction? - at client level? Architecture - new structure?page 6Mlearning 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 toextend an applicationSource :to support features yet unforeseento reduce the size of an applicationto separate source code from an application because ofincompatible software licenses.page 7Mlearning 2009A. Beugnard & J.-M. Gilliot 8. Web Objects Web Components AccessObject +Function nameData Parameters APIdisplay page 8Mlearning 2009 A. Beugnard & J.-M. Gilliot 9. MashupsA User view of componentsHow to use Mashups ?Video : What is a mashup? - ZDNet Using and assembling services Vote Video Document sharing Who proposes/designs services? page 9Mlearning 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 ObjectIntermedary siteData Object Object + DataData page 10Mlearning 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 11Mlearning 2009 A. Beugnard & J.-M. Gilliot 12. Adaptability Adaptability is the quality of being adaptable; aquality that renders adaptable What could be changed?GUI (user interface)Network/ArchitectureMulti-Cultural issuesScaleConfidentiality page 12Mlearning 2009A. Beugnard & J.-M. Gilliot 13. Scalability Scalability is a desirable property of a system, anetwork, or a process, which indicates its ability toeither handle growing amounts of work in agraceful manner, or to be readily enlarged. Scalability is highly architecture dependent. Scalability cannot (usually) be improved withoutlarge re-engineering. page 13Mlearning 2009A. Beugnard & J.-M. Gilliot 14. Dependability Dependability is defined as the trustworthiness of acomputing system which allows reliance to bejustifiably placed on the service it delivers. Itencompasses:Availability - readiness for correct serviceReliability - continuity of correct serviceSafety - absence of catastrophic consequences on theuser(s) and the environmentIntegrity - absence of improper system alterationMaintainability - see later Many factors influence dependability: architecture,design, implementation, even hardware. page 14Mlearning 2009 A. Beugnard & J.-M. Gilliot 15. Confidentiality Confidentiality is the property of preventingdisclosure of information to unauthorizedindividuals or systems. Confidentiality is highly design dependent.Localization is crucial. page 15Mlearning 2009A. 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 16Mlearning 2009 A. Beugnard & J.-M. Gilliot 17. Maintainability Maintainability is defined as the ease with whichmaintenance of a functional unit can be performedin accordance with prescribed requirements.Maintainability is highly design dependent.Maintainability cannot (usually) be improved withouttrace of the design process. page 17Mlearning 2009 A. Beugnard & J.-M. Gilliot 18. Consequences Localization is important for confidentiality andscalability We need adaptability, hence architecture and designchoices must be explicit=> What consequences on component models? page 18Mlearning 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 19Mlearning 2009 A. Beugnard & J.-M. Gilliot 20. Non functional properties and architecture Modifiability Performance Process Functionmodifiability modifiabilitySpace TimeData performance performancemodifiability -- +Dependencies between+++ +NFP and architecture(qualitative)-- -Shared Data Pipe & Filterspage 20Mlearning 2009A. Beugnard & J.-M. Gilliot 21. A certain idea of software architectureNot so different; 3 rolessee mashups Technical expert - furnishes pieces Architect - denes assemblies User - adapts, congures, specializes 2 levels Logical/functional Physical/implementation Adaptable architecture allows other NFP changes Adaptable for mobiles systemspage 21Mlearning 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 22Mlearning 2009 A. Beugnard & J.-M. Gilliot 23. Specifying components The classical approachesFunctional components match physical architecturePhysical architecture guides functional choices Our approachAbstract componentsModel Driven ArchitectureMlearning 2009 A. Beugnard & J.-M. Gilliot 24. Logical/physical mapping Site 2 Site 1 Site 2 Site 1Site 3Site 3 Site 2Site 1Site Site 3 Site 2Site 1ComponentInterface Site 3partLocalization properties expressed and implemented by a component page 24 Mlearning 2009A. Beugnard & J.-M. Gilliot 25. Abstract Component : MediumA logical component must ignore physical borderspage 25Mlearning 2009A. Beugnard & J.-M. Gilliot 26. Medium features Mediums can have distributed interfacesMedium implementation is naturally distributedMany design variants can be imaginedMore, many design variants can coexistDesign is realized thanks to model transformations page 26Mlearning 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 27Mlearning 2009 A. Beugnard & J.-M. Gilliot 28. Medium specification ComponentServicesMediumServices implementsimplements use?UMLpage 28Mlearning 2009A. Beugnard & J.-M. Gilliot 29. Vote example VoterMediumServices VoterComponentServices+ vote(int)*Voter VoteMedium * VoteProposerVoteProposerComponentServices VoteProposerMediumServices page 29Mlearning 2009 A. Beugnard & J.-M. Gilliot 30. Specification to be continued... UML class Diagrams can only describe thestructural part of a system.We also add :Collaboration DiagramSequence DiagramConstraintsAnd a lot of notes ;-) page 30Mlearning 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 31Mlearning 2009 A. Beugnard & J.-M. Gilliot 32. Designing components The classical approachesUML Components by John Cheesman and JohnDanielsStructural decomposition (assembling)System metaphor (architectural style)Our approachModel (and transformation) basedMDEpage 32Mlearning 2009 A. Beugnard & J.-M. Gilliot 33. Our process Identify preoccupationsIdentify the targetModel, model and modelsDene transformationCumulate know-how => Model Driven Engineeringpage 33Mlearning 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 protocolmanagement How observing context/environment ? etc. page 34Mlearning 2009 A. Beugnard & J.-M. Gilliot 35. Designing = making choices among preoccupationsInitial medium Specification Distributed Target for Mediumsetlist treeother 1st preoccupation : Abstract type selection 2nd preoccupation : Tapestry ChordPastr other Distributed protocol selection y 3rd preoccupation : HastableFile Data Base other Internal data representation Implementation Variants page 35Mlearning 2009A. Beugnard & J.-M. Gilliot 36. Vote example VoterMediumServices VoterComponentServices+ vote(int)*Voter VoteMedium * VoteProposerVoteProposerComponentServices VoteProposerMediumServices page 36Mlearning 2009 A. Beugnard & J.-M. Gilliot 37. Vote example (transformation add managers) VoterMediumServices VoterComponentServices+ vote(int) * Voter VoterManager VoteMedium* VoteProposer VoteProposerManager VoteProposerComponentServices VoteProposerMediumServices page 37Mlearning 2009A. Beugnard & J.-M. Gilliot 38. Vote example (centralized) VoterMediumServices VoterComponentServices+ vote(int) * Voter VoterManagerAll data here VoteMedium* VoteProposer VoteProposerManager VoteProposerComponentServices VoteProposerMediumServices page 38Mlearning 2009A. Beugnard & J.-M. Gilliot 39. Vote example (distributed) VoterMediumServices VoterComponentServices+ vote(int) * Voter VoterManager Nothing hereData distributed among managersVoteMedium* VoteProposer VoteProposerManager VoteProposerComponentServices VoteProposerMediumServices page 39Mlearning 2009A. Beugnard & J.-M. Gilliot 40. Mediums deployment Logical componentVoter 1 VoteProposer votesid Voter 2id VoteProposerMiddleware Voter 2 idid Physical componentManagers Voter 1 idData page 40Mlearning 2009 A. Beugnard & J.-M. Gilliot 41. Transformations Design choices are implement withModel transformationsFor each preoccupationInput: the current level of specificationInput: a model of the choice madeOutput: the new level of specificationNote that the model of the choice is conformant to apreoccupation description page 41Mlearning 2009A. Beugnard & J.-M. Gilliot 42. Cumulation, reuseBusiness know-how Design choicesMMmdiumMrservationMvoteMvido Extension MMAbstract TypeTTAMsetMlistMtreeExtensionMMDistributed Protocol TPRMchord MpastryMTapestry Extension MMDataFormat TFDMtable MhactableeMMfile Extension ExtensionExtension ExtensionExtensionExtension Extension MMdistributedmdium MrservationMrservationMvido Variant 1 Variant 2 Variant 1page 42Mlearning 2009A. 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 43Mlearning 2009 A. Beugnard & J.-M. Gilliot 44. Towards architectural adaptivityInstead of a single variant, a component is an embed of many vaobservations Decider Planner Manager variants Executor page 44Mlearning 2009A. Beugnard & J.-M. Gilliot 45. ContextDynamic 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 oneSome NFPVariant 1Variant 2Other NFPpage 45 Mlearning 2009 A. Beugnard & J.-M. Gilliot 46. Challenge 1How to ensure the correctness of the collaborationbetween distributed components after transitions?(How to build correct variants?) page 46Mlearning 2009 A. Beugnard & J.-M. Gilliot 47. Challenge 2How to plan dynamic transitions, includingdistributed architecture variants transitions anddata transitions? page 47Mlearning 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 planningRefinement(4)(1), (2) ensure the Compositiocorrectness of variants (3) n(3) supports dynamictransition(4) allows planningtransitionspage 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: voteService: initializeCitizen 1 VotervoteState mediumVoterVoteProposer Citizen 2page 49 Mlearning 2009 A. Beugnard & J.-M. Gilliot 50. ExampleAbstraction Refinement + Planning Composition1 Citizen 2Middleware StateAdaptmanager Decider PlannerCitizen 1Executor Manager variantsAdapt-mediumAdapt-manager architecturepage 50 Mlearning 2009 A. Beugnard & J.-M. Gilliot 51. Model-based framework automating the development processUMLMedium model DeveloperDesignKermeta Model decision models transformationsmetamodelingUMLAdaptable application modelUML Medium Java functions implementations JavaComposition Fractal +Java Adapt-manager implementationFractal Adapt-medium + Java page 51Mlearning 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 52Mlearning 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 tackledWhat about mobile learning ?Need scalabilityNeed adaptivityWhat specific mediums for mobile learning?page 53Mlearning 2009 A. Beugnard & J.-M. Gilliot 54. What remains to be done? A lot!Valuating preocupation solutions in regards of non-functional properties page 54Mlearning 2009 A. Beugnard & J.-M. Gilliot 55. ANNEX I Software ArchitectureSurvival Kitpage 55 Mlearning 2009 A. Beugnard & J.-M. Gilliot 56. Software Architecture the art of boxologyEntities(boxes) Connectors (lines)Configurations(assembly) page 56 Mlearning 2009 A. Beugnard & J.-M. Gilliot 57. Styles of architectures Pipe and FiltersLayeredKnowledgeKnowledgesource sourceBlackboardKnowledgeKnowledge source sourceBlackBoardClient server REST, P2P, Publish/Subscribe, etc.request Good/Bad properties wrt:CLIENT answer SERVEURScalability, evolutivity, maintainability, aso.page 57Mlearning 2009A. Beugnard & J.-M. Gilliot 58. ANNEX IIUML Survival Kit page 58 Mlearning 2009A. 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)PackageInheritance Ex : Car ClassConcept Data structure with services (ie methods/functions)ClassAn object is a class instanciation. Ex : int i = 5Peugeot ClassObjectValue AnotherClass ConcreteAbstract class 104 Class that can not be instanciated. It represents a functional or a technical concept.AssociationNo ownership conceptEx : I see the moon cont ElementShared aggregationShared ownership List RelationsEx : Two people own the same bank account 0..n AggregationExclusive ownershipEx : Me and my head (I own my head !)./cont CarList Car 10..n0..1Cardinality0 or 1A list contains elements. A carList is a List that only contains Elements specialize0..n 0 to many Note that a relation specialization can also change the relation type and the cardiSpecialized relation/rolepage 59Mlearning 2009A. Beugnard & J.-M. Gilliot 60. UML survival kit - 2/2 (class diagram example) G. Nomitch- BK consulting Cardinality is 0 to many 0..nGeneral functional conceptcont AbstractActor AggregationInheritance (also called specialization)Cont relation specialization Technical class corresponding to a list of concept Role concept.ActorListA role is an actor. /cont 0..n Model corePersonAbstractRole refPersonPhysical roleThe 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 DriverPlayer Nice associationCarBall A driver and only a driver use a car Backpage 60Mlearning 2009A. Beugnard & J.-M. Gilliot 61. ANNEX IIIMDE Survival Kit (Model DrivenEngineering) page 61 Mlearning 2009A. Beugnard & J.-M. Gilliot 62. MDA: The OMG presentation ( (a)(b)(c) Y UMMO MOL FF Business Technical aMode UM UMSPECWEtc LogicArchitecture lLL MM. (PIM)(PDM) aMod aMoel del Everything (software artefact) is a Model System (PSM) Transformations are operations on modelsAnDe that automatizes choices Cod aly sig e Back sisnpage 62 Mlearning 2009A. Beugnard & J.-M. Gilliot