UML2.0 Profile pour la conception des systèmes embarqués

1. UML2.0 Profile pour la conception des systèmes embarqués Réalisé par: Naoui Jihène & Daknou Amani

2. PLAN • Introduction • Les profiles • Les systèmes embarqués • Implémentation d’un profile pour les systèmes embarqués • Conclusions

3. Introduction • What Engineers Do • Before they build the real thing...

4. …they first build models…and then learn from them 

5. PROFILE UML

6. MOF M3 UML CWM M2 Profile Model Profile model M1 M0 Run time model The place of Profile in 4 levels

7. Définition • Un profile UML est une spécialisation du modèle UML pour un domaine d’utilisation particulier. • Il regroupe de manière cohérente les extensions du modèle UML. • Un profile est composé de stéréotypes, de tagged value et de contraintes

8. Stéréotypes • Ajout de nouveaux éléments de modélisation dans le contexte métier ou technique. • Une classe stéréotypée porte la sémantique du stéréotype.

9. Tagged Value • Les valeurs marquées sont principalement utilisées pour ajouter des informations sur les classes. • Une tagged value peut être vue comme un nouvel méta-attribut.

10. Contraintes • Les contraintes sont utilisées pour exprimer les relations entre les stéréotypes et les tagged value. • Les contraintes servent à exprimer la sémantique du profile. • Les contraintes permettent de préciser les conditions d’emploi des éléments du modèle.

11. Profile • Il est possible de stéréotyper ou d’associer des tagged values ou des contraintes à tout concept UML (Classe, Attribut, Association, Use Case) • Les profiles UML peuvent hériter d’autres profiles, avoir des dépendances entre eux, ou encore être regroupés.

12. Profile • Il existe plusieurs profiles standards tels que • « EDOC » (Enterprise distributed object computing » • UML pour CORBA • UML pour le temps réel • UML pour les EJB . =>Chacun de ces standards est en fait un profile UML spécifique d’un domaine d’application ou d’un environnement technique.

13. Profile • Un profile doit contenir: • des mécanismes d’extension (ajouts ou spécialisations) • des descriptions sémantiques du profile. • des notations supplémentaires. • des règles de transformation, de validation ou de présentation.

14. Règles d'implémentation Expert Informaticien Transformation de modèle - Profile UML Modélisation de l'implémentation Expert du domaine Modélisation du problème Codage des production

15. Les systèmes embarqués

16. Définition • En général • Utilise de manière conjointe du matériel et du logiciel pour mettre en oeuvre une fonction spécifique • Le logiciel est utilisé pour plus de flexibilité • Le matériel (processeur, ASIC, DSP, mémoire) est utilisé pour plus de performances

17. Caractéristiques • Doit être sûr • Fiabilité R(t) = probabilité pour que le système fonctionne correctement si c’était satisfait à t=0 • Maintenabilité M(d) = probabilité pour que le système fonctionne correctement d unités de temps après une erreur • Disponibilité: probabilité pour qu’il fonctionne à l’instant t • Sûreté: aucun dommage • Sécurité: confidentialité et authenticité des communications • Doit être efficace • Energie • Taille du Code • Run-time • Poids • Coût

18. Caractéristiques • Dédié à certaines applications • User interfacedédiée(pas de sourie, clavier , écran…)

19. Caractéristiques • Doit répondre à des contraintes real-time • Représentent des systèmes réactifs

20. Domaines d’application • Transports • La recherche de la performance • systèmes de contrôle. • La sécurité

21. Domaines d’application • avions

22. Domaines d’application • automobile:

23. Domaines d’application • Les télécommunicationet l’éléctroniqueGrand public • Le coût unitaire • La consommation d’énergie et la dissipation de chaleur • L’évolutivité • La disponibilité • Les performances

24. Domaines d’application • Les applications multimédia audio, photo, vidéo

25. Domaines d’application • Système de la télématique pour les Automobiles

26. Profils dédiés aux systèmes embarqués • SPT : Scheduling, Performance and Time profil pour UML 1.x http://www.uml.org/ • SysML : UML for Systems Engineering RFP en cours de définition pour UML 2.0 http://www.sysml.org/

27. Profils dédiés aux systèmes embarqués • UML for SoC • proposition d’un consortium japonais • concepts très proches de SystemC • RFC en cours d’évaluation • MARTE : UML Profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE) RFP

