La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Unified Modeling Language 2 Plan du cours 1. Caractéristiques de lobjet Caractéristiques de lobjet 1. Modes de développement Modes de développement 2.

Présentations similaires


Présentation au sujet: "Unified Modeling Language 2 Plan du cours 1. Caractéristiques de lobjet Caractéristiques de lobjet 1. Modes de développement Modes de développement 2."— Transcription de la présentation:

1

2 Unified Modeling Language

3 2 Plan du cours 1. Caractéristiques de lobjet Caractéristiques de lobjet 1. Modes de développement Modes de développement 2. Les activités du projet Les activités du projet 3. Généralités sur UML Généralités sur UML 4. Diagrammes Cas dutilisation Diagrammes Cas dutilisation 1. Etude dopportunité Etude dopportunité 2. Analyse des besoins Analyse des besoins 5. Modélisation logique structurelle 1. Objets Objets 2. Classes Classes 3. Architecture Architecture

4 3 Plan du cours 6. Modélisation de la dynamique 1. Diagramme de séquence Diagramme de séquence 2. Diagramme de communication Diagramme de communication 3. Diagramme dactivité Diagramme dactivité 4. Diagramme Etat-Transition Diagramme Etat-Transition 7. Modélisation de limplémentation et du déploiement 1. Diagramme de composant Diagramme de composant 2. Diagramme de déploiement Diagramme de déploiement

5 4 Caractéristiques de l objet PPourquoi le développement objet? CComment atteindre ces buts? QQuelles répercussions sur les méthodes de développement?

6 5 Caractéristiques de l objet Pourquoi le développement objet? RRéutilisation DDiminution des coûts de développement et de maintenance FFlexibilité et robustesse du logiciel QQualité Pourquoi le développement objet? Comment atteindre ces buts? Quelles répercussions sur les méthodes de développement?

7 6 Encapsulation Pourquoi le développement objet? Comment atteindre ces buts? Quelles répercussions sur les méthodes de développement? Caractéristiques de l objet Comment atteindre ces buts? Propriétés de lobjet Abstraction Héritage Polymorphisme

8 7 Caractéristiques de l objet La brique de base dun logiciel objet est la classe Cette classe est un module qui contient des données (attributs) et les traitements qui manipulent ces données (opérations = méthodes) Commande classe

9 8 Caractéristiques de l objet Il existe des contraintes de visibilité entre les classes, donc entre les objets Un objet ne peut avoir accès aux propriétés dun autre objet que selon certaines conditions définies dans le programme retour

10 9 Caractéristiques de l objet Un objet est une instance de classe Tous les objets dune même classe se décrivent avec les mêmes attributs et ils ont le même comportment Commande Référence Date cde Ref devis Créer Modifier Ref devis

11 10 Quelles répercussions sur Les méthodes de développement? L Le développement incrémental LLe développement agile LLa réutilisation Pourquoi le développement objet? Comment atteindre ces buts? Quelles répercussions sur les méthodes de développement?

12 11 Modèle de développement Analyse du problème Conception de la solution Implémentation Déploiement Analyse des besoins Modèle en cascade Modèle incrémental Analyse du problème Analyse des besoins Implémentation Déploiement Conception de la solution retour

13 12 Modèle de développement Avantages du modèle incrémental Limplication et la satisfaction de lutilisateur La gestion des risques Lintégration progressive

14

15 14 Les activités du projet Elles sont identiques quelque soit le modèle: Cascade, incrémental….

16 15 Activités du projet Toutes ces activités du projet ont une part de modélisation. Modélisation Du problème De la solution UML est un langage de modélisation Analyse du besoin Analyse du problème Opportunité Implémentation Conception de la solution

17 16 Activités du projet Chaque activité donne lieu a un rapport qui contient les modèles et des commentaires. Chaque rapport est écrit ou validé par le client Le rapport détude dopportunité + rapport danalyse des besoins + la V1 du plan projet constituent le cahier des charges Le cahier des charges est un élément essentiel du contrat Analyse du besoin Analyse du problème Opportunité Implémentation Conception de la solution Gestion de projet

18 17 Activités du projet Documents fondamentaux Gestion de projet Rapport dAnalyse du besoin Plan projet Rapport d Étude dopportunité Cahier des charges Organisation du projet, délais, coûts, contrôles, normes, procédures

19 18 Les activités du projet Etude dopportunité On souhaite construire un système informatique pour répondre à un besoin Qui a ce besoin? Quel est-il? Est-il justifié? Bilan gains-coûts estimés On modélise le périmètre du projet et son contexte Analyse du besoin Analyse du problème Opportunité Implémentation Conception de la solution

20 19 Les activités du projet Etude dopportunité Gestion de production Gestion des stocks Etudes Commercial Client Lellipse représente le périmètre du projet Les acteurs représentent les systèmes ou les personnes qui échangent des informations avec le projet Diagramme de contexte

21 20 Les activités du projet Analyse des besoins Exprimer les fonctionnalités demandées au système dinformation +autres besoins (performance, sécurité, flexibilité…) Analyse du besoin Analyse du problème Opportunité Implémentation Conception de la solution

22 21 Les activités du projet Analyse des besoins Ma gestion des commandes Ma gestion des stocks Ma gestion des commandes Ma gestion des stocks On modélise larchitecture de lexpression des besoins et les acteurs Le domaine de létude est découpé selon les fonctions requises par les acteurs Pour chaque cas dutilisation, on rédige un texte qui énonce les exigences de la maîtrise douvrage Cas dutilisation

23 22 Les activités du projet Analyse du problème Exprimer la structure (Entités; données) et la dynamique ( Processus detraitements) du système désiré Analyse du besoin Analyse du problème Opportunité Implémentation Conception de la solution Indépendamment de la technologie

24 23 Les activités du projet Analyse du problème Entités Commande Préparer commande Client VentesEntrepôt Commande annulée Commande expédiée Enregistrer la commande Contrôler Commande Expédier Commande Processus Modéliser le métier Chef des ventes Acteurs

25 24 Les activités du projet Conception de la solution Déterminer larchitecture technique. Prendre en compte la technologie (conception structurelle et dynamique) Analyse du besoin Analyse du problème Opportunité Implémentation Conception de la solution Ne jamais concevoir avant danalyser

26 25 Paquetage Modéliser larchitecture technique (structurer le logiciel) Isoler les solutions techniques qui évoluent indépendamment Les activités du projet Conception de la solution Accès Réseau Accès Base D IHM Métier Modélisation logique structurelle

27 26 Les activités du projet Modélisation logique structurelle Architecture technique Le découpage du logiciel est représenté par des paquetages Les paquetages contiennent des classes, des composants ou dautres paquetages. La visibilité entre les paquetages est limitée (classe façade) La visibilité Une bonne architecture permet la fiabilité et la flexibilité du logiciel

