Le projet de développement logiciel avec UML

Transcription

1 Le projet de développement logiciel avec UML Résumé de la formation UML UML UML UML UML UML UML UML 1 Plan Introduction Modélisation du métier Expression des exigences Conception PIM Conception PSM Conclusion 1

2 Introduction Objectifs d'un processus de développement de logiciel Qualité et productivité: fournir un logiciel de qualité, au moindre coût et dans les délais les plus courts Deux niveaux de qualité: La réponse aux besoins: qualité externe, perçue par les utilisateurs Maintenabilité, évolutivité, réutilisabilité: qualité interne, car non perçue directement par les utilisateurs pour améliorer la productivité => rejoint, à moyen et long terme la contrainte coûts/délais 4 2

3 La modélisation: un outil pour atteindre ces objectifs Centrer le développement sur sa finalité: une réponse aux besoins utilisateur Maîtriser la complexité du système lors de sa conception grâce àl'abstraction Faciliter la communication entre les différents acteurs du projet (managers, client, architectes, développeurs ), grâce: à l'abstraction à l'utilisation d'un formalisme: partagé de tous rigoureux à base de notations graphiques UML (Unified Modeling Language) est le langage de modélisation le plus utilisé dans l'ingénierie logicielle 5 Vue simplifiée d'une démarche OO Chaque objet logiciel est une image d'un "objet" du monde réel Description informelle du système modélisation programmation classe de modèle (UML) classe logicielle (Java, C++) exécution (=instanciation) objet logiciel Commande - numero: String - date: String + facturer() : void Class Commande { string numero; string date; void facturer(); } cdea= new Commande(); Comment entreprendre l'activité de modélisation? 6 3

4 La place d'uml UML est une "boîte à outils", proposant un ensemble de formalismes de modélisation graphique: les diagrammes UML => UML n'est pas une méthode UML doit être complétée par un processus de développement: Le processus de développement définit les étapes de modélisation Chaque étape consiste à élaborer un modèle UML 7 Processus de développement Un processus de développement définit les étapes de modélisation (disciplines de modélisation) Chaque étape/discipline possède son propre niveau d'abstraction Le Rational Unified Process (RUP) est un processus de développement, élaboré par les concepteurs d'uml 4 disciplines de modélisation dans le RUP 8 4

5 Modélisation du métier Réalité: le métier Processus métier Informations métier facture 130 Expression des exigences Réalité: le SI Niveau d'abstraction: vue externe clic total: 304F => passer cde Fact. verif cde Cde Préparer facture livrer cde Client Achete Vendeur 9 Analyse Conception PIM Réalité: SI Niveau d'abstraction: vue interne niveau d'abstraction élevé facture Conception Conception PSM Réalité: SI Niveau d'abstraction: vue interne + architecture technique, stock données cde Modèle d'analyse => Modèle de conception Preparer facture facture cde1 cde2 Preparer facture facture stockage cde1 cde2 10 5

6 Modélisation du métier Business modeling 11 Objectifs de la modélisation du métier Décrire la future organisation du système métier (la société, le département ), de façon formalisée La modélisation du métier consiste à décrire de façon formelle: l'organisation du métier (processus et rôles) les informations métier 12 6

7 Organisation du métier: les processus métier Description du système métier business system: l'entreprise, une activité au sein de l'entreprise: que fait-il? => définition de son objectif, les services offerts comment le fait-il? => définition de son organisation (qui fait quoi?) Le système métier est décrit au travers de ses processus 13 Identification des rôles externes Acteur métier Business Actor Acteur métier = "un rôle externe vis-à-vis du système métier" Exemple: Acteurs métier du système métier "garage" Client Fournisseur de pièces Banque 14 7

8 Identification des processus métier Business process Un processus métier correspond à un service offert à un acteur métier Processus => un début, une fin (service obtenu) Exemple: Processus métier du garage Reparer voiture Fournisseur de pièce Vendre voiture Client Laver voiture 15 Identification des rôles internes Intervenant métier Business worker Un intervenant métier représente le rôle d'un individu au sein du système métier C'est une rôle interne au système métier Exemple: Les intervenants métier du garage Secretaire commerciale Vendeur Responsabl e commercial 16 8

