Modélisation des Systèmes Émbarqueslipari/courses/semba/print-final-07.pdf · Contraintes sur le...
Transcript of Modélisation des Systèmes Émbarqueslipari/courses/semba/print-final-07.pdf · Contraintes sur le...
Modélisation des Systèmes Émbarques
Giuseppe Lipari
LIFL - Université de Lille 1
4 octobre 2015
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 1 / 42
Résumé
Systèmes embarqués
Qu’est-ce que c’est un modèle ?
Langages de modélisation
Analyse des réquisits
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 3 / 42
Crédits
Ces diapositives sont en part l’élaboration :
des diapositives du cours "Embedded Systems Design" par Marco DiNatale à la Superiore Sant’Anna (http://retis.sssup.it/~marco/teaching/embeddedsystems/)
des diapositives de Pierre Boulet pour le cours SEMBA de l’annéedernière
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 4 / 42
Système Embarqué : définition
Des "Wikipedia" :
An embedded system is a special-purpose computer system
designed to perform one or a few dedicated functions, sometimes
with real-time computing constraints. It is usually embedded as part
of a complete device including hardware and mechanical parts. In
contrast, a general-purpose computer, such as a personal computer,
can do many different tasks depending on programming.
Since the embedded system is dedicated to specific tasks, design
engineers can optimize it, reducing the size and cost of the product,
or increasing the reliability and performance.
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 6 / 42
Caractéristiques
Embedded - Dedicated
Interaction avec des processus physiquescapteurs, actionneurs← contraintes temporelles (latency, jitters)
Réactivitéil faut opérer à la même vitesse que l’environnement
Des propriétés fonctionnelles et non-fonctionnellesreal-time, fault recovery, power, security, robustness,
Hétérogénéitéhardware/software tradeoffs
Concurrenceinteraction avec plusieurs processus
Contraintes sur le ressourcesÀ cause du coût, de l’énergie, de l’espace
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 7 / 42
Caractéristiques
Il y a des différences entre le développement logiciel traditionnel, et ledéveloppement d’un système embarqué
Le développement logiciel traditionnelil se concentre sur la fonctionnalitéil oublié complètement le matérielexemple : développement d’un logiciel webil est best effort, le temps n’est pas important
Le développement des systèmes embarquésil comprend le choix du matérielil doit tenir en compte l’interaction avec l’environnement (contraintes tempsréel)il doit tenir en compte les autres contraintes non-fonctionnelles(fault-tolerance, energy, etc.)
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 8 / 42
Les systèmes temps réel
En informatique temps réel, le comportement correct d’un système
dépend, non seulement des résultats logiques des traitements, mais
aussi du temps auquel les résultats sont produits
{John Stankovic. « Misconceptions about real-time computing ». IEEE Computer,
October 1988}
Système prédictible : on cherche à déterminer a priori si le système varépondre aux exigences temporelles.
Un système temps réel n’est pas un système "qui va vite" mais unsystème qui satisfait à des contraintes temporelles
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 9 / 42
Modèle
Un modèle est une représentation abstrait d’un système qui nous
permit de répondre à des questions sur le système.
Les modèles sont utiles quand on a des systèmes trop grands, ou
trop petits, ou trop compliqués, ou qui n’existe plus, ou à construire
de : "Object Oriented Software Engineering, using UML Patterns and Java", Bernd Bruegge, Allen H. Dutoit
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 11 / 42
Pourquoi un modèle du système ?
La modélisation est un activités fondamental dans le Science, et il estpartie du méthode scientifique
Faire un modèle abstrait d’un système réel est utile pourétudier les lois à la base du phénomène en essayant sur letester des hypothèses sur le modèle
Faire un modèle d’un système imaginaire est aussi très utile :il s’agit d’essayer le fonctionnement du système avant de le construireon peut prévoir le résultat finale en analysant le modèleon peut facilement changer des choses qui ne vont pas
L’abstraction permet d’ignorer les détails non essentiels
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 12 / 42
Abstraction
Deux définitions :
L’abstraction est un processus de pensée dans lequel l’idée s’éloigne desobjets
Abstraction comme activité
L’abstraction est l’idée résultant d’un processus de pensée dans lequell’idée s’est éloignée d’un objet
Abstraction en tant qu’entité
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 13 / 42
Modèles dans l’ancienneté
Competition between architects was an old and honoured custom. Patrons
had been making architects compete against another for their commissions
since at least 448 B.C. [. . . ] Under these circumstances, it was normal
practice for architects to produce models as a means of convincing patrons
or panel judges of the virtues of their particular design.
{From Brunelleschi’s Dome : how a renaissance genius reinvented architecture, by Ross King}
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 14 / 42
Modèles dans l’ancienneté
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 15 / 42
Comment construire un modèle ?
Un modèle n’est pas une petite copie exact du système finale
Normalement, beaucoup de détails sont caché (Abstraction)Si le système finale est très compliqué, il faut d’abord construire un modèleplus simple qui capture que les aspects d’intérêtÀ fur et à mesure que on progressait dans la compréhension du modèle,on peut ajouter de détails (Raffinement)
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 16 / 42
Un seul modèle, ou plusieurs ?
On peut penser de construire plusieurs modèles pour un système
à différentes niveau d’abstraction et de complexitépar exemple, un boiler pour réchauffer l’eau peut être représente par unsimple finite state machine (on/off) ou par un ensemble d’équationsdifférentiels
ou, chaque modèle peut décrire un aspect diffèrent du systèmeDans un avion, un modèle décris le sub-système de guide, un autremodèle décrit le système Audio/Vidéo de divertissement
Dans le deuxième cas, il s’agit de deux sous-systèmes différentes etindépendantes, donc il peut être utile de séparer les deux modèles
sauf que on peux avoir de l’interférence électromagnétique entre le deuxsystèmes. . .
Dans le premier cas, il s’agit de deux descriptions du même système, ilest nécessaire garantir que il sont consistent
comme règle général, il est mieux d’avoir un seul modèle pour un mêmesystème, et appliquer de transformations pour raffiner/abstraire le modèle
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 17 / 42
Méthodologie de conception et développement d’un logiciel
The V-model
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 18 / 42
Le V-Model
Le V-Model est une méthodologie de conception et de développementd’un système
les phasesUser RequirementsFunctional SpecificationFunctional ModelingArchitecture ExplorationComponent ModelingBehaviour ModelingCodingModule TestingIntegration TestingSystem VerificationValidation
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 19 / 42
Le V-Model
Il s’agit d’un méthodologie à cascade ou il y à un correspondance entreles premières phases et les dernières
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 20 / 42
Modèle
À chaque phase, il faut construire un modèle qui décrit le système finale
Le premier modèle (User Requirements) doit forcement être très abstrait
À fur et a mesure qu’on progresse dans le phases, le modèle devient plusconcret (raffinement)
Le logiciel finale qui nous allons développer peut être considéré aussicomme un modèle très détaillé de notre système
il s’agit de une abstraction exécutable
Donc la méthodologie de développement peut être considéré comme unetransformation entre modèles
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 21 / 42
Model-based design
Quatre concepts importantes
Test and Verification,Simulation, Validation
Automatic code generation,porquoi ?
Le langage est très important
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 22 / 42
UML (Unified Modeling Language)
Modeling language for Object Oriented Design
Convergence of notations used in object-oriented methodsOMT (James Rumbaugh and collegues)Booch (Grady Booch)OOSE (Ivar Jacobson)Current Version : UML 2.5Information at the OMG portal http://www.uml.org/
Commercial tools : Rational – RSA (IBM),Together (Borland), VisualArchitect (business processes, BCD)
Open Source tools : ArgoUML, Omondo, Papyrus
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 24 / 42
UML diagrams
Use case diagramsDescribe the functional behavior of the system as seen by the user
Class diagramsDescribe the static structure of the system : Objects, attributes,associations
Sequence diagramsDescribe the dynamic behavior between objects of the system
Statechart diagramsDescribe the dynamic behavior of an individual object
Activity diagramsDescribe the dynamic behavior of a system, in particular the workflow.
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 25 / 42
Class diagrams
Class diagrams represent the structure of the system
Classes represent types of objects, linked by relationships
Probably the most important UML diagram
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 27 / 42
Class diagrams
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 28 / 42
Sequence diagrams
Sequence diagrams represent the behavior of a system as messages(“interactions”) between different objects
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 29 / 42
Activity Diagrams
Represent an interesting behavior of the system
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 30 / 42
Other diagrams
UML 2 has many other diagramsStructural : Profile diagrams, Deployment diagrams, Package diagrams, . . .Behavioral : Timing diagram, Interaction Overview diagram, . . .UML 2 is also extensible, thanks to profiles
it is possible to describe the semantic of new concepts and diagrams directlyin UML 2 using the concept of stereotypes
Therefore, UML can be used as a Domain Specific Language (DSL)
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 32 / 42
UML profiles
In a profile, it is possible to define stereotypesa stereotype is a new concept that can later be applied to elements of UML
Example :Suppose you want to create a special type of class that represents activethreads ;it is like a regular class, but it always contains a property called active oftype booleanthen, we define a stereotype ActiveClass that extends the metaclassClass of UML2, and contains a boolean property called activeLater, users of this profile can label some of their UML classes with thestereotype ActiveClass.
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 33 / 42
UML profiles
To create your own profile is useful if you need to specialise some of theUML concept for your own domain, giving them a more precise semantic
In particular, instead of having only the generic concept of class torepresent everything, we can define the concept of OS, Thread,Semaphore, etc. for the domain of real-time programming
Somebody has already worked in this direction, and proposed MARTE
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 34 / 42
MARTE
MARTE = UML profile for Modeling and Analysis of Real-Time and Embeddedsystems
The goal is to be able to design and analyse real-time systems
It introduces the concepts of time, clock, thread, service, priority etc. thatallow to model the platform specific aspect of a software
It is now implemented in Eclipe Papyrus (but no analysis tool)
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 35 / 42
SysML
SysML was born as a separate language to describe both software aswell as the hardware and the physical environment
Later there has been a convergence among SysML and UML, howeversome of the concept of SysML are not part of UML2
Therefore, strictly speaking, SysML is not a profile of UML
however, some modeling tool treatSysML as a separate language
some tool, like Papyrus, treatSysML as an extension of UML2
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 36 / 42
V-model
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 38 / 42
Réquisits
Explique le problème, pas la solution
D’accord avec les clients
Écrit en langage naturel (français, anglais)
Malheureusement, le langage naturel est imprécis
Il faudra être plus précis en utilisant des langages formellesFSM, Z language, LTL, CTL . . .
Quand on passe du langage naturel à un langage formel, on est dans laphase de Specification
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 39 / 42
Analyse des réquisits
On peut utiliser plusieurs techniques pour guider la collecte et l’analysede réquisits, et pour organiser les réquisits
Les objectives sontClartéIntégralité et exhaustivitéPas d’ambiguïté, pas d’inconsistance, pas de redondance
On peut partir de :les états du systèmele modèle des donnée gérées par le systèmeles cas d’utilisation du système et les acteursles activités du système, ou ses réactions, ou les événements typiqueetc.
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 40 / 42
Analyse des réquisits II
Des besoins en conflit :il faut communiquer avec des personnes qui ne sont pas des techniciens,utilisant le langage naturelil faut être précis dans la spécification du système pour éviter desambiguïtés et des inconsistances
Les réquisits peuvent changer pendant le développement du systèmeraffinement par itération
Les document des réquisits est un document toujours vivante, pendanttoute la durée du projet
Giuseppe Lipari (LIFL - Université de Lille 1) Modélisation des Systèmes Émbarques 4 octobre 2015 41 / 42