cours UML,use case, classe, automate, activité, interraction

1. UML Analyse et Conception Objet (C++)

4. Les problèmes

5. Les principales causes de l'échec

6. Les symptômes de l'échec

8. Les bénéfices des techniques OO From the corporate Use Of Object Technology

9. OO Versus Dvp classique Dvp = 20% Maintenance = 50%

10. C versus C++ en Maintenance

11. Notion d'abstraction Classe Moule Seau ~ChateauDeSable() c'est le destructeur Constructeur Objet ChateauDeSable ChateauDeSable couleur : Bleu, Blanc, Rouge poids : int ChateauDeSable(p1 : Couleur, p2 : int)

12. Un programme objet (1)

13. Un programme objet : Réutilisation

14. Un Objet est Nain et Paresseux et snob !!!

15. Un programme objet (2) Mere Run Bronzer Enfant Creer JchaiPasQuoiFaire FaisUnChateau ChateauDeSable Creer Garnir Casser JchaiPasQuoiFaire

16. Un programme objet (3) ChateauDeSable Mere Run Bronzer Enfant JchaiPasQuoiFaire PrendreBain Delete

17. Un programme objet (3) Mere Run Bronzer Enfant JchaiPasQuoiFaire PrendreBain Mer Creer AllerDans FaireVagues BoireTasse Crier

18. Un programme objet (4) Mere Run Bronzer Enfant Mer Crier Delete

19. Un programme objet (5) Fuite Mémoire Mere Run Bronzer Mer

20. Un programme objet (6) Enfant College Lycée Enfant Enfant Enfant Usine

21. Un programme objet (7) Enfant College Lycée Enfant Enfant Enfant Usine

22. Un programme objet (8) Enfant College Lycée Enfant Enfant Enfant Usine

23. Un programme objet persistant P P P P P P Enfant College Lycée Enfant Enfant Enfant Usine T T

28. Encapsulation Public : accessible par tout le monde Protected : accessible par l'objet et par les héritiers Private : accessible seulement par l'objet Les accesseurs : SetAttr et GetAttr

29. Héritage Est un

30. Polymorphisme Un petit programme : Personne p; Dentiste d; Chirurgien c; p = d; p.Travailler(); p = c; p.Travailler(); Arracher des dents Opérer Faire du pain

31. Les concepts d'une bonne conception Ouverture-Fermeture OCP Inversion des dépendances DIP Substitution de Liskov LSP Séparation des interfaces ISP

43. La notation UML Introduction : notion de modèle

44. Le but d ’UML Trouver les bons objets

45. La modélisation : Pourquoi Une bonne société qui développe des programmes est celle qui fabrique des programmes de qualité qui satisfont les besoins des clients (livraison à temps, utilisation des ressources humaines et matérielles optimales) Le but principal n’est donc pas de produire de beaux documents, ni de conduire de nombreuses réunions, ni de proclamer de beaux slogans, ni de gagner des prix Pulitzer sur les lignes de code; mais simplement de produire des programmes capables de satisfaire le client aujourd’hui et demain. Tout le reste est secondaire UML-User Guide

48. Les diagrammes UML + = = = +++ + + +++

49. Les 13 diagrammes UML2.0

50. Un outil UML Navigateur Définitions Boutons génériques Boutons Spécifiques Les diagrammes Classe Use Case Composants

51. Historique d'UML 2005 2.0 DOC-PDF UML1.3 = 4,7MB DOC-PDF UML2.0 = 5.8 MB 2006 2.1 Booch-93 Rumbaugh( OMT2) Oct-95 0.8 Jacobson (use case - sdl) Juillet-96 0.9 Janv-97 1.0 Nov-97 1.0 Sept-97 1.1 (OMG) 2000 1.4

52. La notation UML Diagramme de Use case

54. Diagramme de Use case Use Case Un Cas d’utilisation ( use case ) est une fonctionnalité remplie par le système et qui se manifeste par un ensemble de messages échangés entre le système et un ou plusieurs acteurs.

56. Diagramme de Use case Description d'un Use Case Les scénarios