9 Description détaillée des processus Décrire ce qui se passe depuis l'initiation du processus jusqu'à sa fin résultat significatif pour un acteur métier Le "qui fait quoi quand?" Processus "réparer une voiture": Le client apporte sa voiture au garage La secrétaire l'accueille et enregistre le travail à réaliser Le mécanicien fait le diagnostic et répare la voiture La secrétaire prépare la facture Le client paie et récupère sa voiture auprès de la secrétaire 17 Description des processus avec le diagramme d'activité :Secretaire :Mecanicien Accueillir client Faire le diagnostic Effectuer réparation Preparer facture Récuperer voiture 18 9

10 Description textuelle du processus Résumé Ce processus correspond à la réparation d'une voiture d'un client, depuis l'accueil du client jusqu'à la récupération de la voiture par le client. Flux normal Ce processus se décompose en 5 grandes étapes: Accueil du client Le client apporte sa voiture et décrit le travail à faire à la secrétaire. La secrétaire enregistre la réparation et l'affecte à un mécanicien. La secrétaire téléphone au mécanicien. Diagnostic Réparation activité effectuée via le SI Préparation de la facture Récupération de la voiture Flux alternatif Non récupération de la voiture: si après 20 jours 19 Modélisation conceptuelle des informations Il est possible d'utiliser UML pour décrire de façon purement conceptuelle (i.e. non technique) les informations métier: Description structurelle, statique: diagramme de classe Description des états métier: diagramme de machine à états 20 10

11 Diagramme de classe, niveau conceptuel Classe <<business entity>>: regroupe un ensemble cohérent d'informations métier Chaque information/donnée métier est modélisée sous la forme d'un attribut «business entity» Client 1 1..* «business entity» Voiture - immatriculation - datemiseencirculation - couleur 1 0..* «business entity» Reparation «business entity» Facture 21 Description des états métier Diagramme de machine à états Ne mentionner que les "états métier", i.e. non techniques Affectee fin reparation Terminee facturation Facturee recuperation Recuperee apres (10 ans) 22 11

12 Expression des exigences Requirements 23 Objectifs de l'expression des exigences Décrire les exigences auxquelles le système d'information répond: ce qui est visible à l'extérieur du système Vision boîte noire du SI Du point de vue de l'utilisateur et dans le langage de l'utilisateur L'audience de cette description est: l'utilisateur/moa l'équipe de développement/moe 24 12

13 Les exigences fonctionnelles En UML, exprimés au travers des cas d'utilisation use case Les exigences fonctionnelles y sont décrits selon une vue: utilisateur unique une utilisation donnée, à un moment donné vue du comportement, très unitaire 25 Acteur - Actor Acteur: Représente un rôle qui interagit directement avec le système Un acteur est externe au système Vendeur Directeur SI garage Sys Nomenclature Secretaire 26 13

14 Cas d'utilisation use case Un cas d'utilisation (de base) décrit une séquence d'interactions entre le système et un ou plusieurs acteurs fournissant un résultat significatif et observable à un acteur particulier Un cas d'utilisation raconte une "histoire" entre un acteur et le système Description orientée tests 27 Diagramme de cas d'utilisation Use Case Diagram Creer reparation Secretaire Preparer facture Sys Nomenclature Completer reparation Mecanicien A noter: pas de notion temporelle 28 14

15 Description textuelle Exemple Préparer une facture Résumé Ce cas d'utilisation décrit la préparation d'une facture de réparation par la secrétaire, depuis la demande de préparation de la facture jusqu'à son impression. Precondition La réparation est dans l'état "terminée". L'écran courant est "écran d'accueil" Postcondition La réparation est dans l'état "facturée". Une nouvelle facture est enregistrée dans le système, dans l'état "imprimée". L'écran courant est "écran facture" 29 Préparer une facture - suite Flux normal Le CU commence quand la secrétaire demande à préparer la Facture 1. Sélection de la Réparation 1. Le système affiche toutes les réparations dans l'état "terminée" - écran liste réparations 2. La secrétaire sélectionne une réparation 3. Le système affiche les informations de la réparation écran réparation: la date de la réparation pour chaque ligne de réparation: titre quantité code de Nomenclature (si présent) 30 15