28. La création d’un profile pour la conception des systèmes embarqués

29. Définition du profil Lesmécanismes fondamentaux de l'extension

30. Définition d’un profil UML Système e.g.: Mr Dupont Mr Dupont « conducteur » ? e.g.: Train Circuit Control • Objectif • Un profil peut contenir… • les éléments sélectionnés du méta modèle référence, • des mécanismes d’extension (ajouts ou spécialisations), • des descriptions sémantiques du profil, • des notations supplémentaires, • des règles de transformation, de validation ou de présentation. Spécialiser un méta modèle standard (comme UML) servant de référence en un méta modèle spécifique dédié à un domaine d’application particulier. Méta classes fondamentales sur lesquelles repose le profil Stéréotypes, tagged values et contraintes introduits dans le profil « Semantics Variation Points » et ambiguïtés sémantiques de UML

31. Les mécanismes fondamentaux de l'extension • Les stéréotypes UML • Les extensions des diagrammes UML

32. Les extensions des diagramme UML UseCaseDiagram DiagramKind <<stereotype>> ContextDiagram <<stereotype>> DiagramUsage

33. Diagramme du Concept pour le « Contexte Opérationnel du Système du Véhicule »

34. Diagramme de Use Case pour « Conduire Véhicule »

35. Les diagrammes paramétriques

36. Modèles d'analyse qui définissent un ensemble de propriétés du système et modélisent les rapports paramétriques entre eux. • Utilisés pour exprimer des relations entre des propriétés quantifiables.

37. Le diagramme paramétrique distingue les contraintes paramétriques d'autres parties du modèle. • Les propriétés de ces parties sont connectées par des relations paramétriques • La relation paramétrique peut être utilisée pour supporter l’évaluation d'alternatives (analyse de l'échange).

38. Les contraintes paramétriques • Les contraintes paramétriques représentent un réseau de contraintes entre les propriétés d'un système. • utilisées pour identifier la performance critique des paramètres « Critical performance parameters » et leurs rapports avec d'autres paramètres qui peuvent être traqués partout dans le cycle de la vie du système.

39. Parametric Constraint

41. Diagramme des Requirements

42. Stéréotype Requirement • présente une capacité ou une condition qu'un système doit satisfaire. • permet de spécifier une fonction qu'un système doit exécuter ou une condition de la performance qu'un système doit satisfaire. => « Requirements »sont utilisées pour établir un contrat entre le client (ou autre stakeholder) et les responsables de la conception et de l'implémentation du système.

43. Stéréotype Trace • définit une relation entre les éléments du modèle ou ensembles des éléments du modèle qui représentent le même concept. • les traces sont utilisées essentiellement pour traquer des exigences et des changements au sein des modèles .

44. Stéréotype Derive • Définit une relation de dépendance entre deux requirements où le requirement du client peut être produit ou peut être inféré des requirements du fournisseur ou à partir d'information supplémentaire du design. • Les requirements dérivés peuvent raffiner ou répéter un requirement pour améliorer les communications du stakeholder ou traquer l'évolution du design.

45. Stéréotype Rationale • Définit un élément qui documente les principes ou raisons pour une décision de modélisation, tel qu'un choix de l'analyse ou une sélection du design. • Il peut être attaché à tout élément du modèle.

46. StéréotypeSatisfy • Définit un rapport de dépendance entre un requirement et un élément de modèle qui accomplit le requirement.

47. Stéréotype Verify • Définit un rapport entre un requirement et un «test case» qui peut déterminer si un système accomplit l'exigence.

48. Stéréotype TestCase • Définit un processus ou une activité qui est utilisé(e) pour déterminer si un système a accompli ses exigences.

50. Démo