3.4 Intégration à UML des mécanismes d’extension proposés.
4.3 Intégration de l’association role.
4.3.5 Intégration de la machine à états par l’usage du mécanisme de virtualité.
La technique utilisée pour intégrer la machine à état dans UML est la virtualité d’une machine à état transition .Ceci signifie que son comportement peut être redéfinie par une autre machine de raffinement associée à un produit particulier.
C’est l’une des techniques utilisées pour paramétrer une machine à états en vue de l’appliquer non pour un état généraliste mais pour un état spécifique. Pour notre cas cet état est une classe « role ». On peut aussi utiliser cette technique pendant la dérivation de produit ou le comportement de la machine virtuelle sera remplacé par le comportement de la machine à états de raffinement associée au produit.
La virtualité est introduite par le stéréotype <<virtual>> et le tagged value virtualPart qui indique l’occurrence de la machine virtuelle.
VirtualPart pour notre cas, représente une partie du diagramme de classes qui exprime
la variabilité. Le diagramme de classes est divisé en plusieurs partitions virtuelles au nombre de points de variation et d’optionalité existants. Chaque partie peut renfermer soit une classe variation avec ses sous-classes variantes (roles) soit une classe optionnelle. Les partitions sont nommées partition du diagramme de classes numéro i (DC1, DC2…). Prenons l’exemple de la partition DC4 dans la figure 5.4 du chapitre 5.
La Figure 4.8 montre un exemple d’une machine à états qui référencie une machine virtuelle DC pour la partition DC4 du système surveillance du moteur.
« virtual » Virtualpart=DC
DC4
Rolei Rolej
Un modèle logique pour les architectures logicielles dans l’embarqué Contributions – Expression de la variabilité par les roles.
Présenté en vue de l’obtention du diplôme de magister en informatique industrielle-concepts avancés- Par Djebar Yacine
71
4.4 Vers un Profil UML :
UML introduit la notion de profil UML pour regrouper un ensemble de stéréotypes, de tagged values et de contraintes.
La Figure 4.9 montre un exemple de définition de deux stéréotypes [17] : Clock et Creator. Le stéréotype Clock étend les deux méta-classes Class et Component et il définit
une propriété résolution comme un tagged value dont le type est integer. Le lien d’extension est noté par une flèche orientée (cf. Figure 4.9). Cette figure montre un exemple du profil UML appelé Example regroupant les deux stéréotypes Clock et Creator.
Les profils dans UML2.0 sont notés comme des paquetages UML avec le stéréotype <<profile>>. Le paquetage UserExample est un exemple de modèle utilisateur basé sur le profil Example. La classe StopWatch est définie avec les deux stéréotypes de profil. Les tagged values associées aux stéréotypes sont définis comme des notes UML (cf. Figure 4.9).
Dans le chapitre 3 et les sections précédentes de ce chapitre, nous avons proposé cinq mécanismes pour la spécification de la variabilité dans les diagrammes de classes (3 nouveaux stéréotypes, une nouvelle association et une machine à état virtuelle).
Dans ce qui suit, nous allons regrouper ces extensions sous forme d’un profil UML pour modéliser la variabilité dans les LdP. La Figure 4.10 montre la structure de ce profil.
Nous suivons la notation des profils dans UML2.1 ;
- Une méta-classe est présentée comme une classe stéréotypée <<metaclass>> - Un stéréotype est présenté comme une classe stéréotypée <<stereotype>>.
Ces extensions sont regroupées dans le paquetage que nous avons désigné par « software Product Line » de la figure 4.10.
« metaclass » component « stereotype Creator Autthor : string Date : string « stereotype Clock Resolution :integer « metaclass » Class « clock » Resolution =2 « cretor » Author = ‘jones Date = 02-04-15 « clock , creator » stopWatch « apply »
Fig 4.9 Exemple de spécification d’un profil UML et son utilisation
« Profile » Example
4 .5 Conclusion.
Nous avons proposé dans ce chapitre, une gestion de l’évolution de la variabilité à travers celle des variant-roles par l’usage de machines à état-transitions. Pour cela nous avons introduit une nouvelle association désignée « role » qui lie les variant-roles modélisés sous
forme de classes aux classes variables dans le diagramme de classes.
Les variants sont perçus dans le diagramme de classes comme des roles pouvant être joués par les classes représentant des points de variation. Ces dernières peuvent jouer un seul role parmi plusieurs ou plusieurs roles en même temps. De nouveaux roles peuvent être joués et donc ils seront ajoutés aux classes role liées à cette classe variable. De plus, l’évolution des
roles exprime celle de la variabilité au niveau des points de variation. Ce modèle à l’aide d’un autre diagramme UML, les machines à état-transitions, offrira des facilités au concepteur pour la gestion de l’évolution de la variabilité des LdPs.
Fig 4.10 Le Profil software P.L
« metaclass » classifier « metaclass » feature « metaclass » modelelement « Metaclass » relationship « metaclass » datatype « stereotype » individual « stereotype » collective « Stéréotype » optional accessory « association » role « metaclass » behavior « metaclass » statemachine « metaclass » state « metaclass » transition
« Profile » software product line
« metaclass »
Virtual
Virtualpart :string
« metaclass » package
Un modèle logique pour les architectures logicielles dans l’embarqué Contributions - Application des 3 contributions au système automobile
Présenté en vue de l’obtention du diplôme de magister en informatique industrielle-concepts avancés- Par Djebar Yacine
73
Deuxième partie
Contributions
Chapitre 5.
A
pplication
au système automobile.
74
5-1- Introduction.
Le domaine de l’automobile est très représentatif de la situation dans laquelle les systèmes embarqués se développent. Il comprend de très riches fonctionnalités tant complexes que diversifiées. C’est là où les systèmes embarqués sont les plus nombreux. C’est un domaine où
de nouvelles fonctions du véhicule sont de plus en plus basées et contrôlées sur/par le logiciel [73]. Cet état de fait nous a motivés pour prendre le sous-système moteur/feux antibrouillard qui fait partie du système automobile comme exemple applicatif de notre solution pour la
modélisation de la variabilité d’une LdP .Le diagramme de features correspondant est représenté dans la figure 5.1.
5-2- Application des solutions apportées par notre modèle.
Notre approche utilise comme point de départ les points variables (point de variation et optionnels) comme représentés dans le diagramme de classes de la figure 5.2.
A u t o m o b i l e C l i m a t i s a t i o n F e u x anti-brouillard Alternatives Optional - strict Mandatory Optional- accessory
Système de contrôle du moteur requires M o t e u r
F i g 5.1 U n e p a r t i e d u d i a g r a m m e d e f e a t u r e s p o u r l e s y s t è m e a u t o m o b i le
Fig. 5.2- Modèle logique système automobile Automobile
Système ctrl moteur
« variant »
Moteur
« variant »
Feux anti brouillard
« optional accessory»
Climatisation
« optional strict»
Un modèle logique pour les architectures logicielles dans l’embarqué Contributions - Application des 3 contributions au système automobile
Présenté en vue de l’obtention du diplôme de magister en informatique industrielle-concepts avancés- Par Djebar Yacine
75
5.2.1 Pour l’optionalité.
L’exemple de la classe « feux antibrouillard » –cf fig 5.2- convient pour démontrer l’utilité de ce mécanisme .En effet , cette classe représente une classe variable de type « optionnel
accessoire ». Un point d’extension est prévu pour ce type de feux. L’endroit prévu se situe
généralement sous le pare-choc avant du véhicule .Tous les attributs et toutes les méthodes de cette classe accessoire prennent automatiquement le type optionnel et sont représentés dans la classe par le stéréotype « optional » -selon le mapping du tableau 3.2 du chapitre 3.
La climatisation par contre est un exemple d’une feature optionnelle stricte.