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

UML Unified Modeling Language.

Présentations similaires


Présentation au sujet: "UML Unified Modeling Language."— Transcription de la présentation:

1 UML Unified Modeling Language

2 Plan du cours Caractéristiques de l’objet Les activités du projet
Modes de développement Les activités du projet Généralités sur UML Diagrammes Cas d’utilisation Etude d’opportunité Analyse des besoins Modélisation logique structurelle Objets Classes Architecture

3 Plan du cours Modélisation de la dynamique
Diagramme de séquence Diagramme de communication Diagramme d’activité Diagramme Etat-Transition Modélisation de l’implémentation et du déploiement Diagramme de composant Diagramme de déploiement

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?

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

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

7 Caractéristiques de l ’objet
La brique de base d’un 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

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 d’un autre objet que selon certaines conditions définies dans le programme retour

9 Caractéristiques de l ’objet
Un objet est une instance de classe Tous les objets d’une 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

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

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

12 Modèle de développement
Avantages du modèle incrémental L’implication et la satisfaction de l’utilisateur La gestion des risques L’intégration progressive

13

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

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

16 Activités du projet Gestion de projet Opportunité
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 d’opportunité + rapport d’analyse des besoins + la V1 du plan projet constituent le cahier des charges Analyse du besoin Analyse du problème Gestion de projet Conception de la solution Le cahier des charges est un élément essentiel du contrat Implémentation

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

18 Les activités du projet Etude d’opportunité
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 Analyse du besoin Analyse du problème Conception de la solution On modélise le périmètre du projet et son contexte Implémentation

19 Les activités du projet Etude d’opportunité
Diagramme de contexte Etudes Gestion de production Client Gestion des stocks L’ellipse 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 Commercial

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

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

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

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

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

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

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 d’autres paquetages. La visibilité entre les paquetages est limitée (classe façade) Une bonne architecture permet la fiabilité et la flexibilité du logiciel

27 Les activités du projet Modélisation logique dynamique
Que fait le système informatique? C Comportement des objets D Demandes de service C Conditions Objet Commande Article [s’il y a du stock] Réserver un article Contrôle stock réservation J’ai réservé

28 Les activités du projet Chronologie
Etude d’opportunité ou Initialisation Définition et opportunité du projet Diagramme de contexte Recueil et spécification des besoins. Fonctionnalités du système d’information Cas d’utilisation Analyse du problème Étude de la logique du système d’information (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

29

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

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

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

33 Généralités sur UML Objectifs
Origine Standard Objectifs Contenu 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. Insérer Notation ULM, le bas de la p 15

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

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

36 Généralités sur UML Objectifs
UML permet la modélisation du système d’information 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) Un modèle est une représentation schématique de la réalité destiné à montrer son fonctionnement

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 à d’autres outils de développement

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

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

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

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 l’extension Un stéréotype est une variante d’un é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 Client Client «Entité » Chef des ventes « Acteur » Représentation textuelle

42

43 Diagrammes: Cas d’utilisation Étude d’opportunité Gestion commerciale
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

44 Diagrammes: Cas d’utilisation
Étude d’opportunité Diagrammes: Cas d’utilisation 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

45 Diagrammes: Cas d’utilisation
Analyse des besoins Diagrammes: Cas d’utilisation 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 Directeur commercial Chef des ventes Commissions Fidélisation Responsable CRM

46 Contrat Les cas d’utilisation Validation Les cas d’utilisation guident la MOE dans l’analyse, la conception, la réalisation et les tests. Recette Ils sont sous la responsabilité de la MOA, ils sont la référence des validations et recettes.

47 Les cas d’utilisation Analyse du besoin
Opportunité Analyse du besoin Périmètre du projet Analyse du problème de la solution L’analyse des besoins Conception de la solution Validation La conception du système Implémentation Mise en oeuvre Tests

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

49 Cas d’utilisation 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 d’utilisation: acheteur Préconditions: Les demandes d’achat sont valides, elles ont été affectées à l’acheteur 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

50 Diagrammes: Cas d’utilisation. Acteurs
Chef des ventes Commissions Le domaine du projet est découpé en cas d’utilisation Chaque cas d’utilisation 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 d’abord les acteurs métier puis les fonctions dont ils ont besoin.

51 Diagrammes: Cas d’utilisation. Acteurs
Chef des ventes Wanted

52 Diagrammes: Cas d’utilisation.
Le cas d’utilisation 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.

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

54 Cas d’utilisation Spécifications de besoins, exigences
Le cas d’utilisation 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 l’utilisateur ou par un échec Il comporte souvent plusieurs scénarios Evénement Résultat Tâches

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

56 Cas d’utilisation 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 d’utilisation: acheteur Préconditions: Les demandes d’achat sont valides, elles ont été affectées à l’acheteur 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

