J'ai un système basé sur les événements C # assez basique, mais je ne sais pas comment je le modélise en UML. Je souhaite que je souhaite montrer à l'éditeur d'événements, abonnés, gestionnaires et classes eventargs .. Je pense que vous utilisez des "signaux", mais je ne trouve aucun exemples. Quelqu'un peut-il me dire un exemple ou une lumière?
merci
edit: Je crée un modèle statique, je n'ai pas besoin de représenter l'état ou les chemins dans le processus. Désolé si je ne faisais pas cela clair dans la question initiale ..
6 Réponses :
Utilisez un diagramme d'état ou un diagramme d'activité.
Comme indiqué par Lexu et John, vous pouvez utiliser STechARTS et des diagrammes d'activité pour modéliser certains des aspects dynamiques de votre système.
Pour votre modèle statique, vous pouvez modéliser les événements qu'une classe peut gérer comme opérations. Vous pouvez utiliser un stéréotype ( << événement >> ) pour différencier ces opérations à partir d'autres (par ex. Méthodes appelées de manière synchrone).
J'utiliserais probablement un modèle de composant logique pour représenter les sources / consommateurs et les opérations stéréotypées pour décrire les interactions.
Cependant, comme une idée de champ de gauche - une autre possibilité de messagerie pour moi .....
Je me demande si vous pouvez utiliser certains aspects de BPMN. - Un certain nombre d'outils UML tels que SPARX EA incluent-le
Sa syntaxe de messagement devrait vous permettre de décrire les événements source, et vous pourrez peut-être décrire les consommateurs / les gestionnaires à l'aide de pools ou d'activités, sans nécessairement à vous préoccuper du comportement interne. (Je pense à un niveau d'abstraction. Similaire à "niveau1" de Bruce Siver BPMN) De même, vous pouvez utiliser des interacalités de messagerie pour séparer les charges utiles / evenargs
Si vous utilisez quelque chose de quelque chose similaire à SPARX, vous pouvez probablement ajouter des impératifs de trace des éléments BPM au modèle de classe "réel" du code C #.
Le modèle de paire "Éditeur-abonné" (AKA "Observer"), peut être implémenté différent dans chaque cadre de programmation (langue), conçu par conséquent différents, dans UML
Toute façon, conceptuellement, lorsqu'un événement (" Signal "ou" message ") est envoyé, à partir d'un éditeur (AKA" Server ") à n'importe quel abonné (" Client "), parfois, un" ID "pour identifier un événement particulier, à partir d'autres événements, son fournis et d'autres Les paramètres ou les données sont également envoyés. P>
comme d'autres réponses déjà mentionnées, vous pouvez avoir besoin d'un diagramme (classe) pour décrire le modèle statique. (Notez qu'il existe une "agrégation", pas "composition", "association" peut être utilisée): p> et aussi, vous pouvez avoir besoin d'un diagramme pour décrire la dynamique Modèle: P> .........................................
+----------------+..+----------------+...
| <<Publisher>> |..| <<Subscriber>> |...
| VectorDrawApp |..| Figure |...
+--------+-------+..+--------+-------+...
.........|...................|...........
.......+-+-+...............+-+-+.........
.......| |...send(fill)..| |..Fill().
.......| +==============>+ +---+.....
.......| |...............| |...|.....
.......| |...<<return>>..| |...|.....
.......| |<--------------+ +<--+.....
.......| |...............| |.........
.......+-+-+...............+-+-+.........
.........|...................|...........
.........X...................X...........
.........................................
Aimez ces charmants diagrammes ASCII! +1
Approche du problème d'un angle d'historique de vie d'entité (modélisation d'événement, réf., Système Jackson [de] Développement ):
UML et modélisation de données: une réconciliation Par David C. Hay Réf. p.34
Software Evolution avec UML et XML édité par Hongji Yang 'Entity Life Histoires - Problèmes et problèmes', P142 - Je suis en désaccord BTW, une séquence diag. pourrait être utilisé relativement facilement si limité à l'entité en question, tandis que l'état de la Diag. est illustré avec succès dans Systèmes logiciels Architecture, Nick Rozanski, Eoin Woods ," Modèles de cycle de vie d'informations ", P 317.
La technique que je pense consisterait à esquisser un cas d'utilisation UML et à modéliser l'architecture d'événement avec un diagramme d'état, intégrant ce dernier dans le premier comme indiqué comme indiqué «décrire l'utilisation des comportements de cas ' uml-diagrams.org/use-cast-diagrams-how-a.html - Le même site web suggère que UML n'empêche pas l'utilisation d'autres techniques de modélisation, un ELH est effectivement assez facile à échéager en mode texte, ne nécessite pas la nommage d'un état (commode si elle n'est pas initialement apparente), ainsi que lorsqu'elle est transformée en un diagramme d'état le ELH STRUCTURE (INC. Les taux abstraits) peuvent également être transportés.
L'utilisation de l'explication d'un cas d'utilisation étendu pour spécifier des conditions serait une autre approche? Réf. 'UML utilisation case étend' uml-diagrams.org/use- cas-harvall.html # extension-point , voir aussi ce message Stackoverflow.com/Questtions/23223704/...