57. Diagramme de Use case Payer cash Payer par carte Manger Demander facture Maitre d'hotel Prendre la commande client Aller au restaurant <<include>> <<include>> Caissier Payer <<include>> <<extend>> Sommelier Commander pinard <<extend>> Serveur Retourner plat en cuisine <<extend>>

58. Utilisation des Use case Manger Distribuer le comportement des fonctionnalités aux méthodes des objets Descriptions

59. Use Case : Ex1 Une société de vente par correspondance vous demande de développer son système informatique. Ce système doit pouvoir prendre en compte des commandes passées par la poste et des commandes passées par internet. Il doit suivre les expéditions qui ne sont effectuées que si le paiement est OK. Les paiements se font par carte bancaire dans le cas d'internet et par chèque dans le cas de la poste. Les paiements sont validés par un système bancaire appartenant à la société et existant. Il faut récupérer ce système. Le nouveau système est chargé aussi de la gestion de stocks, lorsqu'un article atteint un seuil minimal, alors il faut passer une nouvelle commande au fournisseur adéquat. A la réception de la commande, la mise à jour de la base est faite par un employé. Dans le cas d'un paiement accepté et de stock disponible, l'expédition est faite par un robot existant au quel il suffit de passer les coordonnées du client, et la liste des produits achetés. En cas d'indisponibilité, une lettre doit être envoyé au client. Correction

62. Supplément sur UC (2) User Stories et Use Cases formalisent les besoins utilisateurs et sont orientés But Ils font facilement l'objet d'ateliers de travail avec les utilisateurs pour les découvrir, les expliciter Ils vont être priorisés et vont ainsi guider les développements Ils mettent en avant les rôles, les différents profils d'utilisateurs Ils ne traitent que des exigences fonctionnelles (les aspects non fonctionnels sont décrits dans les spécifications supplémentaires (contexte UP) et dans les &quot;Constraints Cards&quot; (contexte XP)) Ils sont textuels et obéissent à des règles de construction très précises Ils ne traitent pas des aspects interface et ergonomie Ils aident à organiser le modèle Ils facilitent le choix du contenu des itérations Ils peuvent être rédigés par les analystes (UC) ou le client (US)

63. Business use case La première étape de la définition d’un système d’information consiste donc à s’interroger sur l’organisation (l’entreprise) pour laquelle ce système d’information fonctionne, sur son identité, sur ce qui en fait partie et sur ce qui n’en fait pas partie business actor1 business use-case realization business entity business actor business worker business use case

64. Business use case Une extension UML Que fait l’entreprise Comment fait l’entreprise Sur quoi travaille l’entreprise Qui travaille dans l’entreprise business actor1 business use-case realization business entity business actor business worker business use case Qui utilise l’entreprise Qui est utilisé par l’entreprise (en externe)

66. La notation UML Diagramme de classe

68. Diagramme de classe Les classes Abstrait Nom : type [= Initialisation] Syntaxe libre Attribut dérivé Attribut de classe Opération de classe Responsabilité {abstract}

69. Les classes : Génération de code

70. Diagramme de classe Représentation des classes

71. Diagramme de classe Héritage et agrégation 1 0..32 0..32 Composition Agrégation Héritage Cardinalité multiplicité Héritage = Est un Composition et Agrégation = Est composé de

72. De quoi hérite -t-on ? [ PAM-97 p55 ]

75. Classification dynamique [ PAM-00 p58 ]

77. Conflit de noms [ PAM-00 p60 ]

79. Les interfaces

81. Finalité et réalisation des interfaces

83. Le polymorphisme [ PAM-00 p63 ]

85. Diagramme de classe : Associations Nom d'association Nom de rôle Cardinalité-Multiplicité Personne employeur : Societe Societe employe : ListeOfPersonne Navigabilité Societe Personne 1..* -employes 1..* Societe employes : Personne Personne

86. Association réflexive

88. Diagramme de classe Classe d'association Où mettre le salaire??? La classe ContratTravail est une classe normale qui peut hériter, être associée à d'autres classes, …. L'association et la classe ne forme qu'un élément

89. Diagramme de classe Associations exclusives Contraintes

93. Trouver un qualificateur?

94. qualificateur

