Specification of Distributed and Embedded Sytems

Présentation au sujet: "Specification of Distributed and Embedded Sytems"— Transcription de la présentation:

1 Specification of Distributed and Embedded Sytems
MDE, Distributed Components & Specification Environments Eric Madelaine INRIA Sophia-Antipolis Oasis team Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

2 Schéma du cours 1. Introduction: concurrence/parallelisme, synchrone/asynchrone,   embarqué/distribué  RS 2. MDE: machines d'états, diagrammes d'activité, composants EM   3. Calculs de processus et SOS LH 4. Composants asynchrones et fondements de ProActive LH 5. Sémantique synchrone (Esterel) RS 6. Logique temporelle EM 7. Model Checking RS 8. EXPOSES Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

3 Flash back & keywords… Formal methods in the design flow of distributed/embedded systems Provide mathematical semantics to models so that their relation to implemented product can be asserted and proved : model checking, equivalence checking test generation Communication and control (control-flow): interactions, protocols Modeling languages: UML and variants (StateCharts, SysML,…) Dedicated IDLs and ADLs for system decomposition (…) Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

4 Systems: structure and behavior
In general, a system is: constituted of components, interacting in a collaborative or hierarchical fashion (structure) evolving, as a result of the composed functional of its components (behavior) a system changes state through time; time is counted in number of actions/operations In highly dynamic systems the division is blurred, as structure is transformed by behaviors; e.g. in large scale software services (= business grids, SOA, …) rarely the case in embedded systems See UML and elsewhere, models divided between structural and behavioral ones Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

5 Cycle de developpement/ design cycle
Requirements capture Cahier des charges Sign-off / Recette Global testing (Initial) specification Architectural division Integration Component testing Component design / programmation IP component reuse libraries Implementation Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

6 Cycle de développement/ design cycle
Proof of requirements Requirements capture Cahier des charges Sign-off / Recette Early specification of Architecture and Interaction Global testing (Initial) specification Correct composition: interface compatibility, deadlock freeness, spec implementation Architectural division Integration Test generation Correct-by-Construction Implementation Synthesis Component testing IP component reuse libraries Black box specification Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

7 Agenda Graphical Modeling Languages : Components models : Tools
A zoo of UML diagrams Components models : Fractal, GCM Tools Build development platforms ? Hands-on exercices Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

8 UML -- MDE -- Visual models Single (unified)
Too many different languages, platforms, formalisms…. Unified visual Language Everybody must speak the same language Language for specification / code generation Supposedly precise and non-ambiguous One single view is not enough: Class diagrams Sequence diagrams Activity diagrams State machines Composite structure diagrams Deployment diagrams Marte profile Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

9 A single model is not enough!
Create several independent models but with common points and relations. Logical view Implementation view Analystes/Concepteurs Programmeurs Structure Software management Use-Case View Utilisateur final Fonctionalité Process View Deployment view Ingénieur système Intégrateur système Topologie du système, livraison, installation, communication Performance, scalabilité, débit Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

10 Class diagrams Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

11 Sequence diagram Actor Objects Execution occurrence Messages
Have the students read through this diagram. Help them if they get stuck. The next few slides discuss the details of the items found on this diagram. Note: the purpose of this slide is to show how a sequence diagram fits together. There are no //’s because the // is a way to represent responsibilities. Responsibilities are discussed in the OOAD course but are outside the scope of this course. : Etudiant :FormulaireInscription :ResponsableInscription :GérantListeCours : Catalogue Cours 1: faire EDT( ) 2: get cours offerts( ) 3: get cours offerts(pour Le Semestre) 4: get cours offerts( ) Execution occurrence Messages 5: afficher cours offerts ( ) Actor instance You can have objects and actor instances in sequence diagrams, together with messages describing how they interact. The diagram describes what takes place in the participating objects, in terms of activations, and how the objects communicate by sending messages to one another. You can make a sequence diagram for each variant of a use case's flow of events. The above example shows the object interactions to support the Register for Courses’ use case, Create a Schedule sub-flow. Note the following responsibility allocation rationale. The RegisterForCoursesForm knows what data it needs to display and how to display it. It does not know where to go to get it. That is one of the RegistrationController’s responsibilities. Only the RegisterForCoursesForm interacts with the Student actor. The RegistrationController understands how Students and Schedules are related. Only the CourseCatalogSystem class interacts with the external legacy Course Catalog System. Note the inclusion of the actors. This is important as it explicitly models what elements communicate with the “outside world.” 6: afficher EDT vide( ) Interaction occurrence Choisir les cours ref Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

