De l'analyse à la conception

2 631 vues

Publié le

A partir de quelques diagrammes UML, nous explicitons le passage à la conception et la mise en oeuvre

Publié dans : Formation, Technologie, Business
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 631
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
201
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • \n
  • \n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nOn ne parle pas des mêmes vols dans les deux questions\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nPenser à ajouter un numero au livre physique pour le gérer dans la bibliothèque alors qu’il est omis dans l’énoncé.\n\n\n\n
  • \n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nOn ne parle pas des mêmes vols dans les deux questions\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nOn ne parle pas des mêmes vols dans les deux questions\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nOn ne parle pas des mêmes vols dans les deux questions\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nOn ne parle pas des mêmes vols dans les deux questions\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nOn ne parle pas des mêmes vols dans les deux questions\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nOn ne parle pas des mêmes vols dans les deux questions\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nOn ne parle pas des mêmes vols dans les deux questions\n\n
  • Un vol générique peut exister par lui meme pas le vol.\n
  • Un vol générique peut exister par lui meme pas le vol.\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nOn ne parle pas des mêmes vols dans les deux questions\n\n
  • p90 de UML 2 par la pratique \nEs-ce le coup de l’anti pattern?\n\nOn ne parle pas des mêmes vols dans les deux questions\n\n
  • \n
  • \n
  • je stoppe car j’en ai marre mais cela pourrait etre réutilisé p 121 de l’edition 7\n\n\n
  • \n
  • \n
  • je stoppe car j’en ai marre mais cela pourrait etre réutilisé p 121 de l’edition 7\n\n\n
  • \n
  • \n
  • \n
  • \n
  • Les messages sont numérotés séquentiellement, à partir de un. Si un mes- \nsage est envoyé alors que le traitement du précédent n’est pas terminé, il \nest possible d’utiliser une numération composée (voir figure 5.3) où l’envoi \ndu message 2 intervient pendant l’exécution du message 1. \n\n
  • Les messages sont numérotés séquentiellement, à partir de un. Si un mes- \nsage est envoyé alors que le traitement du précédent n’est pas terminé, il \nest possible d’utiliser une numération composée (voir figure 5.3) où l’envoi \ndu message 2 intervient pendant l’exécution du message 1. \n\n
  • Les messages sont numérotés séquentiellement, à partir de un. Si un mes- \nsage est envoyé alors que le traitement du précédent n’est pas terminé, il \nest possible d’utiliser une numération composée (voir figure 5.3) où l’envoi \ndu message 2 intervient pendant l’exécution du message 1. \n\n
  • Les messages sont numérotés séquentiellement, à partir de un. Si un mes- \nsage est envoyé alors que le traitement du précédent n’est pas terminé, il \nest possible d’utiliser une numération composée (voir figure 5.3) où l’envoi \ndu message 2 intervient pendant l’exécution du message 1. \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • je stoppe car j’en ai marre mais cela pourrait etre réutilisé p 121 de l’edition 7\n\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Les objets sont représentés par des barres verticales au dessus desquelles figure l’objet et sa classe d’appartenance (même formalisme que dans les diagrammes d’objets). Le nom de la classe ou de l’objet peut être omis.\nLes messages entre objets sont représentés par des flêches partant d’un objet et arrivant à un autre objet.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Classe et associations : mieux que les types non primitifs\n\n
  • 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é \n
  • Les objets sont représentés par un rectangle, avec leur nom suivi de : puis le nom de leur classe, le tout souligné. Les objets, instances des classes, sont manipulés dans les «collaboration diagramm»\nLes classes d'objets, ou plus simplement classes, possèdent des attributs et des opérations. Les attributs peuvent avoir un type et une valeur par défaut. Les opérations peuvent avoir des paramètres, typés ou non, et une valeur de retour.\n\nDans un souci de clarté des diagrammes, on peut considérer que telle ou telle information n'est pas importante à ce niveau de l'analyse et donc décider de ne pas la faire apparaître.\nPour la même raison, les zones des attributs et des opérations sont optionnelles.\nUne ellipse à la fin d’une liste d’attributs ou d’opérations signifie qu’il existe d’autres éléments dans le modèle, mais qu’ils dépendent de critères de sélection qui ne les font pas apparaître.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • revoir dans le livre UML2 par la pratique : p95 le découpage en package; réduction du couplage, y compris p101, réduction et couplage\n
  • Trois visibilités sont disponibles pour les attributs et opérations d'une classe (pas sur les relations) :\nPublic : accessible pour tout utilisateur d’une classe, y compris la classe elle-même.\nProtégé : accessible seulement par la classe elle-même, et par ses héritiers.\nPrivé : accessible seulement par la classe elle-même.\nLes visibilités sont fondamentales en phase de conception technique.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • MERISE ET UML: APPROCHE SYSTEMIQUE \n MERISE UML \nLa méthode MERISE s'intéresse aux systèmes ouverts en \nrelation permanente avec leur environnement ( à partir du \nniveau 3. Cf. Cours de systémique ). Trois propriétés \nmajeures sont alors considérées. \n\nGLOBALITE \nContrairement au modèle Cartésien, le comportement d'un \nsystème n'est pas la somme des comportements de ses \nparties \n\nRETROACTION \nLe système réagit à toute stimulation en générant des \nrésultats selon des boucles d'actions-réactions mises en \noeuvre au sein de ses composants. ( feed-back d'ordre 3 ) \n\nFINALITE \nLe système ne peut être stabilisé que si on lui fournit des \nvaleurs acceptables préalablement définies. \n\nL'APPROCHE UML \nL'approche par les CAS D'UTILISATION constitue de fait une \napproche SYSTEMIQUE. Les ACTEURS et les MESSAGES \néchangés sont pris en compte. \n\nCOMMENTAIRES \nLa Maîtrise des concepts de la systémique \n ( ENVIRONNEMENT, ENTREES, SORTIES, OBJECTIFS, \nSTRUCTURE et PROCESSUS ) permet de réaliser une \napproche constructive et consciente des cas d'utilisation. Elle \nfacilite la détermination des CAS D'UTILISATION selon un \ndouble process TOP-DOWN et BOTTOM-UP. L'avantage est \nque le PROCESSUS métier du système est mieux décrit et \nplus compréhensible par les utilisateurs. \n\nFINALITES:Raisons d'être, vocation d'un système. Se déclinent et se formalisent en BUTS. Elles ne sont pas opératoires. ( Cf. FACTEURS ). Par \nexemple: "Recentrer l'activité de l'entreprise sur son métier de base qui est la vente de contrats d'assurances". \n\nBUT:Formalisation des FINALITES. Elles se déclinent en OBJECTIFS qui eux, doivent être opératoires. ( Cf. CRITERES ). Par exemple: "Recentrer \nles résultats de la compagnie sur les primes d'assurances plutôt que sur les marchés financiers" \n\nOBJECTIFS:Concrétisation des BUTS sur la base de critères d'évaluations auxquels sont affectés des niveaux quantifiés à atteindre. ( Cf. \nMETRIQUES ). Par exemple: "Les cotisations d'assurances doivent contribuer à 60% du résultat de la compagnie ". \n\nACTEURS:Classe stérotypée représentant une abstraction faisant partie de l'ENVIRONNEMENT du système étudié. \nOSITEC-Consultants 40/45 18/03/2005\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Les carrés et les cercles ont toutes les propriétés des objets graphiques, cependant une forme graphique est obligatoirement un carré ou un cercle.\nLe mot clef abstract entre accolades indique graphiquement qu’une classe est abstraite.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Le calcul de la surface d’une forme graphique nécessite de connaître sa nature exacte car la formule de calcul va dépendre de cette nature (L2 pour un carré, ΠxR2 pour un cercle). Cependant on sait calculer la surface de toute forme graphique.\nLe mot clef abstract entre accolades indique graphiquement qu’une opération est abstraite.\n
  • \n
  • \n
  • Les intervalles sur les cardinalités exprime le domaine des valeurs admises pour une relation. Il est préférable qu’il soient ordonnés.1..4,7,10 est préférable à 7,1..4,10.\nLa contrainte {or} sur les relations exprime qu’une seule des deux relations sera instanciée sur l’objet Compte en effet un compte est soit celui d’une Societe soit celui d’un particulier.\nLes templates ou classes génériques expriment leurs paramètres formles non bornés à travers un rectangle pointillé situé en haut et à gauche de la classe.\n
  • \n
  • \n
  • \n
  • MERISE ET UML: APPROCHE SYSTEMIQUE \n MERISE UML \nLa méthode MERISE s'intéresse aux systèmes ouverts en \nrelation permanente avec leur environnement ( à partir du \nniveau 3. Cf. Cours de systémique ). Trois propriétés \nmajeures sont alors considérées. \n\nGLOBALITE \nContrairement au modèle Cartésien, le comportement d'un \nsystème n'est pas la somme des comportements de ses \nparties \n\nRETROACTION \nLe système réagit à toute stimulation en générant des \nrésultats selon des boucles d'actions-réactions mises en \noeuvre au sein de ses composants. ( feed-back d'ordre 3 ) \n\nFINALITE \nLe système ne peut être stabilisé que si on lui fournit des \nvaleurs acceptables préalablement définies. \n\nL'APPROCHE UML \nL'approche par les CAS D'UTILISATION constitue de fait une \napproche SYSTEMIQUE. Les ACTEURS et les MESSAGES \néchangés sont pris en compte. \n\nCOMMENTAIRES \nLa Maîtrise des concepts de la systémique \n ( ENVIRONNEMENT, ENTREES, SORTIES, OBJECTIFS, \nSTRUCTURE et PROCESSUS ) permet de réaliser une \napproche constructive et consciente des cas d'utilisation. Elle \nfacilite la détermination des CAS D'UTILISATION selon un \ndouble process TOP-DOWN et BOTTOM-UP. L'avantage est \nque le PROCESSUS métier du système est mieux décrit et \nplus compréhensible par les utilisateurs. \n\nFINALITES:Raisons d'être, vocation d'un système. Se déclinent et se formalisent en BUTS. Elles ne sont pas opératoires. ( Cf. FACTEURS ). Par \nexemple: "Recentrer l'activité de l'entreprise sur son métier de base qui est la vente de contrats d'assurances". \n\nBUT:Formalisation des FINALITES. Elles se déclinent en OBJECTIFS qui eux, doivent être opératoires. ( Cf. CRITERES ). Par exemple: "Recentrer \nles résultats de la compagnie sur les primes d'assurances plutôt que sur les marchés financiers" \n\nOBJECTIFS:Concrétisation des BUTS sur la base de critères d'évaluations auxquels sont affectés des niveaux quantifiés à atteindre. ( Cf. \nMETRIQUES ). Par exemple: "Les cotisations d'assurances doivent contribuer à 60% du résultat de la compagnie ". \n\nACTEURS:Classe stérotypée représentant une abstraction faisant partie de l'ENVIRONNEMENT du système étudié. \nOSITEC-Consultants 40/45 18/03/2005\n
  • \n
  • \n
  • These buttons are different in terms of structure, behavior, or interface\n
  • These buttons are all the same -- they differ only in context, not in structure, behavior, or interface\n
  • These buttons are all the same -- they differ only in context, not in structure, behavior, or interface\n
  • Most often, subclasses are extended and specialized at the same time\n
  • \n
  • Définition du mot BLOB, Binary Large Object, soit un « grand objet binaire », souvent audio ou vidéo, qui peut peser jusqu'à plusieurs Go. Désigne également un objet 3D produit par les altérations structurelles de plusieurs sphères rentrant en contact \n
  • Définition du mot BLOB, Binary Large Object, soit un « grand objet binaire », souvent audio ou vidéo, qui peut peser jusqu'à plusieurs Go. Désigne également un objet 3D produit par les altérations structurelles de plusieurs sphères rentrant en contact \n
  • Définition du mot BLOB, Binary Large Object, soit un « grand objet binaire », souvent audio ou vidéo, qui peut peser jusqu'à plusieurs Go. Désigne également un objet 3D produit par les altérations structurelles de plusieurs sphères rentrant en contact \n
  • Définition du mot BLOB, Binary Large Object, soit un « grand objet binaire », souvent audio ou vidéo, qui peut peser jusqu'à plusieurs Go. Désigne également un objet 3D produit par les altérations structurelles de plusieurs sphères rentrant en contact \n
  • Définition du mot BLOB, Binary Large Object, soit un « grand objet binaire », souvent audio ou vidéo, qui peut peser jusqu'à plusieurs Go. Désigne également un objet 3D produit par les altérations structurelles de plusieurs sphères rentrant en contact \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • http://www4.utc.fr/~nf17/DOCS/modules/01/\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Relationships\nRelationships between entities correspond to foreign key constraints between tables in the physical data model. There are three different types of relationship lines to draw in a logical model: one for parent/child relations (Identifying and Nonidentifying), one for Non-specific relations, and one for Super-sub relations.\nIdentifying\nAn identifying relation indicates that the existence of the child entity is completely dependent on the parent entity. Identifying relations specify that the existence of the parent entity is mandatory for the child entity to exist. A child entity in an identifying relationship does not have to have its own primary key; the primary key of the parent entity is part of the primary key of the child entity.\nExample: the relationship between the entity Employee and the entity Dependent in a company's health plan is identifying. A dependent must "belong" to an employee, because the company does not insure dependents of non-employees. In this example, the primary key of the parent entity Employee is Social Security Number. This also serves as part of the primary key of the entity Dependent.\n
  • Non-Identifying\nA non-identifying relation indicates that the child entity does not rely on the parent entity for its existence. The child entity must, therefore, have its own unique primary key. The parent may be specified as mandatory or optional in a non-identifying relationship.\nIn Telelogic System Architect, the foreign keys that are propagated through a non-identifying relation line in the entity relation model are not primary key attributes in the child entity.\nExample: the relationship between the entity Company and the entity Employee is non-identifying.\nNon-Specific\nThe non-specific relationship line is used during conceptual modeling, when you just want to relate two entities, but don't want to spend time figuring out the exact details of the relationship. \nThis relationship type is not included in any integrity checks, nor can foreign keys be propagated from it. Also, a non-specific relation cannot be converted to an identifying or non-identifying relation. \nExample: you may draw a non-specific relationship between any two entities at the start of your modeling effort, if you do not want to think about the specifics of the relationship between them. \nSuper- and Sub-Relationships\nThe super-sub relationship indicates that one entity may have types. Each sub-entity inherits attributes from Customer, and each has specific attributes of its own.\nExample: you may specify different types of Employees in an organization, for example, a "Union Employee”, a "Non-Union Employee”, and "Management".\nThe super-sub relationship m99y be complete or incomplete. That is, the sub-entities in the model may be all the possible types or just a sample of types. In standard ERD modeling, there is no way to differentiate between a complete and incomplete relationship; in IDEF1X modeling, the line is drawn differently in order to differentiate.\n
  • \n
  • \n
  • Primary Keys from one Entity are replicated as Foreign Keys within another Entity when you select Dictionary, Update FKs. This replication takes place through a One-to-Many or One-to-One Relationship from Parent to Child entity.\nForeign Keys are identified by the FK column within the Attributes grid of an Entity definition. This property is read only; it is toggled on and off automatically whenever foreign keys are updated. If the Relationship is identifying, the Parent identifies child checkbox will be enabled and the Foreign Key will also be a Primary Key.\n\n\n\nDe manière générale il convient de limiter les clefs composées. Chaque fois que l'on aura le choix entre la création d'une clef numérique, et une clef naturelle mais composée, il sera préférable de créer une clef numérique, à de très rares exceptions près.\nEn effet les SGBDR sont plus « à l’aise » lorsqu’ils ont à manipuler des clefs purement numérique. De plus une clef est un concept purement informatique.\nPar exemple le n° de sécurité sociale est une mauvaise clef en générale : un individu étranger qui arrive sur le sol français est doté d’une immatriculation provisoire et ne connaît son numéro définitif que plusieurs mois après avoir rempli les conditions requises par l’administration.\nPar exemple l’immatriculation d’un véhicule est une mauvaise clef : en effet, du fait de la fiscalité sur les véhicules à moteur (et en particulier les vignettes), les sociétés n’hésitent pas à faire immatriculer leur parc de véhicules dans le département où les taxes sont les moins élevées (le 51). Cette immatriculation peut donc être amenée à changer.\nOr toute clef évolutive est un danger pour le système informatique : si la valeur de la clef change, nous verrons qu’il faut la modifier dans tous les fichiers dans laquelle elle est référencée. Il est vrai que certains SGBDR autorise automatiquement ce genre de manœuvre, mais cette automatisation très contraignante pénalise lourdement le fonctionnement du SGBDR.\nOn veillera donc à prendre une clef totalement indépendante des attributs ordinaires de l’entité.\nDe plus une clef a intérêt à être la plus courte possible afin que son stockage soit limité à quelques octets dans les fichiers et donc le temps de recherche le plus rapide possible.\n\nLe plus simple consiste donc à introduire dans le descriptif de l’entité une clef strictement « informatique » qui se résumera en général à un numéro (entier long) que l’on pourra incrémenter automatiquement.\n\nParfois, il arrive qu’une clef ait été créée spécifiquement pour les besoins des systèmes informatiques. C’est en particulier le cas des indicatifs téléphoniques (33 pour la France) ou des code de pays (F pour France). Dans ce dernier cas on devra alors utiliser la clef commune, comme clef de l’entité.\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Personne contient les personnes qui ne sont ni etudiant ni enseignant\n
  • 132 © Éditions Eyrolles \nS’il existe une contrainte de totalité ou de partition sur l’association, il est possible de ne pas \ntraduire la relation issue de la sur-classe. Il faut alors faire migrer tous ses attributs dans la \n(les) relation(s) issue(s) de la (des) sous-classe(s). \n• Dans le cas contraire, il faut faire migrer tous ses attributs dans la ou les relation(s) issue(s) de \nla (des) sous-classe(s) dans la (les) relation(s) issue(s) de la (des) sous-classe(s). \n\n132 © Éditions Eyrolles \nL’exemple 2-33 décrit une contrainte de partition dans l’association d’héritage (aucun personnel \nne peut être à la fois PNT et PNC et il n’existe pas un personnel n’étant ni PNT ni PNC). Les \ndeux relations héritent du contenu intégral de la relation issue de la sur-classe (Personnel). \nLa relation Personnel n’apparaît plus au niveau logique et n’est pas nécessaire, car aucun \n\n
  • 132 © Éditions Eyrolles \nS’il existe une contrainte de totalité ou de partition sur l’association, il est possible de ne pas \ntraduire la relation issue de la sur-classe. Il faut alors faire migrer tous ses attributs dans la \n(les) relation(s) issue(s) de la (des) sous-classe(s). \n• Dans le cas contraire, il faut faire migrer tous ses attributs dans la ou les relation(s) issue(s) de \nla (des) sous-classe(s) dans la (les) relation(s) issue(s) de la (des) sous-classe(s). \n\n132 © Éditions Eyrolles \nL’exemple 2-33 décrit une contrainte de partition dans l’association d’héritage (aucun personnel \nne peut être à la fois PNT et PNC et il n’existe pas un personnel n’étant ni PNT ni PNC). Les \ndeux relations héritent du contenu intégral de la relation issue de la sur-classe (Personnel). \nLa relation Personnel n’apparaît plus au niveau logique et n’est pas nécessaire, car aucun \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • An Access Path (also called an Alternate Key) is a separate storage structure used to enforce uniqueness of data and provide a faster access path to the data – something like a card catalog in a library. You create an Access Path for an entity by specifying the attributes that can be used to locate an individual record that is represented by the entity.\nA Primary Key is in essence an Access Path. By default an access path is created for the Primary Key using the Entity name and the extension _PK. This name can be changed if required, but this access path cannot be deleted.\nYou may also want to create alternate Access Paths, for example, create an access path to look up a book by Author, then Title, then Publishing Date, or create another Access Path to look up a book by Publisher, then Title, then Date.\nWhereas the primary key access path is always unique, the component attributes of other access paths can have duplicates. So you may create Access Paths with the same attributes, but differing orders, for example, Title, then Author, then Date.\nAn Access Path is the equivalent concept to an index in the physical data model.\nA Unique access path represents a Candidate Key. This means that the set of attributes specified for the access path is capable of uniquely identifying an instance of the Entity; therefore, it is capable of being the Primary Key for the Entity. Since only one primary key is permitted for any entity, and there may be many candidate keys, the unique access path provides a means of documenting other alternatives. In the physical model, a unique index may be generated from the unique access path.\n
  • Once the system’s external environment is defined, the analyst must identify key objects and classes and their relationships. \n
  • Used to gain a first-cut object list. Identify the nouns then evaluate them as a potential objects. \n
  • \n
  • \n
  • \n
  • Transactions are finite instances of associations between objects. For example: bus messages and queued data \n
  • \n
  • \n
  • These scenarios map to the use cases that these objects will collaborate to realize\n
  • \n
  • \n
  • Trois visibilités sont disponibles pour les attributs et opérations d'une classe (pas sur les relations) :\nPublic : accessible pour tout utilisateur d’une classe, y compris la classe elle-même.\nProtégé : accessible seulement par la classe elle-même, et par ses héritiers.\nPrivé : accessible seulement par la classe elle-même.\nLes visibilités sont fondamentales en phase de conception technique.\n
  • \n
  • \n
  • \n
  • MERISE ET UML: APPROCHE SYSTEMIQUE \n MERISE UML \nLa méthode MERISE s'intéresse aux systèmes ouverts en \nrelation permanente avec leur environnement ( à partir du \nniveau 3. Cf. Cours de systémique ). Trois propriétés \nmajeures sont alors considérées. \n\nGLOBALITE \nContrairement au modèle Cartésien, le comportement d'un \nsystème n'est pas la somme des comportements de ses \nparties \n\nRETROACTION \nLe système réagit à toute stimulation en générant des \nrésultats selon des boucles d'actions-réactions mises en \noeuvre au sein de ses composants. ( feed-back d'ordre 3 ) \n\nFINALITE \nLe système ne peut être stabilisé que si on lui fournit des \nvaleurs acceptables préalablement définies. \n\nL'APPROCHE UML \nL'approche par les CAS D'UTILISATION constitue de fait une \napproche SYSTEMIQUE. Les ACTEURS et les MESSAGES \néchangés sont pris en compte. \n\nCOMMENTAIRES \nLa Maîtrise des concepts de la systémique \n ( ENVIRONNEMENT, ENTREES, SORTIES, OBJECTIFS, \nSTRUCTURE et PROCESSUS ) permet de réaliser une \napproche constructive et consciente des cas d'utilisation. Elle \nfacilite la détermination des CAS D'UTILISATION selon un \ndouble process TOP-DOWN et BOTTOM-UP. L'avantage est \nque le PROCESSUS métier du système est mieux décrit et \nplus compréhensible par les utilisateurs. \n\nFINALITES:Raisons d'être, vocation d'un système. Se déclinent et se formalisent en BUTS. Elles ne sont pas opératoires. ( Cf. FACTEURS ). Par \nexemple: "Recentrer l'activité de l'entreprise sur son métier de base qui est la vente de contrats d'assurances". \n\nBUT:Formalisation des FINALITES. Elles se déclinent en OBJECTIFS qui eux, doivent être opératoires. ( Cf. CRITERES ). Par exemple: "Recentrer \nles résultats de la compagnie sur les primes d'assurances plutôt que sur les marchés financiers" \n\nOBJECTIFS:Concrétisation des BUTS sur la base de critères d'évaluations auxquels sont affectés des niveaux quantifiés à atteindre. ( Cf. \nMETRIQUES ). Par exemple: "Les cotisations d'assurances doivent contribuer à 60% du résultat de la compagnie ". \n\nACTEURS:Classe stérotypée représentant une abstraction faisant partie de l'ENVIRONNEMENT du système étudié. \nOSITEC-Consultants 40/45 18/03/2005\n
  • \n
  • Most often, subclasses are extended and specialized at the same time\n
  • These buttons are different in terms of structure, behavior, or interface\n
  • These buttons are all the same -- they differ only in context, not in structure, behavior, or interface\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Although signature gets the most attention, it is the easiest to get right – compilers will typically raise errors if the signature is wrong.\nPre- and post conditions are much more difficult to ensure correctness. This is why we lost the Mars Global Surveyor – pre-conditions as to units and ranges weren’t adhered to.\n
  • How the sensor provides its services and it’s internal structure are hidden away behind the interface\n
  • Attributes should generally not be directly accessible from outside the object\n
  • container example: \n"goto right branch & goto left branch"\nvs.\n"get first & get next"\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Les carrés et les cercles ont toutes les propriétés des objets graphiques, cependant une forme graphique est obligatoirement un carré ou un cercle.\nLe mot clef abstract entre accolades indique graphiquement qu’une classe est abstraite.\n
  • Le calcul de la surface d’une forme graphique nécessite de connaître sa nature exacte car la formule de calcul va dépendre de cette nature (L2 pour un carré, ΠxR2 pour un cercle). Cependant on sait calculer la surface de toute forme graphique.\nLe mot clef abstract entre accolades indique graphiquement qu’une opération est abstraite.\n
  • \n
  • Les intervalles sur les cardinalités exprime le domaine des valeurs admises pour une relation. Il est préférable qu’il soient ordonnés.1..4,7,10 est préférable à 7,1..4,10.\nLa contrainte {or} sur les relations exprime qu’une seule des deux relations sera instanciée sur l’objet Compte en effet un compte est soit celui d’une Societe soit celui d’un particulier.\nLes templates ou classes génériques expriment leurs paramètres formles non bornés à travers un rectangle pointillé situé en haut et à gauche de la classe.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • UML définit des stéréotypes de base sur les éléments de modélisation tels que :\n«constructor» ou «destructor» qui permettent de «typer» certaines opérations particulières.\n«utility» pour préciser qu’une classe est une classe utilitaire d’un package.\n«event» pour préciser qu’une classe est de type événement.\n«actor» pour préciser q’une classe est de type acteur.\n«extends» ou «uses» pour préciserle type de relations entre uses-cases\n«friends» ou «instanciates» pour préciser les liens d’utilisation entre classes\n«local», «global», «transient» ... pour qualifier des objets\n...\nLes stéréotypes peuvent être hiérarchiques. La hiérarchie sera celle des classes du méta modèles sur lesquelles, ils se basent.\n
  • \n
  • La notation utilisée pour les notes est un rectangle corné contenant du texte.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • A relay port is also referred to as a delegation port\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • La destruction d’un resultat dans resultat a entraine la destruction du resultat dans resultat.\nOn ne peut pas l’exprimer à l’envers ??\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Indexes\nIndexes specify columns that can be used to locate individual records within a database table. A unique index represents a candidate key, that is, the columns that comprise the index can uniquely identify an individual record. The primary key index is a unique index comprised of the columns in the primary key constraint.\nAn index is the physical equivalent of an access path in the entity relation model.\n\nTriggers\nTriggers enforce the relationship between the parent and child tables. Triggers are used to enforce business rules during database modification. For example, if the business rule is "no order records for active customers can be deleted," a trigger may be used to control the deletion of records from the ORDER table.\nTelelogic System Architect automatically generates update, insert, and delete triggers based on the properties of the relationship or constraint. The names of automatically-generated triggers are prefaced with it_, ut_, and dt_. You may change the name through the Update trigger name, Delete trigger name, and Insert trigger name properties.\nAll triggers are related to specific tables; a trigger cannot be "free-standing" in the database. Depending on the DBMS, triggers may be programmed to fire after, during, or instead of an action.\nUser-defined triggers are added to the project dictionary via the trigger editor. Trigger templates are included with Telelogic System Architect and can be used in whole or part with triggers you write. You can access the templates from within the Explorer.\nConstraint Lines\nA constraint line in the physical data model is the equivalent of an Identifying or Non-Identifying relation line in a logical data model. The non-specific relationship of a logical data model does not exist in a physical data model.\nThe constraint line in the PDM is a visual representation of the foreign key constraints in the database schema that is represented by the diagram. The foreign key constraints control referential integrity in the database, ensuring, for example, that a row in the parent table will not be deleted if there are corresponding rows in the child table.\nIdentifying Constraint Lines: An identifying constraint indicates that an instance of the parent table identifies an instance of the child table; that is, if there is no PARENT table there can be no corresponding CHILD TABLE. The primary keys of the parent table are foreign key components of the child table, pictured on the diagram as [PK] [FK].\nNon-Identifying Constraint Lines: Non-identifying constraints are used when an instance of the parent table does not identify a corresponding instance of the child table. The primary key of the parent table is propagated to the child table as [FK] -- it is a foreign key but not primary key.\n
  • \n
  • Telelogic System Architect supports the process of migration between an Entity Relation Diagram and Physical Data Models. Multiple Physical Data Models can be generated from the same single Logical Model, to support the characteristics of the target RDBMS, hardware and other implementation specific features. Physical data models can be created from a Model Diagram or a Subject Area Diagram.\n
  • \n
  • When designing a database system, it is often advantageous to adhere to the rules of data normalization during the logical design stage. This assures that data redundancy is minimized.\nOnly if you separate the logical and physical design stages, can the logical design be normalized even though the physical data model is denormalized.\n
  • Super/Sub Resolution Method\nIf Super/Sub Relationships have been defined in the Logical Model, the method for handling them in the Physical Model can be specified.\n• Separate Tables – a table is created for each entity in the group. Each super/sub relation line is converted to an identifying one-to-one constraint.\n• Merge Supertype to Subtypes – a table is created for each sub-entity in the group. Each table contains columns representing the attributes in its source sub-entity and in its supertype.\n• Merge Subtypes to Supertype – a table is created for the supertype. It includes columns for each attribute in the source super-entity and each attribute in every sub-entity.\n• Prompt for Each Super/Sub Group – you are prompted for the resolution method for each super/sub group.\n\nResolve Non-Specific Relations: Toggling this choice automatically creates a Table that resolves Many to Many Non-specific relationships on the Logical Model. The Table’s name is provided by the Relation line being resolved and the Column names will be Foreign Keys from the attached Tables.\n\nName Mapping: You may specify how to map the names of entities-to-tables, attributes-to-columns, relationship-lines-to-constraints, and access-paths-to-indexes: either retain the case as they are, mapped to all upper case, or mapped to all lower case.\n\n‘_’ for Special Characters: Specify that special characters (any character that is not a letter, a digit, or an underscore, such as @, #, $, and %) get mapped to an underscore (‘_’).\n
  • Distributed systems are logically one database system, but physically multiple database systems. Separation of logical and physical models allows distributed databases to be effectively modeled and reported on.\nIn Telelogic System Architect, you can create a Project Data Model comprised of multiple subject area ER diagrams, each of which represents a different database in the distributed system. Then you can generate a physical model from each entity relation subject area diagram.\n
  • \n
  • De l'analyse à la conception

    1. 1. Analyse et Conception avec UML De l’analyse à la conception détaillée : esquisses blay@unice.fr www.polytech.unice.fr/~blay IUT Nice-Sophia Antipolis avril 2011Site web du module : http://anubis.polytech.unice.fr/iut/ 1
    2. 2. Quizz 2
    3. 3. QUIZZ03/11 3 /88
    4. 4. QUIZZ i1 ?03/11 3 /88
    5. 5. QUIZZ i1 ?03/11 3 /88
    6. 6. QUIZZ i1 ?03/11 3 /88
    7. 7. QUIZZ Combien d’instance de H sont associées à B? i1 ?03/11 3 /88
    8. 8. QUIZZ Combien d’instances de G et C associées à B ? i1 ?03/11 3 /88
    9. 9. QUIZZ i1 ? agrégation ou composition ?03/11 3 /88
    10. 10. QUIZZ i1 ?03/11 3 /88
    11. 11. QUIZZ Combien d’instance de H sont associées à E? i1 ?03/11 3 /88
    12. 12. QUIZZ i1 ?03/11 3 /88
    13. 13. QUIZZ03/11 4 /88
    14. 14. QUIZZ03/11 5 /88
    15. 15. De Analyse à la conceptionPattern exemplaireStructuration en packageStructuration en package et réutilisationChoix des itérationsDiag. de séquence en conceptionArchitectureDes diag. de séquences aux Diag. de classesDiagrammes de classes en conception
    16. 16. Pattern du type- exemplaire 7
    17. 17. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Exemple de problème - Existe-t-il des vols Nice-Paris le lundi matin? - Réserver le vol Nice-Paris du lundi 28/2/11 à 8h - Les vols Nice-Tunisie sont annulés pour les 15 prochains jours... Comment les recréer ?04/11 8 /115
    18. 18. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Des rôles mieux définis04/11 9 /115
    19. 19. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Des rôles mieux définis ea qu e ri d né e gé iod ol ér .... v p n e U un lid ité va04/11 10/115
    20. 20. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Des rôles mieux définis Métaclasse ou Type Classe ou Exemplaire04/11 11/115
    21. 21. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Autre exemple Un livre et des exemplaires : La bibliothèque nous a donné la définition suivante. Nous gérons des livres. Un livre est caractérisé par une date de parution, un numéro ISBN, un titre. Certains livres sont en mauvais état. Un adhérent peut emprunter un livre. Pour certains livres nous en avons plusieurs exemplaires.04/11 12/115
    22. 22. Structuration en packages 13
    23. 23. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages Cohérence et Indépendance - Finalité : des services de - Minimiser les dépendances même nature - Eviter absolument les - Evolution : Stabilité (le dépendances mutuelles métier)/Evolutive (Applicative) - Cycle de vie des objets04/11 14/115
    24. 24. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages04/11 15/115
    25. 25. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages04/11 16/115
    26. 26. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages04/11 17/115
    27. 27. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages04/11 18/115
    28. 28. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages04/11 19/115
    29. 29. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages04/11 20/115
    30. 30. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages Un vol est ouvert ou fermé à la réservation par la compagnie aérienne04/11 21/115
    31. 31. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages Un vol est ouvert ou fermé à la réservation par la compagnie aérienne04/11 21/115
    32. 32. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages Un vol est ouvert ou fermé à la réservation par la compagnie aérienne04/11 21/115
    33. 33. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages04/11 22/115
    34. 34. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Structuration en packages04/11 23/115
    35. 35. Structuration en packages et réutilisation 24
    36. 36. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Spécialisation La société qui prend en charge les réservations de vols, veut prendre en charge des réservations de train.04/11 25/115
    37. 37. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Spécialisation La société qui prend en charge les réservations de vols, veut prendre en charge des réservations de train.04/11 26/115
    38. 38. Vers la conception :choix des itérations 27
    39. 39. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Choix des itérations On a04/11 28/115
    40. 40. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Choix des itérations Itération 4 Itération 3’ Itération 2’ Itération 1 Itération 204/11 Itération 3 29/115
    41. 41. Des diagrammes de séquence en conception 30
    42. 42. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Vers l’architecture Pas d’interaction directe du client! Les “interfaces avec les acteurs” sont «réifiées».04/11 31/115
    43. 43. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. ObjetFrontière Vers l’architecture04/11 32/115
    44. 44. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Scenario : Identification des interfaces utilisateur Vue IHM Description Sélection d’une équipe dans une liste triée des équipes du laboratoire ou Sélection Equipe par des critères de recherche..... Visualisation Visualisation d’une équipe par ses membres, ... d’une équipe04/11 33/115
    45. 45. Si c’est nécessaire...Après...• avec l’addon Firefox :• http://pencil.evolus.vn/en-US/Downloads/Application.aspx 34
    46. 46. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Enrichissement Classes Paramètres soumettre(Cours) Valider(Cours) Les “paramètres” sont caractérisés. Des classes de contrôles apparaissent.04/11 35/115
    47. 47. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Enrichissement Entité soumettre(Cours) Des données sont identifiées comme persistantes.04/11 36/115
    48. 48. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Scénario : raffinement Quelles sont les informations pertinentes ?04/11 37/115
    49. 49. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Scénario : précisions Beaucoup de paramètres04/11 38/115
    50. 50. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Scénario : précisions rechercher(Information) Des “classes” de mise en oeuvre apparaissent04/11 39/115
    51. 51. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Scenario et réification Des “classes” d’implémentation sont identifiées.04/11 40/115
    52. 52. Vers la conception : Architecture Système 41
    53. 53. Diagramme de Use-cases
    54. 54. Afficher Informations : niveau Analyse
    55. 55. Gérer Informations : niveau Analyse (0)
    56. 56. Diagramme de Use-cases Itération 1 Itération 1I
    57. 57. Choix d’Architecture PrésentationLogique applicative Gérer les informations CREATE TABLE `information` ( Stockage `titre` varchar(20) NOT NULL, `date` varchar(22) NOT NULL, `identifiant` int(11) NOT NULL auto_increment, PRIMARY KEY (`identifiant`))
    58. 58. Choix d’Architecture PrésentationLogique applicative Gérer les informations CREATE TABLE `information` ( Stockage `titre` varchar(20) NOT NULL, `date` varchar(22) NOT NULL, `identifiant` int(11) NOT NULL auto_increment, PRIMARY KEY (`identifiant`))
    59. 59. Choix d’Architecture PrésentationLogique applicative Gérer les informations CREATE TABLE `information` ( Stockage `titre` varchar(20) NOT NULL, `date` varchar(22) NOT NULL, `identifiant` int(11) NOT NULL auto_increment, PRIMARY KEY (`identifiant`))
    60. 60. Choix d’Architecture PrésentationLogique applicative Gérer les informations CREATE TABLE `information` ( Stockage `titre` varchar(20) NOT NULL, `date` varchar(22) NOT NULL, `identifiant` int(11) NOT NULL auto_increment, PRIMARY KEY (`identifiant`))
    61. 61. Choix d’Architecture clickOn() Présentation IHM créer Information ContrôleurLogique applicative Gérer les informations : métier CREATE TABLE `information` ( Stockage `titre` varchar(20) NOT NULL, `date` varchar(22) NOT NULL, `identifiant` int(11) NOT NULL auto_increment, PRIMARY KEY (`identifiant`))
    62. 62. Architectureen couches & Fichiers
    63. 63. modifier Information : niveau Conception
    64. 64. Afficher Informations : niveau Conception index_SI_View.php
    65. 65. Afficher Informations : niveau Conception index_SI_View.php class SI_Controller { public function index($args) { $view = new Index_SI_View(); $view->display(); } SI_Controller.php public function display($args) { header(Content-type: text/xml); $res=<?xml version="1.0"?><data>; $infos = Information::findAll(); foreach($infos as $tmpInformation) { $res = $res.$tmpInformation->toXML() ; } $res=$res.</data>;
    66. 66. Afficher Informations : niveau Conceptionclass Index_SI_View extends Main_Global_View { public function mainContent() { ob_start();?> index_SI_View.php <div id="main"> Information goes here! </div><?php $content = ob_get_contents(); class SI_Controller { public function index($args) { $view = new Index_SI_View(); $view->display(); } SI_Controller.php public function display($args) { header(Content-type: text/xml); $res=<?xml version="1.0"?><data>; $infos = Information::findAll(); foreach($infos as $tmpInformation) { $res = $res.$tmpInformation->toXML() ; } $res=$res.</data>;
    67. 67. Afficher Informations : niveau Conception class Information implements iCRUDclass Index_SI_View extends Main_Global_View { { public function mainContent() { private $_id; ob_start(); private $_titre;?> index_SI_View.php private $_date; <div id="main"> Information.php public static function findAll() { Information goes here! $informations = array(); </div> Database::connect();<?php $query = "SELECT * FROM information"; $content = ob_get_contents(); $res = mysql_query($query); while($line = mysql_fetch_assoc($res)){ $titre = $line["titre"]; $date = $line["date"]; $key = $line["identifiant"]; $info = new Information($titre,$date,$key); array_push($informations, $info); } Database::disconnect(); return $informations; class SI_Controller { public function index($args) { $view = new Index_SI_View(); $view->display(); } SI_Controller.php public function display($args) { header(Content-type: text/xml); $res=<?xml version="1.0"?><data>; $infos = Information::findAll(); foreach($infos as $tmpInformation) { $res = $res.$tmpInformation->toXML() ; } $res=$res.</data>;
    68. 68. Créer Information : niveau Conception
    69. 69. Créer Information : niveau Conceptionclass Index_Admin_View extends Main_Global_View { admin_View private $infosListe; public function Index_Admin_View($args) { $this->infosListe = $args[infosListe]; }...<h1>Gestion des Informations</h1> <h2> Liste des informations </h2> <form id="infoModifForm" name="infoModifForm" method="post" action="./"> <p>
    70. 70. Créer Information : niveau Conception class Admin_Controller { public function index($args) { $args[infosListe] = Information::findAll(); $view = new Index_Admin_View($args); $view->display(); } Admin_Controller.php public function confirmer_modifier($args) { $key = $_POST["key"]; $newTitre = $_POST["NouveauTitre"]; $info = Information::read($key); $info->setTitre($newTitre); $info->update(); $args[infosListe] = Information::findAll(); $view = new Index_Admin_View($args); $view->display(); } public function create($args) { $titre = $_POST["Titre"]; $info = new Information($titre, $this->today()); $info->create(); $args[infosListe] = Information::findAll(); $view = new Index_Admin_View($args); $view->display(); }
    71. 71. Des diagrammes de séquence et d’activitésaux diagrammes de classes 53
    72. 72. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Des diagrammes de séquence aux classes Classe Relations? Classe Classe04/11 54/115
    73. 73. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opération  Le comportement d’une classe est constitué de ses opérations  On identifie les opérations en examinant les diagrammes d’interactions04/11 55/115
    74. 74. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Classes : corps de méthode04/11 56/115
    75. 75. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Relations On identifie les relations en examinant les diagrammes d’interaction  Si deux objets doivent communiquer, il doit exister un chemin entre eux04/11 57/115
    76. 76. Compléments sur les classes :vers la mise en oeuvre 58
    77. 77. Vers la mise en oeuvre des classes Visibilité Abstraction Attributs et Opérations* de Classes Généralisation Packages Transformations des associations Anti-PatternsOpération : terme générique désignant le plus souvent des méthodes
    78. 78. Vers la mise en oeuvre des classes Visibilité Abstraction Attributs et Opérations* de Classes Généralisation Packages Transformations des associations Anti-PatternsOpération : terme générique désignant le plus souvent des méthodes
    79. 79. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Visibilité  Différentes visibilités des membres dune classe public = + usager Interface protégé = # héritier privé = - implémenteur corps04/11 61/115
    80. 80. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Visibilité Représentation Classe +a1 : T1 -a2 : T2 #m1 (p1,p2,p3) +m2 (p1,p2,p3) Pas de sens en analyse...04/11 62/115
    81. 81. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Encapsulation : accessibilité des attributs et des opérations Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 63/115
    82. 82. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Encapsulation : accessibilité des attributs et des opérations Peut-on accéder à tous les attributs ou à toutes les méthodes d’un objet ? Non La classe définit ce qui est accessible C’est le principe de l’encapsulation Un objet complexe ne peut être utilisé qu’au travers de ce qui est accessible Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 63/115
    83. 83. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Encapsulation : accessibilité des attributs et des opérations Peut-on accéder à tous les attributs ou à toutes les méthodes d’un objet ? Non La classe définit ce qui est accessible C’est le principe de l’encapsulation Un objet complexe ne peut être utilisé qu’au travers de ce qui est accessible Principes : Il n’est possible d’utiliser une voiture qu’à travers son volant, son frein, son accélérateur, etc. L’accès au carburateur est impossible sauf par les méthodes qui le font de manière cohérente (méthode accélérer de l’accélérateur) Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 63/115
    84. 84. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes..Encapsulation avec le concept de Visibilité Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 64/115
    85. 85. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes..Encapsulation avec le concept de Visibilité Les attributs sont en général inaccessibles (secrets). Ils sont alors qualifiés de : « private » : notation UML « − » Lecture ou modification possible au travers des opérations (p.ex. les accesseurs : setAdresse(), getAdresse()) Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 64/115
    86. 86. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes..Encapsulation avec le concept de Visibilité Les attributs sont en général inaccessibles (secrets). Ils sont alors qualifiés de : « private » : notation UML « − » Lecture ou modification possible au travers des opérations (p.ex. les accesseurs : setAdresse(), getAdresse()) Les opérations sont en général accessibles par toutes les classes. Elles sont alors qualifiées de : « public » : notation UML « + » Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 64/115
    87. 87. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Encapsulation avec le concept de Visibilité Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 65/115
    88. 88. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Encapsulation avec le concept de Visibilité Certains attributs/Opérations doivent être accessibles par les sous-classes ou aux classes d’un même package et inaccessibles aux autres classes. Ils sont alors qualifiés de : « protected » : notation UML « # » Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 65/115
    89. 89. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Encapsulation avec le concept de Visibilité Certains attributs/Opérations doivent être accessibles par les sous-classes ou aux classes d’un même package et inaccessibles aux autres classes. Ils sont alors qualifiés de : « protected » : notation UML « # » Certaines opérations peuvent cependant être privées (factorisation interne de traitements) et certains attributs peuvent être publics (non souhaitable / principe d’encapsulation) Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 65/115
    90. 90. Vers la mise en oeuvre des classes Visibilité Abstraction Attributs et Opérations* de Classes Généralisation Packages Transformations des associations Anti-PatternsOpération : terme générique désignant le plus souvent des méthodes
    91. 91. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Classes et Opérations abstraites Une opération/Classe abstraite apparaît en italique.04/11 67/115
    92. 92. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Classes et Opérations abstraites Une classe abstraite est une classe non instanciable, cest à dire quelle nadmet pas dinstances directes. Une classe abstraite est une description dobjets destinée à être « héritée » par des classes plus spécialisées. Pour être utile, une classe abstraite doit admettre des classes descendantes concrètes. La factorisation optimale des propriétés communes à plusieurs classes par généralisation nécessite le plus souvent lutilisation de classes abstraites.04/11 /115
    93. 93. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Représentation de classes abstraites  Classes sans instances immédiates Forme Carre Cercle Une instance de «Forme» est obligatoirement une instance de la classe Carre ou de la classe Cercle04/11 69/115
    94. 94. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Représentation de classes abstraites04/11 70/115
    95. 95. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Classes et Opérations abstraites04/11 71/115
    96. 96. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Représentation de classes abstraites Attention des choix de mises en oeuvre non explicités au niveau du modèle apparaissent dans ce code.04/11 72/115
    97. 97. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations abstraites Une opération abstraite est une opération nadmettant pas dimplémentation : au niveau de la classe dans laquelle est déclarée, on ne peut pas dire comment la réaliser. Les opérations abstraites sont particulièrement utiles pour mettre en œuvre le polymorphisme. Toute classe concrète sous-classe dune classe abstraite doit “concrétiser” toutes les opérations abstraites de cette dernière.04/11 /115
    98. 98. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Classes abstraites classe FormeGéométrique abstraite centre : Point opération abstraite classe abstraite dessiner() (dessiner() est déplacer(delta : Vecteur) héritée et non classe concrète concrétisée) Polygone Ellipse régulier : Boolean grandDiam : Vecteur petitDiam : Vecteur Polygone opération utile que si dessiner() concrétisée spécialisée04/11 /115
    99. 99. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations abstraites Attention des choix de mises en oeuvre non explicités au niveau du modèle apparaissent dans ce code.04/11 75/115
    100. 100. Vers la mise en oeuvre des classes Visibilité Abstraction Attributs et Opérations* de Classes Généralisation Packages Transformations des associations Anti-PatternsOpération : terme générique désignant le plus souvent des méthodes
    101. 101. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Attributs et opérations de classe Le nombre total de participations est une caractéristique des personnes (classe), donc applicable à Julien Dupont (objet) L’opération getNbTotalParticipations() utilise la valeur de l’attribut nbTotalParticipations connue par la classe Cette opération peut être appliquée directement à la classe Personne et aussi aux objets / instances de Personne Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 77/115
    102. 102. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Attributs et opérations de classe04/11 78/115
    103. 103. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations du niveau de la classe : Static Une opération «de niveau classe» est soulignée.04/11 79/115
    104. 104. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations du niveau de la classe : Static04/11 80/115
    105. 105. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations du niveau de la classe : Static Dans la classe Produit04/11 81/115
    106. 106. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations du niveau de la classe : Static Dans la classe Produit04/11 82/115
    107. 107. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations du niveau de la classe : Static Dans la classe Produit04/11 83/115
    108. 108. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations du niveau de la classe : Static Dans la classe Produit04/11 84/115
    109. 109. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations du niveau de la classe : Static Dans la classe Produit04/11 85/115
    110. 110. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations du niveau de la classe : Utilisation04/11 86/115
    111. 111. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Opérations du niveau de la classe : Static 1. Obtenir la liste des clients 2. Modifier la date d’une réservation 3. Créer une réservation 4. Modifier le prénom d’une personne 5. Calculer le prix d’une réservation04/11 87/115
    112. 112. Vers la mise en oeuvre des classes Visibilité Abstraction Attributs et Opérations* de Classes Généralisation Packages Transformations des associations Anti-PatternsOpération : terme générique désignant le plus souvent des méthodes
    113. 113. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Généralisation04/11 89/115
    114. 114. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Mauvaise généralisation Attention à la généralisation multiple: Quel execute 2 copies de est exécuté ? l’Attribut id. This is also known as the Diamond of Death. (IBM)04/11 90/115
    115. 115. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Pattern Composite...04/11 91/115
    116. 116. Vers la mise en oeuvre des classes Visibilité Abstraction Attributs et Opérations* de Classes Généralisation Packages Transformations des associations Anti-PatternsOpération : terme générique désignant le plus souvent des méthodes
    117. 117. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Package04/11 93/115
    118. 118. Vers la mise en oeuvre des classes Visibilité Abstraction Attributs et Opérations* de Classes Généralisation Packages Transformations des associations Anti-PatternsOpération : terme générique désignant le plus souvent des méthodes
    119. 119. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Association...04/11 95/115
    120. 120. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Association...04/11 96/115
    121. 121. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Association: De la conception à l’implémentation04/11 97/115
    122. 122. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Gestion des associations04/11 98/115 D’UML à java Ph. Collet -- Miage
    123. 123. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Associations & Navigations04/11 99/115 D’UML à java Ph. Collet -- Miage
    124. 124. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Exemple de Raffinement04/11 100 /115 D’UML à java Ph. Collet -- Miage
    125. 125. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation04/11 101 /115 D’UML à java Ph. Collet -- Miage
    126. 126. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation Extrémité d’association 104/11 101 /115 D’UML à java Ph. Collet -- Miage
    127. 127. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation Extrémité d’association 1 Rôle en Attribut avec type de l’extrémité04/11 101 /115 D’UML à java Ph. Collet -- Miage
    128. 128. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation Extrémité d’association 1 Rôle en Attribut avec type de l’extrémité Type getRole()04/11 101 /115 D’UML à java Ph. Collet -- Miage
    129. 129. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation Extrémité d’association 1 Rôle en Attribut avec type de l’extrémité Type getRole() Extrémité d’association *04/11 101 /115 D’UML à java Ph. Collet -- Miage
    130. 130. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation Extrémité d’association 1 Rôle en Attribut avec type de l’extrémité Type getRole() Extrémité d’association * Rôle (pluriel) en collection04/11 101 /115 D’UML à java Ph. Collet -- Miage
    131. 131. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation Extrémité d’association 1 Rôle en Attribut avec type de l’extrémité Type getRole() Extrémité d’association * Rôle (pluriel) en collection Type de l’extrémité en élément de collection04/11 101 /115 D’UML à java Ph. Collet -- Miage
    132. 132. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation Extrémité d’association 1 Rôle en Attribut avec type de l’extrémité Type getRole() Extrémité d’association * Rôle (pluriel) en collection Type de l’extrémité en élément de collection Collection getRoles()04/11 101 /115 D’UML à java Ph. Collet -- Miage
    133. 133. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation Extrémité d’association 1 Rôle en Attribut avec type de l’extrémité Type getRole() Extrémité d’association * Rôle (pluriel) en collection Type de l’extrémité en élément de collection Collection getRoles() // Collection<TypeExtrémité>//04/11 101 /115 D’UML à java Ph. Collet -- Miage
    134. 134. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation ( Suite)04/11 102 /115 D’UML à java Ph. Collet -- Miage
    135. 135. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation ( Suite) Fixer une extrémité d’association 104/11 102 /115 D’UML à java Ph. Collet -- Miage
    136. 136. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation ( Suite) Fixer une extrémité d’association 1 void setRole(Type t)04/11 102 /115 D’UML à java Ph. Collet -- Miage
    137. 137. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation ( Suite) Fixer une extrémité d’association 1 void setRole(Type t) Fixer une extrémité d’association *04/11 102 /115 D’UML à java Ph. Collet -- Miage
    138. 138. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation ( Suite) Fixer une extrémité d’association 1 void setRole(Type t) Fixer une extrémité d’association * void setRoles(Collection c)04/11 102 /115 D’UML à java Ph. Collet -- Miage
    139. 139. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation ( Suite) Fixer une extrémité d’association 1 void setRole(Type t) Fixer une extrémité d’association * void setRoles(Collection c) void addRole(TypeElement t)04/11 102 /115 D’UML à java Ph. Collet -- Miage
    140. 140. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation ( Suite) Fixer une extrémité d’association 1 void setRole(Type t) Fixer une extrémité d’association * void setRoles(Collection c) void addRole(TypeElement t) Fixer une association navigable dans les 2 sens :04/11 102 /115 D’UML à java Ph. Collet -- Miage
    141. 141. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Principes d’implémentation ( Suite) Fixer une extrémité d’association 1 void setRole(Type t) Fixer une extrémité d’association * void setRoles(Collection c) void addRole(TypeElement t) Fixer une association navigable dans les 2 sens : Définir les responsabilités : un des objets est responsable de la connexion/déconnexion (cf. exemple)04/11 102 /115 D’UML à java Ph. Collet -- Miage
    142. 142. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. ImplémentationClass Student { Collection getClasses() { return classes;//Collection<Course> } Définition des protected List classes=new ArrayList… responsabilités} Ne jamais appelerClass Course { addHasSections ou Collection getHasSections(); addClass directement ! protected List addSection = new… protected addHasSections(Section s){ hasSections.add(s); }04/11 103 /115 D’UML à java Ph. Collet -- Miage
    143. 143. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Implémentation Prise de responsabilités04/11 104 /115 D’UML à java Ph. Collet -- Miage
    144. 144. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Implémentationclass Student { Result getResult(Section s) }class Section { Result getResult(Student s) }class Result { Student getStudent() Section getSection()}04/11 105 /115 D’UML à java Ph. Collet -- Miage
    145. 145. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. En résumé : Traduction des associations en attributs04/11 Introduction 106/115 au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris
    146. 146. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. En résumé : Traduction des associations en attributs Autant d’attributs que de classes auxquelles elle est reliée (navigable)04/11 Introduction 106/115 au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris
    147. 147. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. En résumé : Traduction des associations en attributs Autant d’attributs que de classes auxquelles elle est reliée (navigable) Association unidirectionnelle = pas d’attribut du côté de la flèche04/11 Introduction 106/115 au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris
    148. 148. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. En résumé : Traduction des associations en attributs Autant d’attributs que de classes auxquelles elle est reliée (navigable) Association unidirectionnelle = pas d’attribut du côté de la flèche Nom de l’attribut = nom du rôle ou forme nominale du nom de l’association04/11 Introduction 106/115 au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris
    149. 149. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. En résumé : Traduction des associations en attributs Autant d’attributs que de classes auxquelles elle est reliée (navigable) Association unidirectionnelle = pas d’attribut du côté de la flèche Nom de l’attribut = nom du rôle ou forme nominale du nom de l’association Attribut du type référence sur un objet de la classe à l’autre extrémité de l’association Référence notée « @ »04/11 Introduction 106/115 au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris
    150. 150. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. En résumé : Traduction des associations en attributs Autant d’attributs que de classes auxquelles elle est reliée (navigable) Association unidirectionnelle = pas d’attribut du côté de la flèche Nom de l’attribut = nom du rôle ou forme nominale du nom de l’association Attribut du type référence sur un objet de la classe à l’autre extrémité de l’association Référence notée « @ » Traduction des multiplicités 1 =⇒ @Classe ∗ =⇒ Collection @Classe 0..N =⇒ Tableau[N] Classe04/11 Introduction 106/115 au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris
    151. 151. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. En résumé : Traduction des associations en attributs Autant d’attributs que de classes auxquelles elle est reliée (navigable) Association unidirectionnelle = pas d’attribut du côté de la flèche Nom de l’attribut = nom du rôle ou forme nominale du nom de l’association Attribut du type référence sur un objet de la classe à l’autre extrémité de l’association Référence notée « @ » Traduction des multiplicités 1 =⇒ @Classe ∗ =⇒ Collection @Classe 0..N =⇒ Tableau[N] Classe Multiplicité avec tri = Collection ordonnée @Classe04/11 Introduction 106/115 au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris
    152. 152. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Compositions Introduction au langage de modélisation UML, Denis Conan, Chantal Taconet, Christian Bac, Telecom Sud Paris04/11 107 /115
    153. 153. Vers la mise en oeuvre des classes Visibilité Abstraction Attributs et Opérations* de Classes Généralisation Packages Transformations des associations Anti-PatternsOpération : terme générique désignant le plus souvent des méthodes
    154. 154. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Anti-Patterns Blob ou la classe Dieu04/11 109 /115
    155. 155. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Anti-Patterns Blob ou la classe Dieu04/11 109 /115
    156. 156. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Anti-Patterns Blob ou la classe Dieu04/11 109 /115
    157. 157. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Anti-Patterns Blob ou la classe Dieu04/11 109 /115
    158. 158. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Anti-Patterns Blob ou la classe Dieu04/11 109 /115
    159. 159. Pattern ex. Packages Itérations Séquences Archi. De seq . Classes.. Anti-Patterns A Améliorer encore...04/11 110 /115
    160. 160. D’un modèle à classes au modèle relationnel 111

    ×