95. Association : Génération du code

96. Diagramme de classe Dépendance Depenser i = Banque::GetInstance()->DonnerSolde(); Acheter(i); Voler b = new Banque(); i = b->DonnerSolde(); Economiser (p : Banque) p->Deposer(10000);

97. Les classes paramétrées

98. Diagramme de classe Exo3

99. Diagramme de packages

100. Diagramme de packages On peut montrer ce qu’il y a à l’intérieur du package Une classe appartient à un package et un seule, mais peut être utilisée dans d'autres package. Un package est un regroupement des éléments du model. Cela s’applique à tous les éléments UML ainsi qu’aux différents diagrammes. Les packages sont la base de la gestion de configuration P.13

103. Packages et dépendances(1)

104. Organisation des packages RMQ : On peut rajouter des classes P-AB1B2 P-CD

105. Trouver trois packages et les relations

106. Trouver trois packages et les relations (suite) K L A B I E J G D H C F

107. Trouver trois packages et les relations (suite) K L A B I E J G D H C F p1 P2 P3 Design Pattern Façade

108. Dépendances circulaires (Pb)

110. Dépendances circulaires (Solution) Rmq : si il y a des méthodes différentes, alors faire plusieurs interfaces

111. Dépendances circulaires (RMQ 1) Rmq1 : L'objet A ne doit pas créer l'objet B Rmq2 : L'objet B ne doit pas créer l'objet A Rmq3 : Si nécessaire, on peut laisser l'un des deux Rmq1 Rmq2

113. Dépendances circulaires (RMQ 1) op1 fqq fqq() A::AddMonB(FqqAble p) B::AddMonA(FqqAble p)

117. Diagramme de classe Boundary-Controleur-Entité (1) Environnement Métier Fonctionnel B C E Fonctionnel Métier Environnement

118. Diagramme de classe Boundary-Contrôleur-Entité (2)

119. Diagramme de classe Boundary-Contrôleur-Entité (2)

120. Diagramme de classe Exo4 Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Locataire Proprietaire Nourriture Lapin Whisky Mariage CompteBanquaire Personne

121. Diagramme de classe Exo4 Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Locataire Proprietaire Nourriture Lapin Whisky Mariage CompteBanquaire Personne

122. Diagramme de classe Exo5

123. La notation UML Diagramme d'objets

126. La notation UML Diagrammes dynamiques

128. Diagramme de Séquence new

129. Diagramme de Communication Collaboration

130. Diagramme de communication

131. Diag. de Séquence :Navigation

132. Diagramme de communication Génération de code

133. Diagramme de Séquence (UML2.0)

136. Automate État & Transition Événement qui déclenche la transition Garde Action effectuée sur la transition Envoie de Ev2 à un objet Cible Action en entrant dans l'état Action en sortant de l'état Action déclenchée sur réception de Ev1 Activité

137. Automate imbriqué

138. Représentation d'un automate imbriqué

139. Automate:état historique profond

140. Automate :point de Jonction(1)

141. Automate :point de Jonction(2)

142. Automate :point de décision

144. Automate : exo7 E1 E3 E1 E3 E1 E2 E1 E2 E3 E1 ST1 entry: i = 0 exit: i++ ST2 entry: i++ exit: i++ on E4: i ++ E1 / i++ ST3 ST4 on E2: i = i - 2 E3[ i == 5 ] E2 E1 E1 E3 E3

145. Diagramme d'activité(1)

146. Diagramme d'activité(2)

147. Diagramme d'activité : nœud d'objet avec état

148. La notation UML Les autres diagrammes

149. Diagramme de composants (1)

150. Diagramme de composants (2)

151. Diagramme de composants (3)

152. Diagramme de déploiement(1)

153. Diagramme de déploiement(2)

154. Structure Composite :le problème

155. Structure Composite : exemple

156. Diagramme de temps

158. La notation UML Utilisation des diagrammes

159. Importance des diagrammes

160. La notation UML Les diagrammes (1) ==> Les fonctionnalités vues de l'extérieure du système ==> Les choses qui existent à l'intérieure du système ==> Distribution des fonctionnalités aux choses qui existent. Découverte des opérations des classes, de nouvelles classes, …. Diagramme d'activité ==> Description des opérations complexes Diagramme de UC Diagramme de classe Diagramme d'interaction

