Management des Systèmes d’Information (MSI)

Management des Systèmes d’Information (MSI) Cours : chapitre 2 UML Use cases Classes - Objets

UML : Unified Modelling Language Historique : GradyBooch 1981, ADA, « Object OrientedDevelopment » James Rumbaugh 1991, OMT, JOOP (Journal of OO programming) Ivar Jacobson, OOSE sept 97, UML 1.1. Références : http://www.omg.org http://uml.free.fr/ site en françaisen France Pierre Alain Muller (U-Mulhouse) et Valtech http://uml.developpez.com/ UML 2 : De l'apprentissage à la pratique, 2009, Ellipses, Laurent Audibert Conception & Réalisation des bases de données: de UML à SQL, Jacques Guyot, 2002, éditions Internet. Conception de bases de données avec UML, Gilles Roy, PUQ, 2007, ISBN 2760519449, 9782760519442, 511 pages Outils : StarUMLversion 5.1 Rational ROSE , http://www.rational.com plus de 30 outils de modélisation et de CASE (Computer Aided Software Engineering)

Système (VEGA2) : acteur (intéragissant avec VEGA2) Architecture message message message message Constituant Constituant Constituant Constituant UML • modelling information systems • at conceptual level • at logical level propriétés propriétés Technologie

UML 1.3 OMG Acceptance, Nov 1997 UML 1.1 Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 UML 1.0 UML partners public feedback UML 0.9 Web - June ´96 Unified Method 0.8 OOPSLA ´95 OOSE Other methods Creating the UML UML 2.0 2003 Booch method OMT

HP Fusion Meyer Booch Operation descriptions and message numbering Before and after conditions Booch method Rumbaugh Embley Harel OMT Singleton classes and high-level view Statecharts Gamma, et al Wirfs-Brock Frameworks and patterns, Responsibilities Odell Shlaer - Mellor Jacobson Classification Object lifecycles OOSE Contributions to the UML

Axes de modélisation d’un système Statique (ce que le système EST) • diagramme de classes • diagramme d’objets • diagramme de composants • diagramme de déploiement Dynamique (comment le système EVOLUE) Fonctionnel (ce que le système FAIT) • diagramme de séquence • diagramme de collaboration • diagramme d’états-transitions • diagramme d’activités • diagramme de cas d’utilisation • diagramme de collaboration

Grenoble INP Génie industriel 2A ICL MSI – UML 1 Niveaux d’abstraction d’un SI En UML, les mêmes modèles peuvent être utilisés à différents niveaux d’abstraction du plus conceptuel à l’implémentation. On peut donc appliquer des mécanismes de transformation continue. • Conceptuel • organisationnel • logique • physique

Grenoble INP Génie industriel 2A ICL MSI – UML 1 Les 9 diagrammes UML 1.0 • diagramme de cas d’utilisation • diagramme de classes • diagramme de séquence • diagramme de collaboration • diagramme d’objets • diagramme d’états-transitions • diagramme d’activités (nous utiliserons IDEF 0) • diagramme de composants • diagramme de déploiement

Description UML des 9 diagrammes UML 1.0 Diagramme Classes Composants Déploiement Collaboration Etats Transitions Séquence Objets Classes Etats Transitions Séquence Activité Ceci est un commentaire Cas d ’utilisation Cas d ’utilisation

Grenoble INP Génie industriel 2A ICL MSI – UML 1 Exemples : Quelques diagrammes Système (VEGA2) : acteur (intéragissant avec VEGA2) message message message Diagramme de Classes message Diagramme de séquence Chaque cas d'utilisation apparaît comme un scénario, décrit par un ou plusieurs diagrammes de séquence. Un diagramme de séquences montre les interactions entre les acteurs et le système selon un point de vue temporel pour accomplir une fonctionnalité attendue du système (un cas d ’utilisation). C’est une ensemble de messages échangés entre les acteurs et le système, ordonnés chronologiquement. cas d'utilisation Acteur Cas d’utilisation une fonctionnalité attendue du système (VEGA2) par les différents acteurs.