28 27 Les activités du projet Modélisation logique dynamique Que fait le système informatique? C Comportement des objets DDemandes de service CConditions Commande Article [sil y a du stock] Réserver un article Jai réservé réservation Contrôle stock Objet

29 28 Les activités du projet Chronologie Etude dopportunité ou Initialisation Définition et opportunité du projet Diagramme de contexte Recueil et spécification des besoins. Fonctionnalités du système dinformation Cas dutilisation Analyse du problème Étude de la logique du système dinformation (Indépendant des technologies) Modélisation métier (vue logique) Conception de la solution Décisions technologique Affinement de la vue logiques Implémentation (Programmation, diagramme de composants) Déploiement (Diagramme de déploiement) Activité de gestion de projet pendant toute la durée du projet

30

31 30 Généralités sur UML Origine Standard Objectifs Outils Contenu.

32 31 Généralités sur UML Origine Issue des méthodes objet de: Grady Booch OMT de James Rumbaugh OOSE dIvar Jacobson Origine Standard Objectifs Contenu

33 32 Généralités sur UML Standard UML est une notation standard Elle a été acceptée par lOMG (Object Management Group), en novembre 97 Un dispositif est en place à lOMG qui permet daméliorer UML de façon continue LOMG est un consortium international, il réunit environ 800 entreprises. Son but est de définir des standards pour le développement orienté objet Origine Standard Objectifs Contenu

34 33 Généralités sur UML Objectifs Modélisation des systèmes informatiques Analyse des besoins Analyse du problème Conception de la solution Implémentation, Déploiement UML est une notation graphique. Une notation permet de décrire le système informatique avec des concepts adaptés et non ambigus. Origine Standard Objectifs Contenu

35 34 Généralités sur UML Objectifs UML est une notation non une méthode Une méthode contient non seulement une notation mais aussi une démarche de projet Plusieurs démarches peuvent être associées à la notation UML. Nota: Ne pas confondre les concepts de démarche et les concepts UML

36 35 Généralités sur UML Objectifs UML est bien adapté à la démarche itérative Analyse du problème Analyse des besoins Implémentation Déploiement Conception de la solution

37 36 UML permet la modélisation du système dinformation et du système informatique Et il aide: à la réalisation à la réflexion À la documentation Il deviendra peut-être un langage de réalisation (MDA) Généralités sur UML Objectifs Un modèle est une représentation schématique de la réalité destiné à montrer son fonctionnement

38 37 Généralités sur UML Objectifs Outils UML Rational Rose Together Objectory (Softeam) Visio … Les outils Permettent la modélisation (dessin et contrôle) Gèrent un référentiel Produisent le squelette des programmes Produisent les DDL des SGBDR Produisent les interfaces des ORB (Object Request Broker) Se relient à dautres outils de développement

39 38 Généralités sur UML Contenu: Éléments UML propose des éléments de modélisation qui ont une définition sémantique et un graphisme Exemples Origine Standard Objectifs Contenu Métier Acteur Paquetage Classe Gestion articles Client raisonSociale calculerRemise Composant

40 39 Généralités sur UML Contenu: Diagrammes UML propose 9 types de diagrammes (règles de combinaison des élément standards): Cas dutilisation Classes Objets Séquence Collaboration Activité États-Transitions Composants Déploiement

41 40 Généralités sur UML Contenu: Diagrammes Exemple: Diagramme de classe ClientDétaillant ClientGrossiste Commande Client facturer() 11..*1

42 41 Généralités sur UML Contenu: Extension de la notation: stéréotypes UML est une méthode ouverte Les stéréotypes permettent lextension Un stéréotype est une variante dun élément standard, il hérite de sa sémantique, il spécifie souvent un rôle. Exemple: Une façade,un acteur sont des stéréotypes de classe Représentation graphique Chef des ventes « Acteur » Représentation textuelle Client «Entité » Client

43

44 43 Représentation du contexte du système Définir les Limites du système à développer Relations entre le système et son environnement. Gestion financière Gestion commerciale Gestion de production Bureau détude Direction Étude dopportunité Diagrammes: Cas dutilisation

45 44 Diagrammes: Cas dutilisation Gestion commerciale représente le périmètre de létude Les acteurs sont des personnes ou des systèmes en relation avec le domaine de létude. Les acteurs sont extérieurs au domaine de létude. Gestion commerciale Gestion de production Bureau détude Direction Gestion financière Étude dopportunité

46 45 Diagrammes: Cas dutilisation Pour: Structurer fonctionnellement le domaine pour décrire les exigences Répartir le travail et les responsabilités pour la spécification et la validation des besoins. Analyse des marges Fidélisation Commissions Directeur commercial Responsable CRM Chef des ventes Analyse des besoins

47 46 Les cas dutilisation Les cas dutilisation guident la MOE dans lanalyse, la conception, la réalisation et les tests. Contrat Ils sont sous la responsabilité de la MOA, ils sont la référence des validations et recettes. Validation Recette

48 47 Lanalyse des besoins Les cas dutilisation Analyse du besoin Analyse du problème de la solution Conception de la solution Opportunité Tests La conception du système Validation Périmètre du projet Implémentation Mise en oeuvre

49 48 Cas dutilisation Chaque cas dutilisation est accompagné dun texte et éventuellement de diagrammes Ceux-ci expriment les exigences du client Les exigences constituent une partie du contrat entre le client (maîtrise douvrage) et les développeurs (maîtrise dœuvre)

50 49 Cas dutilisation Exemple de rédaction Titre: Préparation de la commande fournisseur But: Déterminer la date de passation de commande Version, date de rédaction Auteur de la rédaction Acteurs du cas dutilisation: acheteur Préconditions: Les demandes dachat sont valides, elles ont été affectées à lacheteur qui initialise le processus. Postcondition: La date de passation de commande de la DA est prévue Événement initial: Affectation des DA nouvellement arrivées à un acheteur Description du scénario de base Description des flots alternatifs

51 50 Diagrammes: Cas dutilisation. Acteurs Le domaine du projet est découpé en cas dutilisation Chaque cas dutilisation représente une fonction du système informatique dont un acteur métier a besoin Un acteur métier est un rôle. Dans la démarche: on recherche dabord les acteurs métier puis les fonctions dont ils ont besoin. Commissions Chef des ventes

52 51 Diagrammes: Cas dutilisation. Acteurs Wanted Chef des ventes

53 52 Diagrammes: Cas dutilisation. Le cas dutilisation spécifie la façon dont le système est utilisé pour aider un client ou un utilisateur à atteindre ses objectifs. Il décrit un processus.

