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
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
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
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
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
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