12 Activity diagram Choice Action Concurrent executions Synchronisation
Walk the students through the activity diagram and explain each component (decision, fork, join, and so on). Sélectionne cours Concurrent executions [ efface cours ] Efface cours [ ajoute cours ] Synchronisation (Fork) Vérifie EDT Vérifie Pré-requis Guard Synchronisation (Join) [ OK ] KO Affecte Cours An activity diagram may include the following elements: Activity/Action represents the performance of a step within the workflow. Transitions show the activity/action that follows. Decisions evaluate conditions defined by guard conditions. These guard conditions determine which of the alternative transitions will be made and, thus, which activities are performed. You may also use the decision icon to show where the threads merge again. Decisions and guard conditions allow you to show alternative threads in the workflow of a use case. Synchronization bars show parallel sub-flows. They allow you to show concurrent threads in the workflow of a use case. résout conflits Transition metAJour EDT Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

13 State machine diagram MCF Candidate Prof class 2 Prof class 1
Provide a sample state machine for the students to read. Briefly explain the advanced concepts of the state machine that are not covered in detail in this course. The Hired state is a composite state which means that it contains additional behavior inside the state. The H within a circle is known as a history pseudo state or a return to history. When the accepted transition reaches history of the Hired state, since we have never been here before we go to the initial pseudo state. The takeSabbatical transition is a group transition which means that any state inside of Hired can trigger this transition. When the return transition reaches history of the Hired state, we return to the state we were in last, i.e., if we were in the Tenured state when we took a Hiatus, we will return to the Tenured state upon reaching history. hired MCF Candidate success H HDR Prof class 2 fail promotion retirement Prof class 1 H detached back Engineer R&D Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

14 Component and Composite structure diagrams
Provided / required interfaces Hierarchical components Ports Bindings Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

15 Deployment diagram 0..2000 <<Campus LAN>> 1 1 1
Provide an example of a deployment diagram for the student to read. <<client workstation>> PC JDK 1.6 <<Campus LAN>> 1 <<application server>> deptinfo 1 Matlab Simulateur VHDL Eclipse 1 <<Campus LAN>> <<Campus LAN>> The above diagram illustrates a refined deployment view for the Course Registration System. There are PC client workstations on the campus network. Each running a StudentApplication process. The main business processing hardware is the Registration Server running the CourseCatalogSystemAccess, CourseRegistrationProcess, and BillingSystemAccess processes. The Registration Server talks to the two machines that host the legacy systems. All nodes are on the campus network. 1 1 <<legacy RDBMS>> Apogée <<legacy>> Geisha Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

16 MARTE: UML Profile for Modeling and Analysis of Real-Time and Embedded Systems
Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

17 Synchronous / Asynchronous
Components Hardware / software Synchronous / Asynchronous Flat / Hierarchical Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

18 Agenda Graphical Modeling Languages : Components models : Tools
A zoo of UML diagrams Components models : Fractal, GCM Tools Build development platforms ? Hands-on exercices Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

19 The Fractal component model
Systems and middleware engineering Generic enough to be applied to any other domain Fine grain (wrt EJB or CCM), close to a class model Lightweight (low overhead on top of objects) Independent from programming languages Homogeneous vision of all layers (OS, middleware, services, applications) Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

20 Fractal Open and adaptable/extensible
Usable as a component framework to build applications with “standard” Fractal components Usable as a component framework framework building different kinds of components with minimum introspection and simple aggregation (à la COM) with binding and lifecycle controllers (à la OSGi) with a two-level hierarchy and bindings (à la SCA) with persistence and transaction controllers (à la EJB) with attribute controllers (à la MBean) Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

21 Fractal : controllers Control Non functional (tech’al) properties
Implemented in the membrane Made of a set of controllers E.g. security, transaction, persistence, start/stop, naming Controllers accessible through a control interface Controllers and membranes are open Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

22 Fractal tools Fraclet Fractal ADL Fractal API
programming model based on annotations (within Java programs) Fractal ADL XML-based architecture description language (ADL) Fractal API set of Java interfaces for introspection reconfiguration dynamic creation/modification of Fractal components and component assemblies Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

23 Fractal : development tools
F4E: Eclipse development environment for Fractal applications Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