16 Préparer une facture - fin 2. Création de la facture 1. La secrétaire demande la facturation 2. Le système calcule le montant de la facture: cf règle de calcul métier si des pièces ont été changées, le système envoie une demande de tarif au système de nomenclature (except "erreur nomenclature") le système crée la facture et l'affiche - écran facture" 3. Impression de la facture La secrétaire demande l'impression de la facture Le système l'imprime et passe son état à "imprimée" Le cas d'utilisation est terminé Flux alternatifs Except erreur nomenclature: Si le système de nomenclature renvoie une erreur, le système Autre besoins La Facture est imprimée sur un papier spécial, référence 43ER 31 Scénario de cas d'utilisation Diagramme de séquence Scénario = un chemin particulier dans un CU Exemple: :SI garage :Secretaire demande preparation facture() ecran liste reparations() :Sys Nomenclature selection reparation() ecran reparation() demande facturation() requetetarif() tarif() ecran facture()

17 Les exigences non fonctionnelles L'approche "FURPS" 4 catégories de exigences non fonctionnelles Utilisabilité - Usability: ergonomie, esthétique Robustesse/fiabilité Reliability: fréquence et sévérité des fautes Performance: temps de réponse, charge, volume des données, quantité mémoire "Supportabilité" - Supportability: maintenabilité, évolutivité, réutilisabilité, portabilité, testabilité, intégration à l'existant 33 Description détaillée des interfaces entre système et acteur humain Conception graphique des écrans A partir de la description des cas d'utilisation Généralement, pas de modélisation mais élaboration à l'aide d'un outil de conception d'écran => prototypage 34 17

18 Analyse Analysis Conception PIM 35 Qu'est-ce que l'analyse? Structuration du logiciel sur un critère uniquement fonctionnel Indépendamment de l'architecture technique Ne s'intéresse qu'à la réalisation des exigences fonctionnelles L'analyse est une sorte de pré-conception simplifiée, d'un haut niveau d'abstraction: définition d'une architecture logicielle logique 36 18

19 Classe d'analyse 1 classe d'analyse est une abstraction de plusieurs classes de conception Exemple: 1 classe d'analyse "Commande" devient 3 classes en conception Commande - numero: - date: - nbcommandes: + creercommande() + supprimercommande() + ajouterproduit() => CommandeBean - numero: - date: + ajouterproduit() CommandeHome - nbcommandes: + creercommande() + supprimercommande() T_Commande column numero: date: 37 Analyse et MDA MDA Model Driven Architecture: approche de développement logiciel élaborée par l'omg L'objectif est de mettre en place des architectures logicielles évolutives Le moyen: séparer la logique fonctionnelle/métier de la technologie de la plate-forme technique L'architecture logique est exprimée dans un PIM (Platform Independent Model) L'architecture spécifique à une technologie est exprimée dans un PSM (Platform Specific Model ) Le modèle d'analyse du Unified Process est un PIM au sens MDA 38 19

20 MDA Transformation PIM =>PSM=>code PIM: Commande - numero - date - nbcommandes + ajouterproduit() + creercommande() + supprimercommande() PSM: technologie J2EE EJB2.0, persistance relationnelle CommandeBean - numero - date + ajouterproduit() CommandeHome - nbcommandes + creercommande() + supprimercommande() T_Commande «column» numero date Code: class CommandeBean implements EntityBean{ } 39 MDA Transformation PIM =>PSM=>code (2) PIM: Commande - numero - date - nbcommandes + ajouterproduit() + creercommande() + supprimercommande() PSM: technologie Java, pas de persistance =>PIM = PSM Commande - numero: String - date: String - nbcommandes: int Code: class Commande{ String numero; } + getnumero() : String + getdate() : String + ajouterproduit() + creercommande() + supprimercommande() 40 20

