UML

EPITECH 2009sebastien@migniot.com

UML4 - Conclusion

• Pré-requis– Le langage– La méthode– Le but

• La méthode– Livres blancs et AMOA– UseCases et requirements– Activités et complexités– Séquencement des

opérations– Classes et CRUD– Review et ROI

• Diagrammes d'activité– Facile et agréables– Détail des notations– Exemple

• Diagrammes d'état– Vue croisée– Détail des notations– Exemple

• Conclusion– Documents normatifs– UML perfectible– Questions

Pré-requis

• Le langage• La méthode• Le but

Le but

• Arriver au but– Lutte contre le défaut du développeur à faire le sous-marin

pendant 3 mois sans montrer de résultat intermédiaire, sans partager et pour finalement échouer

• Faire le moins possible– Généralisation du capitalisme et de la vision financière du

client roi, le développement dicté par les UseCase limite les modules ajoutés arbitrairement

• Capitaliser meme si Turn Over– Disposer d'une modélisation partageable et pouvoir modifier

tout ou partie de l'équipe sans compromettre le projet

Pré-requis

• Le langage• La méthode• Le but

La méthode

Pré-requis

• Le langage• La méthode• Le but

Le but

• Arriver au but– Lutte contre le défaut du développeur à faire le sous-marin

pendant 3 mois sans montrer de résultat intermédiaire, sans partager et pour finalement échouer

• Faire le moins possible– Généralisation du capitalisme et de la vision financière du

client roi, le développement dicté par les UseCase limite les modules ajoutés arbitrairement

• Capitaliser meme si Turn Over– Disposer d'une modélisation partageable et pouvoir modifier

tout ou partie de l'équipe sans compromettre le projet

La méthode

• Livres blancs et AMOA• UseCases et requirements• Activités et complexités• Séquencement des opérations• Classes et CRUD• Review et ROI

Livres blanc et AMOA

• La MOA est le client• L'AMOA est

l'assistance au client• Livre blanc = Besoins

client non signés• Cahier des charges =

Besoins client signés

Livres blanc et AMOA

• Le besoin client– Discuter avec les potes– Echanger des fichiers

• Le livre blanc– Serveur de messagerie privatif et centralisé

avec gestion de messages textuels et binaires

La méthode

• Livres blancs et AMOA• UseCases et requirements• Activités et complexités• Séquencement des opérations• Classes et CRUD• Review et ROI

UseCases et requirements

• Certaines entreprises fonctionnent en requirements

• D'autres fonctionnent directement en UseCases

UseCases et requirements

• Les UseCases spécifient les besoins en périphérie du système

• Les requirements peuvent sur-contraindre l'interne du système

• Un système sur-contraint se fissure ou explose en automatique

• Les UseCases fonctionnent mieux

UseCases et requirements

• S'inscrire• Se connecter• Chercher des contacts• Ajouter des contacts• Commencer une discussion• Envoyer/Recevoir un message• Envoyer/Recevoir un fichier• Terminer la discussion• Se déconnecter

La méthode

• Livres blancs et AMOA• UseCases et requirements• Activités et complexité• Séquencement des opérations• Classes et CRUD• Review et ROI

Activités et complexité

• Les diagrammes d'activité sont naturels

• Ils décrivent en général des ruptures de flux multiples

• Nécessaires pour les cas non triviaux, complexes

Activités et complexité

• S'inscrire– remplir fiche contact– pseudo dispo– sinon choisir nouveau pseudo– si oui envoi mail

• Commencer discussion– si pas dans contacts– ajouter aux contacts– ouvrir fenetre discussion

La méthode

• Livres blancs et AMOA• UseCases et requirements• Activités et complexité• Séquencement des opérations• Classes et CRUD• Review et ROI

Séquencement des opérations

• Décrit le séquencement, l'enchaînement

• Chaque message est une opération

• Le diagramme qui génère classes et code

Séquencement des opérations• Inscrire

– Registry.exists(login:string):boolean

– Registry.join(contact:Contact):boolean

• Connecter

– Registry.getState(login:string):State

– Registry.login(login:string, password:string):Contact