57 Diagramme de cas d’utilisation Relations
Les cas d’utilisation peuvent être fractionnés. Puis reliés. relation « include » relation « extend » relation « generalise » Nota: Les flux d’informations sont indiqués dans d’autres diagrammes

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

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

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

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

62 Cas d’utilisation Relation généralisation
Plusieurs cas d’utilisation ont le même but Ils ont des fonctionnements différents, Ce sont les variantes d’une même fonction.

63 Cas d’utilisation Relation Généralisation
« include » » contrôle comptable Règlement cotisations « Généralisation » Règlement par courrier Règlement par Internet adhérent

64 Exercice Faire le modèle de cas d’utilisation 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 d’un formulaire) Réception des règlements Dans ces 2 cas l’identité du client est contrôlée Traitement des anomalies commandes Le contrôle des commandes est sous la responsabilité du commercial ou de l’administration des ventes.Le comptable est responsable de la réception des règlements

65

66 Exercice Modèle de cas d’utilisation
Prise de commande chez client Commercial Contrôle identité client <<include>> <<généralisation>> <<include>> Réception règlement Comptable Contrôle commande <<extend>> Saisie commande au siège Administration ventes Traitement anomalies commandes

67 Cas d’utilisation Traiter le passage en caisse
Caissier exemple Titre : Traiter le passage en caisse Résumé : un client arrive à une caisse avec des articles qu’il souhaite acheter. Le caissier enregistre les achats et récupère le paiement. A la fin de l’opé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.

68 Description du flot de base :
Ce cas d’utilisation commence quand un client arrive à la caisse avec des articles qu’il souhaite acheter. Le caissier enregistre chaque article. S’il y a plus d’un exemplaire par article, le caissier indique également la quantité. La caisse détermine le prix de l’article et ajoute les informations sur l’article, à la vente en cours. La caisse affiche la description et le prix de l’article en question. 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. Le caissier annonce le montant total au client. Le client choisit le type de paiement : En cas de paiement cash, calculer la monnaie à rendre La caisse enregistre la vente effectuée et imprime un ticket. Le caissier donne le ticket de caisse au client. Le client s’en va avec les articles qu’il a achetés. retour

69 Pour éviter les Si dans le flot de base
Les flots alternatifs sont décrits à part Flot alternatif 1: numéro d’identification inconnu Cette alternative démarre au point 2 du flot de base. La caisse indique au caissier que le numéro d’identification de l’article est inconnu. L’article 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 l’ensemble de la vente et le cas d’utilisation se termine en échec (post condition non réalisée)

70 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

71 Exercice Faire le cas d’utilisation de paiement par carte en créant un cas d’utilisation extension

72

73 Traiter le passage en caisse
Cas d’utilisation paiement par carte Ce cas d’utilisation remplace le point 6 du cas d’utilisation: « 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 Payer par carte « extend » Traiter le passage en caisse Caissier

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

75 Modélisation logique structurelle Diagramme de classe
Architecture du système d’information du système informatique Objets Classes Paquetages

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.  

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

78 Modélisation structurelle Les objets
Un objet offre des opérations (son comportement) qui permettent d’examiner ou de modifier son état.   L’état d’un objet garde le souvenir de l’exécution des opérations

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

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

81 Modélisation structurelle Les classes
Une classe est une abstraction qui représente l’idée ou la notion générale que l’on peut avoir d’un ensemble d’objets similaire Par exemple tous les salariés d’une entreprise appartiennent à la classe « Salarié » Tous les objets d’une 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.

82 Modélisation structurelle Les Classes
Pendant la phase d’analyse 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 d’imprimante, fenêtre…) elle est affinée par des notions techniques (ex: visibilité) Pendant la phase d’implémentation une classe est un élément du logiciel

83 Modélisation structurelle Les Classes
Chaque classe est représentée sous la forme d’un 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

84 Modélisation structurelle Les Attributs
Chaque nom d’attribut 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

85 Modélisation structurelle Les attributs dérivés
Un attribut dérivé peut être calculé à partir d’autres attributs On le trouve: soit dans le compartiment attribut précédé d’une barre oblique soit dans le compartiment opération C’est un choix de conception

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

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

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

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

90 Modélisation structurelle Les relations
L’association La généralisation La dépendance La réalisation

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

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 qu’a un seul client et elle est nécessairement reliée à un client. Ces contraintes expriment la multiplicité d’une classe dans sa relation avec une autre ou avec elle-même

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

94 Modélisation structurelle Classes d’association
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 Diplôme * * * nom niveau DiplômeObtenu date obtention exercice

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

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 Sans le qualificatif la multiplicité serait * 1 1 Répertoire Fichier Nom de fichier 1 * Banque Personne compte

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

98