21 Analyse et architecture logique L'analyse fournit une architecture logique du logiciel: structuration en éléments de forte granularité indépendamment de l'architecture matérielle pour améliorer l'évolutivité, la maintenance du code Les critères de structuration sont: la cohérence fonctionnelle la limitation des dépendances et non le déploiement physique 41 Comment réduire les dépendances fonctionnelles entre classes Elaborer une architecture logique du logiciel Un pattern d'architecture logique: l'architecture en couches - layers Class1 Class2 couche n+1 Class3 Class4 Class7 couche n Class5 Class6 couche n

22 Architecture en couches d'un SI: MVC Modèle-Vue-Contrôleur GUISecretaire layer View/Presentation/GUI SessionPreparerFacture layer controller/application/uiprocess Commande Produit Facture layer model/business CommandeDAO ProduitDAO layer data access JavaSwing Oracle JavaRMI layer technicalplatform/middleware 43 Les classes de la couche Vue View Notation UML: classe <<boundary>> «boundary» GUISecretaire GUISecretaire Abstraction de plusieurs classes de conception gérant l'interface du système (ex: plusieurs classes Window ou Frame ) Démarches de découverte: une classe unique: GUI une classe par acteur humain: GUISecretaire une classe par CU: GUIPreparerFacture 44 22

23 Les classes de la couche Contrôleur de la vue Notation UML: classe <<control>> «control» SessionPreparerFacture Démarche de découverte: une classe par cas d'utilisation Classe orientée fonctionnel SessionPreparerFacture Opérations: une opération par requête/action utilisateur Attributs: caractérise l'état de la session peu d'attributs «control» SessionPreparerFacture - ecrancourant - nberreurs + traiterrequetefacturation() : void + traiterrequeteimpression() : void 45 Classes de la couche Modèle/Métier Notation UML: classe <<entity>> «entity» Commande Démarche de découverte: une classe par business entity Classe orientée données: Commande Attributs: correspondent à des informations métier, généralement persistantes Opérations: traitements "métier", indépendants de la session «entity» Commande - numerocde - date - total + ajouterproduit() : void 46 23

24 Couches "Data access" et "Technique" Couche Data access - Responsabilité fonctionnelle: prend en charge l'accès aux données persistantes permet le développement d'une couche modèle indépendante de la solution de persistance Couche Technique - Responsabilité fonctionnelle: offre des solutions techniques: de communication distribuée de persistance de visualisation graphique 47 Les couches d'analyse GUISecretaire layer View/Presentation/GUI SessionPreparerFacture layer controller/application/uiprocess Commande Produit Facture layer model/business CommandeDAO ProduitDAO layer data access JavaSwing Oracle JavaRMI layer technicalplatform/middleware 48 24

25 Modéliser les classes Modélisation structurelle/statique des classes: Attributs Relations d'association Relations de généralisation Opérations Modélisation dynamique Réalisation interne des cas d'utilisation => Scénario de cas d'utilisation 49 Modélisation structurelle Diagramme de classes «boundary» GUIClient 0..1 «control» SessionPasserCommande + traiteridentification(char, char) : void + traitermotcle(char) : void + traiterselectionproduit(produit) : void + traiterajoutproduit() : void 0..1 «entity» 0..1 Client «entity» - nom - prenom - pseudo - motdepasse - adressefacturation - adresselivraison Commande - datecommande -/ montant a passé «identity» 1 0..* - numerocommande 1 «entity» LigneCommande - quantite -/ montant * «identity» - numeroclient + create() : void + ajouterproduit(produit) : void + rechercherclientparpseudo(char, char) : void + getinfo() : void + getnom() : void + getprenom() : void 50 25

26 Modélisation dynamique Scénario de cas d'utilisation vision interne :Secretaire «boundary» :GUI «control» SessionPreparerFacture «entity» :Reparation demande preparation facture() traiterprepfacture() rechercherreparationparetat(terminee) reponserecherche(lesreparations) reponseprepfacture(ecranlistereparations,lesreparations) ecranlistereparations() Conception Design Conception PSM 52 26