– Registry.disconnect(login:string)

• Contacts

– Registry.find(search:string):Contact[]

– Contact.addFriend(contact:Contact):Contact

• Discussion

– Thread.addContacts(contacts:Contact[])

– Thread.addMessage(message:Message)

• Message:content+contact

– Thread.getMessages():Message[]

– Thread.getMessagesAfter(date:Date):Messate[]

– TextMessage,FileMessage->Message

La méthode

• Livres blancs et AMOA• UseCases et requirements• Activités et complexité• Séquencement des opérations• Classes et CRUD• Review et ROI

Classes et CRUD

• Déjà écrites par les diagrammes de séquence

• Ajouter les CRUD évident

• Contient plus d'Interfaces que de classes

Classes et CRUD

• Le client ajoute des besoins hors contrat

• Si le contact n'est plus là le fichier doit etre conservé– OK assuré par conception

• Ajouter mails, rss et versionnement des fichiers word– KO défaut de la MOA

« Nous avons un problème de maitrise par la MOA qui nous fait hésiter stratégiquement. La ligne naturelle d'application des pénalités n'est pas défendue par le management qui met en avant le ROI d'un positionnement en tant qu'AMOA. »

La méthode

• Livres blancs et AMOA• UseCases et requirements• Activités et complexité• Séquencement des opérations• Classes et CRUD• Review et ROI

Review et ROI

• Arriver au but– Lutte contre le défaut du développeur à faire le sous-marin pendant 3

mois sans montrer de résultat intermédiaire, sans partager et pour finalement échouer

• Faire le moins possible– Généralisation du capitalisme et de la vision financière du client roi, le

développement dicté par les UseCase limite les modules ajoutés arbitrairement

• Capitaliser meme si Turn Over– Disposer d'une modélisation partageable et pouvoir modifier tout ou partie

de l'équipe sans compromettre le projet

• Anticiper le changement– Les Design Pattern assurent le maximum de

OK par conception

Review et ROI

• Discuter les capacités individuelles et de groupe à arriver au bout de cette application

• Discuter des capacités à ne pas construire un système en inflation

• Issu des années 70 … et assure le financier

UML4 - Conclusion

• Pré-requis– Le langage– La méthode– Le but

• La méthode– Livres blancs et AMOA– UseCases et requirements– Activités et complexités– Séquencement des

opérations– Classes et CRUD– Review et ROI

• Diagrammes d'activité– Facile et agréables– Détail des notations– Exemple

• Diagrammes d'état– Vue croisée– Détail des notations– Exemple

• Conclusion– Documents normatifs– UML perfectible– Questions

Diagrammes d'activité

• Faciles et agréable• Détail des notations• Exemple

Détail des notations

• Partition• Action• Transition• Etats• Decision/Merge• Fork/Join• Activity

Exemple

• Faire d'après l'exemple• Commencer discussion

– si pas dans contacts– ajouter aux contacts– ouvrir fenetre discussion

Diagrammes d'état

• Vue croisée– Utilisé en général en fin de projet– Force un état stable sur chaque objet– Utile pour les factures/réservations/etc

• Détail des notations• Exemple

Détail des notations

• Etat initial• Etat• Transition• Etat final• Autres..

Exemple

• Faire d'après l'exemple• Ticket de Hotline/Mantis/BugZilla/Trac

UML4 - Conclusion

• Pré-requis– Le langage– La méthode– Le but

• La méthode– Livres blancs et AMOA– UseCases et requirements– Activités et complexités– Séquencement des

opérations– Classes et CRUD– Review et ROI

• Diagrammes d'activité– Facile et agréables– Détail des notations– Exemple

• Diagrammes d'état– Vue croisée– Détail des notations– Exemple

• Conclusion– Documents normatifs– UML perfectible– Questions

Conclusion

• Documents normatifs• UML Perfectible• Questions

Documents normatifshttp://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

http://www.omg.org/spec/UML/2.2/

UML Perfectible

Opinions

• UML donne une méthode éprouvée• UML sert à initialiser le code d'un projet• UML sert à suivre et documenter un projet• Les outils du marché sont orientés

Questions