99 Autre exemple Hôtel Chambre N°Chambre Société Personne Matricule
1 Hôtel 1 Chambre N°Chambre Autre exemple Société * 1 Personne Matricule Emploi Salaire

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

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

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

103 Exercice : Gestion des représentations d’un théâtre
Construire un diagramme de classes à partir des données suivantes : 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 l’agence N° de téléphone agence N° billet Nom du pompier de service Heure de représentation Date prise réservation Suite

104 Le théâtre peut offrir plusieurs représentations le même jour.
Respecter les règles de gestion suivantes  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

105 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

106

107

108 Modélisation structurelle L’agré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. Développeur Mission * Agrégation simple

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

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

111

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

113 Modélisation structurelle Généralisation et spécialisation
La généralisation consiste à factoriser les éléments communs (attributs, opérations, relations) d’un 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

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

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

116 Modélisation structurelle Généralisation et spécialisation
Exercice Une société d’arché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 d’informations sur les nations, les sites et les particuliers.

117

118 Exercice * * * Site Objet Nation Code Musée Bâtiment ObjetMobile Bijou
0..1 * 1 Musée Bâtiment ObjetMobile * 0..1 Bijou Statue Particulier * 0..1

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

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

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

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

123 Représentation de l’architecture Les Paquetages
Un paquetage est un conteneur il permet de représenter l’organisation du système d’information et du logiciel. Il peut contenir tous les éléments de modélisation : des classes, des interfaces, des composants, des nœuds, des cas d’utilisation, des diagrammes, d’autres paquetages…

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

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

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

127 Modélisation de la dynamique du système
Diagrammes d’interaction Diagramme de séquence Diagramme de communication Diagramme d’activité Diagramme État-Transition

128 Modélisation de la dynamique du système
Les diagrammes d’interaction et d’activité précisent le texte du cas d’utilisation Lors de l’analyse des besoins,ils expriment les interactions entre les utilisateurs (acteurs) et le système. Lors de l’analyse-conception, ils expriment les interactions entre les objets du système Cas d’utilisation n diagrammes de séquence n diagrammes d’activité flot de base Flots alternatifs Texte Diagramme de classe

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

130 Modélisation de la dynamique Diagramme de séquence
Le diagramme de séquence transforme la structure fonctionnelle, décrite par le cas d’utilisation 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 d’opérations ou de groupes d’opérations. Ils sont effectués par des objets vers des objets. Les objets sont des acteurs ou des objets logiciels.

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

132 Modélisation de la dynamique Diagramme de séquence
Un objet ou un participant peut être anonyme, identifié, qualifié : adhérent Martin : adhérent adhérent actif Anonyme Identifié Qualifié : adhérent L’objet adhérent appartient à la classe adhérent Adhérent est ici un objet du logiciel

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

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.

135 Modélisation de la dynamique Diagramme de séquence
Exercice Faire le diagramme de séquence correspondant à cet extrait du cas d’utilisation 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 d’utlisation) 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é à l’adhérent Quelles interactions doit-il y avoir entre les objets de ces classes pour réaliser le cas d’utilisation: Règlement de cotisation? Paiement Règlement cotisations Adhérent AppelCotisation

136

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

138 Client théatre : : Spectacle : : Place Paiement : Client Activité Représentation Contrôle client [client pas OK] Flot de contrôle Contrôle activité [activité pas OK] Flot d’informations [Réservation OK] Le flot d’informations est facultatif Il revient par le chemin inverse du flot de contrôle Les messages sont synchrones par défaut retour

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

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

141 Diagramme de séquence, Représentation de plusieurs scénarios
Found message= la source du message est indéterminée Exercice le service commercial doit la contrôler Si elle n’est pas correcte, l’annuler 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: service commercial Recevoir la commande

142

143 Alt Recevoir la commande [Commande pas OK] [else] service commercial
Livraison Facture Recevoir la commande Contrôler Alt Refuser [Commande pas OK] Livrer [else] Facturer Enregistrer l’état

144 Diagramme de séquence, Représentation d’une itération
Par un cadre d’interaction Jardinier Plantoir Sol Bulbe 15 octobre Prendre loop [Pour chaque bulbe] Creuser Placer Ranger

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 l’article Si la commande est OK Il fait la facture

146

147 loop Recevoir la commande service commercial Commande Article Facture
Saisir loop [Pour chaque article] En stock? Annuler l’article [Article pas OK] Facturer [Commande OK]

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

149 Modélisation de la dynamique Diagramme de communication
Modélisation de la dynamique Diagramme de communication : 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 adhérent nom adhérent activité nom activité montant * association Correspondance avec le diagramme de classe séquence Classes correspondantes

150 Modélisation de la dynamique Diagramme de communication
: 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 Un lien est une connexion entre objets, qui indique qu’une forme de navigation et de visibilité entre eux est possible, c’est une intance d’association

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