cas d'utilisation cas d'utilisation Confirmation client cas d'utilisation Pas de confirmation client après 1 mois 10 ans après paiement paiement effectué article Implantation code désignation prix-U rayon ss-rayon Nom emplacement état final comporte * Rayon Sous rayon emplacement nom 1 contient> 1 * En préparation do / ajout article Confirmée do / préparer livraison état initial Implantation Display () Number-product Livrée do / attente paiement Payée état final Acteur 1 Acteur 2

Modèle Fonctionnel • Use Cases : cas d’utilisation • diagramme de collaboration

Diagramme de cas d’utilisation Ceci est un cas d’utilisation Ceci est un acteur Ceci est une relation Représente les fonctions du systèmede point de vue de l ’utilisateur. relation Cas d’utilisation Acteur Eléments du diagramme : • acteur : un rôle joué par une personne, un service, etc. qui interagit avec le système étudié • cas d’utilisation : manière spécifique d ’utiliser un système. Image d’une fonctionnalité attendue, déclenchée en réponse à la stimulation d’un acteur • relations entre cas d’utilisations et acteurs

Relations entre cas d’utilisations « use » virement identification « extend » Virement par Internet virement Trois types de relations : • relation de communication : entre un acteur et un cas d’utilisation. Exprime l’échange d’informations entre l’acteur et le système. Effectue virement client • relation d’utilisation : entre deux cas d’utilisation. Exprime que le cas d’utilisation source comprend également le comportement décrit par le cas d’utilisation destinataire (utile pour la factorisation de cas). • relation d’extension : entre deux cas d’utilisation. Exprime que le cas d’utilisation source étend le comportement du cas d’utilisation cible (utile pour la spécialisation de cas).

Grenoble INP Génie industriel 2A ICL MSI – UML 1 Acteurs : diagramme de cas d’utilisation Acteur humain : il s’agit ici d’un rôle et non d’un acteur identifié. Acteur non humain : exemple un logiciel de comptabilité ou d’ERP avec lequel le système interagit Conçoit les schémas Récupère les et nomenclatures schémas Exemple Récupère les Gestion des schémas contraintes Développeur Définit les contraintes mécaniques Gestion des contraintes Responsable CFAO Gère la création et les révisions d ’un job Responsable Gestion des jobs BE <<dépend>> Gère la création et les révisions des dossiers variantes Gestion des dossiers

Bien recueillir les besoins • Bien souvent, la maîtrise d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d’exprimer leurs besoins. C’est précisément le rôle des diagrammes de cas d’utilisation qui permettent de recueillir, d’analyser et d’organiser les besoins, et de recenser les grandes fonctionnalités d’un système. Il s’agit donc de la première étape UML d’analyse d’un système. • Un diagramme de cas d’utilisation capture le comportement d’un système, d’un sous-système, d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d’utilisation, ayant un sens pour les acteurs. Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système, ils sont donc une vision orientée utilisateur de ce besoin au contraire d’une vision informatique. • Compréhensibles par toutes les personnes, même par les non-informaticiens.

Formalisme des diagrammesde cas d’utilisation Acteur Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou une chose (matériel ou immatériel) qui interagit avec un système. ou • Plusieurs utilisateurs peuvent avoir le même rôle, et donc correspondre à un même acteur, et inversement une même personne physique peut jouer des rôles différents vis-à-vis du système, et donc correspondre à plusieurs acteurs.

Acteur complément • Un acteur représente un ensemble cohérent de rôles joués vis-à-vis d’un système (mettre « comptable » plutôt que « madame Dupont »). Plusieurs personnes peuvent avoir le même rôle (exemple : « client » pour une banque) • Tout ce qui est à l’extérieur du système et qui interagit avec le système est un acteur Acteur humain : il s’agit ici d’un rôle et non d’un acteur identifié. Acteur non humain : exemple un logiciel de comptabilité ou d’ERP avec lequel le système interagit

Formalisme des diagrammes de cas d’utilisation 2.3 Représentation d’un diagramme de cas d’utilisation Nom du Système Frontière du système Cas d’Utilisation Acteur Relation d’Association

Relations entre cas d’utilisation Il existe principalement 2 types de relations: • Dépendances stéréotypées, dont les plus usitées sont : • Inclusion • Extension Formalisme : • Généralisation / spécialisation Formalisme :