27 Objectifs de la conception Affiner le modèle d'analyse en faisant les choix de conception: transformer le PIM en PSM passer de l'architecture logique à l'architecture technique Prend en compte les exigences non fonctionnelles, en particulier les performances et la persistance Proche de l'implémentation 53 Démarche A partir des exigences non fonctionnelles: Définir l'architecture physique Choisir un langage et un framework (en prenant en compte notamment la persistance) Transformer le PIM en PSM conformément à ces choix: Concevoir les composants logiciel et leur déploiement, et parallèlement, Concevoir le code: définir les classes de conception par affinement technique des classes d'analyse (en prenant en compte le déploiement des composants) 54 27

28 Mise en œuvre de la démarche A partir du modèle d'analyse PIM Vue statique «boundary» GUI «control» SessionPasserCommande + traiteridentification(motpasse :char, pseudo :char) : void + traitermotcle(motcle :char) : void + traiterselectionproduit(produit :Produit) : void + traiterajoutproduit() : void «entity» Client - nom - prenom - pseudo - motdepasse - adressefacturation - adresseli vrai son «identity» - numeroclient + rechercherclientparpseudo(motpasse :char, pseudo :char) : Client 55 PIM - vue dynamique Cas d'utilisation "Passer commande" scénario normal CB :GUI :SessionPasserCommande clx :Client :Client Web... identification(pseudo,motdepasse) traiteridentification(pseudo,motdepasse) rechercherclientparpseudo(motpasse, pseudo) :Client (ecranaccueilperso, clx) (clx) La GUI obtient les infos à afficher (i.e. le nom et le prénom) par l'objet clx ecran accueil perso(message de bienvenue) 56 28

29 Modèle de conception PSM Architecture physique et composants du framework: Architecture physique: 1 tier Framework: Java (JavaSwing pour l'ihm) Base de donées relationnelle MySQL 57 Architecture physique et composants du framework (2) Diagramme de déploiement PC StandAlone Client MySql 58 29

30 La conception des composants et de leur déploiement PC StandAlone AppliGestionCommandes Client MySql 59 La conception des classes Vue statique «boundary» GUI «trace» «JPanel» EcranAccueil «trace» «JPanel» EcranAccueilPerso «control» SessionPasserCommande «JavaBean» SessionPasserCommande «trace» + traiteridentification() : void «JavaBeanSingleton» ClientManager + rechercherclientparpseudo() : void «entity» Client «trace» «trace» «JavaBean» Client «trace» + create() : void + getnom() : void T_Client 60 30

31 La conception des classes La vue dynamique JavaSwing «FrameJavaSwing» «JavaBean» «JavaBeanSingleton» «JavaBean» :MySql AccueilFrame :SessionPasserCommande :ClientManager clx :Client :Client :JFrame... SaisieIdentification(pseudo,,motDePasse) clickvalidationident() mouseclicked(ev) traiteridentification(pseudo,motdepasse) rechercherclientparpseudo(motdepasse,pseudo) select() (ligne client) create(data ligne) (clx) (clx) (flagperso, clx) getnom() (nom) ecran accueil perso(message de bienvenue) 61 Conclusion UML n'est pas une méthode C'est une boîte à outils de diagrammes facilitant la modélisation de systèmes logiciels Bien utiliser UML, c'est: définir un processus de développement, le RUP par exemple choisir les notations UML adaptées choisir un outil de modélisation adapté aux choix précédents 62 31

32 Bibliographie UML 2.0 Guide de référence - Jacobson, Booch, Rumbaugh CampusPress De Merise à UML Nasser Kettani Eyrolles Advanced Use Case Modeling Frank Armour Addison Wesley UML 2.0 et design pattrens UML en action Pascal Roques Eyrolles (Etude de cas) Designing Enterprise Applications with Java 2 Platform, Second Edition Addison Wesley ("blue prints") (exemples de code J2EE ) Design Patterns Erich Gamma Addison-Wesley Le processus unifié Jacobson, Booch, Rumbaugh Eyrolles RUP, XP Architectures et outils Pierre-Yves Cloux Dunod Sites Forum