54 53 Cas dutilisation Spécifications de besoins, exigences Le texte doit être bien structuré Il est sous la responsabilité de lutilisateur Il peut être accompagné de diagrammes UML Il décrit ce que doit faire le système et non comment Rédaction des exigences Chaque cas dutilisation donne lieu à une description en texte

55 54 Cas dutilisation Spécifications de besoins, exigences Le cas dutilisation décrit un processus métier Le processus est déclenché par un événement métier Il se termine par un résultat intéressant pour lutilisateur ou par un échec Il comporte souvent plusieurs scénarios EvénementRésultat Tâches

56 55 Diagrammes:Cas dutilisation Chaque cas dutilisation est accompagné dun texte et éventuellement de diagrammes Ceux-ci expriment les exigences du client Les exigences constituent une partie du contrat entre le client (maîtrise douvrage) et les développeurs (maîtrise dœuvre)

57 56 Cas dutilisation Exemple de rédaction Titre: Passation de la commande au fournisseur But: Transmettre une commande valide au fournisseur Version, date de rédaction Auteur de la rédaction Acteurs du cas dutilisation: acheteur Préconditions: Les demandes dachat sont valides, elles ont été affectées à lacheteur qui initialise le processus. Postcondition: La commande est transmise, sa transmission est enregistrée Événement initial: Affectation des DA nouvellement arrivées à un acheteur Description du scénario de base Description des flots alternatifs

58 57 Diagramme de cas dutilisation Relations Les cas dutilisation peuvent être fractionnés. Puis reliés. relation « include » relation « extend » relation « generalise » Nota: Les flux dinformations sont indiqués dans dautres diagrammes

59 58 Cas dutilisation Relation « include » Permet d identifier des sous-ensembles communs à plusieurs cas d utilisation Règlement cotisations comptable Inscription activité Accueil Contrôle adhérent « include » Contrôle adhérent est extrait de « Règlement cotisation » et de « Inscription activité » afin de ne le décrire quune fois

60 59 Cas dutilisation Relation « include » Gestion force de vente Chef des ventes Gestion des notes de frais Gestion des notes de frais est aussi utilisé dans une autre application, on ne le décrit quune fois La relation entre les 2 cas dutilisation est exprimée dans le texte de Gestion des forces de vente Include est un stéréotype dun autre élément: la dépendance « include »

61 60 Cas dutilisation Relation « extend » Permet de décrire séparément certaines partis alternatives, optionnelles ou exceptionnelles Inscriptionactivité Accueil contrôle adhérent Inscriptionactivité inexistante « include » « extend » extension

62 61 Cas dutilisation Relation « extend » Lextension peut être planifiée dans un autre incrément que le cas dutilisation de base Lextension ne peut être activée directement Inscription activité Accueil contrôle adhérent Inscription activité inexistante « include » « extend » Texte: La relation est indiquée dans le cas extension, ici inscription activité inexistante

63 62 Cas dutilisation Relation généralisation Plusieurs cas dutilisation ont le même but Ils ont des fonctionnements différents, Ce sont les variantes dune même fonction.

64 63 Cas dutilisation Relation Généralisation Règlementcotisations comptable Règlement parcourrier Règlement par Internet « Généralisation » adhérent contrôle « include » »

65 Exercice Faire le modèle de cas dutilisation correspondant aux fonctions suivantes: Contrôle des commandes client (la saisie des commandes est faite chez le client par le commercial ou au siège à partir dun formulaire) Réception des règlements Dans ces 2 cas lidentité du client est contrôlée Traitement des anomalies commandes Le contrôle des commandes est sous la responsabilité du commercial ou de ladministration des ventes.Le comptable est responsable de la réception des règlements

66

67 66 Exercice Modèle de cas dutilisation Administration ventes Réception règlement Contrôle identité client Traitement anomalies commandes Prise de commande chez client Contrôle commande > Comptable Saisie commande au siège Commercial

68 67 Cas dutilisation Traiter le passage en caisse exemple Titre : Traiter le passage en caisse Résumé : un client arrive à une caisse avec des articles quil souhaite acheter. Le caissier enregistre les achats et récupère le paiement. A la fin de lopération, le client part avec les articles. Acteurs : principal caissier, secondaire client. Pré conditions : la caisse est ouverte (donc en service) ; un caissier y est connecté Post conditions: Le client a payé, la vente est enregistrée, le ticket de caisse a été donné au client. Traiter le passage en caisse Caissier

69 Description du flot de base : 1.Ce cas dutilisation commence quand un client arrive à la caisse avec des articles quil souhaite acheter. 2.Le caissier enregistre chaque article. Sil y a plus dun exemplaire par article, le caissier indique également la quantité. 3.La caisse détermine le prix de larticle et ajoute les informations sur larticle, à la vente en cours. La caisse affiche la description et le prix de larticle en question. 4.Après avoir enregistré tous les articles, le caissier indique que la vente est terminée. La caisse calcule et affiche le montant total de la vente. 5.Le caissier annonce le montant total au client. 6.Le client choisit le type de paiement : En cas de paiement cash, calculer la monnaie à rendre 7.La caisse enregistre la vente effectuée et imprime un ticket. 8.Le caissier donne le ticket de caisse au client. 9.Le client sen va avec les articles quil a achetés. retour

70 Pour éviter les Si dans le flot de base Les flots alternatifs sont décrits à part Flot alternatif 1: numéro didentification inconnu Cette alternative démarre au point 2 du flot de base. -La caisse indique au caissier que le numéro didentification de larticle est inconnu. Larticle ne peut alors être pris en compte dans la vente en cours. Le flot de base reprend au point 2. Flot alternatif 2 : client ne pouvant pas payer Cette alternative démarre au point 6 du flot de base. -Le client ne peut payer le total avec aucun moyen de paiement autorisé. -Le caissier annule lensemble de la vente et le cas dutilisation se termine en échec (post condition non réalisée)

71 Flot alternatif 3: client payant par chèque Cette alternative remplace le point 6 de la version de base. Le chèque est mis par le caissier dans le lecteur de chèque qui imprime le montant et la date Le caissier fait signer le chèque. Le flot de base reprend au point 7 Les pointeurs sont écrits dans les flots alternatifs et non dans le flot de base

72 71 Exercice Faire le cas dutilisation de paiement par carte en créant un cas dutilisation extension

73

74 Cas dutilisation paiement par carte Ce cas dutilisation remplace le point 6 du cas dutilisation: « Traiter le passage en caisse ». En cas de succès, le flot reprend au point 7; en cas déchec il reprend au point 6 de « Traiter le passage en caisse » Flot de base 1. Le client insère la carte dans le lecteur de carte et saisit son code Flot alternatif échec: Le code saisit est faux 3 fois de suite à la suite du point 1 Traiter le passage en caisse Caissier Payer par carte « extend »

