Réserver une Démo

SVP notez : Cette page d’aide n’est pas pour la dernière version d’Enterprise Architect. La dernière aide peut être trouvée ici.

Pré. Proc.

Modélisation Statemachines Exécutables

La plupart du travail requis pour modéliser un Statemachine Exécutable est une modélisation standard basée sur UML des modélisation de classes et State , bien qu'il y ait quelques conventions qui doivent être respectées pour assurer une base de code bien formée. La seule nouvelle construction est l'utilisation d'un élément Artefact stéréotypé pour former la configuration d'une instance ou d'un scénario Statemachine Exécutable . L'artefact est utilisé pour spécifier des détails tels que :

  • Le langage de code ( JavaScript , C# , Java, C++ dont C)
  • Les Classes et Statemachines impliquées dans le scénario
  • Les spécifications de l'instance, y compris l'état d'exécution ; note que cela pourrait inclure plusieurs instances de la même Statemachine , par exemple lorsqu'une classe 'Player' est utilisée deux fois dans une simulation de match de tennis

Outils et objets de modélisation de base pour Statemachines Exécutables des Modélisation

Ce sont les principaux éléments de modélisation utilisés lors de la construction des modélisation Statemachines Exécutables .

Type d'élément

Description

Classes et Diagrammes de classes

Les classes définissent les types d' object pertinents pour la ou les Statemachine d'état modélisées. Par exemple, dans un scénario de match de tennis simple, vous pouvez définir une classe pour chacun d'un joueur, d'un match, d'un Hit et d'un arbitre. Chacun aura sa propre Statemachine (s) et au moment de l'exécution sera représenté par des instances d' object pour chaque entité impliquée. Voir le Guide de Modélisation UML pour plus d'informations sur les Classes et les diagrammes de Classes.

Statemachines

Pour chaque classe que vous définissez et qui aura un comportement dynamique dans un scénario, vous définirez généralement une ou plusieurs Statemachines UML . Chaque Statemachine déterminera le comportement légal basé sur l'état approprié pour un aspect de la classe propriétaire. Par exemple, il est possible d'avoir une machine à Statemachine qui représente l'état émotionnel d'un joueur, une qui suit sa condition physique et ses niveaux d'énergie actuels et une qui représente son état de victoire ou de défaite. Toutes ces Statemachines seront initialisées et démarrées lorsque le scénario Statemachine commencera son exécution.

Artefact Statemachine Exécutable

Cet artefact stéréotypé est l'élément central utilisé pour spécifier les participants, la configuration et les conditions de démarrage d'un Statemachine Exécutable . Du point de vue du scénario, il est utilisé pour déterminer quelles instances (de classes) sont impliquées, quels événements elles peuvent se déclencher et s'envoyer, et dans quelles conditions de démarrage elles fonctionnent.

Du point de vue de la configuration, l'artefact est utilisé pour configurer le lien vers un script d'analyseur qui déterminera le répertoire de sortie, le langage de code, le script de compilation, etc. Un clic droit sur l'Artefact vous permettra de générer, construire, compiler et visualiser l'exécution en temps réel de vos Statemachines .

Constructions Statemachine prises en charge

Ce tableau détaille les constructions Statemachine prises en charge et toutes les limitations ou contraintes générales pertinentes pour chaque type.

Construction

Description

Statemachines

  • Statemachine simple : la Statemachine a une région
  • Statemachine orthogonale : la Statemachine d'état contient plusieurs régions
Sémantique d'activation de la région de niveau supérieur (appartenant à Statemachine ):

Activation par défaut : Lorsque la Statemachine commence à s'exécuter.

Entrée du point d'entrée : transitions du point d'entrée aux sommets dans les régions contenues.

  • Note 1 : dans chaque région de la Statemachine possédant le point d'entrée, il y a au plus une seule transition du point d'entrée à un sommet dans cette région
  • Note 2 : cette Statemachine d'état peut être référencée par un State de sous-machine - les références des points de connexion doivent être définies dans l' State de la sous-machine en tant que sources/cibles de transitions ; la référence du point de connexion représente une utilisation d'un point d'entrée/sortie défini dans la Statemachine d'état et référencé par l' State de la sous-machine
Multiple Statemachines : L'ordre de listage dans la fenêtre du Navigateur détermine l'ordre d'exécution.
  • Lorsqu'un State de sous-machine est impliqué, il peut y avoir plusieurs Statemachines sous la classe
  • Utilisez les flèches Monter ou Descendre dans la barre d'outils de la fenêtre Navigateur pour ajuster l'ordre des Statemachines ; celui du haut sera défini comme la Statemachine principale
Non supporté
  • Statemachine protocole
  • Statemachine

States

  • State simple : n'a pas de sommets ni de transitions internes
  • State composite : contient exactement une région
  • State orthogonal : contient plusieurs régions
  • Submachine State : fait référence à une Statemachine entière

Entrée d' State composite

  • Entrée par défaut
  • Entrée explicite
  • Entrée d'historique peu profonde
  • Entrée d'historique approfondie
  • Entrée du point d'entrée

Sous-états

  • Sous-états et sous-états imbriqués
La sémantique d'entrée et de sortie, où la transition comprend plusieurs niveaux d'états imbriqués, obéira à l'exécution correcte des comportements imbriqués (tels que OnEntry et OnExit).

Prise en Support transitions

  • Transition externe
  • Transition locale
  • Transition interne (dessinez une transition personnelle et changez le type de transition en interne)
  • Transition d'achèvement et Événements
  • Gardes de transition
  • Transitions composées
  • Priorités de tir et algorithme de sélection
Pour plus de détails, reportez-vous à la spécification OMG Spécification UML

Déclencheur et Événements

Un Statemachine Exécutable supporte la gestion des événements pour les signaux uniquement.

Pour utiliser les types d'événement Call, Timing ou Change, vous devez définir un mécanisme externe pour générer des signaux basés sur ces événements.

Signal

Attributes peuvent être définis dans Signaux ; la valeur des attributs peut être utilisée comme argument d'événement dans Transition Gardes et Effets .

Par exemple, voici le jeu de code dans l'effet d'une transition en C++ :

if(signal->signalEnum == ENUM_SIGNAL2)

{

int xVal = ((Signal2*)signal)->myVal ;

}

Signal2 est généré comme ce code :

classe Signal2 : Signal public{

Publique:

Signal2(){} ;

Signal2(std::vector<String>& lstArguments);

int myVal;

} ;

Note : Plus de détails peuvent être trouvés en générant un Statemachine Exécutable et en se référant au fichier 'EventProxy' généré.

Initial

Un pseudo-état initial représente un point de départ pour une région. C'est la source d'au plus une transition ; il peut y avoir au plus un sommet initial dans une région.

Régions

Activation par défaut et activation explicite :

Les transitions se terminent sur l' State contenant :

  • Si un pseudo-état initial est défini dans la région : activation par défaut
  • Si aucun pseudo-état initial n'est défini, la région restera inactive et l' State contenant est traité comme un State simple
  • Si la transition se termine sur l'un des sommets contenus dans la région : Activation explicite , entraînant l'activation par défaut de toutes ses régions orthogonales, à moins que ces régions ne soient également saisies explicitement (plusieurs régions orthogonales peuvent être saisies explicitement en parallèle via des transitions provenant du même Pseudo-état de fourche)
Par exemple, s'il y a trois régions définies pour un State orthogonal et que RégionA et RégionB ont un pseudo-état initial, alors RégionC est explicitement activée. L'activation par défaut s'applique à RegionA et RegionB ; l' State contenant aura trois régions actives.

Choix

Les contraintes de garde sur toutes les transitions sortantes sont évaluées dynamiquement, lorsque la traversée de la transition composée atteint ce pseudo-état.

Jonction

Branche conditionnelle statique : les contraintes de garde sont évaluées avant l'exécution de toute transition composée.

Bifurquer / Rejoindre

Sans thread, chaque région active se déplace alternativement d'une étape, sur la base d'un mécanisme de pool d'événements d'achèvement.

Nœuds EntryPoint / ExitPoint

Non-threadé pour Statemachine State ; chaque région active se déplace alternativement d'une étape, sur la base d'un mécanisme de pool d'événements d'achèvement.

Nœuds d'historique

  • DeepHistory : représente la configuration d' State active la plus récente de son State propriétaire
  • ShallowHistory : représente le sous-état actif le plus récent de son State contenant, mais pas les sous-états de ce sous-état

Événements différés

Dessinez une transition auto et changez le type de transition en Interne. Type 'différer();' dans le champ 'Effet' pour la transition.

Références des points de connexion

Une référence de point de connexion représente une utilisation (dans le cadre d'un State de sous-machine) d'un point d'entrée/sortie défini dans la Statemachine d'état référencée par l' State de sous-machine. Les références de point de connexion d'un State de sous-machine peuvent être utilisées comme sources et cibles de transitions. Ils représentent les entrées ou les sorties de la Statemachine référencées par la Submachine State .

Comportements State

Les comportements State 'entry', 'doActivity' et 'exit' sont définis comme des opérations sur un State . Par défaut, vous saisissez le code qui sera utilisé pour chaque comportement dans le champ Panneau 'Code' de la fenêtre Propriétés pour l'opération Comportement. Note que vous pouvez modifier cela pour saisir le code dans le panneau 'Comportement', en personnalisant le gabarit de génération .

Le comportement 'doActivity' généré sera exécuter jusqu'à la fin avant de continuer. Le code n'est pas concurrent avec un autre comportement d'entrée ; le comportement 'doActivity' est implémenté en tant que comportement 'exécuter en séquence après entrée'.

Références aux comportements dans d'autres contextes/classes

Si l' State de la sous-machine fait référence à des éléments de comportement en dehors du contexte ou de la classe actuelle, vous devez ajouter un connecteur <<import>> de la classe de contexte actuelle à la classe de contexte de conteneur. Par exemple:

State S1 de la sous-machine dans la classe 1 fait référence à la Statemachine d'état ST2 dans la classe 2

Par conséquent, nous ajoutons un connecteur <<import>> de Class1 à Class2 afin que la génération de code Statemachine Exécutable génère correctement le code pour Submachine State S1. (Sur la classe 1, cliquez sur la flèche Quick Linker et faites glisser jusqu'à la classe 2, puis sélectionnez "Importer" dans le menu des types de connecteurs.)

Réutiliser les artefacts Statemachine Exécutable

Vous pouvez créer plusieurs modèles ou versions d'un composant à l'aide d'un seul artefact exécutable. Un artefact représentant une résistance, par exemple, pourrait être réutilisé pour créer à la fois une résistance à feuille et une résistance bobinée. Cela est susceptible d'être le cas pour des objets similaires qui, bien que représentés par le même classifieur, présentent généralement des états exécuter différents. Une propriété nommée 'resistorType' prenant la valeur 'wire' plutôt que 'foil' pourrait modélisation du point de vue de la modélisation. Les mêmes Statemachines peuvent ensuite être réutilisées pour tester les changements de comportement qui pourraient résulter de la variance de l'état d'exécution. Voici la procédure :

Marcher

Action

Créer ou ouvrir un diagramme de composants

Ouvrez un diagramme de composants sur lequel travailler. Il peut s'agir du diagramme contenant votre artefact d'origine.

Sélectionnez l' Statemachine Exécutable à copier

Trouvez maintenant l'artefact original Statemachine Exécutable dans la fenêtre Navigateur .

Créer le nouveau composant

Tout en maintenant la touche Ctrl enfoncée, faites glisser l'artefact d'origine sur votre diagramme . Deux questions vous seront posées.

La réponse au premier est Object et au second Tout. Renommez l'artefact pour le différencier de l'original, puis procédez à la modification de ses valeurs de propriété.