152 Diagrammes d’interaction 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 s’il n’y a pas de chronologie ou si on veut montrer les liens entre les objets) classe système

153 Modélisation de la dynamique Diagramme d’activité
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

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

155 Diagramme d’activité Partitions
Client Ventes Entrepôt Ressource Enregistrer la commande Contrôler Commande Workflow Les partitions représentent les ressources qui réalisent les actions Sortir article Expédier Commande

156 Diagramme d’activité Décisions
Client Ventes Entrepôt Contrôler Commande Sortir article OU [OK] Sortir article [Pas OK] Annuler la commande Expédier Commande Commander Chemins alternatifs OU Enregistrer état Commande Pour que l’action Enregistrer état commande s’exécute, il suffit q’une des actions précédentes soit terminée

157 Modélisation de la dynamique Diagramme d’activité
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

158

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

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

161 Les diagrammes d’activité Barre de synchronisation
Chemins parallèles 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 n’importe 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

162 Exercice lorsque le réveil sonne
Lorsque le réveil sonne, l’homme 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 l’homme fait l’inspection finale et la mise en route.

163

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

165 Les diagrammes d’activité Décomposition d’une action
Les actions peuvent être décomposées en sous-activités. On peut ainsi décrire un processus globalement puis l’affiner progressivement

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

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

168 Détailler l’exercice: « lorsque le réveil sonne »
Pour préparer le petit déjeuner l’homme 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

169

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

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

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

173 Réserver l’itinéraire
Signal accepté Réserver l’itinéraire Itinéraire confirmé Retenir itinéraire Envoyer l’itinéraire Annuler itinéraire Signal émis Attendre 48 heures

174 Exercice Une commande Fournisseur est rédigée puis envoyée A la réception de l’accusé de réception, la commande est validée. Si 2 semaines après l’envoi de la commande, l’accusé de réception du fournisseur n’est toujours pas parvenu, la commande est annulée

175

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

177 Région d’expansion Une région d’expansion délimite dans un diagramme d’activité une zone ou les actions s’exécutent une fois pour chaque élément d’une collection

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

179 Exercice Contrôle d’une commande: On contrôle le client
On contrôle l’existence et la présence en stock de chaque article Si tout est correct, on établit une facture Sinon on refuse la commande

180 Existence de l’article Etablir la facture Contrôle stock de l’article
Contrôle client Existence de l’article Etablir la facture Contrôle stock de l’article

181 Modélisation de la dynamique Les diagrammes d’activité
Activités et flot d’objets Dans un diagramme d’activité, 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é. Etablir Devis D : Devis [établi] Commander

182 Enregistrer la commande
Modélisation de la dynamique Les diagrammes d’activité Activités et flots d’objets Client Ventes Entrepôt Enregistrer la commande commande [contrôlée] Contrôler Commande Préparer commande commande [préparée] commande [préparée] Décision [OK] [Pas OK] Expédier Commande Commande annulée Commande expédiée

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

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

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

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

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

188 Modélisation de la dynamique Diagramme état-transition
Plusieurs types d’opé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:

189 Modélisation de la dynamique Diagramme état-transition
Opérations courtes ou actions, pratiquement sans durée: Précédées de entry lorsqu’elles s’exécutent au moment ou l’objet entre dans le nouvel état  Précédées de exit lorsqu’elles s’exécutent au moment ou l’objet sort d’un état Précédées de: / lorsqu’elles sont déclenchées par un événement

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 qu’un événement est instantané Condition:Je sors si le temps est beau Événement: s’il se met à pleuvoir, je rentre

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

192

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

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

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

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 d’abord un diagramme global, pour avoir une vision d’ensemble, puis on affine en recherchant les états emboîtés.

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

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

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 d’utilisation et des postes de travail. Les composants sont distribués sur les postes de travail

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é

201 La modélisation de l’implémentation ………………. …
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

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

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

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

205 Annexe

206 Description des processus De l’analyse des besoins à la conception
Le diagramme de séquence Description des processus De l’analyse 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 planche de silhouettes de l'ombre choix de silhouette liste de choix possibles Diagramme de séquence objet logiciel Diagramme de séquence système retour

207 Représentation du dialogue entre l’acteur et le système.
Cas d’utilisation 1 1..* 1 Scénario 1..* Opération système 0..* 0..1 DiagrammeSéquence : 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 planche de silhouettes de l'ombre choix de silhouette liste de choix possibles Diagramme séquence système Diagr. séquence objets logiciel Représentation du dialogue entre l’acteur 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.

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

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

210

211 Description des données Règles de gestion
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. Notes retour

212

213 Notes

214


Télécharger ppt "UML Unified Modeling Language."

Présentations similaires


Annonces Google