Relations entre cas d’utilisation Relation d’inclusion • Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B : le cas A dépend de B. • Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A. Cette dépendance est symbolisée par le stéréotype << include >> • Les inclusions permettent essentiellement de factoriser une partie de la description d’un cas d’utilisation qui serait commune à d’autres cas d’utilisation. • Les inclusions permettent également de décomposer un cas complexe en sous-cas plus simples (attention, ce n’est pas une décomposition fonctionnelle). • Attention, il n’existe pas de temporalité

Relations entre cas d’utilisation Relation d’extension • Un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B. • Exécuter B peut éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >> . • L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle le point d’extension.

Relations entre cas d’utilisation Relation de généralisation • Un cas A est une généralisation d’un cas B, si B est un cas particulier de A. • Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés objet la consultation d’un compte via Internet est un cas particulier de la consultation.

Relations entre cas d’utilisation Relations entre acteurs • La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.

Relations entre cas d’utilisation

Comment identifier les acteurs ? (1/2) • Les acteurs (utilisateurs) d’un système sont les entités externes à ce système qui interagissent (saisie de données, réception d’information, …) avec lui. • Les acteurs sont à l’extérieur du système et dialoguent avec lui. • Ces acteurs permettent de cerner l’interface que le système va devoir offrir à son environnement. (attention à ne pas oublier qu’un acteur peut être humain, matériel ou immatériel). Chaque acteur doit être nommé. Ce nom doit refléter son rôle, car un acteur représente un ensemble cohérent de rôles joués vis-à-vis du système.

Comment identifier les acteurs ? (2/2) • Les différents acteurs d’un système peuvent être : • des utilisateurs (ex : responsable clientèle, responsable d’agence, administrateur, approbateur, …) • les périphériques manipulés par le système (imprimantes, hardware d’un distributeur de billet, …) ; • des logiciels déjà disponibles à intégrer dans le projet ; • des systèmes informatiques externes au système, mais qui interagissent avec lui, etc. • Pour faciliter la recherche des acteurs, on peut imaginer les frontières du système. Tout ce qui est à l’extérieur et qui interagit avec le système est un acteur, tout ce qui est à l’intérieur est une fonctionnalité à réaliser. (exemple de la caisse enregistreuse, le Client est-il un acteur ?)

Comment recenser les cas d’utilisation ? (1/2) • L’ensemble des cas d’utilisation décrit exhaustivement les exigences fonctionnelles du système. • Chaque cas d’utilisation correspond à une fonction métier du système, selon le point de vue d’un de ses acteurs (exemple du distributeur de billet : Retirer de l’argent ou Distribuer de l’argent ?). • Aussi, pour identifier les cas d’utilisation, il faut se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi il se sert du système.

Comment recenser les cas d’utilisation ? (2/2) • Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon niveau d’abstraction. • Nommez les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément en vous plaçant du point de vue de l’acteur, et non pas de celui du système. • De par la nature fonctionnelle, et non objet, des cas d’utilisation, et en raison de la difficulté de trouver le bon niveau de détail, il faut être très vigilant pour ne pas retomber dans une décomposition fonctionnelle descendante hiérarchique. Un nombre trop important de cas d’utilisation est en général le symptôme de ce type d’erreur. • Dans tous les cas, il faut bien garder à l’esprit qu’il n’y a pas de notion temporelle dans un diagramme de cas d’utilisation.

Notions générales du langage UML Classeur ou Paquetage • Un paquetage est un regroupement d’éléments de modèle et de diagrammes. • Il permet ainsi d’organiser des éléments de modélisation en groupes. Il peut contenir tout type d’élément de modèle : des classes, des cas d’utilisation, des interfaces, des diagrammes, … et même des paquetages imbriqués (décomposition hiérarchique). • Tout élément n’appartient qu’à un seul paquetage. Les paquetages constituent un mécanisme de gestion important des problèmes de grande taille. • Il existe un paquetage racine unique, éventuellement anonyme, qui contient la totalité des modèles d’un système.

Cas d’étude de l’agence de voyage Exemple : gestion de voyages personnalisés Réserver une chambre d’hotel Réserver un taxi Réserver un billet de train Organiser un voyage Agent de voyage • Une agence de voyages organise des voyages où l’hébergement se fait en hôtel. Le client doit disposer d’un taxi quand il arrive à la gare pour se rendre à l’hôtel • Certains clients demandent à l’agent de voyages d’établir une facture détaillée. Cela donne lieu à un nouveau cas d’utilisation appelé « Etablir une facture détaillée». Comment mettre ce cas en relation avec les cas existants? • Le voyage se fait soit par avion, soit par train. Comment modéliser cela ?

