le profil UML en temps réel MARTE

1

le profil UML en temps réel MARTE

Élaboré par :NASRI Ines

RAHMANI Hajer SBOUI Samer

1

Encadré par :Mr BEN STA

Hatem

PlanIntroductionDomaine d’applicationStéréotypes

Tagged values

Contraintes

Conclusion2

Introduction3

IntroductionDomaine d’applicationStéréotypesTagged valuecontraintes Conclusion

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 values et des contraintes.

4

IntroductionQu’est ce qu'un profile UML?Qu’est ce qu’un système embarqué?Définition Profile MARTE


5

UMl

Real time EJB CORBA SQL …….

IntroductionQu'est ce qu'un profile UML?Qu’est ce qu’un système embarqué?Définition Profile MARTE

Figure 1 : Standardisation des différents domaines sous forme de profiles UML


6

• Un système embarqué peut être défini comme un système électronique et informatique autonome, qui est dédié à une tâche bien précise.

• Les systèmes embarqués font très souvent appel à l‘informatique, et notamment aux systèmes temps réel.

• Le terme de système embarqué désigne aussi bien le matériel que le logiciel utilisé.



7


Caractéristiques des systèmes embarqués

Doit répondre à des contraintes real-time

Représentent des systèmes réactifs


Le profil UML pour MARTE(MODELING AND

ANALYSIS OF REAL-TIME AND EMBEDDED SYSTEMS )a pour objectif d’étendre UML pour l’utiliser dans une approche de développement dirigé par les modèles de systèmes temps réel et embarqués.

MARTE fournit des supports pour les étapes de spécification, de conception et de vérification /validation .

8


Définition

Domaine d’application

9


10

avions automobile


11

Les applications multimédia audio, photo, vidéo

Stéréotypes12


StéréotypesAjout 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.Les stéréotypes ne peuvent être utilisés que

conformément à leur définition

13

Introduction Domaine d’application StéréotypesTagged valuecontraintes Conclusion

StéréotypesExemples :

<<interface>>, <<entity beans>>, <<ApplicationComponent>>

Tout concept UML (Classe, Attribut, Association, Use Case, Component, Part…) peut être stéréotypé

14


15

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.


16

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 .


17

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.

18

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.

IntroductionDomaine d’application StéréotypesTagged valuecontraintes Conclusion


19

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.


20

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.

21

VehiculeSystemSpecification

VehiculeAcceleration1 «requirement»

id=102text=System shall...

R1111 «requirement»

id=111text=System shall...

«trace»

«trace»

Le système doit accélérer de 0-60mph dans moins de 8 secondes sous les conditions spécifiées.

PowerSubsystemSpecification



«derive»

VehiculeSystemUseCases

ConduireVehicule

Driver

«trace»

VehiculeSystemDesign

Vehicule«system»

«satisfy»

Frein«assembly»

PowerTrain«assembly»

PowerSubsystemDesign

Engine

p1

«satisfy»

«flow»

Transmission

p2«flow»«flow»

Diagramme des exigences de "Vehicul system Requirements Flowdown"

Déclaration du travail«rationale»

EngineHorsepowerT est«testCase»

«verify»

BesoinduMarché1 «document»

L'analyse de l'échange«rationale»

Tagged values22


Tagged valueLes valeurs marquées sont principalement

utilisées pour ajouter des informations sur les classes. En fait c’une annotation des éléments de modélisation

Une tagged value peut être vue comme un nouvel méta-attribut.

23


Tagged valuePeuvent être définies pour des éléments

existants ou des stéréotypesVirtualisées sous la forme : nom de la propriété,

valeurExemples

{virtual}, {primary key}Il est possible d’associer des tagged values à tout

concept UML (Classe, Attribut, Association, Use Case, Component, Part…)

24

Contraintes25


ContraintesLes contraintes sont utilisées pour exprimer les

relations entre les stéréotypes et les tagged values.

Les contraintes servent à étendre la sémantique d’UML par l’ajout de nouvelles règles ou la modification de règles existantes

26


ContraintesLes contraintes permettent de préciser les

conditions d’emploi des éléments du modèle.Préciser les conditions d’emploi des éléments

du modèlePeuvent être représentées en utilisant soit le

langage naturel, soit OCL (Object Constraint Language)

27


28

currentTime( ): Real

resolution: Real {readOnly}

« clockType »{ nature = discrete, unitType = TimeUnitKind,resolAttr=resolution, getTime = currentTime }

Chronometric

currentTime( ): Real

« clockType »{ nature = dense, unitType = TimeUnitKind,

getTime = currentTime }IdealClock

resolution = 0.01

« clock »{ unit = s, standard = UTC }

cc1:Chronometric

resolution = 0.01

« clock »{ unit = s, standard = UTC }

cc2:Chronometric

« clock »{ unit = s }

idealClk:IdealClock

« timedDomain »ApplicationTimeDomain

« clockConstraint » { kind = required }{ Clock c is idealClk discretizedBy 0.001; cc1 isPeriodicOn c period 10; cc2 isPeriodicOn c period 10; cc1 hasStability 1E-5; cc2 hasStability 1E-5; cc1,cc2 haveOffset [0..5] ms wrt idealClk;}

Figure3 :exmple du domaine du temps avec clockconstraint


29

RTEA (Real-Time & Embedded Analysis)

MARTE Foundations

Generic Quantitative Analysis

Schedulability Performance

RTEM (Real-Time and Embedded Design)

« import »

« import »

« import »

TimeNFP

Components AllocationResources

« import »

« import »

« import »

« import »« import »

MoCC

HW Resources

SWResources

« import »

Figue 4 : DOMAINE DU MODELE UML MARTE détaillé

Conclusion30


31

L’implémentation d’un profile UML2 dédié aux systèmes embarqués permet de:

– Guider Contrôler le développement des

modèles Automatiser

Assure :

– Amélioration de la maîtrise de développement d’un produit


32

Offre:

– Gain en qualité, sûreté et en fiabilité des produits issus d’un tel développement

Merci pour votre attention

33

Documents

le profil UML en temps réel MARTE