urbanisation-si.com

30/01/2016

0 J'aime 0 Poster un commentaire

SysML : Décomposition des exigences avec le diagramme de requirement SysML - Les spécifications du HSUV (tutorial SysML partie 8)

sysml-tutoriel-tutorial-didacticiel-requirement-diagram-HSUV-78.png

Exemple montrant la hiérarchisation des exigences du HSUV.

Les spécifications textuelles du HSUV sont complexes. Elles doivent répondre par exemple au passage des tests antipollution.

Cet exemple montre la gestion de cette complexité, en décomposant les macros exigences en exigences élémentaires plus simples.

sysml-tutoriel-tutorial-didacticiel-requirement-derivation-diagram-HSUV-79.png

Exemple d'exigences dérivées en utilisant les dépendances stéréotypées <<deriveReqt>> ainsi que les commentaires stéréotypés <<problem>> et <<rationale>> (le concept découle d'un raisonnement logique/mathématique).

sysml-tutoriel-tutorial-didacticiel-requirement-refinement-diagram-HSUV-80.png

Diagramme de "requirement" montrant l'ensemble des relations avec l'exigence "Acceleration" :

le use case "Accelerate" (Accélérer) explicite cette exigence
l'exigence "Power" (Puissance) dérive de cette exigence et est satisfaite par le bloc "PowerSubsystem" (Sous Système de Puissance)
le cas de test "MaxAccelaration" vérifie cette exigence

Pour les éléments de modélisation et d'autres exemples voir les articles déjà parus :

Rhona Maxwel

@rhona_helena

"Une seule chose est nécessaire : la solitude. La grande solitude intérieure. Aller en soi-même, et ne rencontrer durant des heures personne, c'est à cela qu'il faut parvenir."
Rainer Maria Rilke

Voir aussi :

28/01/2016

0 J'aime 0 Poster un commentaire

SysML : Décrire le comportement du système avec les diagrammes de séquence et d'état - Le diagramme de séquence boite noire du HSUV (tutorial SysML partie 7)

sysml-tutoriel-tutorial-didacticiel-sequence-diagram-HSUV-BoiteNoire-76.png

Le diagramme de séquence "boite noire" pour l'interaction "Démarrer le véhicule" (StartVehicule) faisant référence au diagramme de séquence "boite blanche" (StartVehiculeWhiteBox).

sysml-tutoriel-tutorial-didacticiel-sequence-diagram-HSUV-BoiteBlanche-77.png

Le diagramme de séquence "boite blanche" pour l'interaction "Démarrer le véhicule" (StartVehicule).

Pour ce diagramme on utilise la décomposition du bloc "Power System" en partie "PowerControlUnit" et "ElectricalPowerController".

Pour les détails de syntaxe sur le diagramme de séquence, voir les articles :

Rhona Maxwel

@rhona_helena

"Nul bonheur, nulle sérénité, nulle espérance, nulle fierté, nulle jouissance de l'instant présent ne pourrait exister sans faculté d'oubli."
Friedrich Wilhelm Nietzsche

Voir aussi :

26/01/2016

0 J'aime 0 Poster un commentaire

SysML : Décrire le comportement du système avec les diagrammes de séquence et d'état - Les états opérationnels du HSUV (tutorial SysML partie 6)

sysml-tutoriel-tutorial-didacticiel-state-diagram-HSUV-75.png

Diagramme de Machine D'état - HSUV États Opérationnels

Les états opérationnels du bloc de HSUV sont décrits via un diagramme "machine d'état" nommée "HSUVOperationalStates".

Au début le véhicule est dans l'état "Off" (Moteur éteint).

Lorsque le conducteur démarre, l’événement associé produit la transition de l'état "Off" au super état "Operate" (En fonction).