24 Case Study Source: France Telecom / Charles Un. Prague
Specification of an Airport Wifi Network Hierarchical, real-size Fractal specification + Sofa “behavior protocols” Model-checking Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

25 GCM Grid Component Model
A Fractal Extension Scopes and Objectives: Grid Codes that Compose and Deploy No programming, No Scripting, … Innovations: Abstract Deployment Multicast and GatherCast Controller (NF) Components Standardization By the ETSI TC-GRID

26 GCM: NxM communication
1 to N = multicast / broadcast / scatter N to 1 bindings = gathercast Attach a behaviour (policy) to these interfaces Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

27 GCM: components for controllers
“Componentize” the membrane: Build controllers in a structured way Reuse of controller components Applications: control components for self-optimization, self-healing, self-configuring, interceptors for encryption, authentication, … Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

28 GCM architecture specifications: VCE tool
Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

29 Agenda Graphical Modeling Languages : Components models : Tools
A zoo of UML diagrams Components models : Fractal, GCM Tools Build development platforms ? Hands-on exercices Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

30 VCE VerCors Component Editor
A “Domain Specific Language” for Fractal/GCM Component architecture diagrams Behaviour diagrams Model generation for verification tools Code generation Agenda: Tool architecture Validation rules “hands-on” exercices Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

31 VCE Architecture Vercors Graphical Editor (Eclipse Plugin) G C M /
ProActive ADL/IDL (final) Runtime Behav Specification (LTS) pNets/ Fiacre Model Generator Finite model Prover Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

32 VCE Architecture (middle term)
Vercors G C M / ProActive Graphical Editor (Eclipse Plugin) ADL/IDL (final) Code Generator Java Skeletons JDC Specification Runtime Business code JDC Formula pNets/ Fiacre Model Generator Finite model Prover Formula Compiler Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

33 VCE Eclipse and MDE Tools
Eclipse Modelling Tools: EMF (Eclipse Modeling Framework): XMI model definition and Java code generation GEF (Graphical Editing Framework) GMF (Graphical Modeling Framework) for developing graphical editors Model Development Tools Atlas Transformation Language (ATL) …. Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

34 Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

35 VCE Validation, OCL Several notions of correctness in the diagram editors: Structural correctness, by construction: the graphical tools maintain a number of constraints, like bindings attached to interfaces, interfaces on the box borders, etc. But some rules are related to the model structure, not to the graphical objects. E.g. bindings should not cross component levels, or sibling objects should have distinct names… There is a “Validation” function (and button), that must be checked only on “finished” diagrams, before model/code generation. It is defined using OCL rules. Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

36 VCE : Validation, OCL OCL example : context Binding inv FromClientToServer_InContent_ROLES: ( Content.allInstances()->exists(c : Content | c.bindings->includes(self)) and Content.allInstances()->any(bindings->includes(self)).subcomponents ->exists(sc : Component | sc.oclAsType(ComponentDefinition).externalInterfaces ->includes(self.sourceInterface)) ->includes(self.targetInterface)) ) implies self.sourceInterface.role = InterfaceRole::client and self.targetInterface.role = InterfaceRole::server Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

37 VCE Examples for the SSDE course
Component: external view Component: internal architecture Multicast: example, workflow style Multicast: build a matrix application Master/slave, RPC style Matrix: parameterized style Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

38 1. External view Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

39 2. Internal architecture
Build a composite component, with : Outside: 1 serveur interface SI 2 client interface CI1, CI2 A number of control (NF) interfaces Inside: 2 subcomponents One connected to SI Each connected to one client interface One binding between them Check its validity and produce the ADL Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

40 3. Multicast and gathercast, workflow style
Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

41 4. Composite, multicast, matrix
Build a composite component, with: One server interface, with an internal multicast interface 2 x 3 subcomponents representing matrix blocks, each linked to its left neighbour Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

42 5. Master/slave, RPC style
Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

43 6. Matrix, parameterized style
Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

44 7. Exercice Analyze this diagram (semantics, errors, …)
Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009

45 Corrigés Exercice 2 Exercice 4 Exercice 7:
1 true error: Bindings crossing component bounds 1 false error (bug in a validation rule): more than one component in membrane Interesting features : 1 provided service is not connected (thus not implemented…); is this a problem? 2 client interfaces are not used; is this a problem ? The logger component has no visible interface; is this a problem ? The life-cycle controller does not control anything; this may be a problem… Spécification des Systèmes Distribués et Embarqués -- UNSA -- Master 2009