Figure 4.3. Les diagrammes de SysML [SysML2007]
En SysML, seul le diagramme de séquences est retenu parmi les diagrammes d’interactions ; les diagrammes de timing, de collaborations et de vue globale d'interactions (Interactions overview) qui sont définis dans UML2 sont exclus.
Le diagramme des exigences est la principale extension apportée par SysML (figure 4.4), il est défini en tant qu’extension du diagramme de classes. Il permet d’analyser les exigences en gardant une trace des réflexions des ingénieurs. Il permet de structurer les besoins fonctionnels et non fonctionnels. Il définit de nouveaux stéréotypes décrits dans le tableau 4.1.
Tableau 4.1. Stéréotypes utilisables dans un diagramme des exigences.
<<requirement>> Est une extension abstraite de "Classe" affichant deux
méta-propriétés spécifiques. La méta-propriété "id" est destinée à la numérotation hiérarchisée des besoins. "text" permet de décrire le texte du besoin.
<<deriveReqt>> permet d'expliciter un besoin qui était implicite dans un besoin de
niveau hiérarchique supérieur de la décomposition
<<Verify>> permet de lier des jeux de test à un besoin
<<copy>> permet la réutilisation d'un besoin dans un autre diagramme de besoins
<<satisfy>> est une sous-classe du stéréotype <<realization>> qui permet de dire qu'un ensemble d'éléments implémentent un ensemble de besoins
Une deuxième extension importante est le Block qui est défini en tant que stéréotype de la classe définie dans UML2 dans le package StructuredClasses
[UML2007] (figure 4.5). Cette classe étend la classe UML2 en y ajoutant la possibilité
d’avoir une structure interne et des ports. Un Block est une unité modulaire. Il peut contenir des éléments structurels et comportementaux.
Figure 4.5. Le stéréotype de classe : <<Block>> [SysML2007]
Le diagramme de définition de blocks est basé sur le diagramme des classes d'UML2. Il permet de décrire des relations de composition, des agrégations, des dépendances, des généralisations de blocks.
Le diagramme des blocks internes est aussi une extension apportée par SysML. Il est basé sur le diagramme des structures composites d’UML2 [UML2007] (figure 4.6). Il décrit des structures internes de blocks par des interconnexions de blocks ou des parties de blocks (<<parts>>) à travers des ports. Des connexions peuvent être reliées directement à des propriétés internes d'un block sans passer par un port. Le diagramme IBD permet de décomposer le système, de représenter les composants (physiques ou logiques) et les interfaces qui les lient (figure 4.6). Il est utilisé pour représenter les flux d’information et les flux continus ou discrets entre les composants.
Figure 4.6. Diagramme IBD [SysML2007].
Le diagramme des contraintes paramétriques est un nouveau type de diagrammes qui est une extension au diagramme de blocks internes. Ainsi dans un diagramme paramétrique un block sera stéréotypé <<ConstraintBlock>> et une propriété de block sera stéréotypée <<ConstraintProperty>> (figure 4.7). Il permet de spécifier des grandeurs physiques. Il est utilisé pour décrire :
• Des caractéristiques quantitatives d’un système.
• Des expressions mathématiques (F=m*a..) reliant des propriétés physiques du système (figure 4.15).
• Des performances critiques.
Figure 4.7. Diagramme des contraintes paramétriques [SysML2007].
Quant au diagramme des activités, dans SysML le support des modèles markoviens est introduit en permettant l'affectation d'une distribution de probabilités des transitions entre actions. Dans UML2 on peut dire que le paramètre d'une activité peut se répéter pendant l'exécution de l'activité (propriété {isStream}), en SysML on peut définir en plus de cela la fréquence de cette répétition ({Rate}) et si ce flux est continu ou discret. Il permet de décrire :
• Représenter la dynamique des sous-systèmes similaires aux EFFBD15.
• Entrées/sorties, séquencement, coordination.
• Flux physiques, continus, activités interruptibles.
• Permet l’expression des distributions probabilistes.
D’autres éléments inter-diagrammes sont introduits par SysML. La notation d'appel externe (callout notation) est un mécanisme fourni dans SysML pour décrire des relations entre éléments appartenant à différents diagrammes. On peut ainsi rappeler une machine d'états en vue par exemple de l’allouer à un block défini dans un diagramme de blocks internes IBD.
Le commentaire <<rationale>> peut être utilisé pour illustrer le raisonnement qui a conduit à un choix donné. Cette extension n'est réalisable que si des modifications sont apportées au méta-modèle UML2. En effet "comment" ne peut pas être stéréotypé en UML2. Le commentaire <<Problem>> peut être attaché à n'importe
quel élément du modèle SysML pour décrire une limitation détectée par le concepteur. <<View>> et <<Viewpoint>> sont introduites pour décrire des perspectives particulières d'un système. Nous pouvons ainsi définir les points de vue que nous jugeons utiles tels que les points de vue de la qualité de service, de la performance, de l'ergonomie etc.
SysML propose aussi le mécanisme d’allocation. Contrairement au profile MARTE [MARTE2007] qui limite l’utilisation de l’allocation ; l’allocation d’un élément applicatif à un autre de la plateforme, SysML permet d’allouer n’importe quel sous-ensemble d’éléments à n’importe quel autre sous-ensemble d’éléments
[Gérard2007]. Mickael Latta [LattaHomepage], qui est un des reviewers de SysML,
critique vivement cette approche de SysML en disant que les ingénieurs du logiciel affectent dés le début de la conception les comportements aux structures statiques, ils créent des classes dans lesquelles ils créent des propriétés et des méthodes, plus tard dans la conception ils font du « refactoring » pour modifier ces classes. Par contre, les ingénieurs système séparent les structures des comportements puis allouent ces derniers aux structures. SysML permet de décrire cette allocation de manière à documenter une décision de conception qui pourra être détaillée plus tard, Latta critique alors cette approche en ajoutant qu’au-delà de la documentation, les allocations devraient être en plus des éléments de conception sémantiquement actifs et que l’allocation d’un comportement à une structure doit être équivalente à l’implémentation d’une méthode pour une classe ; ce qui est le cas avec les allocations dans MARTE.