Ce super état contient les états "Idle" (Le véhicule est à l'arrêt et tourne au ralenti), "Accelarating/Cruising" (En accélération/En vitesse constante) et "Braking" (En freinage).

Les événements correspondent aux actions du conducteur : accélérer, appuyer sur le frein, relâcher le frein ou à la vitesse égale à 0 (stopped).

Ces événements produisent les différentes transitions d'état du véhicule représentées sur le diagramme de state machine.

Pour la syntaxe du diagramme d'état, voir les articles :

Notez que cette machine d'état a été développée en cohérence avec le diagramme de séquence "boite noire", voir l'article :

https://www.urbanisation-si.com/sysml-decrire-le-comportement-du-systeme-avec-les-diagrammes-de-sequence-et-d-etat-diagramme-de-sequence-boite-noire-tutorial-sysml-partie-5

Notez aussi que cette machine d'état raffine l'exigence "PowerSourceManagment", qui sera élaboré dans les exigences.

Ce diagramme exprime seulement les états nominaux.

Par exemple l'exception "acceleratorFailure", n'est pas exprimée sur ce diagramme.

Rhona Maxwel

@rhona_helena

"Les plus belles années d'une vie sont celles que l'on n'a pas encore vécues."
Guillaume Musso

Voir aussi :

22/01/2016

0 J'aime 0 Poster un commentaire

SysML : Décrire le comportement du système avec les diagrammes de séquence et d'état - Diagramme de séquence boite noire (tutorial SysML partie 5)

sysml-tutoriel-tutorial-didacticiel-sequence-diagram-HSUV-74.png

Modélisation du comportement "boite noire" du use case "Conduire le véhicule" en utilisant le diagramme de séquence.

Diagramme de séquence montrant l'ordonnancement des interactions entre le conducteur et une instance "vehiculeIncontext" du système "HybridSUV" correspondant au use case "Conduire le véhicule" (Drive the Vehicule) idendifié lors de l'étape précédente :

"Préciser le contexte du système c'est à dire délimiter les frontières et identifier les "use case" (diagrammes interne de bloc et diagrammes de use case)" (voir l'article : https://www.urbanisation-si.com/sysml-les-use-case-top-level-et-operationnels-tutorial-sysml-partie-4 ).

Ce diagramme représente les interactions "boite noire" du use case "Conduire le véhicule".

Cette phase d'analyse montre comment le sujet c'est à dire le système (HybridSUV) interagit avec les éléments extérieurs sans révéler aucun détail de son fonctionnement interne.

Voir l'article consacré à la méthode ultime pour modéliser en UML l'expression de besoin d'un projet informatique :

https://www.urbanisation-si.com/urbanisation-si-la-methode-ultime-pour-modeliser-les-besoins-d-un-projet-16eme-partie-scenarios-cas-dutilisation-uml-diag-sequence

La syntaxe et l'exhaustivité des artefacts graphiques de modélisation du diagrmme de séquence ont été vus dans les articles :

Les conditions pour chaque alternative (fragment alt) sont exprimées en OCL (Object Constraint Language) et sont liés aux états du bloc "HybridSUV).

OCL est le langage d'expression de règles et de contraintes utilisés en UML. Toutes les contraintes du langage UML sont écrites en OCL. OCL est aussi utilisé dans les profils pour spécifier les nouvelles règles propres.

Voir la série d'articles consacrés à OCL :

Rhona Maxwel

@rhona_helena

"Qui ne possède pas sa pensée ne possède pas son action."
Victor Hugo

Voir aussi :

https://www.urbanisation-si.com/sysml-utilisez-le-diagramme-interne-de-bloc-pour-modeliser-l-aspect-contextuel-de-votre-systeme-tutorial-sysml-partie-3

09/01/2016

0 J'aime 0 Poster un commentaire

SysML : les use case "top level" et opérationnels (tutorial SysML partie 4)

sysml-tutoriel-tutorial-didacticiel-use-case-diagram-1-HSUV-72.png

Le use case "top level" permet de visualiser les interactions avec les acteurs et les autres systèmes au plus haut niveau et avec la plus forte granularité.

Suite et fin de la 2 ème étape : "Préciser le contexte du système c'est à dire délimiter les frontières et identifier les "use case" (diagrammes interne de bloc et diagrammes de use case)" abordée dans l'article précédent :

Dans un premier temps, il est important de modéliser à la maille la plus grosse possible, dans notre exemple, le périmètre est représenté par la "boundary" UML "HybridSUV", les acteurs sont identifiés : le conducteur (Driver), le propriétaire (Registered Owner), le concessionnaire (Maintainer) faisant l'entretien, la compagnie d'assurance (Insurance Company) et le service de carte grise (Department Of Motor Vehicles).

sysml-tutoriel-tutorial-didacticiel-use-case-diagram-2-HSUV-73.png

Les use case de haut niveau doivent décomposer en sous use case correspondant à des use case opérationnels ("ceux de la vraie vie").

Par exemple le use case de haut niveau "Operate the vehicule" déclenché par le conducteur est décomposé en sous use case opérationnels : "Conduire le véhicule" (Drive the vehicule) et "Garer le véhicule" (Park).

Le use case "Conduire le véhicule" inclut systématiquement les use case "Accélérer" (Accelerate), "Freiner" (Brake) et "Diriger" (Steer). Le use case "Démarrer" (Start) étend de manière optionnel le use case "Conduire le véhicule" , si le véhicule n'est pas démarré, il faudra le faire pour le conduire.

De même le use case "Garer le véhicule" inclut le use case "Freiner" qui est donc factorisé avec le use case "Conduire le véhicule".

Voir les articles consacrés aux use case pour plus d'informations :

https://www.urbanisation-si.com/sysml-le-diagramme-de-cas-d-utilisation-use-case-diagram

et

https://www.urbanisation-si.com/urbanisation-si-la-methode-ultime-pour-modeliser-les-besoins-d-un-projet-14eme-partie-cas-dutilisation-uml-diag-use-case

Rhona Maxwel

@rhona_helena

"Ni haïr, ni aimer fait la première moitié de toute intelligence du monde ; ne rien dire et ne rien croire la deuxième."
Arthur Schopenhauer

Voir aussi :

https://www.urbanisation-si.com/sysml-tutoriel-tutorial-didacticiel-description-de-l-etude-de-cas-partie-1

07/01/2016

0 J'aime 0 Poster un commentaire

SysML : Utilisez le diagramme interne de bloc pour modéliser l'aspect contextuel de votre système (tutorial SysML partie 3)

sysml-tutoriel-tutorial-didacticiel-internal-block-diagram-context-HSUV-71.png

Utilisation du diagramme interne de bloc pour représenter une cartographie du contexte (délimitation du périmètre) du système de SUV Hybride.

Parmi les grandes étapes de modélisation répertoriées dans l'article :

nous allons abordé la 2 ème étape : "Préciser le contexte du système c'est à dire délimiter les frontières et identifier les "use case" (diagrammes interne de bloc et diagrammes de use case)".

Parmi les premières étapes de la modélisation d'un système figure la cartographie du contexte.

Parmi les 9 diagrammes proposés par SysML, le diagramme interne de bloc (ibd internal block diagram) est le plus adéquat pour remplir les objectifs d'une cartographie contextuelle.

Ce diagramme ibd est donc stéréotypé <<ContextDiagram>>.

Le but est de définir le contexte dans lequel se trouve le système Hybride SUV (d'où l'intérêt du diagramme interne de bloc délimitant le périmètre du contexte).

Le système est un bloc stéréotypé <<system>> nommé HSUV et de type HybridSUV. Il représente le système comme une boite noire sur laquelle va interagir des acteurs et sera lié à d'autres blocs stéréotypés <<external>>.

On a 3 acteurs au sens UML, le conducteur, les passagers et le réparateur.

les blocs externes liés : les bagages et les conditions de conduite environnementales qui inclut 3 autre blos (les conditions météorologiques, la route et diverses entités externes).

Le diagramme contient un commentaire stéréotype <<diagramDescription>> précisant la version, la description, ...

Le but recherché est de préciser les entités de plus haut niveau et les relations qu'elles entretiennent.

Le modélisateur ou le méthodologue a donc la possibilité de représenter la cartographie de plus haut niveau dans laquelle figure des entités conceptuelle figurant les éléments d'environnement en relation avec le futur système à réaliser considéré pour l'instant comme une boite noire.

L'objectif de la modélisation SysML est de transformer cette boite noire en boite blanche en montrant sa structure et sa dynamique interne.

A ce stade de la modélisation, les entités sont conceptuelles mais seront raffinées dans le cadre du processus de développement.

Les stéréotypes <<system>> et <<external>> sont définis par l'utilisateur (non SysML), mais aident le modeleur à identifier l'environnement dans lequel évolue le système.

Ce diagramme peut faire partie des présentations de groupe de travail (les fameux powerpoint servant encore trop souvent comme outil de modélisation de haut niveau :-)).

On peut inclure des icônes pour rendre plus convivial le modèle, surtout s'il est destiné à des non techniciens (sponsors, ...).

En plus de la sémantique, ce diagramme est donc une aide visuelle facilitant la compréhension.

Les associations parmi les blocs peuvent représenter des relations conceptuelles abstraites parmi les entités, qui seraient raffinées dans des diagrammes ultérieurs.

Rhona Maxwel

@rhona_helena

"Tu n'avais pas eu besoin des sciences cognitives pour savoir que sans intuitions ni affects il n'y a ni intelligence ni sens."
André Gorz

Voir aussi :

https://www.urbanisation-si.com/sysml-tutoriel-tutorial-didacticiel-description-de-l-etude-de-cas-partie-1

06/01/2016

0 J'aime 0 Poster un commentaire

SysML : tutoriel ( tutorial - didacticiel ) Le diagramme de package (partie 2)

sysml-tutoriel-tutorial-didacticiel-diagramme-package-HSUV-67.png

Diagramme de package - Cartographie à grosses mailles des éléments du modèles représentés sous forme de packages. Certains éléments de hauts niveaux sont représentés comme le block "Automotive Domain", les vues et les points de vue (stéréotypes de classe).

Suite et fin de la première étape : "Vue d'ensemble des packages représentant la structure au plus haut niveau du système", commencée dans l'article précédent :

Les packages (identiques en UML et SysML) permettent de regrouper des éléments appartenant à un même domaine que ce soit métier, fonctionnel, technique ou bien encore des domaines de modélisation comme c'est le cas dans l'exemple ci-dessus.

Un élément se trouvant à l'intérieur d'un package peut être représenté avec la relation avec le + entouré ou carrément figuré à l'intérieur du symbole de package.

On peut avoir des relations de dépendances (<<import>>, simple dépendance UML, ...) entre les packages.

Dans cet exemple on voit des éléments stéréotypés <<view>> et <<viewpoint>>, vous voulez un petit rappel sur le sujet "aussitôt dit, aussitôt fait".

Le point de vue (<<viewpoint>>) spécifie des règles pour construire une vue (<<view>>) comme une documentation destinée à public spécifique comme par exemple un ensemble de parties prenantes et en fonction de leurs préoccupations. La vue est une représentation du système suivant la perspective d'un point de vue. La figure suivante montre une vue simple et un exemple de point de vue avec la Version 1.4 de SysML:

sysml-tutoriel-tutorial-didacticiel-diagramme-package-view-viewpoint-HSUV-68.png

En général les outils SysML ont leur propre générateur de documentation et ils sont très rares ceux qui utilisent les vues.

sysml-tutoriel-tutorial-didacticiel-diagramme-package-view-viewpoint-2-69.png

Avec la version 1.4 (la toute dernière qui vient de paraître à ce jour), SysML fournit un élément de modèle pour les parties prenantes. La partie prenante a un nom et une liste de préoccupations. Les préoccupations sont des éléments de modèle de commentaire. La relation entre la partie prenante et les commentaires n'a aucune notation. La partie prenante d'élément de modèle de SysML étend le classificateur UML, c'est-à-dire une partie prenante pourrait être un acteur spécial aussi bien qu'un bloc spécial. La partie prenante est définie dans le contexte de point de vue et de la vue.

L'élément vue de SysML étend l'élément classe UML. La vue a deux propriétés : une liste de parties prenantes qui provient de la liste des parties prenantes du point de vue et la vue est lié par la relation d'héritage stéréotypée <<conform>> à un point de vue. Ce stéréotype étend) la relation de généralisation UML. Cela signifie qu'une vue est une sorte plus spécifique d'un point de vue et hérite de toutes les caractéristiques du point de vue. La vue représente les artefacts physiques, par exemple un document de texte, un tableau ou la présentation de diapositives.

sysml-tutoriel-tutorial-didacticiel-diagramme-package-view-viewpoint-3-70.png

Rhona Maxwel

@rhona_helena

"Nous aimons utiliser notre intelligence, et, souvent, la joie de remporter un défi de l'esprit vaut plus que n'importe quelle récompense matérielle."
Thierry Janssen

Voir aussi :

05/01/2016

0 J'aime 0 Poster un commentaire

SysML : tutoriel ( tutorial - didacticiel ) Description de l'étude de cas (partie 1)

Ce tutorial traite du développement d'une automobile, et plus particulièrement d'un Véhicule Utilitaire Sportif Hybride ( HSUV Hybrid Sport Utility Vehicle ), un 4 x 4 alimenté au gazole et électrique.

L'étude de cas est intéressante du point de vue des exigences contradictoires : basse consommation de carburant, mais capacité de charge importante et la possibilité de rouler hors de routes en tout terrain.
Comme il s'agit avant tout d'un tutorial pédagogique pour mettre en oeuvre les 9 diagrammes SysML et l'ordre des étapes pour parvenir à une modélisation efficiente, l'exactitude technique et la faisabilité de la solution ne sont pas réelles et ne font pas partie des objectifs de ce tutoriel.

Le didacticiel se focalise sur les choix de conception : frontières entre les sous-système du 4 x 4 hybride, les exigences, les analyses de performance, la structure et le comportement.

Voici l'ordre des grandes étapes de modélisation suivi dans ce tutorial :

Vue d'ensemble des packages représentant la structure au plus haut niveau du système. Un des principes de la modélisation est de raffiner et d'augmenter l'échelle des cartographies pour arriver aux niveaux des destinataires voulus et répondre à la question : à quoi vont servir tous ces modèles ?
Préciser le contexte du système c'est à dire délimiter les frontières et identifier les "use case" (diagrammes interne de bloc et diagrammes de use case).
Décrire le comportement du système avec les diagrammes de séquence et d'état.
Recenser les exigences sous forme de diagrammes d'exigence et de matrices.
Structurer le système avec les diagrammes de définition de bloc et les diagrammes internes de bloc.
Définir les ports et les flux (diagrammes de définition de bloc et les diagrammes internes de bloc, diagrammes paramétriques).
Analyser les performances (diagrammes de définition de bloc, diagrammes de package, diagrammes paramétriques et les diagram UML de timing qui ne font pas partie de la norme SysML.).
Définir les allocations des activités (diagrammes d'activité, diagrammes de définition de bloc, diagrammes d'activité semblable aux diagrammes Enhanced Function Flow Block Diagram (EFFBD), et diagrammes internes de bloc).

Commençons donc par la vue d'ensemble des packages représentant la structure au plus haut niveau du système, les autres étapes suivront dans les prochains articles.

Le package HSUVMODEL représente le modèle d'utilisateur.
Le Profil de SysML doit être appliqué à ce package pour inclure des stéréotypes du profil.
Le package HSUVMODEL importe les bibliothèques de modèle, comme la bibliothèque de modèle des unités physiques (longueur, masse, puissance, ...).

sysml-tutoriel-tutorial-didacticiel-HSUV-contexte-65.png

sysml-tutoriel-tutorial-didacticiel-HSUV-contexte-2-66.png

Rhona Maxwel

@rhona_helena

"Sur cent personnes à qui l'on souhaite bonne année, bonne santé le premier janvier, deux meurent d'atroces souffrances avant le pont de la Pentecôte."
Pierre Desproges

Voir aussi :

04/01/2016

0 J'aime 0 Poster un commentaire

SysML : exemples de diagramme d'exigence tout droit sortie de la norme de l'OMG

Exemple 1 : une exigence composée d'exigences multiples et dépendantes de sous exigences

sysml-exemple-diagramme-d-exigence-requirement-diagram-example-59.png

Exemple 2 : exigences avec des exigences dérivées ainsi que des éléments de modélisation (block, commentaires) satisfaisant les exigences et des commentaires portant sur des bonnes pratiques, règles, ..., reliés aux relations <<satisfy>>

sysml-exemple-diagramme-d-exigence-requirement-diagram-example-60.png

Exemple 3 : commentaire précisant les exigences satisfaites par les éléments de modélisation rattachés

sysml-exemple-diagramme-d-exigence-requirement-diagram-example-61.png

Exemple 4 : l'utilisation de la dépendance <<copy>> pour permettre à une exigence simple d'être réutilisée dans plusieurs hiérarchies d'exigences différentes. L'étiquette de maître (master) fournit une référence textuelle à l'exigence réutilisée.

sysml-exemple-diagramme-d-exigence-requirement-diagram-example-62.png

Exemple 5 : exigence d'utiliser le procédé de brunissage à froid (burnish) pour améliorer la résistance à l’abrasion dans le domaine du freinage automobile pour la sécurité (NHTSASAFETYREQUIREMENTS). Notez que le texte de l'exigence indique un ordre spécifique de critères de transition et des étapes. La relation <<verify>> montre que l'exigence doit être vérifiée par le scénario de test "BurnishTest".

sysml-exemple-diagramme-d-exigence-requirement-diagram-example-63.png

Exemple 6 : diagramme de machine d'état du scénario de test de l'exemple précédent "BurnishTest", qui exprime l'ordre textuel et les critères de l'exigence "Burnish" sous forme de machine d'état. On montre la relation <<verify>> en utilisant la notation avec le commentaire lié au cadre du diagramme (Verifies <<requirement>> Burnish), qui indique que le scénario de test (stéréotype UML <<testCase>>) "BurnishTest" vérifie l'exigence "Burnish".

sysml-exemple-diagramme-d-exigence-requirement-diagram-example-64.png

Rhona Maxwel

@rhona_helena

"Car le bonheur seul est salutaire pour le corps, mais c'est le chagrin qui développe les forces de l'esprit."
Marcel Proust

Voir aussi :