Diagramme d'activité en UML
•Download as KEY, PDF•
6 likes•24,865 views
Introduction aux diagrammes d'activité pour des étudiants en IUT
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Recently uploaded
Recently uploaded (20)
Diagramme d'activité en UML
- 1. Plan Problèmes du développement logiciel Histoire brève jusqu’aux limites de la programmation structurée Du bidouillage au Génie logiciel Introduction à UML Un peu d’histoire Survol Présentation du Module : démarche générale 03/11 1
- 2. Diagramme d’activité Sur la base de : http://www.isys.ucl.ac.be/etudes/cours/geti2101/ tutorialslides/GETI_2101_activity_diagrams.ppt et UML par la pratique Mireille Blay-Fornarino* IUT Nice-Sophia Antipolis blay@polytech.unice.fr http://www.polytech.unice.fr/~blay Site web du module : http://anubis.polytech.unice.fr/iut/ 2
- 3. Le but du diagramme d’activité Diagramme d’activité est utilisé pour: Modéliser un workflow dans un use case ou entre plusieurs use cases. Spécifier une opération (décrire la logique d’une opération) Le diagramme d’activité est le plus approprié pour modéliser la dynamique d’une tâche ou d’un processus métier. 03/11 3
- 4. Notion du diagramme d’activité Diagramme d’activité = Ensemble de noeuds Des actions (peut faire appel à une autre activité, attente et émission d’événements, Des contrôles (conditions, synchronisation, ...) Des objets (données) Départ et terminaison Transitions entre les noeuds Swimlanes ou Partitions: représentent le responsable des actions. 03/11 4
- 5. Notion du diagramme d’activité •Etat de départ •Etat de terminaison •Transition [ ] [ ] •Transition Alternative 03/11 5
- 6. Notion du diagramme d’activité Synchronisation disjonctive et conjonctive 03/11 6
- 7. Notion du diagramme d’activité Itération 03/11 7
- 8. Notion du diagramme d’activité Swimlanes/ Partitions 03/11 8
- 9. http://sourcemaking.com/uml/ modeling-business-systems/ external-view/activity-diagrams Savoir lire un D.A. 03/11 9
- 10. http://sourcemaking.com/uml/ modeling-business-systems/ external-view/activity-diagrams Savoir lire un D.A. 03/11 9
- 11. http://sourcemaking.com/uml/ modeling-business-systems/ external-view/activity-diagrams Savoir lire un D.A. 03/11 10
- 12. Construction un diagramme d’activité 1. Identifiez la portée (« scope ») du diagramme d'activité Commencez en identifiant ce que vous allez modéliser. Un seul use case? Une partie d'un use case ? Un « workflow » qui inclut plusieurs use cases ? Une méthode de classe ? 2. Ajouter l’état de départ et de terminaison 3. Ajouter les actions Si vous modélisez un « workflow », introduisez une activité pour chaque processus principal, souvent un use case. Enfin, si vous modélisez une méthode, il est souvent nécessaire d’avoir une action pour chaque grand étape de la méthode. 4. Ajouter des transitions (séquentielles), des transitions alternatives (conditionnelles), des synchronisations entre des actions, des itérations. 5. Identifier des partitions et répartir des actions identifiées dans ces partitions. 03/11 11
- 13. Exercice la recette de cuisine • Commencer par Casser le chocolat en morceaux, puis le faire fondre. • En parallèle, casser les oeufs en séparant les blancs des jaunes. • Quand le chocolat est fondu, ajouter les jaunes d'oeuf. • Battre les blancs en neige jusqu'à ce qu'ils soient bien fermes. • Les incorporer délicatement à la préparation chocolat sans les briser. • Verser dans des ramequins individuels. • Mettre au frais au moins 3 heures au réfrigérateur avant de servir 12
- 14. Exercice la recette de cuisine Action sur événement temporel 13
- 15. Exercice la recette de cuisine Action sur événement temporel 14
- 16. Exercice la recette de cuisine Le chef et son assistant travaille à nous régaler.... Qui fait quoi? Action sur événement temporel 15
- 17. Partitions représentant les entités responsables des actions Exercice la recette de cuisine avec assistant visible 16
- 18. Partitions représentant les entités responsables des actions Exercice la recette de Quels sont les ingrédients cuisine manipulés? avec assistant visible 16
- 19. Exercice la recette de cuisine et Flots d’objets Objets [état] 17
- 20. Exercice la recette de cuisine et Flots d’objets Objets [état] Plusieurs ramequins? 17
- 21. Exercice la recette de cuisine et Boucle d’expansion sur le remplissage Mélange des ramequins ramequin 18
- 22. Exercice la recette de cuisine et Boucle d’expansion sur le remplissage Mélange des ramequins ramequin Tous les jaunes sont-ils bien séparés des blancs ? 18
- 23. Exercice Eléments de l’itération la recette de cuisine et gestion des itérations Décision fin de flot 19
- 24. Et si le chocolat brûle ? Exercice Eléments de l’itération la recette de cuisine et gestion des itérations Décision fin de flot 19
- 25. Zone d’activité interruptible Exercice Evénement la recette de cuisine et gestion des erreurs Récupération d’erreur 20
- 26. Exercice: Commander un produit • Construire un diagramme d’activité pour modéliser le processus de commande d’un produit. Le processus concerne les acteurs suivants: – Client: qui commande un produit et qui paie la facture – Caisse: qui encaisse l’argent du client – Vente: qui s’occupe de traiter et de facturer la commande du client – Entrepôt: qui est responsable de sortir les articles et d’expédier la commande. 21
- 27. Commander un Produit: Solution possible 22
- 28. Commander un Produit: Solution possible Pendant que le service des ventes traite la commande, l’entrepôt se charge de l’expédition. La facture est envoyée au client indépendamment de l’expédition de la commande. 23
- 29. Commander un Produit: Solution possible Pendant que le service des ventes traite la commande, l’entrepôt se charge de l’expédition. La facture est envoyée au client indépendamment de l’expédition de la commande. La facture doit être payée avant l’expédition au client 23
- 30. Commander un Produit: Solution possible Pendant que le service des ventes traite la commande, l’entrepôt se charge de l’expédition. La facture est envoyée au client indépendamment de l’expédition de la commande. La facture doit être payée avant l’expédition au client Une commande est close que lorsqu’elle a été expédiée. 23
- 31. Commander un Produit: Solution possible Pendant que le service des ventes traite la commande, l’entrepôt se charge de l’expédition. La facture est envoyée au client indépendamment de l’expédition de la commande. La facture doit être payée avant l’expédition au client Une commande est close que lorsqu’elle a été expédiée. Si la commande est urgente, elle est expédiée en collisimo. 23
- 32. Commander un Produit: Solution possible Pendant que le service des ventes traite la commande, l’entrepôt se charge de l’expédition. La facture est envoyée au client indépendamment de l’expédition de la commande. La facture doit être payée avant l’expédition au client Une commande est close que lorsqu’elle a été expédiée. Si la commande est urgente, ell est expédiée en collisimo. Une commande est close que si elle a été livrée. 24
- 33. Connexion telnet Décrire la connexion d'un client à un serveur telnet. On considère trois protagonistes: le client, le démon telnet (i.e. le serveur logiciel) et la machine serveur. Une fois la connexion établie entre le client et le serveur, le démon demande un mot de passe au client, ce dernier dispose de trois tentatives avant que la connexion ne soit rompue. Les tentatives infructueuses sont enregistrées dans un fichier sur le serveur. Une fois l'identification faite, un terminal est ouvert et l'utilisateur peut alors saisir des commandes qui sont interprétées par le démon et exécutées sur le serveur. La commande exit déconnecte le client du serveur. http://www.nawouak.net/?doc=exercises.uml+ch=activity+lang=fr 25
- 34. Connexion telnet 26 http://www.nawouak.net/?doc=exercises.uml+ch=activity+lang=fr
- 35. Trouver les erreurs ... 27
Editor's Notes
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- PARLER D ACTIONS VERSUS ACTIVITES\n
- You start reading at the initial node, or in Figure 3.17 with the acceptance of the event passenger arrive sat check-in (1), and continue along the arrows of the control flow (2). The subsequent action passenger checks in(3) means that at this point the activity ‘passenger checks in’ is processed. This is depicted in more detail in another activity diagram as is indicated by the ‘fork’ in the action symbol:\n\nIf you follow the control flow, next you will come to a conditional branch or decision node (4): if the check-in is OK the next step along the control flow can follow. Otherwise (5), the passenger cannot fly and the task of passenger services is completed. This can be seen at the black dot with border—the activity final node.\n57\nAfter successful check-in (7) you come to a black cross bar. All arrows that come from this bar (7) symbolize flows that are processed simultaneously. While the luggage is being loaded onto the airplane (9) the passenger is boarding the airplane (10). Between point (8) and point (11) the flows are independent from one another. At the second cross bar (11) the simultaneously processed flows (9 and 10) are merged, meaning that only when the passenger is on the plane (10) and the luggage has been loaded onto the plane (9), does the control flow continue below the cross bar (11). In our example, one more action (12) and subsequent to that the final state(13) follow, meaning that after the passenger is on the plane (10) and the luggage has been loaded onto the plane (9), the airplane can taxi toward the runway (12). You can see here that the last action airplane taxis toward runway (12) is only defined as a single action, even though this process is very complex and could be described in many other activity diagrams. In our context, however, it is not important to describe this step in detail.\n\nTaxis = verbe disant qu’il va vers la piste.\n\n
- The activity diagram in Figure 3.18 is divided into two partitions: passenger (1) and passenger services (2). The passenger, for instance, carries out showing ticket at check-in counter (3), checking luggage (4), and paying fee(i). All other actions are located in the partition (swim lane) of passenger services (2) and are carried out by passenger services.\n
- \n
- \n
- \n
- Nous proposons ci-après une classification pour dissocier clairement les objets propres au système à modéliser et les objets matériels ou réels qu’il peut être intéressant de faire apparaître dans un workflow (diagramme d’activité).\n\nPour notre proposition nous nous inspirons de l’exemple de la gestion commerciale présenté en page 289 de [BRJ-00]. Nous avons ajouté, à notre système, une responsabilité « Caisse » qui traitera du paiement en liquide des clients. Ce premier diagramme ne montre volontairement que les activités pour bien fixer le cadre du workflow. \n\nPour éviter de surcharger notre modèle, nous avons retiré les mécanismes de synchronisation et pour des questions de réalisation du support de cours nous avons mis la responsabilité « Caisse » à gauche de l’acteur externe « Client » alors que nous devrions la mettre à droite également.\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Nous proposons ci-après une classification pour dissocier clairement les objets propres au système à modéliser et les objets matériels ou réels qu’il peut être intéressant de faire apparaître dans un workflow (diagramme d’activité).\n\nPour notre proposition nous nous inspirons de l’exemple de la gestion commerciale présenté en page 289 de [BRJ-00]. Nous avons ajouté, à notre système, une responsabilité « Caisse » qui traitera du paiement en liquide des clients. Ce premier diagramme ne montre volontairement que les activités pour bien fixer le cadre du workflow. \n\nPour éviter de surcharger notre modèle, nous avons retiré les mécanismes de synchronisation et pour des questions de réalisation du support de cours nous avons mis la responsabilité « Caisse » à gauche de l’acteur externe « Client » alors que nous devrions la mettre à droite également.\n
- Nous proposons ci-après une classification pour dissocier clairement les objets propres au système à modéliser et les objets matériels ou réels qu’il peut être intéressant de faire apparaître dans un workflow (diagramme d’activité).\n\nPour notre proposition nous nous inspirons de l’exemple de la gestion commerciale présenté en page 289 de [BRJ-00]. Nous avons ajouté, à notre système, une responsabilité « Caisse » qui traitera du paiement en liquide des clients. Ce premier diagramme ne montre volontairement que les activités pour bien fixer le cadre du workflow. \n\nPour éviter de surcharger notre modèle, nous avons retiré les mécanismes de synchronisation et pour des questions de réalisation du support de cours nous avons mis la responsabilité « Caisse » à gauche de l’acteur externe « Client » alors que nous devrions la mettre à droite également.\n
- Nous proposons ci-après une classification pour dissocier clairement les objets propres au système à modéliser et les objets matériels ou réels qu’il peut être intéressant de faire apparaître dans un workflow (diagramme d’activité).\n\nPour notre proposition nous nous inspirons de l’exemple de la gestion commerciale présenté en page 289 de [BRJ-00]. Nous avons ajouté, à notre système, une responsabilité « Caisse » qui traitera du paiement en liquide des clients. Ce premier diagramme ne montre volontairement que les activités pour bien fixer le cadre du workflow. \n\nPour éviter de surcharger notre modèle, nous avons retiré les mécanismes de synchronisation et pour des questions de réalisation du support de cours nous avons mis la responsabilité « Caisse » à gauche de l’acteur externe « Client » alors que nous devrions la mettre à droite également.\n
- Nous proposons ci-après une classification pour dissocier clairement les objets propres au système à modéliser et les objets matériels ou réels qu’il peut être intéressant de faire apparaître dans un workflow (diagramme d’activité).\n\nPour notre proposition nous nous inspirons de l’exemple de la gestion commerciale présenté en page 289 de [BRJ-00]. Nous avons ajouté, à notre système, une responsabilité « Caisse » qui traitera du paiement en liquide des clients. Ce premier diagramme ne montre volontairement que les activités pour bien fixer le cadre du workflow. \n\nPour éviter de surcharger notre modèle, nous avons retiré les mécanismes de synchronisation et pour des questions de réalisation du support de cours nous avons mis la responsabilité « Caisse » à gauche de l’acteur externe « Client » alors que nous devrions la mettre à droite également.\n
- Nous proposons ci-après une classification pour dissocier clairement les objets propres au système à modéliser et les objets matériels ou réels qu’il peut être intéressant de faire apparaître dans un workflow (diagramme d’activité).\n\nPour notre proposition nous nous inspirons de l’exemple de la gestion commerciale présenté en page 289 de [BRJ-00]. Nous avons ajouté, à notre système, une responsabilité « Caisse » qui traitera du paiement en liquide des clients. Ce premier diagramme ne montre volontairement que les activités pour bien fixer le cadre du workflow. \n\nPour éviter de surcharger notre modèle, nous avons retiré les mécanismes de synchronisation et pour des questions de réalisation du support de cours nous avons mis la responsabilité « Caisse » à gauche de l’acteur externe « Client » alors que nous devrions la mettre à droite également.\n
- \n
- \n
- pas de début pas de fin .. confusion entre plusieurs évènement ... pas nécessaire de distinguer qui s’inscrit ... Absence de liens entre organise et cloture car evenement n’apparait pas comme un lien, pas de relation avec s’inscrire, ....Mauvaise notaion des gardes, \n
- \n
- \n
- \n
- \n
- \n