Diagramme de Collaboration : ascenseur 1 : monter : cabine 3 : fermer : porte 2 : allumer : lumière Interactions entre objets du système avec un accent particulier sur la structure spatiale statique des objets (contexte des objets). Les messages sont numérotés pour indiquer l’ordre des envois. Permet de situer le contexte du système. Message: Simple, Asynchrone, Synchrone, Minuté Objet 1 1 : message 2 : message Objet 2 5 : message 4 : message 3 : message Objet 3

Modèle Statique • diagramme d’objets • Diagramme de classes

Objets et classes MaVoiture : Voiture marque = Renault Modèle = Nevada Immatriculation = 648ADX38 AnnéeModele = 1992 Kilométrage = 285 000 Voiture marque : chaîne Modèle : chaîne Immatriculation : chaîne (8) AnnéeModele : date Kilométrage : entier Rouler ( ) Kilometrage_annuel_moyen ( ) Objet : une entité concrète avec une identité bien définie qui encapsule un état et un comportement. L’état est représenté par des valeurs d’attribut et des associations, le comportement par des méthodes. Un objet est une instance d’une classe. Classe : une description d’un ensemble d’objets qui partagent les mêmes attributs, opérations, méthodes, relations et contraintes. Une classe peut posséder des attributs ou des méthodes « de classe ».

Diagramme d’Objets Nom de l’objet : Classe Attributs = valeurs Opérations = méthodes Structure statique d’un système, en termes d’objetset de liens entre ces objets. Ces objets et ces liens possèdent des attributs qui possèdent des valeurs. Un objet est une instance de classe et un lien est une instance d’association. Etienne : personne Date-naissance= 30/6/89 âge ? Personne Date-naissance (date) âge (): entier collaborateur * patron patron 1 collaborateur Abstraction Concrétisation Jean-Luc : personne Date-naissance= 22/6/99 âge ? emploie> Diagramme de classes Diagramme d ’objets