75 74 Diagramme cas dutilisation Le diagramme de cas dutilisation montre le comportement dun système, les services visibles de lextérieur, fournis par le système dans le contexte de son environnement Exemple: Téléphone mobile Passer appel téléphonique Passer appel conversation à 3 Recevoir appel Utiliser agenda Recevoir nouvel appel « extend » Réseau mobile Utilisateur Exemple

76 75 Modélisation logique structurelle Diagramme de classe Architecture du système dinformation du système informatique Objets Classes Paquetages

77 76 Modélisation structurelle Les objets Un objet est « une chose » qui peut être parfaitement identifiée; une personne précise, une organisation, une machine ou un événement peuvent être considérés comme des objets.

78 77 Modélisation structurelle Les objets Un objet peut sauvegarder des valeurs, ces valeurs ont un nom (nom dattribut).Ces valeurs constituent létat de lobjet. létat de lobjet peut changer

79 78 Modélisation structurelle Les objets Un objet offre des opérations (son comportement) qui permettent dexaminer ou de modifier son état. Létat dun objet garde le souvenir de lexécution des opérations

80 79 Modélisation structurelle Les objets 3 représentations possibles dun objet: Valérie Date embauche = Valérie: Personne : Personne nom de lobjet nom de lobjet, nom de la classe Objet anonyme Un objet est une instance de classe

81 80 Modélisation structurelle Les Classes Les objets sont groupés en ensembles appelés classes. Les objets sont des instances de classe. Salarié nom Poste salaire payer() Lili:Salarié nom:Lili poste:DRH 3000 euros Instance de

82 81 Modélisation structurelle Les classes Une classe est une abstraction qui représente lidée ou la notion générale que lon peut avoir dun ensemble dobjets similaire Par exemple tous les salariés dune entreprise appartiennent à la classe « Salarié » Tous les objets dune classe partagent les mêmes attributs, le même comportement et les mêmes associations. Tous les salariés ont un salaire, chaque mois ils touchent leur salaire, ils travaillent pour une entreprise.

83 82 Modélisation structurelle Les Classes Pendant la phase danalyse une classe est un concept du monde réel (ex : salarié, adhérent, prime) Pendant la phase de conception elle peut être un concept technique (ex : pilote dimprimante, fenêtre…) elle est affinée par des notions techniques (ex: visibilité) Pendant la phase dimplémentation une classe est un élément du logiciel

84 83 Modélisation structurelle Les Classes Chaque classe est représentée sous la forme dun rectangle divisé en 3 compartiments. Le 1er compartiment contient le nom de la classe, le second les attributs et le 3ème les opérations Personne adressePrincipale nom facturer () Analyse Conception

85 84 Modélisation structurelle Les Attributs Chaque nom dattribut peut être accompagné de détails facultatifs tels que le type ou la valeur par défaut. Le type et la valeur par défaut seront généralement mentionnés à partir de la phase de conception. Conception

86 85 Modélisation structurelle Les attributs dérivés Un attribut dérivé peut être calculé à partir dautres attributs On le trouve: soit dans le compartiment attribut précédé dune barre oblique soit dans le compartiment opération Cest un choix de conception

87 86 Modélisation structurelle Les opérations Une opération spécifie une action quun objet doit exécuter Une méthode est une procédure qui implémente une opération Généralement En phase danalyse, on écrit seulement le nom de lopération En phase de conception on écrit La visibilité Les paramètres Le type de retour La portée

88 87 Modélisation structurelle Les opérations adresse nom solde Facturer ( remise : Int = 0, montant : Int ) : montantDu {auteur=Rémi} « entité » créer Portée de classe Portée dinstance Personne

89 88 Modélisation structurelle La visibilité UML définit 3 niveaux de visibilité pour les attributs et les opérations + Public qui rend lélément visible à tous les clients de la classe · # Protégé qui rend lélément visible aux sous-classes de la classe Privé qui rend lélément visible aux opérations de la classe seule

90 89 Modélisation structurelle La visibilité Client nom adressePrincipale enregistrer () # facturer () + consulter nom()

91 90 Modélisation structurelle Les relations Lassociation La généralisation La dépendance La réalisation

92 91 Passe > Modélisation structurelle Lassociation Il existe des liens entre les objets Exemple: Les commandes sont liées aux clients Commande dateCommande Client raisonSociale 1 *

93 92 Modélisation structurelle Multiplicité Un objet peut être relié à plusieurs objets: Un client peut être relié à plusieurs commandes. Mais une commande ne peut être reliée qua un seul client et elle est nécessairement reliée à un client. Ces contraintes expriment la multiplicité dune classe dans sa relation avec une autre ou avec elle-même

94 93 Modélisation structurelle La multiplicité sécrit : 1 toujours ou 1 * ou 0..*0 à plusieurs 1..*1 à plusieurs m..nde m à n (entiers naturels)

95 94 Modélisation structurelle Classes dassociation Chaque lien de l association est reli é à un objet de la classe association. Chaque objet de la classe association est identifi é par les r é f é rences aux classes reli é es ; Il ne peut y avoir plusieurs liens entre les mêmes objets On indique cette classe si le lien est porteur d attributs ou d op é rations. Une classe d association peut être associ é e à d autres classes Personne nom Diplôme niveau DiplômeObtenu date obtention * * * exercice

96 95 * Modélisation structurelle Rôle Un rôle décrit la part prise par une classe dans une association, il est écrit sur lassociation du coté de la classe correspondante Le rôle permet de distinguer plusieurs associations entre les 2 même classes * Personne Ville * 1 travailleur résident nom

97 96 Modélisation structurelle Associations qualifiées Le qualificatif permet de retrouver 1 ou n objets à l autre bout de l association il s é lectionne certains objets) Nom de fichier est un identifiant relatif pour Fichier Banque 1 * compte Personne 1 1 Sans le qualificatif la multiplicité serait * F ichierRépertoire Nom de fichier

98 97 Modélisation structurelle Associations qualifiées Exercice Comment modéliser les chambres dune chaîne dhôtels en indiquant que les hôtels ont la liberté de leur numérotation

99

100 ChambreHôtel N°Chambre 1 1 Autre exemple PersonneSociété Matricule 1 * Emploi Salaire

101 100 Modélisation structurelle Contraintes dintégrité sur association { ou exclusif } Musée Statue Site Les contraintes dintégrité sont de format libre, elles sont écrites entre accolades Commune Personne habitant Conseiller municipal * * 1 * Sous-ensemble

102 101 Modélisation structurelle Association réflexives Un objet d une classe peut être associ é à un autre objet de la même classe Personnel 1 chef 1 collaborateur 1..*