161. La notation UML Les diagrammes (2) Diagramme Automate ==> Comportement des classes complexes ==> Validation des diagrammes de classe ==> Description des fichiers contenant l'application (source, exe, …) ==> Les machines supportant l'application Diagramme d'instance Diagramme de composants Diagramme de déploiement

162. Cinématique des diagrammes UML Interaction Diagram Requirements Sequence Collaboration Use Cases GUI Class diagram State Activity Implementation Component Deployment Code Code Code Code Tests

163. La démarche Process Process Qui Quoi Quand Méthode Comment Langage Avec quoi UML Outils Hommes UP XP: Binôme TD Scrum

164. Processus en V V Winston Royce Addison Wesley

174. Processus : le RUP : Historique

176. Processus : le RUP Les phases

177. Processus : le RUP Analyse et conception Mettre en place les mécanismes de persistance Méthode Concepteur BD Concepteur Analyste Architecte Architecte Architecte Trouver et spécifier avec des responsabilités les classes Boundary-Control et entité Trouver les abstractions clés Faire le mapping objet BDR

179. Méthode Persistance (1) Mapping objet vers Table relationnelle fait automatiquement par les outils (choix de l'architecte) T_B a c T_B_ID b 50 Raymonde 0 1 55 Casta 1 1 45 Simone 2 1 T_A a c T_A_ID b 55 Robert 0 0 60 Haddock 1 0 35 0 Tintin 2 T_0 T_A_ID T_B_ID 0 1 0 1 1 0 0 2

180. Méthode Persistance (2) Data Modeler

181. Processus Light XP Process Agile RAD Programmation visuelle TV4IT : Pourquoi le poste de développeur est déconsidéré en France Eric Groise

182. Design patterns

183. Classification des patterns Création Comportement Structure

186. State : UML Client Etat +Op1(Context) +Op2(Context) +Op3(Context) * Etat1 +Op1(Context) +Op2(Context) Etat2 +Op2(Context) +Op3(Context)

187. State + Singleton

188. Stratègie : UML

189. Patron de méthode

190. l’Observer : UML Réutilisable Rmq : souvent UpDate contient des paramètres (evt, le sujet, l'état du sujet, …)

191. l ’Observer : la dynamique

193. Visitor : UML

194. Mémento : UML La classe à surveiller-----La mémoire----Le programme client (main) UnDo-ReDo

195. Itérateur: UML

196. Chain of Resp : Exemple Président <100000 Vice-président <25000 Directeur <10000 Comité >=100000 Director grouillot = new Director(); VicePresident Sam = new VicePresident(); President Tammy = new President(); Grouillot.SetSuccessor(Sam); Sam.SetSuccessor(Tammy); Purchase p = new Purchase( 350.00, &quot;Formation&quot;); Grouillot.ProcessRequest(p); p = new Purchase( 24000, &quot;Voiture&quot;); Grouillot.ProcessRequest(p); p =new Purchase ( 99000, &quot;Maison&quot;); Grouillot.ProcessRequest(p); p = new Purchase( 122100.00, &quot;Usine&quot;); Grouillot.ProcessRequest(p); U M V F

197. Command : UML Configurateur Utilisateur

198. Mediator : UML Mediator ConcreteMediator Colleague +mediator bouton liste textArea Controleur menu Rmq :Façade-Observer

200. Proxy : UML Proxy.Operation1() { fait qqchose….. leSujet.Operation1();} Proxy.Proxy(Sujet param){ leSujet = param;}

201. Decorator : UML Decorateur.Operation(): fait qq chose super.Operation() Cela revient à rajouter une responsabilité à une classe mais sans en changer l'interface. Comparer avec le composite ComposantConcret.Operation : fin de la chaîne Decorateur.Operation() : monComposant.Operation()

202. l ’Adaptateur : Uml et Exemple

204. Façade : UML

205. Flyweight : Poids mouche :UML Utilisation : beaucoup de petits objets à se partager à plusieurs. Exemple : les caractères d'un document PluriGleton

206. Bridge : UML Rmq : ressemble au state

208. Le singleton uml

209. Fabrication : le Design pattern

210. Fabrication Abstraite : motivation Application IHM Motif IHM windows Application IHM IHM Motif IHM windows L’application utilise IHM sans savoir si il s ’agit de Motif ou bien de Windows

211. Fabrication Abstraite : Structure Application <<instancie>>

212. Builder : UML

214. Etude de cas

216. UML : Bibliographie (suite)

217. WWW CETUS

218. Autres sites web http://www.numbersix.com/ http://www.m2tech.net/

219. Corrections des exercices

220. Use Case : Correction Ex1

221. Use Case : Correction Ex1

222. UC : Secrétaire

223. UC: Détails

224. UC: Suppléments

225. IHM : Secrétaire

226. UC Web

231. UC : Requirements

234. Diagramme de classe Correction Exo3 (1)

235. Diagramme de classe Correction Exo3 (2) {or} Construction ContratSimple ContratDouble Contrat Vehicule Maison Couple Roue Personne 0..* 0..* 2 2 Entreprise Voiture 4 4

236. Diagramme de classe Correction Exo4

237. Diagramme d'objets Correction Exo5 (1) Famille : Tintin & Milou, locataire

238. Diagramme d'objets Correction Exo5 (2) Haddock qui boit du whisky est marié à la Castafiore et est propriétaire de Moulinsart ????????

239. Diagramme d'objets Correction Exo5 (3) Haddock qui boit du whisky est marié à la Castafiore et est propriétaire de Moulinsart

240. Diagramme d'objets Correction Exo5 (4) Tournesol est locataire d’une partie de Moulinsart

241. Diagramme d'interaction Correction Exo6 (1)

242. Diagramme d'interaction Correction Exo6 (2)

243. Diagramme d'interaction Correction Exo6 (3)

244. Les développeurs Français Comment revaloriser le métier d'informaticien et d'ingénieur ? Je crois qu'il est important de mieux expliquer ce qu'est le logiciel. Car c'est encore trop abstrait pour beaucoup de monde. Il faut expliquer que c'est une véritable industrie (qui demande donc des investissements et une approche industrielle..) mais également en quelque sorte un art (car les talents sont clés). Ensuite il faut rappeler qu'il y aura plus d'innovation dans les 30 ans qui viennent que dans les 30 ans passés - et que nous sommes donc au cœur d'une industrie qui va générer de la croissance et des emplois . Enfin il faudrait refaire rêver sur les perspectives d'une carrière dans l'informatique et revaloriser les filières techniques . Nous avons chez Microsoft des architectes logiciels qui sont à des niveaux hiérarchiques supérieurs à des managers de grandes divisions. Cette révolution &quot;culturelle&quot; n'a pas encore eu lieu en France mais nous sommes optimistes.

247. Supplément sur UC (2) User Stories et Use Cases formalisent les besoins utilisateurs et sont orientés But Ils font facilement l'objet d'ateliers de travail avec les utilisateurs pour les découvrir, les expliciter Ils vont être priorisés et vont ainsi guider les développements Ils mettent en avant les rôles, les différents profils d'utilisateurs Ils ne traitent que des exigences fonctionnelles (les aspects non fonctionnels sont décrits dans les spécifications supplémentaires (contexte UP) et dans les &quot;Constraints Cards&quot; (contexte XP)) Ils sont textuels et obéissent à des règles de construction très précises Ils ne traitent pas des aspects interface et ergonomie Ils aident à organiser le modèle Ils facilitent le choix du contenu des itérations Ils peuvent être rédigés par les analystes (UC) ou le client (US)

248. Supplément sur UC (3)

249. Le robot Correction

250. Le robot correction : les UC

251. Le robot correction : les UC : jouer(1)

252. Le robot correction : les UC : jouer(2)

253. Le robot correction : les UC : Deplacer

254. Le robot correction : les UC : Prendre

255. Le robot correction : les UC : Deposer

256. Le robot correction : les UC : Attaquer

257. Le robot correction : les UC : IHM