Méthodes de concep7on et de valida7on de logiciel (DUGL)
|
|
- Florent Picard
- il y a 2 ans
- Total affichages :
Transcription
1 Méthodes de concep7on et de valida7on de logiciel (DUGL) Mathieu Acher h"p://www.mathieuacher.com Associate Professor University of Rennes 1
2 Objec/fs Méthodes de concep7on et de valida7on de logiciel En fait: génie logiciel / socware engineering Comment développer des systèmes logiciels de plus en plus complexe? #1 Prendre conscience de la complexité des systèmes logiciels actuels et à venir Les enjeux et l impact sur le mé7er #2 Modélisa/on UML, SysML #3 Design pa"erns, refactoring, test OO avancé #4 Méthodes 2
3 Outline UML History and Overview UML Language UML Functional View UML Structural View UML Behavioral View UML Implementation View UML Extension Mechanisms UML Internals UML Tools Conclusion 3
4 Outline UML History and Overview UML Language UML Functional View UML Structural View UML Behavioral View UML Implementation View UML Extension Mechanisms UML Internals UML Tools Conclusion 4
5 Méthodes de modélisation L apparition du paradigme objet à permis la naissance de plusieurs méthodes de modélisation OMT, OOSE, OOD, Fusion, Chacune de ces méthodes fournie une notation graphique et des règles pour élaborer les modèles Certaines méthodes sont outillées 5
6 Méthodes de modélisation Entre 89 et 94 : le nombre de méthodes orientées objet est passé de 10 à plus de 50 Toutes les méthodes avaient pourtant d énormes points communs (objets, méthode, paramètres, ) Au milieu des années 90, G. Booch, I. Jacobson et J. Rumbaugh ont chacun commencé à adopter les idées des autres. Les 3 auteurs ont souhaité créer un langage de modélisation unifié 6
7 Méthodes de modélisation OMT de James Rumbaugh (General Electric) fournit une représentation graphique des aspects statique, dynamique et fonctionnel d un système ; OOD de Grady Booch définie pour le Department of Defense, introduit le concept de paquetage (package) ; OOSE d Ivar Jacobson (Ericsson) fonde l analyse sur la description des besoins des utilisateurs (cas d utilisation, ou use cases). 7
8 Genealogy of UML UML (Rumbaugh, Booch, Jacobson) OOA (P. Coad) Use-Case (I.Jacobson) OOA - OODLE (Schlaer & Mellor) OMT (J. Rumbaugh et al.) OOA-OOD (G.Booch) FUSION (HP-Labs) CLASSE- RELATION (P. Desfray) CRC (R. Wirf-Brooks) JSD (M. Jackson) Data-Flow SADT/SA-SD (De Marco) Diagrammes Etat-Transition (HAREL) Entite-Relation Merise (Chen) 8
9 Genealogy of UML 9
10 UML History 10
11 Aujourd hui UML est le langage de modélisation orienté objet le plus connu et le plus utilisé au monde UML s applique à plusieurs domaines OO, RT, Deployment, Requirement, UML n est pas une méthode RUP Peu d utilisateurs connaissent le standard, ils ont une vision outillée d UML (vision utilisateur) 5% forte compréhension, 45% faible compréhension, 50% aucune compréhension UML est fortement critiqué car pas assez formel Le marché UML est important et s accroît MDA et MDD, UML2.x, IBM a racheté Rational!!! 11
12 UML Today Official website: Official specifications: Current version: v2.4.1, August
13 UML: one model, 4 main dimensions, multiple views : Device" <<Actor>>" Operator" controls! 1" 0..*" start()" stop()" Device" : Operator" start( )" stop( )" e.g., Class diagram e.g., Sequence diagram ControllingSite" RemoteSite" TCP/IP" : Device" : Operator" : Operator" e.g., UseCase diagram e.g., Implementation diagram 13
14 The X diagrams of UML n Modeling along 4 main viewpoints: Static Aspect (Who?) Describes objects and their relationships (Class, Object and Composite Structure Diagrams) Structuring with packages (Package Diagram) User view (What?) Use cases Diagram Dynamic Aspects (When?) Interaction Diagrams Sequence Diagram (scenario) Communication Diagram (between objects) Timing Diagram State Machine Diagram (from Harel) Activity Diagram Implementation Aspects (Where?) Component and Deployment Diagrams 14
15 UML 2.4 Overview Cf. 15
16 UML : pourquoi? Réfléchir Définir la structure «gros grain» Documenter Guider le développement Développer, Tester, Auditer 16
17 Un peu de méthodologie... Une méthode de développement de logiciels, c est : Une notation La syntaxe --- (semi-) graphique dans le cas de UML Un méta-modèle La sémantique --- paramétrable dans UML (stéréotypes) Un processus Détails dépendants du domaine d activité : Informatique de gestion Systèmes réactifs temps-réels Shrink-wrap software (PC) 17
18 Processus de développement avec UML Approche itérative, incrémentale, dirigée par les cas d utilisation Expression des besoins Analyse Elaboration d un modèle «idéal» Conception passage du modèle idéal au monde réel Réalisation et Validation 18
19 UML et Java? UML Vers Java : Génération de code Java Vers UML : Rétro-ingéniérie UML Java UML n'est pas une syntaxe graphique pour Java! Traduction (très) incomplète Pas de traduction standardisée Dépend du métier, des outils disponibles,... Des outils industriels disponibles Des recherches en cours vers une capitalisation du savoir-faire 19
20 UML et Java : vision globale MODELES STATIQUES Traduction des diagrammes de classes Classes, Associations, Généralisation Propriétés dérivées, Invariants MODELES DYNAMIQUES Traduction de pré/post conditions Traduction de diagrammes d'états / d'activités Traduction du langage d'actions (UML exécutable)... traduction souvent incomplète mais très utile 20
21 Outline UML History and Overview UML Language UML Functional View UML Structural View UML Behavioral View UML Implementation View UML Extension Mechanisms UML Internals UML Tools Conclusion 21
22 Outline UML History and Overview UML Language UML Functional View UML Structural View UML Behavioral View UML Implementation View UML Extension Mechanisms UML Internals UML Tools Conclusion 22
23 Expression des besoins Sujet longtemps négligé (e.g., OMT) Question de l'expression des besoins pourtant fondamentale Et souvent pas si facile (cible mouvante) cf. syndrome de la balançoire Object-Oriented Software Engineering (Ivar Jacobson et al.) Principal apport : la technique des acteurs et des cas d'utilisation Cette technique est intégrée a UML 23
24 Quatre objectifs ❶ Se comprendre ❷ Représenter le système ❸ Exprimer le service rendu ❹ Décrire la manière dont le système est perçu 24
25 Functional View Use Case Diagram 25
26 Modèle des cas d utilisation Buts : modéliser le point de vue des utilisateurs définir les limites précises du système Notation très simple, compréhensible par tous, y compris le client Permet de structurer : les besoins (cahier des charges) le reste du développement Modéle (principalement) pour communiquer A1 CasU1 CasU4 CasU5 S CasU2 CasU3 A3 A2 26
27 Modèle des cas d utilisation Moyens : Les acteurs UML Les use-cases UML Utilisation d un dictionnaire du domaine 27
28 Intérêt du dictionnaire Outil de dialogue Informel, évolutif, simple a réaliser Etablir et figer la terminologie Permet de figer la terminologie du domaine d'application. Constitue le point d'entrée et le référentiel initial de l'application ou du système. 28
29 Use Case Diagram Example Client RetirerDeLArgentAuDi stributeur ConsulterSonCompte RetirerLes CartesAvalées Ajouter DesBillets Assurer LaMaintenance 29
30 Use Case Diagram Example Client RetirerDeLArgentAuDi stributeur Banque Centrale ConsulterSonCompte RetirerLes CartesAvalées Transporteur DeBillets Ajouter DesBillets Assurer LaMaintenance Technicien DistributeurDeBillet 30
31 Use Case Diagram Example Client RetirerDeLArgent AuDistributeur ConsulterSonCompte RetirerLes CartesAvalées Transporteur DeBillets Ajouter DesBillets Assurer LaMaintenance Technicien DistributeurDeBillets 31
32 Modèle de cas d utilisation Diagramme de cas d utilisation A1 CasU1 CasU4 CasU2 CasU3 A2 Modèle de cas d utilisation CasU5 S A3 descriptions textuelles, diagrammes de cas d'utilisation diagrammes de séquences dictionnaire de données 32
33 Eléments de base Acteurs Cas d'utilisation Système 33
34 Cas d utilisation (CU) Cas d utilisation une manière d utiliser le système une suite d interactions entre un acteur et le système Correspond à une fonction du système visible par l acteur Permet à un acteur d atteindre un but Doit être utile en soi Regroupe un ensemble de scénarii correspondant à un même but EnregistrerEntrée RetirerDeLArgentAu Distributeur SIdentifier EntrerPendant LesHeuresDOuverture TaperSonCode 34
35 Système Le système est modélisé par un ensemble de cas d utilisation vu comme une boîte noire Le système contient : les cas d utilisation, mais pas les acteurs. Un modèle de cas d utilisation permet de définir : les fonctions essentielles du système, les limites du système, le système par rapport à son environnement, délimiter le cadre du projet! 35
36 Acteurs Un Acteur = élément externe qui interagit avec le système (prend des décisions, des initiatives. Il est "actif".) Rôle qu un "utilisateur" joue par rapport au système PorteurDeCarte Gardien Administrateur Capteur AIncendie 36
37 Acteurs vs. utilisateurs Ne pas confondre les notions d acteur et de personne utilisant le système Une même personne peut jouer plusieurs rôles ex: Maurice est directeur mais peut jouer le rôle de guichetier Plusieurs personnes peuvent jouer un même rôle ex: Paul et Pierre sont deux clients Un rôle par rapport au système plutôt qu une position dans l'organisation ex: PorteurDeCarte plutôt qu'enseignant Un acteur n est pas forcément un être humain ex: un distributeur de billet peut être vu comme un acteur 37
38 Différents types d acteurs Ne pas oublier d'acteurs : Utilisateurs principaux ex: client, guichetier Utilisateurs secondaires ex: contrôleur, directeur, ingénieur système, administrateur... Périphériques externes ex: un capteur, une horloge externe,... Systèmes externes ex: système bancaires 38
39 Notation Notations alternatives pour les acteurs <<actor>> PorteurDeCarte PorteurDeCarte PorteurDeCarte Note de style : utiliser plutôt le stéréotype <<actor>> pour les acteurs non humains <<actor>> CapteurAIncendie <<actor>> SystèmeBancaire PorteurDeCarte 39
40 Un peu de méthodologie Description préliminaire du système Choisir un identificateur Baptiser le système, le plus tôt possible Risque d'être référencé dans toute la vie future de l'entreprise Brève description textuelle (quelques lignes max.) Description préliminaire des acteurs choisir un identificateur représentatif de son rôle donner une brève description textuelle Description préliminaire des cas d utilisation choisir un identificateur représentatif donner une description textuelle simple la fonction réalisée doit être comprise de tous préciser ce que fait le système, ce que fait l acteur pas trop de détails, se concentrer sur le scénario «normal» 40
41 Warning!! "A common sign of a novice (or academic) use case modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text.... Use case diagrams and use case relationships are secondary in use case work. Use cases are text documents. Doing use case work means to write text." [Applying UML and Patterns, Craig Larman] 41
42 Relations entre les éléments de base Relations acteurs cas d'utilisation? Relations acteurs acteurs? Relations cas d'utilisation cas d'utilisation???? 42
43 Relation acteur cas d'utilisation Client RetirerDeLArgent AuDistributeur Point de vue besoin: représente la possibilité d'atteindre un but Point de vue système: représente un canal de communication Echange de messages, potentiellement dans les deux sens Protocole particulier concernant le cas d'utilisation considéré Client RetirerDeLArgent AuDistributeur 43
44 Relation acteur cas d'utilisation Client RetirerDeLArgent AuDistributeur Description via des diagrammes de séquences "systèmes" Plus tard dans le cours... 44
45 Relation acteur cas d'utilisation Guichetier Système Bancaire Acteur primaire Acteur auxiliaire ConsulterUnCompte Acteur "primaire» utilise le système comme outil pour réaliser son but initie généralement la communication Acteur(s) "auxiliaire(s)" interviennent suite à l'intervention de l'acteur primaire offrent généralement leurs services au système 45
46 Relation cas d utilisation cas d utilisation Communications internes non modélisées. UML se concentre sur la description du système et de ses interactions avec l'extérieur Formalisme bien trop pauvre pour décrire l'intérieur du système. Utiliser les autres modèles UML pour cela. Autres relations possibles entre CU (slides suivants) Client Directeur RetierDeLArgent ConsulterLesSoldes Système Bancaire 46
47 Relation cas d utilisation cas d utilisation Utilisation («include» / «uses») Utilisation d autres use-cases pour en préciser la définition Extension («extend» / «extends») Un use-case étendu est une spécialisation du use-case père 47
48 Relation acteur acteur Communications externes non modélisée UML se concentre sur la description du système et de ses interactions avec l'extérieur Client ConsulterSonCompte RetirerDeLArgent AuDistributeur RetirerDeLArgent ParChèque Guichetier Système Bancaire 48
49 Relation acteur acteur : généralisation La seule relation entre acteurs est la relation de généralisation CréerUnCompte Guichetier FermerUnCompte RetirerDeLArgent DUnCompte Guichetier EnChef AnnulerUnCompte 49
50 Notation en résumé «subsystem» Commandes Consulter Commander 1 1 Traiter Commande Client 1 MàJ catalogue 0..1 Etablir crédit 50
51 Notation en résumé Transaction sur distributeur «extends» Aide en ligne Retrait «includes» Lecture carte 51
52 Problèmes de la granularité A quel niveau décrire les cas d'utilisation? Bonne question... mais pas de réponse Trop haut trop loin du système trop abstrait et "flou" trop complexe à décrire Trop bas trop de cas d'utilisation trop près de l'interface trop loin des besoins métiers Conclusion: choisir le "bon" niveau 52
53 Problèmes de la granularité Tous les cas d'utilisations n'ont pas a être au même niveau Différents niveaux de détail POURQUOI vs. COMMENT Décoration du niveau (e.g., selon Cockburn) Non standardisé mais intuitif et utile 53
54 Niveaux d'abstractions Clouds Level Trop haut Kite Level Niveau résumé : décrit un regroupement correspondant à un objectif plus global Sea Level Niveau normal : décrit un but de l'acteur qu'il peut atteindre via une interaction avec le système Fish Level Niveau détaillé : décrit une interaction avec le système, pas un but en soi Clam Level Trop bas 54
55 Exemple de marquage SIdentifier Client RetirerDeLArgentAuDi stributeur ConsulterSonCompte Transporteur DeBillets Ajouter DesBillets GérerLaSécurité Administrateur DistributeurDeBillets 55
56 Cas d'utilisation vs. Scénarii Un scénario est un exemple : une manière particulière d utiliser le système par un acteur particulier dans un contexte particulier. cas d utilisation = ensemble de scénarios scénario = une exécution particulière d un CU 56
57 Diagramme de séquences système Pour décrire un scénario : un diagramme de séquences Diagramme de séquences : L une des notations UML, une notation générale Peut être utilisée dans de nombreux contextes Permet de décrire une séquence de messages échangés entre différents objets Différents niveaux de détails Pour décrire un scénario simple, deux objets : l acteur et le système «Diagramme de séquences système» 57
58 Exemple de diagramme de séquence système paul : Client le système Insérer carte Demander code Vérifier carte Entrer code 1234 Message d erreur Vérifier code Demander code Appeler Sylvia Entrer code
59 Cas d'utilisation vs. scénarii Niveau modèle Niveau instances 59
60 Un peu de méthodologie Stabilisation du modèle par consensus grandissant Équivalent à définir une table des matières et des résumés pour chaque chapitre Pas de règles strictes Effectuer les meilleurs regroupement possibles Rester simple! Structuration possible en termes de paquetages Culture d'entreprise 60
61 Pour en savoir plus Pour un template "standard" de description de cas d'utilisation : Quelques livres : 61
62 Pour en savoir encore plus 62
63 Outline UML History and Overview UML Language UML Functional View UML Structural View UML Behavioral View UML Implementation View UML Extension Mechanisms UML Internals UML Tools Conclusion 63
64 Structural View Class and Object Diagrams 64
65 Rappel Un objet Encapsulation d un état et d un ensemble d opérations (qui s appliquent à cet état) Abstraction d une entité réelle Identité unique Existence temporelle (création, modification, destruction) Une classe Description du comportement et des propriétés communs à un ensemble d objets Un objet est une instance d une classe Chaque classe a un nom 65
66 Notations simplifiées pour les classes Compte Compte Compte numéro solde... Compte créditer() débiter()... Compte numéro solde... créditer() débiter()... Compte numéro solde : réel découvertmax : entier consultersolde() : entier créditer( somme : entier) débiter( somme ) Note de style : les noms de classes commencent par une majuscule les noms d attributs et de méthodes commencent par une minuscule 66
67 Notation pour les classes Nom de la classe Attributs nom type Opérations nom paramètre type du résultat Compte numéro : entier solde : réel découvertmax : entier consultersolde() : entier créditer( somme : entier) débiter( somme : entier) Contraintes { inv: solde > découvertmax } 67
68 Notations pour les objets lecomptedepaul : Compte lecomptedepaul : Compte lecomptedepaul : Compte numéro = 6688 solde = 5000 découvertmax = -100 Convention : les noms d objets commencent par une minuscule et sont soulignés 68
69 Classe vs. Objets M1 M0 Une classe spécifie la structure et le comportement d'un ensemble d'objets de même nature La structure d'une classe est constante Des objets peuvent être ajoutés ou détruits pendant l exécution La valeur des attributs des objets peut changer lecomptedemarie:compte numéro = 2275 solde = découvertmax = Compte numéro solde : réel découvertmax : entier consultersolde() : entier créditer( somme : entier) débiter( somme ) :Compte numéro = 1200 solde = 150 découvertmax = 10 lecomptedepaul : Compte numéro = 6688 solde = 5000 découvertmax = -100 Diagramme de classes Diagramme d objets 69
70 Liens (entre objets) Un lien indique une connexion entre deux objets paul : Client APourCompte c1 : Compte pierre : Client APourCompte APourCompte c2 : Compte marie : Client c3 : Compte Note de style : les noms des liens sont des formes verbales et commencent par une majuscule indique le sens de la lecture (ex: «paul APourCompte c1») 70
71 Contrainte sur les liens Au maximum un lien d'un type donné entre deux objets donnés APourEpouse joseph : Personne APourEpouse marie : Personne EstEnfantDe madeleine : Personne EstGardePar EstEnfantDe OK josé : Personne 71
72 Rôles Chacun des deux objets joue un rôle diffèrent dans le lien pierre : Client titulaire APourCompte compte c1 : Compte Note de style : choisir un groupe nominal pour désigner un rôle si un nom de rôle est omis, le nom de la classe fait office de nom (avec la première lettre en minuscule) 72
73 3 noms pour 1 concept utilisations différentes selon le contexte a g R f b pierre : Client APourCompte titulaire compte c1 : Compte a R b b "joue le role de" f "pour" a a "joue le role de" g "pour" b pierre a pour compte c1 c1 joue le role de compte pour pierre pierre joue le role de titulaire pour c1 73
74 Associations (entre classes) Une association décrit un ensemble de liens de même "sémantique" Client titulaire APourCompte compte Compte Diagramme de classes (modèlisation) M1 M0 paul : Client APourCompte> c1 : Compte pierre : Client APourCompte> APourCompte> c2 : Compte Diagramme d objets (exemplaires) marie : Client c3 : Compte 74
75 Association vs. Liens Un lien lie deux objets Une association lie deux classes Un lien est une instance d association Une association décrit un ensemble de liens Des liens peuvent être ajoutés ou détruits pendant l exécution (ce n est pas le cas des associations) Le terme "relation" ne fait pas partie du vocabulaire UML 75
76 Utiliser les rôles pour «naviguer» M1 Client titulaire APourCompte comptes Compte M0 paul.comptes pierre.comptes marie.comptes c1.titulaire c2.titulaire c3.titulaire = {c1} = {c2,c3} = { } = paul = pierre = pierre paul : Client pierre : Client marie : Client titulaire titulaire titulaire APourCompte> comptes APourCompte> comptes APourCompte> comptes c1 : Compte c2 : Compte c3 : Compte Nommer en priorité les rôles 76
77 Cardinalités d une association Précise combien d objets peuvent être liés à un seul objet source Cardinalité minimale et cardinalité maximale ( C min..c max ) Doivent être des constantes Client 1 APourCompte 0..* titulaire comptes Compte M1 «Tout client a toujours 0 ou plusieurs comptes» «Tout compte a toujours 1 et 1 seul titulaire» M0 paul : Client APourCompte> c1 : Compte pierre : Client APourCompte> APourCompte> c2 : Compte marie : Client c3 : Compte 77
78 Cardinalités d une association 1 Classe Exactement une * 0..1 Classe Plusieurs (0 à n) Classe Optionnelle (0 ou 1) 1,2, Classe Classe Cardinalité spécifiée Intervalle 78
79 Cas particulier d association Relation réflexive : encadre chef 1 Personne 1..* sous-fifre Une relation réflexive lie des objets de même classe 79
80 Contraintes entre associations Client 1 titulaireprincipal 0..* 0..* co-titulaires 0..* 1..* /titulaires 0..* Compte numéro solde... Les cardinalités sont loins d'être suffisantes pour exprimer toutes les contraintes... décrire les contraintes en langue naturelle (ou en OCL) (1) Un client ne peut pas être à la fois titulaire principal et co-titulaire d un même compte. (2) Les titulaires d un compte sont le titulaire principal et les co-titulaires le cas échéant 80
81 1 Client signataire 0.. * titulaires CarteBleue Code retraitmax signataire : Consor tium paul : Client pierre : Client marie : Client sophie : Client * signataire titulaires titulaires titulaires titulaires * Compte 1 : Banque : Distrib uteur numéro solde... : Banque EstAcceptéPar> : CarteBl eue : CarteBl eue 1.. * c1 : Compt e c2 : Compt e c3 : Compt e 1..* EstAcc eptépa r> EstAcc eptépa r> c1 : Compt e c2 : Compt e c3 : Compt e EstAcc eptépa r> EstAcc eptépa r> Distributeur Banque numéro nom : CarteBl eue : CarteBl eue : Banque : Banque : Distrib uteur titulaires titulaires titulaires titulaires 0..* 1.. * Consortium paul : Client pierre : Client marie : Client signataire sophie : Client : Consor tium signataire * Diagrammes de classes vs. d objets Un diagramme de classes défini l ensemble de tous les états possibles les contraintes doivent toujours être vérifiées Un diagramme d objets décrit un état possible à un instant, un cas particulier doit être conforme au modèle de classes Les diagrammes d objets peuvent être utilisés pour expliquer un diagramme de classe (donner un exemple) valider un diagramme de classe (le «tester») 81
82 : Client : Client : Compte : Client titulaires titulaires signat aire : : : Client : : : Consortium : titulaires titulaires > > > : Compte : Compte : : Banqu e : Banqu e : Distributeur : Banqu e : Distributeur : Consortium : Client : : : Consortium : Client titulaires titulaires : : Client : Compte : Client : : > > > : Compte : Compte : : Banqu e : Banqu e : Distributeur : Consortium : Client : Compte : Client titulaires titulaires : : : Client : : : Consortium : > > > : Compte : Compte : : Banqu e : Banqu e : Distributeur : Consortium Diagrammes de classes vs. d objets 1 Client signataire * titulaires Compte numéro solde * Banque numéro nom 1..* 0..* 1 Consortium 0..* CarteBleue * 1 M1 Code retraitmax EstAcceptéPar> 1..* Distributeur 0..* M0... t 1 t 2 t 3 82
83 Généralisation / Spécialisation Une classe peut être la généralisation d une ou plusieurs autres classes. Ces classes sont alors des spécialisations de cette classe. Personne Cas général Compte "Sous classes" Homme Femme Cas spécifique Deux points de vue lié (en UML) : relation d'héritage relation de sous-typage Compte Epargne 83
84 Relation d'héritage Les sous-classes «héritent» des propriétés des superclasses (attributs, méthodes, associations, contraintes) solde Compte créditer() débiter() * Banque {inv: solde > -5000} CompteEpargne solde tauxintérêt * Banque CompteEpargne créditer() débiter() calculintérêts () tauxintérêt ajouterintérêts () {inv: tauxintérêt < 100} {inv: solde > et tauxintérêt < 100} 84
85 Relation d'héritage et redéfinitions Une opération peut être "redéfinie" dans les sousclasses Compte solde créditer() débiter() CompteEpargne Permet d'associer des méthodes spécifiques à chaque classe pour réaliser une même opération PEL créditer() débiter() ajouterintérêts () créditer() débiter() ajouterintérêts () PEC débiter() PET débiter() 85
86 Relation de sous typage : vision ensembliste Compte M1 Compte Epargne M0 c3 tout objet d une sous-classe appartient également à la superclasse ce1 ce2 ce3 c4 c4 c1 c2 Compte CompteEpargne 86
87 Synthèse des concepts de base Classe attribut méthode Association rôle cardinalité Héritage M1 M0 o1 o1 o3 o1 o2 o2 o4 o5 o2 o3 Objet Lien Inclusion ensembliste 87
88 Diagramme de classe Utilisation avancée 88
89 UML?...une question de style et de contexte S'adapter au niveau d'abstraction au domaine d'application aux outils utilisés aux savants et ignorants ingénierie vs. retro-ingénierie 89
90 A. Raffinement du concept de CLASSIFICATEUR Les classificateurs (classifier) : Classe Classes abstraites Enumération Datatypes Interfaces Classes paramétrées 90
91 Déclaration d'attributs Syntaxe: [/][visibility]name[:type][multiplicity][=default][{prop}] Propriétés: {readonly}, {union}, {subset <p>}, {redefines <p>}, {ordered}, {unique}, {non-unique}, {prop-constraint}. Visibilité: [+,~,#,-] Peuvent être soulignés (attributs de classe) age +age /age - solde : Integer = 0 # age : Integer [0..1] # numsecu : Integer {frozen} # motsclés : String [*] {addonly} nbpersonne : Integer 91
92 Attribut dérivé Attribut dont la valeur peut être déduite d autres éléments du modèle e.g., âge si l on connaît la date de naissance notation : /age En termes d analyse, indique seulement une contrainte entre valeurs et non une indication de ce qui doit être calculé et ce qui doit être mémorisé 92
93 Déclaration d'opérations Syntaxe: [/] [ visibilité ] nom [ ( params ) ] [ : type ] [ { props... } ] params := [ in out inout ] nom [ : type] [ =defaut ] [{ props... } ] /getage() + getage() : Integer - updateage( in date : Date ) : Boolean # getname() : String [0..1] +getage() : Integer {isquery} +addproject() : { concurrency = sequential } +addproject() : { concurrency = concurrent } +main( in args : String [*] {ordered} ) 93
94 Propriétés des opérations redefines <operation-name> query concurrent: des appels multiples peuvent arriver simultanément et être traités de façon concurrente guarded: des appels multiples peuvent arriver simultanément mais seront traités un à la fois sequential: un seul appel peut arriver à la fois. 94
95 Classe abstraite Encapsule un comportement commun Ne possède pas d instances Possède des opérations abstraites Etudiant Etudiant {abstract} Dans les langages de programmation OO : deferred en Eiffel abstract en Java pure virtual en C++ méthodes ^self shouldnotimplement en Smalltalk 95
96 Data Type Type, dont: les valeurs n ont pas d identité les opérations sont des fonctions pures «datatype» Date day : Integer month : Integer year : Integer Exemples de Data Type : Enumeration Types primitifs: Boolean, Integer, UnlimitedNatural, String 96
97 Enumération (Data Type particulier) Définition <<enumeration>> Jour Lundi Mardi Mercredi Jeudi Vendredi Samedi Dimanche <<enumeration>> Titre Secretaire President Tresorier VicePresident Membre Utilisation Association1901 nom : String jourdereunion : Jour 97
98 Interface Une déclaration d un ensemble cohérent d opérations Une interface peut être implémentée ou demandée «Interface» Serializable + read() + write Exporter write() HTML Page title : String size : Integer render() save() HTML Page title : String size : Integer render() save() Serializable Exporter write() 98
99 Type paramétré (classe générique) Indispensable pour les classes conteneurs (e.g., listes) Existe en Ada, Eiffel, C++ (templates) et Java (>1.5) N est pas nécessaire en Smalltalk et Python Vecteur item : T taille : int ajouter() supprimer() T <<bind>> <Point> Classe générique Vecteur element : T dim : Entier T, Entier : Integer Polygone paramètres génériques Classe effective Point3D <<bind>> <Double, 3> paramètres effectifs 99
100 + # - Visibilité des éléments Restreindre l'accès aux éléments d'un modèle Contrôler et éviter les dépendances entre classes et paquetages + public visible # protégé visible dans la classe et ses sous-classes - privé visible dans la classe uniquement ~ package visible dans la package uniquement Utile lors de la conception et de l'implémentation, pas avant! N'a pas de sens dans un modèle conceptuel (abstrait), e.g., modèle d analyse N'utiliser que lorsque nécessaire La sémantique exacte dépend du langage de programmation! 100
101 + # - Visibilité des éléments Interface corps public = + protégé = # privé = - usager héritier implémenteur 101
102 B. Raffinement du concept d'association Association uni/bi directionnelle Composition Agrégation {frozen}, {addonly}, {ordered}, {nonunique} Classes associatives Associations n-aires Associations attribuées Associations qualifiées 102
103 Navigation Association unidirectionnelle On ne peut naviguer que dans un sens UML2.0 Client 1 titulaire * Compte A priori, que dans les diagrammes de spécifications et d'implémentation En cas de doute, ne pas mettre de flèche!!! 103
104 Composition Notion intuitive de "composants" et de "composites" Voiture 4 Roue 1 1 Pneu Jante composition = cas particulier d association + contraintes décrivant la notion de "composant"
105 Composition Contraintes liées à la composition : Pas de partage : un objet composant ne peut être que dans 1 seul objet composite Cycle de vie du composant lié au cycle de vie du composite : si un objet composite est détruit, ses composants aussi Dépend de la situation modélisée! (e.g., vente de voitures vs. casse) 105
106 Composition Contraintes liées à la composition : Pas de partage : un objet composant ne peut être que dans 1 seul objet composite Cycle de vie du composant lié au cycle de vie du composite : si un objet composite est détruit, ses composants aussi Document 1..* 1..* Chapitre 0..* Section Figure
107 Composition Document 1 1..* 1..* Chapitre Section M1 0..* 1..* Figure M0 : document : chapitre : chapitre : section : section : figure : section Contrainte : le graphe d'objets forme un arbre (ou une forêt) : figure 107
108 Agrégation agrégation = cas particulier d association + contraintes décrivant la notion d'appartenance... (???) * Figure * x y Point Partage possible Pas de concensus sur la signification exacte de l'aggrégation Utiliser avec précautions (ou ne pas utiliser...) Supprimé en UML
109 Autre vues de la composition/agrégation Différentes formes suggérant l inclusion : Voiture Voiture roulement[4-6]: Roue structure: Chassis roulement 4-6 structure 1 Roue Chassis 109
110 Classes association Pour associer des attributs et/ou des méthodes aux associations classes associations Personne employés sociétés * 0..2 Société salaire Emploi augmenter() Le nom de la classe correspond au nom de l association (problème: il faut choisir entre forme nominale et forme verbale) 110
111 Classes association Personne employés sociétés * 0..2 Société M1 Emploi salaire augmenter() M0 e1 salaire = 1500 employé jean employé e2 salaire = 700 xerox ujf Le salaire est une information correspondant ni à une personne, ni à une société, mais à un emploi (un couple personne-société). e3 marie employé salaire =
112 Classes association RAPPEL: pour une association donnée, un couple d'objets ne peut être connectés que par un seul lien correspondant à cette association (sauf si l'association est décorée par {nonunique} en UML2.0) p1 Emploi> Emploi> s1 Cette contrainte reste vraie dans le cas où l association est décrite à partir d une classe association : Emploi salaire = 1500 p1 s1 : Emploi salaire =
113 Classes association Personne employé sociétés * 0..2 Emploi salaire p1 Société e1 s1 Ci-dessus, une personne peut avoir deux emplois, mais pas dans la même société p1 e1 e2 s1 Personne employé 0..2 Emploi * société 1 salaire 1 Société Ci-dessus, une personne peut avoir deux emplois dans la même société 113
114 Classes association (sémantique) A rolea(s) carda roleb(s) cardb B C Transformation systèmatique pour revenir aux concepts de base A rolea c(s) c(s) roleb C 1 1 B Il ne peut y avoir qu'un objet C entre un objet A et un objet B donné 114
115 Classes association (sémantique) Personne employés sociétés * 0..2 Emploi Société Personne emplois emplois employé société Emploi * 1 Société Il ne peut y avoir qu'un Emploi entre une Personne et une Société 115
116 Classes association Les classes association sont des associations mais aussi des classes. Elles ont donc les mêmes propriétés et peuvent par exemple être liées par des associations. Personne employé * Emploi société 0..2 Société FicheDePaye * {ordered} salaire augmenter() 116
117 Associations n-aires Relations entre plus de 2 classes (à éviter si possible) : PROFESSEUR * Enseignant Enseignement 1..* Enseignée MATIERE Destinataire 1..* CLASSE PROFESSEUR 0..* Enseignant 1..* Enseignement 1..* 1 1..* Enseignée MATIERE Destinataire 1..* CLASSE 117
118 Associations attribuées L'attribut porte sur le lien Etudiant candidat épreuve n..k objet_épreuve Matière Note 118
119 Associations qualifiées Un qualificateur est un attribut (ou un ensemble d'attributs) dont la valeur sert à déterminer l'ensemble des instances associées à une instance via une association. Repertoire nom 0..1 Fichier "Pour un répertoire, à un nom donné on associe qu'un fichier (ou 0 s'il existe aucun fichier de ce nom dans ce répertoire)." Correspond à la notion intuitive d'index absente ci-dessous Repertoire * Fichier 119
120 Associations qualifiées - exemple Association1901 * titre:titre * membres * 0..1 Personne <<enumeration>> Titre Secretaire President Tresorier membres fred membres ass1 Tresorier sylvia President ahmed Secretaire joe ass2 President 120
121 Cardinalité des associations qualifiées Cas classique: cardinalité 0..1 Banque nc Compte 0..1 Cas plus rare: cardinalité * (pas de contrainte particulière exprimée) Banque titre * * Employe Cas plus rare: cardinalité 1 (généralement c'est une erreur) Echiquier nl : NumLigne nc : NumCol Case 0 comme cardinalité minimale, sauf si le domaine de l'attribut qualifieur est fini et toutes les valeurs ont une image
122 Attributs de l'association Les attributs qualifieurs sont des attributs de l'association, pas de la classe Repertoire nom * 0..1 Fichier r1 nom="a" nom="b" f1 r2 nom="f" f2 Exemple liens "hard" en Unix: un fichier peut correspondre à des noms différents dans des repertoires différents 122
123 Problèmes classiques Souvent l'index est également un attribut de classe indexée Solution correcte: Repertoire nom Fichier Le nom du fichier correspond au nom qu'a le fichier dans le répertoire /nom 2 erreurs communes: Repertoire nom 1 1 Fichier nom 123
124 Classes qualifiée (sémantique) Repertoire nom * Contient 0..1 Fichier Transformation systèmatique pour revenir aux concepts de base Contient nom Les attributs du qualifieur sont des attributs de l'association Repertoire * * Fichier Un répertoire contient 0 ou 1 fichier pour un nom donné 124
125 Contraintes prédéfinies sur les associations Par exemple : {ordered}: les éléments de la collection sont ordonnés {nonunique} : répétitions possibles (UML2.0) {frozen}: fixé lors de la création de l objet, ne peut pas changer {addonly}: impossible de supprimer un élément RelevéDe Compte lignes * {ordered,addonly} Ligne Opération Il est possible de définir de nouvelles contraintes 125
126 Contraintes prédéfinies sur les rôles {redefines <end-name>} : redéfinition d un autre rôle {subsets <property-name} : le rôle représente un sous-ensemble {union} : union dérivée de tous ses sous-ensembles 126
127 Rôle non unique (sémantique) A rolea carda R {nonunique} bs * B A a 1 rs * R rolea carda b 1 B 127
128 Rôle unique (sémantique) A rolea carda R {unique} bs * B A a 1 rs * R rolea carda b 1 B Entre un a et un b donné il n'y a qu'un r 128
129 Rôle ordonné (sémantique par index) A rolea carda R {ordered} bs * B A 1 a rs * R ib : integer rolea carda b 1 B Pour tout a, tous les rs ont un indice ib différent et couvrant l'intervalle de 1 au nombre de bs. (si {unique} on a aussi Entre un a et un b il n'y a qu'un r) rs->isunique(ib) and rs.i->asset=sequence{1..bs->size()} -- si {unique} rs->isunique(b)
130 Rôle ordonné (sémantique par index) A rolea carda R {ordered} bs * B A ib : integer rolea carda R b 0..1 B R->isUnique(ib) and R.ib->asSet = R.Set{1..b->size} 130
131 Rôle ordonné (sémantique par chainage) A rolea carda R {ordered} bs * B A aoffirstrb firstrb R rolea carda prevb nextrb RHasNextb aoffirstrb->isempty xor prevb->isempty allnextrb()->excludes(self) avec allnextrb() : Set(R) = nextrb.allnextrb()->including(nextrb) b 1 B 131
132 Rôle ordonné 1-* (sémantique par index) A a x..1 R {ordered} bs * B A Pour tout a, tous les bs ont un indice irb différent et couvrant l'intervalle de 1 au nombre de bs. bs->isunique(irb) and rs.i->asset=sequence{1..bs->size()} a x..1 bs B * irb [x..1] : integer irb->isempty = a->isempty
133 Synthèse sur les associations Nom de rôle sens de lecture Nom d association Cardinalités ClasseA x : string Composition (ou agrégation ) rolea <AssociationX 0..* ClasseB {frozen} AssociationX attributz Navigation Contrainte Classe associative 133
134 C. Raffinement du concept de GÉNÉRALISATION Re-définition Classes abstraites Méthodes abstraites Héritage simple vs. Multiple Classification simple vs. Multiple Classification statique vs. dynamique 134
135 Héritage et redéfinition Une sous classe peut redéfinir une méthode à condition toutefois de rester compatible avec la définition originale Figure surface() déplacer() Cercle surface() Polygone surface() Carré surface() 135
136 Classes et méthodes abstraites Une classe abstraite ne peut pas être instanciée utile pour définir un comportement abstrait peut contenir des méthodes abstraites Une méthode abstraite doit être définie dans une sous classe est dans un classe abstraite Notations équivalentes : surface() déplacer() Figure Figure {abstract} surface() {abstract} déplacer() 136
137 Classes abstraites du point de vue ensembliste M1 M0 Figure surface() déplacer() Cercles Figures Polygones Cercle Polygone c1 c2 Triangles t1 Carrés ca1 surface() surface() c3 t2 ca2 Triangle Carré c4 surface() surface() 137
138 Classification vs. Héritage Classification Héritage/Spécialisation Chien Chien Animal M1 M0 <<instanceof>> medor medor coco 138
139 Héritage multiple Une classe peut hériter de plusieurs super-classes Chauffage Appareil Appareil Électrique M1 M0 Poêles Chauffage Appareils Chauffages électriques Appareils électriques Micro ondes Poel Chauffage Électrique MicroOndes Interdit dans certains langages de programmation (e.g., Java et C#) 139
140 Points liés à l héritage et à la classification Les modèles orientés-objets ne font pas tous les mêmes hypothèses Héritage simple vs. héritage multiple Une classe peut elle hériter de plusieurs classes? Classification simple vs. classification multiple Un objet peut-il être simultanément instance de plusieurs classes? Classification statique vs. classification dynamique Un objet peut-il changer de classe pendant l exécution? 140
141 Hypothèses UML par défaut Sauf si le contraire est indiqué explicitement, en UML les hypothèses par défaut sont : Héritage multiple une classe peut hériter de plusieurs classes Classification simple un objet est instance d une seule classe Classification statique un objet est créé à partir d une classe donnée et n en change pas 141
142
143 Où en est on? (Récapitulatif) From Programing to Modeling Functional view with UML (use case diagram & model, system sequence diagram) Structural view with UML: Class diagram (M1 = type level) vs. Object Diagram (M2 = instance level) classifiers, associations, generalization objects, links, polymorphism Now: advanced UML (packages, OCL, etc.) behavioral and implementation views with UML 143
144 D. Concept de DÉPENDANCE (1/3) Relation entre deux éléments (client et fournisseur) Abstraction : Entre éléments de différents niveaux sémantiques «derive» : éléments dérivés, pas forcément du même type «refine» : raffinement entre modèles «type» Personne «refine» Personne Impl «trace» : (aussi) - utilisé pour marquer les changements entre modèles Intérêt : Outillage de méthodes de développement (RUP, Catalysis, etc.) Permission («permit») : droits d accès aux propriétés privées Etudiant + nom - cartable «permit» Professeur 144
145 Concept de dépendance (2/3) Relation entre deux éléments (client et fournisseur) Réalisation («realize») : Relation entre deux ensembles d éléments, de spécification et d implémentation Utilisé pour représenter: raffinement, optimisation, transformations, synthèses, etc. Substitution («substitute») : Relation entre classificateurs. Les instances du fournisseur peuvent remplacer celles du client Etudiant + nom - cartable «substitute» Espion 145
146 Concept de dépendance (3/3) Relation entre deux éléments (client et fournisseur) Usage : Représentation des associations non permanentes. Très utiles pour estimer la testabilité d un modèle ou l impact d un changement «call» : dépendance entre opérations (où classes) «create» : le client créé des instances du fournisseur (classificateurs) «instantiate» : les opérateurs du client créent des instances du fournisseur «send» : entre une opération et un signal 146
147 E. Raffinement du concept de CONTRAINTE Exemple de contraintes : Invariant (sur une classe) Pre-/Post- condition (sur une méthode) Remarque : exprimée sur un diagramme de classe, une contrainte réduit le nombre de diagrammes d objet conformes 147
148 Représentation des invariants Invariants = Propriétés vraies pour l'ensemble des instances de la classe dans un état stable, chaque instance doit vérifier les invariants de sa classe Des contraintes peuvent être ajoutées aux éléments du modèle UML Notation : entre { } Des contraintes peuvent être exprimées à l aide d OCL (Object Constraint Language) e.g. {solde >= plancher} Compte {solde>=plancher} solde: Somme plancher: Somme créditer (Somme) débiter (Somme) 148
149 Représentation des pré/post conditions Préconditions {«precondition» expression booléenne OCL} Abrégé en: {pre: expression booléenne OCL} Postconditions {«postcondition» expression booléenne OCL} Abrégé en: {post: expression booléenne OCL} Operateur «valeur précédente» (idem old Eiffel): expression 149
150 Etre abstrait et précis avec UML Compte {solde>=plancher} solde: Somme plancher: Somme créditer (montant : Somme) {pre: montant > 0} {post: solde = + montant} débiter (s: Somme) {pre: montant > 0 and montant<=solde-plancher} {post: solde = - montant} Analyse précise ou analyse par contrat 150
151 Contraintes OCL navigant les relations Chaque association est un chemin de navigation Le contexte d une expression OCL est le point de départ (la classe de départ) Les noms de rôle sont utilisés pour identifier qu elle relation on veut naviguer Personne 1 propriétaire possession propriété * Context Voiture inv: self.propriétaire.age >= 18 Voiture 151
152
153 Mo/va/ons d OCL Diagrammes exprimant certaines contraintes graphiquement contraintes structurelles (e.g. un a"ribut dans une classe) contraintes de types (e.g. sous- typage) contraintes diverses (e.g. composi7on, cardinalité, etc.) via des propriétés prédéfinies sur des classes (e.g. {abstract}) sur des rôles (e.g. {ordered}) Les diagrammes UML manquent parfois de précision. Mais le langage naturel (français ou anglais) est souvent ambigu.
154 Illusions partagées ou non Attention aux contraintes supposées être évidentes ou vérifiée "naturellement" 1" 1..4" 0..*" Client" titulaires" signataire" Compte" numéro" solde" dmax" 1 : CarteBleue" 0..*" CarteBleue" *" signataire" paul : Client" titulaires" c1 : Compte" Le signataire d'une carte bleue " est titulaire de ce compte." pierre : Client" titulaires" c2 : Compte" titulaires" marie : Client" titulaires" c3 : Compte" signataire" titulaires" : CarteBleue" jean : Client" titulaires" c2 : Compte"
155 Expression des contraintes en langue naturelle Simple à me"re en oeuvre u7lisa7on des notes en UML + texte libre compréhensible par tous Indispensable! documenter les contraintes est essen7el détecter les problèmes le plus tôt possible Problèmes ambigu, imprécis difficile d exprimer clairement des contraintes complexes difficile de lier le texte aux éléments du modèle
156 Concep/on par contrats avec UML Ajout de contraintes à des éléments de modélisa7on. {context Personne inv : self.epouse - >notempty() implies self.epouse.mari = self and self.mari - > notempty() implies self.mari.epouse = self}
157 Exemple 1" Client" signataire" 0..*" 1..4" 0..*" titulaires" CarteBleue" code" retraitmax" *" *" Compte" numéro" solde" dmax" 1 1..*" 1" Banque" numéro" 1..*" Distributeur 1..*" 0..*" Consortium 1" 0..*" (1) Le solde d'un compte ne doit pas être inférieur au découvert maximum autorisé" (2) Le signataire d'une carte bleue associée à un compte est le titulaire de ce compte." (3) Une carte bleue est acceptée dans tous les distributeurs des consortiums de la banque." (4) Les clients d'une banque non affiliée à un consortium ne peuvent pas avoir de carte bleues."
158 Exemple 1" Client" signataire" 0..*" 1..4" 0..*" titulaires" CarteBleue" code" retraitmax" Compte" numéro" solde" dmax" 1 *" *" 1..*" 1" Banque" numéro" 1..*" Distributeur 1..*" 0..*" Consortium 1" 0..*" -- (1) Le solde d'un compte ne doit pas être inférieur au découvert maximum autorisé " context context c Compte : Compte inv: inv: solde dmax > dmax >= 0 inv: solde > dmax
159 Exemple 1" Client" signataire" 0..*" 1..4" 0..*" titulaires" CarteBleue" code" retraitmax" *" *" Compte" numéro" solde" dmax" 1 Compte" 1..*" 1" Banque" numéro" 1..*" Distributeur 1..*" 0..*" Consortium 1" 0..*" -- (2) Le signataire d'une carte bleue associée à un compte est le titulaire de ce compte." context CarteBleue inv: self.signataire = self.compte.titulaires
160 Exemple 1" Client" signataire" 0..*" 1..4" 0..*" titulaires" CarteBleue" code" retraitmax" *" *" Compte" numéro" solde" dmax" 1 Compte" 1..*" 1" Banque" numéro" 1..*" Distributeur 1..*" 0..*" Consortium 1" 0..*" -- (2) Le signataire d'une carte bleue associée à un compte est l'un des titulaires de ce compte." context CarteBleue inv: self.compte.titulaires->includes(self.signataire)
161 Exemple 1" Client" signataire" 0..*" 1..4" 0..*" titulaires" CarteBleue" code" retraitmax" *" *" Compte" numéro" solde" dmax" 1 1..*" 1" Banque" numéro" 1..*" Distributeur 1..*" 0..*" Consortium 1" 0..*" -- (3) Une carte bleue est acceptée dans tous les distributeurs des consortiums de la banque. " context CarteBleue inv: self.distributeur = self.compte.banque.consortium.distributeur->asset
162 Exemple 1" Client" signataire" 0..*" 1..4" 0..*" titulaires" CarteBleue" code" retraitmax" *" *" Compte" numéro" solde" dmax" 1 1..*" 1" Banque" numéro" Distributeur 1..*" / distributeurspossibles 1..*" 0..*" Consortium 1" 0..*" context CarteBleue::distributeursPossibles : set(distributeur) derive: self.compte.banque.consortium.distributeur->asset
163 Caractéristiques d OCL Langage d'expressions (fonctionnel) Valeurs, expressions, types Fortement typé Pas d'effets de bords Langage de spécification, pas de programmation Haut niveau d'abstraction Pas forcément exécutable Permet de trouver des erreurs beaucoup plus tôt dans le cycle de vie
164 Caractéristiques d OCL Points faibles Pas aussi rigoureux que VDM, Z ou B => pas de preuves possibles Puissance d'expression limitée Points forts Relativement simple à écrire et à comprendre Très bien intégré à UML Bon compromis entre simplicité et puissance d'expression Passage vers différentes plateformes technologiques
165 Contexte d'une contrainte Contrainte toujours associée à un élément de modèle : le contexte de la contrainte. Deux techniques pour spécifier le contexte : 1 { init: 0 } Client" signataire" 0..*" 1..4" 0..*" titulaires" CarteBleue" code" retraitmax" *" Compte" numéro" solde" dmax" 1" { inv: dmax >= 0 inv: solde > -dmax } context Compte inv: dmax >=0 inv: solde > -dmax context CarteBleue inv: inv: inv: Compte.titulaires->includes(self.signataire) code>0 and code<=9999 retraitmax>10 { inv: Compte.titulaires->includes(self.signataire)} context Compte::solde : integer init: floor(depotinitial * 10 / 100)
166 Où utiliser OCL OCL peut être utilisé pour décrire des prédicats inv: invariants de classes inv: solde < decouvertmax pre: pré-conditions d opérations pre: montantaretirer > 0 post: post-conditions d opérations post: solde > OCL peut également être utilisé pour décrire des expressions def: déclarer des attributs ou des opérations def: nbenfants:integer init: spécifier la valeur initiale des attributs init: enfants->size() body: exprimer le corps de méthodes {query} body: enfants->select(age< a ) derive: définir des élements dérivés (/) derive: age<18
167 Navigation des relations 0..* Par navigation on n obtient plus un scalaire, mais une collection d objets OCL défini 3 sous-types de collections Set : obtenu par navigation d une relation 0..* Context Personne inv: propriété retourne un Set[Voiture] chaque élément est présent au plus une fois Bag : si plus d un pas de navigation un élément peut être présent plus d une fois Sequence : navigation d une relation {ordered} c est un Bag ordonné Nombreuses opérations prédéfinies sur les types collection. Syntaxe : Collection->opération 167
168 Class Diagram: Conclusion Un diagramme de classes est un graphe d éléments connectés par des relations. Un diagramme de classes est une vue graphique de la structure statique d un système. Company Person Company members 0..1 * Employee 168
169 Constituants d une classe Concept représenté (nom) Classes héritées (concepts précisés) Relations avec autres classes Attributs (classe, nom, visibilité) Opérations (paramètres) Contraintes, invariants Généricité (classes paramétrées) Stéréotypes 169
170 Structural View Composite Structure Diagram 170
Méthodes de Développement Industriel (MDI)
Méthodes de Développement Industriel (MDI) Mathieu Acher h"p://www.mathieuacher.com Associate Professor University of Rennes 1 h,p://mathieuacher.com/teaching/mdi/ 2 Objec:fs de MDI Méthodes de développement
Université de Bangui. Modélisons en UML
Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et
Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation
Un peu d'organisation Conception et Programmation par Objets HLIN406 Marianne Huchard, Clémentine Nebut LIRMM / Université de Montpellier 2 Premières semaines Contrôle des connaissances Supports 2015 Sommaire
IFT2255 : Génie logiciel
IFT2255 : Génie logiciel Chapitre 6 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon et Houari Sahraoui 6.1. Introduction à UML 1. Vers une approche orientée objet 2. Introduction ti
Plan. Exemple: Application bancaire. Introduction. OCL Object Constraint Language Le langage de contraintes d'uml
OCL Object Constraint Language Le langage de contraintes d'uml Plan 1. Introduction 2. Les principaux concepts d'ocl Object Constraint Language 1 Object Constraint Language 2 Exemple: une application bancaire
Diagramme de classes
Diagramme de classes Un diagramme de classes décrit les classes et leurs relations (associations, généralisation/spécialisation, ). classe association méthodes attributs héritage Diagramme de classes :
5 Génie logiciel orienté objet. Modélisation par objets et UML
5 Génie logiciel orienté objet 5.1 Introduction et concepts de base 5.2 Modélisation par objets et UML 5.3 Diagramme de classes 5.4 Diagramme de cas d utilisation 5.5 Diagrammes de collaboration 5.6 Diagramme
Modélisation Principe Autre principe
Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux
MODÉLISATION DES BESOINS
MODÉLISATION DES BESOINS Diagrammes de cas d utilisation Cas d'utilisation : Use Case (Jacobson) Permettent déxprimer les attentes/besoins des utilisateurs Permettent de définir les limites du système
Module B9-1 : sensibilisation à l UML
Module B9-1 : sensibilisation à l UML Olivier Habart : habart.olivier@gmail.com ENSTA B9-1 UML (Olivier Habart) Septembre 14 Diapositive N 1 Session 2 : Vue statique Sommaire Diagramme de classes Diagrammes
Le langage UML : Les cas d utilisation
Le langage UML : Les cas d utilisation Lydie du Bousquet Lydie.du-bousquet@imag.fr A1 CasU1 CasU4 CasU5 S CasU2 CasU3 A3 A2 En collaboration avec J.-M. Favre, I. Parissis, Ph. Lalanda, Y. Ledru 1 Le diagramme
OCL - Object Constraint Language
OCL - Object Constraint Language Laëtitia Matignon laetitia.matignon@univ-lyon1.fr Département Informatique - Polytech Lyon Université Claude Bernard Lyon 1 2012-2013 Laëtitia Matignon SIMA - OCL - Object
Diagrammes de classe UML
labsticc.univ-brest.fr/pages_perso/babau/ Diagrammes de classe UML Jean-Philippe Babau Département Informatique, UFR Sciences, Laboratoire Lab-STICC 2 1 Plan Introduction aux diagrammes de classe Description
Projet : Plan Assurance Qualité
Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET
Expression des contraintes. OCL : Object C o n t r a i n t L a n g u a g e
P r o b l é m a t i q u e OCL : O b j e c t C o n s t r a i n t L a n g u a g e Le langage de contraintes d UML Les différents diagrammes d UML permettent d exprimer certaines contraintes graphiquement
UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins. Emmanuel Pichon 2013 V1.1
UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins 2013 V1.1 Objectif Diagramme de classes (class diagram) pour le recueil des besoins et l analyse Présenter un ensemble
Introduction au Génie Logiciel
Introduction au Génie Logiciel Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, I. Parissis, Ph. Lalanda Qu est-ce que le logiciel? programme, ensemble d instructions Caractéristiques
Modélisation objet Le langage UML
Modélisation objet Le langage UML Brahim HAMID La base de contrôle Robot Zone à explorer brahim.hamid@irit.fr brahim.hamid@univ-tlse2.fr http://mass-cara.univ-tlse2.fr/~brahimou/ens/uml 1 Les méthodes
Use Cases. Introduction
Use Cases Introduction Avant d aborder la définition et la conception des UC il est bon de positionner le concept du UC au sein du processus de développement. Le Processus de développement utilisé ici
Plan. Partie 2 : UML. Module Génie Logiciel : Cours d'analyse Orientée Objet.
Partie II : UML Plan Partie 2 : UML 1 - Présentation d'uml 2 - Les diagrammes de cas d'utilisation 3 - Les diagrammes de classes et d'objets 4 - Les diagrammes d'interaction 5 - Les diagrammes de comportement
Rappels sur l objet. Yannick Prié Département Informatique - UFR Sciences et Techniques Université Claude Bernard Lyon 1 2011-2012
Rappels sur l objet Yannick Prié Département Informatique - UFR Sciences et Techniques Université Claude Bernard Lyon 1 2011-2012 Objectifs de ce cours 2 Rappels sur les concepts fondamentaux liés à la
Conventions communes aux profils UML
Conventions communes aux profils UML Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable 2.1 Date : Juin 2002 * : Les partenaires du
II.3. Diagrammes de classes
II.3. s de classes II.3. s de classes 1. Introduction Introduction Les diagrammes d'uml de structure comportemental de classes de package d objets d activités de cas d utilisation de composant de déploiement
Conception et Programmation par Objets GLIN404. Langages et paradigmes de programmation
Conception et Programmation par Objets GLIN404 Marianne Huchard, Clémentine Nebut LIRMM / Université de Montpellier 2 2013 Langages et paradigmes de programmation Le raisonnement classicatoire paradigme
UML. Diagrammes de classes (suite) Delphine Longuet. delphine.longuet@lri.fr
Polytech Paris-Sud Formation initiale 3 e année Spécialité Informatique Année 2014-2015 UML Diagrammes de classes (suite) Delphine Longuet delphine.longuet@lri.fr Opérations Opérations Service qui peut
Modélisation Orientée Objet / UML
Modélisation Orientée Objet / UML Laurent Henocque http://laurent.henocque.free.fr/ Enseignant Chercheur ESIL/INFO France http://laurent.henocque.perso.esil.univmed.fr/ mis à jour en Octobre 2006 Licence
IFT2251 : Génie logiciel
4.1. Introduction à UML IFT2251 : Génie logiciel 1. Approches de développement 2. Introduction à UML (une méthodologie basée sur l approche orientée aspect) 3. Rappel de quelques concepts objets Chapitre
DEMARCHE OU PROCESSUS LOGICIEL
DEMARCHE OU PROCESSUS LOGICIEL PROCESSUS LOGICIEL Définition Un processus définit une séquence d étapes, en partie ordonnées, qui concourent à l obtention d un système logiciel ou à l évolution d un système
Modèle d implémentation
Modèle d implémentation Les packages UML: Unified modeling Language Leçon 5/6-9-16/10/2008 Les packages - Modèle d implémentation - Méthodologie (RUP) Un package ou sous-système est un regroupement logique
UML (Diagramme de classes) Unified Modeling Language
UML (Diagramme de classes) Unified Modeling Language Sommaire Introduction Objectifs Diagramme de classes Classe (Nom, attribut, opération) Visibilité et portée des constituants d une classe Association
basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML
basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes
UML. Cas d'utilisation. Delphine Longuet. delphine.longuet@lri.fr
Polytech Paris-Sud Formation initiale 3 e année Spécialité Informatique Année 2014-2015 UML Cas d'utilisation Delphine Longuet delphine.longuet@lri.fr Processus de développement logiciel Analyse des besoins
Cours de Génie Logiciel
Cours de Génie Logiciel Sciences-U Lyon Diagrammes UML (2) http://www.rzo.free.fr Pierre PARREND 1 Avril 2005 Sommaire Les Diagrammes UML Diagrammes de Collaboration Diagrammes d'etats-transitions Diagrammes
Pierre Parrend IUT Lumière Lyon II, 2005-2006 pierre.parrend@univ-lyon2.fr. Bases de Données Avancées - UML et Bases de Données
Pierre Parrend IUT Lumière Lyon II, 2005-2006 pierre.parrend@univ-lyon2.fr Bases de Données Avancées - UML et Bases de Données Sommaire I. UML A. Ce qu'est UML B. Diagrammes de Cas d'utilisation C. Diagrammes
Description et illustration du processus unifié
USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins
1. Objectifs de la Modélisation. Dériver le schéma de la BD. Élaborer un modèle conceptuel. Modélisation E/R des Données
. Objectifs et principes Modélisation E/R des Données 2. Le modèle Entité-Association (E/R) 3. Passage au relationnel 4. Conclusion. Objectifs de la Modélisation Permettre une meilleure compréhension Le
UML. Diagrammes de classes. Delphine Longuet. Polytech Paris-Sud Formation initiale 3 e année Spécialité Informatique Année 2015-2016
Polytech Paris-Sud Formation initiale 3 e année Spécialité Informatique Année 2015-2016 UML Diagrammes de classes Delphine Longuet delphine.longuet@lri.fr Objets et classes Conception orientée objet :
UML : Les cas d utilisation
UML : Les cas d utilisation 2014 tv - v.1.0 Point de vue fonctionnel L expression préliminaire des besoins donne lieu à une modélisation par les cas d utilisation. Le concept de cas d
Le génie Logiciel (suite)
Le génie Logiciel (suite) Lors du cours précédent, on a étudié différents cycles de vie, dont la cascade, ou la spirale. Analyse des besoins L analyse des besoins est une étape menant à l élaboration de
Génie logiciel avancé
Université Paris-Sud L3 MIAGE apprentissage Année 2014-2015 Génie logiciel avancé Analyse des besoins et spécification Delphine Longuet delphine.longuet@lri.fr Analyse des besoins et spécification Objectif
UML 1ère partie. Référence: http://uml.developpez.com/lp/cours/uml_free_fr_cours.html UML
UML UML 1ère partie Référence: http://uml.developpez.com/lp/cours/uml_free_fr_cours.html LOG2000 Éléments du génie logiciel 2002 Bayomock André-Claude PLAN Définition et historique Vue générale A quoi
Conception et Développement Orientés Objets Cours 1 : Introduction. 2 Les paradigmes de programmation. 3 Les concepts de la programmation objet
CNAM UV 19357 Année 2003-2004 David Delahaye David.Delahaye@cnam.fr Conception et Développement Orientés Objets Cours 1 : Introduction 1 Présentation de la valeur Ce cours s adresse à toute personne ayant
Analyse, Conception Objet. Diagrammes de classes. Sommaire. Utilisation
Analyse, Conception Objet Sommaire Diagrammes de Classes Une partie du matériau de ce cours est issue du cours de S.Galland (Stephane.Galland@emse.fr) Septembre 2003 Définition Paquetages Classe Association
Traduction des Langages : Le Compilateur Micro Java
BARABZAN Jean-René OUAHAB Karim TUCITO David 2A IMA Traduction des Langages : Le Compilateur Micro Java µ Page 1 Introduction Le but de ce projet est d écrire en JAVA un compilateur Micro-Java générant
alg - Relations entre classes [kr]
alg - Relations entre classes [kr] Karine Zampieri, Stéphane Rivière, Béatrice Amerein-Soltner Unisciel algoprog Version 21 avril 2015 Table des matières 1 L association 2 1.1 Définitions...................................
Exposé de M.C.O. Thème. La methode orientée objet OMT (Object Modeling Technic)
Exposé de M.C.O Thème La methode orientée objet OMT (Object Modeling Technic) 1 Plan du travail Introduction Le cycle de vie Formalismes de représentation UML Les outils d assistance OMT et UML Conclusion
Analyse,, Conception des Systèmes Informatiques
Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance
Formation UML 2 le diagramme de cas d utilisation
Formation UML 2 le diagramme de cas d utilisation Travaux dirigés 11 au 13 février 2014 Hervé DOMALAIN CPII/DOSO/ED FORMATION UML 2 LE DIAGRAMME DE CAS D UTILISATION Travaux dirigés 1. Enoncé du cahier
Génie logiciel avancé
Université Paris-Sud L3 MIAGE apprentissage Année 2014-2015 Génie logiciel avancé Conception Delphine Longuet delphine.longuet@lri.fr Documentation du processus de GL Cahier des charges Analyse des besoins
IFT2251 : Génie logiciel
Cas IFT2251 : Génie logiciel Chapitre 4. Analyse orientée objets Section 3. Cas 1. Le diagramme de cas 2. Les acteurs 3. Les scénarios d un cas 4. Relations entre cas 5. Construction d un diagramme de
Langage et Concepts de Programmation Objet. 1 Attributs et Méthodes d instance ou de classe. Travaux Dirigés no2
Langage et Concepts de Programmation Objet Travaux Dirigés no2 Pôle Informatique École Nationale Supérieure des Mines de St-Etienne Vous trouverez plus de détails sur les concepts abordés lors de ce TD
AMSI - Chapitre 3 Perspectives de modélisation et UML
AMSI - Chapitre 3 Perspectives de modélisation et UML Philippe Thiran Année académique 2010-2011 Notes de cours: Patrick Heymans, Isabelle Pollet & Philippe Thiran The University Of Namur Version du vendredi
Modélisation Principe Autre principe
Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux
Rappels. Génie logiciel. Rappels. Règles métier. RUP, phases milestones, disciplines. Processus itératif & incrémental? Certification, CMM?
Rappels Génie logiciel RUP, phases milestones, disciplines Philippe Dugerdil 09.10.2008 Rappels Règles métier Processus itératif & incrémental? Certification, CMM? Modification des specification en cours
Approche orienté objet. Seifeddine Ferchichi
Approche orienté objet Seifeddine Ferchichi plan Récapitulation de l approche fonctionnelle Introduction Cycle de vie RUP Rappel des critères de qualité du logiciel Approche orienté objet Récapitulation
Chapitre 4 Modélisation et Conception de BD
Pourquoi une modélisation préalable? Chapitre 4 Modélisation et Conception de BD Il est difficile de modéliser un domaine sous une forme directement utilisable par un SGBD. Stockage physique Cohérence/intégrité
Ingénierie des Modèles. Méta-modélisation
Ingénierie des Modèles Méta-modélisation Eric Cariou Master Technologies de l'internet 2 ème année Université de Pau et des Pays de l'adour UFR Sciences Pau Département Informatique Eric.Cariou@univ-pau.fr
NFP121 Programmation Avancée. Relations entre classes
NFP121 Programmation Avancée Relations entre classes Xavier Crégut ENSEEIHT Télécommunications & Réseaux Xavier Crégut (N7) NFP121 Programmation Avancée Relations entre classes
Annexe du cours Conception des sites web marchands et mobiles
Conception des sites web marchands et mobiles Nassim BAHRI {contact@nassimbahri.ovh} 1 Novembre 2015 1 Diagramme de séquence système Les cas d'utilisation décrivent les interactions des acteurs avec le
Module B9-1 : sensibilisation à l UML
Module B9-1 : sensibilisation à l UML Session 1 : Introduction du module et diagramme de cas d utilisation Olivier Habart : habart.olivier@gmail.com ENSTA B9-1 UML (Olivier Habart) Septembre 13 Diapositive
Positionnement de UP
UNIFIED PROCESS Positionnement de UP Unified Process Langage Méthode Outil logiciel UML UP RUP 6 BONNES PRATIQUES développement itératif gestion des exigences architecture basée sur des composants modélisation
Chapitre II Analyse 1
Chapitre II Analyse 1 Plan du chapitre II II. Analyse A. Identification des besoins : Cas d utilisation 1. Définitions 2. Modes d utilisation 3. Format détaillé 4. Principes de rédaction 5. Concevoir les
Guichet automatique de banque
Guichet automatique de banque Mastère 2004 1 Guichet automatique de banque : GAB Objectif : Illustrer la vue fonctionnelle et particulièrement la définition des cas d utilisation. 1. Spécification du problème
Chapitre 2 : Conception de base de données relationnelle
Chapitre 2 : Conception de base de données relationnelle Le modèle entité-association 1. Les concepts de base 1.1 Introduction Avant que la base de données ne prenne une forme utilisable par le SGBD il
3. SPÉCIFICATIONS DU LOGICIEL. de l'expression des besoins à la conception. Spécifications fonctionnelles Analyse fonctionnelle et méthodes
PLAN CYCLE DE VIE D'UN LOGICIEL EXPRESSION DES BESOINS SPÉCIFICATIONS DU LOGICIEL CONCEPTION DU LOGICIEL LA PROGRAMMATION TESTS ET MISE AU POINT DOCUMENTATION CONCLUSION C.Crochepeyre Génie Logiciel Diapason
Sixième partie VI. Diagramme de cas d utilisation. Cours de Génie Logiciel. David Janiszek. Introduction. Les éléments. Les relations.
Sixième partie VI Diagramme de cas d utilisation Définition Le diagramme de cas d utilisation représente la structure des grandes fonctionnalités nécessaires aux utilisateurs du système Rôle du diagramme
Bases de données Cours 2 : Modélisation d une base de données
Cours 2 : Modélisation d une base de données POLYTECH Université d Aix-Marseille odile.papini@univ-amu.fr http://odile.papini.perso.esil.univmed.fr/sources/bd.html Plan du cours 1 Modélisation d une base
Systèmes d information dans les entreprises
Systèmes d information dans les entreprises Chargé: JF Couturier Cours # 4 MTI515 Automne 2013 JF Couturier 1 Retour sur les derniers cours Le document de vision Petit retour sur les diagrammes d activité
3. UML - Unified Modeling Language Diagrammes statiques
3. UML - Unified Modeling Language Diagrammes statiques Laëtitia Matignon laetitia.matignon@univ-lyon1.fr Département Informatique - Polytech Lyon Université Claude Bernard Lyon 1 2012-2013 Laëtitia Matignon
SYSTEMES D INFORMATION & CONCEPTION de BdD
SYSTEMES D INFORMATION & CONCEPTION de BdD PLAN CONCEPT DE SYSTEME D INFORMATION MODELISATION D UN SYSTEME D INFORMATION MODELISATION CONCEPTUELLE : les METHODES METHODE SYSTEMIQUE METHODE OBJET L3 Informatique
Chapitre 2 Modélisation de bases de données
Pourquoi une modélisation préalable? Chapitre 2 Modélisation de bases de données 1. Première étape : le modèle conceptuel Eemple : le modèle Entités-Associations (E/A) 2. Deuième étape : le modèle Traduction
Diagramme de Classe UML et Base de Données Relationnelle-objet
Ecole des Hautes Etudes Commerciales HEC Alger Diagramme de Classe UML et Base de Données Relationnelle-objet par Amina GACEM Module Informatique 1ière Année Master Sciences Commerciales Plan Introduction
SysML : les diagrammes
SysML : les diagrammes DIDIER FGNON, STÉPHNE GSTON [1] L outil SysML est un langage constitué de nombreux diagrammes. Nous vous proposons une ressource sous la forme de fiches-outils qui trouveront une
Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language
Unified Modeling Language UML Salima Hassas Version Cycle de vie du logiciel Client Besoins Déploiement Analyse Test Conception Cours sur la base des transparents de : Gioavanna Di Marzo Serugendo et Frédéric
Chapitre I : le langage UML et le processus unifié
I. Introduction Les méthodes d analyse orientées objet sont initialement issues des milieux industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c est-àdire les principes et
Cours de Génie Logiciel
Cours de Génie Logiciel Sciences-U Lyon MDE Model Driven Engineering http://www.rzo.free.fr Pierre PARREND 1 Mai 2005 Sommaire MDE : principe MDE et le génie logiciel MDE et UML MDE et les Design Patterns
Introduction aux Composants Logiciels
Introduction aux Composants Logiciels Christian Pérez LIP/INRIA Année 2010-11 Plan Introduction aux composants logiciels Pourquoi des composants logiciels Notions de composants logiciels Conclusion Survol
Le Processus Unifié appliqué au projet MOOCS
Le Processus Unifié appliqué au projet MOOCS Violaine Louvet GTN, 7 mai 2003, Orsay Le Processus Unifie applique au projet MOOCS p. 1 L objet Objet = entité regroupant des données (attributs) et des services
<< Crédit Club Auto >>
Abbas Ahmad Année 2010/2011 Matin Bayramov Analyse et Modélisation des Systèmes Informatique (AMSI) Projet de Modélisation UML > Professeur encadrant : M. GUILLAUME PAQUETTE Projet
GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009
GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage
LES CONCEPTS OBJETS. On regroupe les objets ayant les mêmes types de propriétés et de comportements en une classe.
LES CONCEPTS OBJETS I Objet et Classe Un objet est une entité du monde réel qui a très souvent un identifiant des propriétés des comportements (actions qu il peut effectuer). La voiture de Clément a pour
Concevoir des applications Web avec UML
Concevoir des applications Web avec UML Jim Conallen Éditions Eyrolles ISBN : 2-212-09172-9 2000 1 Introduction Objectifs du livre Le sujet de ce livre est le développement des applications web. Ce n est
Programmation Orientée Objet. Ecrire beaucoup de lignes de code, même très propres, ne suffit pas
2 Modélisation Construire un bon logiciel : Répondre aux objectifs fixés (satisfaire le client) Avoir une base architecturale solide qui permette l évolution Mettre en place un processus de développement
TD McGood 2004. McGood. Mastère 2004 1
McGood Mastère 2004 1 McGood Une petite entreprise familiale de restauration rapide, avec des produits de terroir (McGood), voudrait cesser de tenir sa comptabilité à la main (écriture des opérations comptables
CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES
MODEL-BASED TESTING (MBT) CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES Le Model-Based Testing est une pratique de test en plein développement dans l'industrie pour accroitre l'efficacité
Ingénierie des Modèles. Transformations de Modèles
Ingénierie des Modèles Transformations de Modèles Eric Cariou Université de Pau et des Pays de l'adour Département Informatique Eric.Cariou@univ-pau.fr 1 Plan Types de transformation Raffinement Projection
Éléments d UML pour le projet (Unified Modeling Language)
Éléments d UML pour le projet (Unified Modeling Language) C Crochepeyre UML 1 PLAN 1. Introduction 2. Préliminaires 3. Les règles UML 4. Les diagrammes UML 5. Outils de modélisation UML 6. L étude préalable
C est quoi le SWAT? Les équipes décrites par James Martin s appellent SWAT : Skilled With Advanced Tools.
1- RAD Quelle sont les avantages que apporte la méthode RAD à l entreprise? Une méthode RAD devrait, d après son auteur, apporter trois avantages compétitifs à l entreprise : Une rapidité de développement
PASCAL ROQUES. UML par. la pratique. Groupe Eyrolles, 2001, 2002, 2004, 2005, 2006, 2009. ISBN : 978-2-212-12508-5
est f o E Y R O L L E S PASCAL ROQUES UML par la pratique Groupe Eyrolles, 2001, 2002, 2004, 2005, 2006, 2009. ISBN : 978-2-212-12508-5 Sommaire Introduction 9 Objectifs du livre... 9 Structure de l ouvrage...
Introduction aux bases de données Cours 2 : Modélisation d une base de données
Cours 2 : Modélisation d une base de données ESIL Université de la méditerranée Odile.Papini@esil.univmed.fr http://odile.papini.perso.esil.univmed.fr/sources/bdmat.html Plan du cours 1 Modélisation d
Conception de bases de données relationnelles
Conception de bases de données relationnelles Niveau conceptuel : modélisation de BD relationnelles Marie Szafranski 2015-2016 ensiie 1 2015-2016 ensiie 1 Modélisation d une BD Modélisation d une BD Étape
Introduction aux Bases de Données
Introduction aux Bases de Données I. Bases de données I. Bases de données Les besoins Qu est ce qu un SGBD, une BD Architecture d un SGBD Cycle de vie Plan du cours Exemples classiques d'applications BD
Le génie logiciel. maintenance de logiciels.
Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction
L outil Cup. Licence info et GMI documentation COMPIL 2007-2008. Pour toutes remarques, questions, suggestions : mirabelle.nebut@lifl.
UFR IEEA Licence info et GMI documentation COMPIL 2007-2008 FIL Pour toutes remarques, questions, suggestions : mirabelle.nebut@lifl.fr 1 raccourci pour Java-Based Constructor of Useful Parsers est un
Stéphane GOBRON HES SO HE Arc ISIC
Stéphane GOBRON HES SO HE Arc ISIC 2015 Où en sommes nous? Plan de cours Ch.1 : OO Rappels Ch.2 : Etude de cas => le bridge DP Ch.3 : Conceptualisation, Singleton et Composite DPs Ch.4 : Decorator, State,
CONCEPTION des SYSTÈMES d INFORMATION UML
CONCEPTION des SYSTÈMES d INFORMATION UML 2 : Analyse Fonctionnelle Epitech 3 Automne 2007 Bertrand LIAUDET SOMMAIRE LES CAS D UTILISATION 2 1. Présentation intuitive de la notion de cas d utilisation
Chapitre 5 LE MODELE ENTITE - ASSOCIATION
Chapitre 5 LE MODELE ENTITE - ASSOCIATION 1 Introduction Conception d une base de données Domaine d application complexe : description abstraite des concepts indépendamment de leur implémentation sous
Développement itératif, évolutif et agile
Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie
Conception de Bases de Données Avec UML
1 1 Bases de Données Avancées Module B IUT Lumière, License CE-STAT 2006-2007 Pierre Parrend Plan du Cours Table of Contents Conception de Bases de Données Avec UML UML et la conception de Bases de Données...2
GENIE LOGICIEL Détermination du périmètre cible d une application
GENIE LOGICIEL Détermination du périmètre cible d une application Hervé DOMALAIN 2004 / 2005 Génie logiciel 2004 / 2005 Page 1 Diagrammes de CU et périmètre cible Le domaine cible d une application est