103 102 Modélisation structurelle Associations n-aires Des associations peuvent relier plus de 2 classes Joueur Record Équipe Année Gain Un record est identifié par une équipe, un joueur, une année

104 N° place Nom catégorie Prix place Date de représentation Nom spectacle Nom du metteur en scène Nom acteur principal Nom agence Adresse de lagence N° de téléphone agence N° billet Nom du pompier de service Heure de représentation Date prise réservation Exercice : Gestion des représentations dun théâtre Construire un diagramme de classes à partir des données suivantes : Suite

105 Le théâtre propose des spectacles joués en une ou plusieurs représentations. Pour chaque spectacle, sont annoncés le nom du metteur en scène et du ou des acteurs principaux. Le théâtre peut offrir plusieurs représentations le même jour. Plusieurs spectacles peuvent être joués le même jour. En revanche, un seul spectacle est joué par représentation. Suite Respecter les règles de gestion suivantes

106 Les agences de spectacles sont contractuellement autorisées à réserver des places par avance. Les autres clients doivent faire des achats fermes. Pour chaque place, à chaque représentation est attribué un billet lors de la vente. Le prix de la place est fonction de la catégorie de la place, et de la représentation

107

108

109 108 Modélisation structurelle Lagrégation L agr é gation est une forme particulière d association qui exprime un couplage plus fort entre classes. L agr é gation permet de repr é senter les relations de type maître esclave, tout et partie, ou composé et composant. Mission * Agrégation simple Développeur

110 109 Modélisation structurelle Agrégation de composition Lagrégat « possède » ses parties, Les partie sont « à lintérieur » de lagrégat ; Un objet ne peut être lélément de plusieurs agrégats. La destruction de lagrégat entraîne la destruction des parties Commande LigneDeCommande quantitéCommandée préparer 1..* 1 1 Article référenceArticle * datCom Agrégation de composition

111 110 Exercice Un médecin veut modéliser des informations concernant ses patients, leurs consultations, leurs maladies.

112

113 112 Exercice Patient Consultation Date 0..*1 Nom Maladie Nom 0..* Atteint de

114 113 Modélisation structurelle Généralisation et spécialisation La généralisation consiste à factoriser les éléments communs (attributs, opérations, relations) dun ensemble de classes dans une classe plus générale appelée super-classe. Les sous-classes héritent des caractéristiques de leur super-classe

115 114 Modélisation structurelle Généralisation et spécialisation Fournisseur régler() Tiers raisonSociale Client facturer() Banque Code Fournisseur et client héritent de raison sociale et de lassociation à banque facturer est spécifique à Client; régler est spécifique à Fournisseur Exemple: Sous-classe Super-classe

116 115 Modélisation structurelle Généralisation et spécialisation Exemple: Tiers raisonSociale Client facturer() Banque Code ClientNat ClientExport TypeCrédit Fournisseur régler() Devise

117 116 Modélisation structurelle Généralisation et spécialisation Exercice Une société darchéologie vous demande de faire son diagramme de classe Elle étudie des objets archéologiques, ces objets appartiennent à une nation; ils peuvent être des bâtiments, des statues ou des bijoux. Tous ces objets peuvent se trouver dans un site, les statues et les bijoux peuvent se trouver dans un musée. Les bijoux peuvent aussi se trouver chez un particulier. On dispose dinformations sur les nations, les sites et les particuliers.

118

119 ObjetNation Code Bâtiment Musée Particulier Statue Bijou ObjetMobile Site Exercice 0..1 * 1 * *

120 119 Modélisation structurelle Contrainte dintégrité sur généralisation StatueBijou Objet Un objet archéologique ne peut pas être à la fois une statue et un bijou {complétude} Statue Bijou Objet Un objet archéologique ne peut être quune statue ou un bijou {Ou exclusif}

121 120 Modélisation structurelle Classe abstraite Activité nom activité montant planifier() planifier() Classe abstraite Une classe abstraite ne peut être instanciée, ses sous-classes sont concrètes {complétude} lieu planifier() Entraineur Classe concrète Toutes les classes ont des propriétés spécifiques TennisFoot

122 121 Modélisation structurelle Représentation de larchitecture Une bonne architecture doit permettre: La réutilisation La répartition du travail entre équipes Létude dimpact lors des changements fonctionnels, techniques et dexplitation Larchitecture est la description des différentes parties du système et de leurs relations

123 122 Modélisation structurelle Représentation de larchitecture UML offre des notations destinées à découper Le système dinformation Le logiciel À isoler les éléments du logiciel

124 123 Représentation de larchitecture Les Paquetages Un paquetage est un conteneur il permet de représenter lorganisation du système dinformation et du logiciel. Il peut contenir tous les éléments de modélisation : des classes, des interfaces, des composants, des nœuds, des cas dutilisation, des diagrammes, dautres paquetages…

125 124 Représentation de larchitecture Les Paquetages Chaque élément est la propriété directe dun paquetage unique. Le paquetage forme un espace de nommage Les paquetages sont représentés dans le diagramme de classe

126 125 Modélisation structurelle Représentation de larchitecture Architecture technique 1 paquetage= n éléments 1 composant=1 ou n classes Métier Commande Gestion articles paquetagecomposantclasse

127 126 Modélisation structurelle Représentation de larchitecture Les Paquetages livraison (from vente) article (from stock) Commercial::Vente + commande + client livraison java.io Le paquetage vente appartient à commercial dépendance Paquetages leur contenu et leurs dépendances Classe non visible à lextérieur du paquetage stock +stockFaçade _article _ entrepôt Classe livraison appartient à vente commercial

128 127 Modélisation de la dynamique du système Diagrammes dinteraction Diagramme de séquence Diagramme de communication Diagramme dactivité Diagramme État-Transition

129 128 Modélisation de la dynamique du système Les diagrammes dinteraction et dactivité précisent le texte du cas dutilisation Diagramme de classe Cas dutilisation n diagrammes de séquence n diagrammes dactivité flot de base Flots alternatifs Texte Lors de lanalyse des besoins,ils expriment les interactions entre les utilisateurs (acteurs) et le système. Lors de lanalyse-conception, ils expriment les interactions entre les objets du système

130 129 Modélisation de la dynamique Diagramme de séquence Un diagramme de séquence représente un ou plusieurs scénarios dun cas dutilisation (cas dutilisation parent) Pour un cas dutilisation, il peut y avoir autant de diagrammes de séquence quil y a de scénarios

131 130 Modélisation de la dynamique Diagramme de séquence Le diagramme de séquence transforme la structure fonctionnelle, décrite par le cas dutilisation en une structure objet Il représente les messages que les objets doivent séchanger pour réaliser la fonction. Ces messages sont des appels dopérations ou de groupes dopérations. Ils sont effectués par des objets vers des objets. Les objets sont des acteurs ou des objets logiciels.