Diagramme de classes Voiture Couleur Cylindrée Vitesse max Démarrer () Accélérer () Freiner () Nom de classe Attributs Opérations () Structure statique d’un système, en termes de classes et de relations entre ces classes. exemple : Syntaxe: • nom_attribut : type_attribut = valeur initiale • nom_opération (nom_argument : type_argument = valeur_par_défaut, …) : type_retourné Visibilité : trois niveaux de visibilité pour les attributs et les opérations: • public(+) : élément visible à tous les clients de la classe • protégé ( #) : élément visible aux sous-classes de la classe • privé (-) : élément visible à la classe seule

Diagramme de classes : Relations entre classes Agrégation : quand une classe fait partie d’une autre classe (agrégat - composant) Association : toute relation structurelle entre classes, autre que l’agrégation et la généralisation Généralisation : factorisation des éléments communs d’un ensemble de classes dits sous-classes dans une classe plus générale dite super-classe. Elle signifie que la sous-classe est un ou est une sorte de la super-classe. Le lien inverse est appelé spécialisation. classe 2 généralisation spécialisation association Véhicule classe 1 1 1..* 1 1..* Moteur Constructeur classe 3 agrégation Voiture Camion Avion classe 4

Associations Agrégation: • Association transitive : si voiture est composée de moteur et si moteur est composé de courroie, alors voiture est composée de courroie • Association non symétrique : si voiture est composée de moteur, moteur ne peut pas être composé de voiture • Association qui peut être réflexive : une fonction peut être composée d’autres fonctions Rôle et multiplicité : • Une classe a un rôle dans une association. • Les rôles portent une information de multiplicité précisant le nombre d’associations auquel une instance d’objet peut être associée. Les multiplicités les plus courantes sont : 1 / 0..1 / m..n / * / 0..* / 1..*

Nommage des associations constructeur véhicule Construire> produit fabricant <construit par <Transporte passager véhicule personne véhicule Conduit> conducteur véhicule Possède> propriétaire véhicule <Emploie employé employeur personne entreprise Dirige> directeur société Possède> société actionnaire

Multiplicité des associations 1 Un et un seul (obligatoire) 0 .. 1 Zéro ou un (optionnel) m .. n De m à n (entiers) quelconque * ou 0 .. * 1 .. * Au moins 1 Personne Société 0..* Employeur 1 Employé N°SS Nom prénom N°SIREN

Classe-association Etudiant Travail 1 Réalise > 0 .. * 0 .. * 0..* 1 Diplôme Note Valeur = [0, 20] Mention 0..1 Chambre Numéro

Contraintes personne compte Est_titulaire> 0 .. * 1 {Ordonnée} 0 .. * personne classe Parent d ’élève {Sous ensemble} 0 .. * Délégués 0 .. * personne université Enseignants {Ou-exclusif} 0 .. * Etudiants

Grenoble INP Génie industriel 2A ICL MSI – UML 1 Agrégation Livre Chapitre 1 .. * {Ordonnée} 1 {Ordonnée} 1 .. * Paragraphe

Composition Homme Tête 1 1 Bâtiment Salle 1 * La composition traduit une dépendance existentielle forte.

Problème Titre_Problème Projet Objectif Delai NomProjet Prix NuméroPDM NiveauPriorite DateDebutProjet FicheEtude 1 Conclusion Projet() Tes_infos?() Problème() Nouv_Paramètres() Tes_infos?() Créer_Problème() Nou_Paramètres() Créer_Etude() 1..* Outil Simulation Créer_Projet() Etude Modifier_Projet() Titre_Etude ModifierParamètre_Projet() NomPièce Créer_Problème() ButEtude Modifier_Problème() TypeEtude ModifierParamètre_Problème() Conclusion Créer_Etude() Modifier_Etude() Etude() ModifierParamètre_Etude() Tes_infos() FaireAppelAUneAncienne_Etude() Nouv_Paramètres() Conclure_Etude() Créer_Cycle() Créer_Cycle() Ajouter_Conclusion() Modifier_Cycle() ModifierPramètre_Cycle() Rajouter_Entité() Conclure_Cycle() Exemple de diagramme de classes 1..* 1..* 1 Induit 1..* 1..* 1..* LesProjets LesProblèmes 1 1 EstResoluPar 0..* 0..* 0..1 0..1 0..1 0..1 Suivant ComplétéePar 0..* 0..* 0..* 0..* LesEtudes 1..* 1..*

Passage Classes -- relationnel • Passage d’un diagramme de classe à un modèle relationnel

Classe produit Réf-produit Libellé-p Prix-vente-p fournisseur Produit (Réf-produit, Libellé-p, Prix-vente-p) Relation / Table Code-fournisseur Adresse Téléphone Fournisseur (Code-fournisseur, Adresse, Téléphone) Règle 0 & 1: attribut et classe Passage du modèle statique UML au relationnel : les associations

produit Réf-produit Libellé-p Prix-vente-p Classe 1 fournisseur < fournir Produit (Réf-produit, Libellé-p, Prix-vente-p, Code-fournisseur, remise) Relation / Table Code-fournisseur Adresse Téléphone Fournisseur (Code-fournisseur, Adresse, Téléphone) remise Règle 2 : relation de multiplicité (1) Passage du modèle statique UML au relationnel : les associations

Grenoble INP Génie industriel 2A ICL MSI – UML 1 Relation / Table Produit (Réf-produit, Libellé-p, Prix-vente-p, remise, Code-fournisseur) produit Fournisseur (Code-fournisseur, Adresse, Téléphone) Réf-produit Libellé-p Prix-vente-p fournisseur Code-fournisseur Adresse Téléphone remise Règle 3 : relation de multiplicité(0-1) Passage du modèle statique UML au relationnel : les associations Classe * 0-1 < fournir

produit Réf-produit Libellé-p Prix-vente-p Classe 0..* ou 1..* Relation / Table < fournir fournisseur Produit (Réf-produit, Libellé-p, Prix-vente-p) Code-fournisseur Adresse Téléphone Fournisseur (Code-fournisseur, Adresse, Téléphone) remise Fournir (Réf-produit, Code-fournisseur, remise) Règle 4 : relation de multiplicité(0..*) (1..*) Passage du modèle statique UML au relationnel : les associations

Management des Systèmes d’Information (MSI)