132 131 Modélisation de la dynamique Diagramme de séquence Acteur : Accueil : activité : adhérent Demande inscription activité inscription Demande supplément cotisation Paiement Un objet de la classe activité Message La flèche est dans le sens du flux de contrôle Ligne de vie de lobjet Période dactivité de lobjet retour

133 132 Modélisation de la dynamique Diagramme de séquence Un objet ou un participant peut être anonyme, identifié, qualifié : adhérentMartin : adhérent adhérent actif AnonymeQualifiéIdentifié Lobjet adhérent appartient à la classe adhérent : adhérent Adhérent est ici un objet du logiciel

134 133 Modélisation de la dynamique Diagramme de séquence, concepts Acteur Un acteur déclenche un scénario (il a été identifié dans le cas dutilisation parent) Scénario Un diagramme de séquence représente un ou plusieurs scénarios (flot de base, flots alternatifs). On peut représenter lensemble des scénarios dun cas dutilisation avec 1 ou plusieurs diagrammes de séquence

135 134 Modélisation de la dynamique Diagramme de séquence, concepts Événements (ou messages) Un diagramme de séquence montre les messages que les objets séchangent. Ces messages sont des événements : Ils déclenchent des opérations sur les objets destinataires Ligne de vie La dur é e de vie d un objet est mat é rialis é e par une ligne verticale pointill é e.

136 135 Modélisation de la dynamique Diagramme de séquence Exercice Faire le diagramme de séquence correspondant à cet extrait du cas dutilisation Règlement cotisations Suite à un appel de cotisation (qui a été fait longtemps avant et qui, par conséquent est décrit dans un autre cas dutlisation) les adhérents paient leur cotisation, le paiement est enregistré, les appels de cotisation correspondants sont mis à jour, un accusé de réception est retourné à ladhérent Règlement cotisations Adhérent Paiement AppelCotisation Quelles interactions doit-il y avoir entre les objets de ces classes pour réaliser le cas dutilisation: Règlement de cotisation?

137

138 137 Modélisation de la dynamique Diagramme de séquence unPaiement : Adhérent unAppel Cotisation paiement cotisation accuséRéception

139 : Client Clientthéatre : Activité : Spectacle : Représentation : PlacePaiement [client pas OK] Contrôle activité [activité pas OK] Contrôle client [Réservation OK] Flot de contrôle Flot dinformations Le flot dinformations est facultatif Il revient par le chemin inverse du flot de contrôle Les messages sont synchrones par défaut retour

140 139 Diagramme de séquence Représentation des paramètres : ClientClient Demande réservation(code client,code activité) Opération Paramètres Le nom de lopération peut être accompagné de ses paramètres Client est un objet logiciel stéréotype entité

141 140 Diagramme de séquence, Représentation de plusieurs scénarios adhérent Un paiement Un appel cotisation paiement cotisation Qualité du montant Accusé réception Avis solde [Si montant OK] [Else] Alt Par un cadre dinteraction

142 141 Diagramme de séquence, Représentation de plusieurs scénarios Exercice le service commercial doit la contrôler Si elle nest pas correcte, lannuler Si elle est correcte, Faire le bon de livraison Faire la facture Dans tous les cas mémoriser son état A la réception de la commande: Found message= la source du message est indéterminée Recevoir la commande service commercial

143

144 Recevoir la commande service commercial CommandeLivraisonFacture Contrôler Refuser Livrer Facturer Enregistrer létat Alt [Commande pas OK] [else]

145 15 octobre JardinierPlantoirSolBulbe Prendre Creuser [Pour chaque bulbe] Placer Ranger Diagramme de séquence, Représentation d une it é ration Par un cadre dinteraction loop

146 145 Diagramme de séquence, Représentation d une it é ration A la réception de la commande: le service commercial doit la contrôler Il saisit la commande Il contrôle que chaque article est en stock Sinon, il annule larticle Si la commande est OK Il fait la facture

147

148 Recevoir la commande service commercial CommandeArticleFacture Saisir Annuler larticle En stock? Facturer [Commande OK] loop [Article pas OK] [Pour chaque article]

149 148 Modélisation de la dynamique Diagramme de communication Le diagramme de communication est une autre forme de diagramme dinteraction : Adhérent :Paiement : Appel cotisation 2:cotisation 1. paiement 3.Accusé de réception [montant OK] 3.Avis de solde [écart]

150 149 Modélisation de la dynamique Diagramme de communication Classes correspondantes adhérent nom adhérent activité nom activité montant **** association Correspondance avec le diagramme de classe séquence : Adhérent :Paiement : Appel cotisation 2:cotisation 1. paiement 3.Accusé de réception [montant OK] 3.Avis de solde [écart] Flux de contrôle Message Lien

151 150 Modélisation de la dynamique Diagramme de communication Un lien est une connexion entre objets, qui indique quune forme de navigation et de visibilité entre eux est possible, cest une intance dassociation : Adhérent :Paiement : Appel cotisation 2:cotisation 1. paiement 3.Accusé de réception [montant OK] 3.Avis de solde [écart] Flux de contrôle Message Lien

152 151 Paiement : Client Clientthéatre : Activité : Spectacle : Représentation : Place 1: Demande réservation 2: Contrôle client 3: [client pas OK] 4: Contrôle activité 5: [activité pas OK] 6: 7: 8:9: 10: 11: 12: 13:14: 15: [Réservation OK] Modélisation de la dynamique Diagramme de communication seqence Représentation proche du diagramme de classe

153 152 Diagrammes dinteraction et démarche Diagramme de séquence Interactions entre les acteurs et le système (Analyse des besoins) Interactions entre les objets logiciels (Analyse du problème et conception) Diagramme de communication Interaction entre les acteurs (Analyse des besoins) Diagramme de flux (Analyse des besoins) Interaction entre les objets logiciels (Analyse du problème et conception) (surtout sil ny a pas de chronologie ou si on veut montrer les liens entre les objets) classe système

154 153 Modélisation de la dynamique Diagramme dactivité Permet de représenter une logique procédurale, un processus métier, un workflow On peut représenter le déroulement des actions dans des chemins alternatifs ou parallèles

155 154 Modélisation de la dynamique Diagramme dactivité Enregistrer la commande Contrôler Commande Sortir article Expédier Commande Déroulement séquentiel des actions dun processus métier Nœud initial Action Nœud final

156 155 Diagramme dactivité Partitions Client VentesEntrepôt Enregistrer la commande Contrôler Commande Sortir article Expédier Commande Workflow Les partitions représentent les ressources qui réalisent les actions Ressource

157 156 Diagramme dactivité Décisions Commander Sortir article Client VentesEntrepôt [OK] [Pas OK] Annuler la commande Contrôler Commande Sortir article Expédier Commande Chemins alternatifs Enregistrer état Commande OU Pour que laction Enregistrer état commande sexécute, il suffit qune des actions précédentes soit terminée

158 157 Exercice Lorsque le réveil sonne, prendre le petit déjeuner puis préparer le cartable (sauf le mercredi) puis, dans tous les cas, se laver Modélisation de la dynamique Diagramme dactivité

159

160 Sonnerie réveil Déjeuner mercredi? Préparer cartable Se laver non oui

161 160 Les diagrammes dactivité Barre de synchronisation Préparer Commande VentesEntrepôt Contrôler Commande [OK] [Pas OK] Commande expédiée administration Préparer bon livraison Contrôler Commande Préparer bon livraison Barre de synchronisation (fork) Barre de synchronisation (joint) Chemins parallèles ET

162 161 Les diagrammes dactivité Barre de synchronisation Explication du schéma précédent Si le contrôle de la commande est satisfaisant (OK) on peut faire le bon de livraison et préparer la commande, dans nimporte quel ordre successivement ou parallèlement Pour expédier la commande il faut que sa préparation soit terminée et que le bon de livraison soit fait Chemins parallèles

163 162 Exercice lorsque le réveil sonne Lorsque le réveil sonne, lhomme commence par prendre sa douche. Au sortir de la douche, il réveille sa femme et effectue sa gymnastique Ensuite, il prépare le petit déjeuner pour sa famille, et enfin prépare la voiture pour le départ La femme, à son réveil, fait sa toilette matinale, puis prépare les cartables des enfants – sauf le mercredi – et enfin prend son petit déjeuner avec les enfants. Tout le monde se retrouve ensuite en voiture lhomme fait linspection finale et la mise en route.

164

165 Sonnerie réveil Douche Gym Préparation petit déjeuner Préparation voiture Inspection et mise en route Famille en route Toilette Préparation cartable Petit déjeuner Mercredi? [ Non ] [ Oui ] FemmeHomme Exercice

166 165 Les diagrammes dactivité Décomposition dune action Les actions peuvent être décomposées en sous-activités. On peut ainsi décrire un processus globalement puis laffiner progressivement

167 Réception commande Exécution commande Envoi facture Traitement paiement Livrer Clore l'ordre Le rateau signifie que laction est décomposable en sous activités

168 Livrer Livraison normale Livraison urgente Livraison normale Livraison urgente Exécution commande Clore l'ordre

169 Exercice Détailler lexercice: « lorsque le réveil sonne » Pour préparer le petit déjeuner lhomme sort les ingrédients Si le café manque, il prend du thé. Il prépare soit le thé soit le café Il dresse la table

170

171 170 Les diagrammes dactivité Invocation dune méthode Dans une action, on peut invoquer une méthode Livrer Livraison normale Livraison urgente Livraison normale Livraison urgente Exécution commande Clore l'ordre Ordre::SuppressOrder Nom de la classe Nom de la méthode

172 171 Les diagrammes dactivité Signaux Signal temporel Une activité écoute ces signaux en permanence, ils constituent un événement dun processus extérieur, le diagramme définit comment lactivité réagit à ces événements

173 Faire les bagages Partir pour l'aéroport Taxi arrive 2 heures avant le vol Je ne pars à laéroport que si mes bagages sont faits et si le taxi est arrivé Laction Partir pour laéroport accepte le signal Taxi arrive Une action peut aussi émettre des signaux Signal temporel Signal accepté

174 Réserver litinéraire Retenir itinéraire Annuler itinéraire Itinéraire confirmé Envoyer litinéraire Signal émis Signal accepté Attendre 48 heures

175 Exercice Une commande Fournisseur est rédigée puis envoyée A la réception de laccusé de réception, la commande est validée. Si 2 semaines après lenvoi de la commande, laccusé de réception du fournisseur nest toujours pas parvenu, la commande est annulée

176

177 Rédiger commande Commande validée Annuler commande Accusé de réception Envoyer commande Attendre 2 semaines

178 177 Région dexpansion Une région dexpansion délimite dans un diagramme dactivité une zone ou les actions sexécutent une fois pour chaque élément dune collection

179 Choisir un thème Ecrire larticle Relire larticle Publier la revue « concurrent » On écrit n article, chacun est relu. Les différents articles peuvent être écrits en même temps Région dexpansion

180 Exercice Contrôle dune commande: On contrôle le client On contrôle lexistence et la présence en stock de chaque article Si tout est correct, on établit une facture Sinon on refuse la commande

181 Contrôle client Existence de larticle Contrôle stock de larticle Etablir la facture

182 181 Modélisation de la dynamique Les diagrammes dactivité Activités et flot dobjets Dans un diagramme dactivité, il est possible de faire apparaître clairement les objets créés, détruits ou modifiés, par une activité.. Les objets modifiés sont indiqués par des flèches en pointillé. Commander Etablir Devis D : Devis [établi]

183 182 Modélisation de la dynamique Les diagrammes dactivité Activités et flots dobjets Préparer commande Client VentesEntrepôt [OK] [Pas OK] Commande annulée Commande expédiée Décision commande [préparée] commande [préparée] commande [contrôlée] Enregistrer la commande Contrôler Commande Expédier Commande

184 183 Modélisation de la dynamique Diagramme État-Transition Naît Agit sur les autres objets en envoyant des messages Est modifié par les autres objets en recevant des messages Meurt La vie dun objet:

185 184 Modélisation de la dynamique Diagramme État-Transition Concepts É tat Un objet passe par différents états au cours de son existence Un état est une situation au cours de la vie dun objet pendant la quelle il satisfait certaines conditions, exécute certaines activités ou répond à certains événements Létat dun objet est matérialisé par la valeur de certains de ses attributs et par ses liens

186 185 Modélisation de la dynamique Diagramme État-Transition Concepts Transitions Une transition représente le passage dun état à un autre Événements Un événement est un stimulus qui peut déclencher une transition détat

187 186 Modélisation de la dynamique Diagramme état-transition Le diagramme détats-transitions représente: Les différents états possibles dun objet Les opérations qui peuvent être exécutées dans cet état Les événements qui provoquent des transitions dun état à un autre.

188 Diagramme état-transition commande commande valide entry: mise en attente exit/^: bon de préparation commande invalide commande servie commande en enregistrement entry: contrôle client do: contrôle article Urgence / priorité exit: décision priseen compte commande [ non ] [oui ] [ stock OK ] / ordre de servir Etat initial Etat final Commande refusée Evénement déclencheur condition Opération courte pendant la transition Opération courte pendant létat Opération longue Durée de létat Événement qui ne change pas létat Activité Envoi dévénement

189 188 Modélisation de la dynamique Diagramme état-transition Plusieurs types dopérations: Une opération longue ou activité se prolonge autant que dure létat est précédée de la mention do: Opérations courtes ou actions pratiquement sans durée:

190 189 Modélisation de la dynamique Diagramme état-transition Opérations courtes ou actions, pratiquement sans durée: Précédées de entry lorsquelles sexécutent au moment ou lobjet entre dans le nouvel état Précédées de exit lorsquelles sexécutent au moment ou lobjet sort dun état Précédées de: / lorsquelles sont déclenchées par un événement

191 190 Modélisation de la dynamique Diagramme état-transition Conditions Les conditions sont encadrées par des crochets Une condition peut avoir une certaine durée alors quun événement est instantané Condition:Je sors si le temps est beau Événement: sil se met à pleuvoir, je rentre

192 191 Modélisation de la dynamique Diagramme état-transition Monter le diagramme détats-transitions représentant les différents états que peut prendre, au sens de létat civil, la classe INDIVIDU Exercice

193

194 CÉLIBATAIRE Naissance MARIÉDIVORCÉVEUF DÉCÉDÉ Décès individu Contrat de mariage signé Jugement de divorce Contrat de mariage signé Décès conjoint PACSÉ Contrat PACS signé Contrat PACSE signé iDécès individu Rupture contrat

195 194 Modélisation de la dynamique Diagramme état-transition Sous- état Un sous- état est un état emboîté dans un autre état. Un état composé peut contenir soit des sous-états concurrents, soit des sous- états séquentiels

196 195 Modélisation de la dynamique Diagramme état-transition Sous-état Sous-état séquentiel Plante en croissance Plante non mure Plante à maturité on Disponibilité[ temps favorable ]: Récolter do: Arroser Plante récoltée Plante non mure Plante à maturité Disponibilité[ temps favorable ] / Récolter

197 196 Modélisation de la dynamique Diagramme état-transition Sous-état Plante semée Plante en hibernation Plante en croissance Plante récoltée Bonne pratique On fait dabord un diagramme global, pour avoir une vision densemble, puis on affine en recherchant les états emboîtés.

198 197 Modélisation de la dynamique Diagramme détats concurrents et synchronisation Préparation Emission do: Distribuer billets exit: billets pris do: éjecter carte exit: carte prise Prêt à initialiser do: Distribuer billets exit: billets pris do: éjecter carte exit: carte prise Ce distributeur de billets fournit les billets ou la carte dans un ordre indifférent For k join t

199 198 La modélisation de l implémentation Les Composants Les composants sont des éléments physiques comme les exécutables, les composants Com, les EJB, les biblioth è ques, les tables, les fichiers et les documents Un composant peut r é aliser une interface définie dans le mod è le logique G é néralement, les services d un composant sont disponibles uniquement à travers leur interface

200 199 La modélisation de l implémentation Les Composants, organisation On peut regrouper les composants en paquetages Les composants sont des éléments de la gestion de configuration. On détermine les composants à partir des cas dutilisation et des postes de travail. Les composants sont distribués sur les postes de travail

201 200 La modélisation de l implémentation Les Composants La distribution des composants permet un découplage entre les applications et le métier et facilite La réutilisation La maintenance La flexibilité

202 201 La modélisation de l implémentation ………………. …... Développement par composants On créé un syst è me à partir de composants, On le fait é voluer En ajoutant de nouveaux composants En remplaçant les anciens Sans avoir à reconstruire le syst è me grâce aux interfaces

203 202 La modélisation de l implémentation Diagramme de composants Servir disponibilité Le composant Servir contient les classes Article et Entrepôt Livraison interfaces Article +contrôle stock() +préparation() > disponibilité Entrepôt +préparation() livraison

204 203 Modélisation du déploiement Nœud Un nœud représente une ressource de calcul Un composant peut être déployé par un ou plusieurs nœud

205 Diagramme de déploiement Client 1 Serveur Client 2 Livraison Servir « support »

206

207 206 Description des processus De lanalyse des besoins à la conception : client systè système effectuez votre choix type de végétal pourquoi?(de l'ombre?des fruits?des fleurs?) des arbres réponse nature du sol ensoleillement Planche de fruits idem des fruits choix de fruit planche de fleurs choix de fleurs des fleurs idem planche de silhouettes de l'ombre choix de silhouette liste de choix possibles idem Diagramme de séquence système Diagramme de séquence objet logiciel Le diagramme de séquence retour

208 Représentation du dialogue entre lacteur et le système. On représente les flux de données Quelles données sont saisies Quelles données sont affichées. Eventuellement les traitements importants effectués par le système. : client systè système effectuez votre choix type de végétal pourquoi?(de l'ombre?des fruits?des fleurs?) des arbres réponse nature du sol ensoleillement Planche de fruits idem des fruits choix de fruit planche de fleurs choix de fleurs des fleurs idem planche de silhouettes de l'ombre choix de silhouette liste de choix possibles idem Cas dutilisation Scénario DiagrammeSéquence 1 1..* 1 0..* 0..1 Diagramme séquence système Diagr. séquence objets logiciel Opération système

209 Les opérations système Opérations système :système : RespFormation initialiserFormation (titre, durée, prix) creerFormation( ) creerContenu( ) creerContenu( audience, prerequis, objectifs, outils, plan ) creerSession(date debut, lieu) creerSession() gestion Catalogue Exemple Conseil Un diagramme de séquence par fonction (Créer, Modifier, Supprimer, Editer,../) : RespFormation

210 209 Identifier les opérations système creerFormation() creerContenu() creerSession() creerFiliere() modifierFormation() modifierContenu() modifierSession() modifierFiliere() ….. :Système :système : Utilisateur initialiserFormation (titre, durée, prix) creerFormation( ) creerContenu( ) creerContenu( audience, prerequis, objectifs, outils, plan ) creerSession(date debut, lieu) creerSession retour

211 210

212 Description des données Référence matière, Adresse de l'élève, Nombre d'heures, Nom de la classe, Nom de l'élève, Nom du professeur, Valeur de la note, Numéro de salle, Prénom de l'élève Règles de gestion A chaque classe est attribuée une seule salle de cour Chaque matière est enseignée par un seul professeur Pour chaque classe et chaque matière est défini un nombre fixe d'heures de cours A chaque élève est attribuée une seule note par matière L'établissement scolaire gère les emplois du temps des professeurs, des élèves et le contrôle des connaissances. retour

213 212

214

215 214


Télécharger ppt "Unified Modeling Language 2 Plan du cours 1. Caractéristiques de lobjet Caractéristiques de lobjet 1. Modes de développement Modes de développement 2."

Présentations similaires


Annonces Google