Unified Modeling Language UML
Transcription
Unified Modeling Language UML
Unified Modeling Language UML Introduction What is UML and what is it for? UML is a language for – – – – Visualizing Specifying Constructing Documenting Syntax, Semantics (verification) Graphics Architecture and behavior Allow code generation Textual and graphical descriptions the artifacts of a software-intensive system From now on, slides from B. Selic [3] 2 Charles André - UNSA UML: Evolution 3 Charles André - UNSA UML 2 Language Architecture A core language + a set of optional “language units” Some language units have multiple increments 4 Multiple levels of compliance Charles André - UNSA UML 2: Run-Time Semantics Much more than a notation 5 Charles André - UNSA How things happen in UML In UML, all behavior results from the actions of (active) objects Object behavior (e.g., statechart) Inter-object behavior (interaction) 6 Charles André - UNSA UML approach: Single Model Views are projections of a complete model Continuous integration of views with dynamic detection of inconsistencies 7 Charles André - UNSA UML 2 Diagram Types The different diagram types of UML represent different views of a given system typically based on different viewpoints or representations UML Diagram Structure Diagram 8 Behavior Diagram Instance Diagram Class Diagram Activity Diagram Statechart Diagram Deployment Diagram Package Diagram Interaction Diagram UseCase Diagram Collaboration Diagram Composite Structure Timing Diagram Interaction Overview Sequence Diagram Communication Diagram Charles André - UNSA Object-Orientation Overview The (application) world is composed of objects These objects are linked together Static relationships (links) These objects react to stimuli (messages) Either internal or external Originating from other objects or from outside the system These objects have an internal state Internal data (attributes) and status of the links with other The state may change when the objects are stimulated 9 Charles André - UNSA What is an object? Object = Identity + State + Behavior Objects should be distinguishable The identity is independent of the state Operations, events, messages… Public interface Internal data values Status of links with other objects Objects have “crisp” conceptual boundaries (Booch, 1994) 10 Charles André - UNSA What is an object? Static information: architectural aspects – List of operations (interface) • The messages the object can accept and react to – State values • Possible values of internal data (attributes) • Possible links with other objects, that are message transport media Dynamic behavior: control aspect – State evolution and messages sent to other objects • Triggered by message flows 11 Charles André - UNSA What is in a Class? A group of objects sharing common properties – common structure: • same attributes • same possible relations with other objects – common behavior: same operations An abstract data type A model to instantiate objects – A class defines the possible behaviors and the information structure of all its instances 12 Charles André - UNSA Model Elements “Thing” Abstractions, first-class citizen in the model Relation Tie "things" together Diagram Group interesting collections of things and express (some of) their relationships ModelElement 13 Charles André - UNSA Model Elements: Summary Class “Thing” ModelElement Relation Diagram 14 Structural Active Class Interface Collaboration Use Case Interaction Component Node Behavioral State Machine Package Organizational Note Annotational Dependency Association Generalization Realization Class Object Use Case Sequence Collaboration State-Transition Activity Component Deployment Charles André - UNSA UML: Diagrammes de Classes Transparents inspirés de [4] Diagrammes de classes • Les diagrammes de classes représentent un ensemble de classes, d'interfaces et de collaborations, ainsi que leurs relations. Ce sont les diagrammes les plus fréquents dans la modélisation des systèmes à objets. Ils présentent la vue de conception statique d'un système. Les diagrammes de classes, (qui comprennent aussi les classes actives), présentent la vue de processus statique d'un système. 16 Charles André - UNSA Les classes • Caractéristiques des • La classe est une description abstraite d’un ensemble d’objets classes • La classe peut être vue comme la – Attributs factorisation des éléments communs – Opérations à un ensemble d’objets – Réceptions • La classe décrit le domaine de – Relations définition d’un ensemble d’objets – Multiplicité • Description conceptuellement séparée en deux parties – Persistance – La spécification d’une classe qui décrit – Composant le domaine de définition et les propriétés des instances de cette classe (type de donnée) – La réalisation qui décrit comment la spécification est réalisée 17 Charles André - UNSA Eléments graphiques nom de la classe nom de la classe - variable privée + variable publique # variable protégée attributs nom_attr : type = valeur initiale opérations nom_op (arg_list):type - opération privée + opération publique # opération protégée parametre classe parametrable nom de l’association une classe une autre classe nom de la classe association attributs operations / association dérivée rôle 1 nom de l’association une classe rôle 2 une autre classe Remarque: Commencer le nom d’une classe par une majuscule 18 Charles André - UNSA Visibilité des attributs et opérations • Public + Visible à l’extérieur de la classe • Protected # Visible seulement par les descendants • Private Visible à l’intérieur des méthodes • Package ~ • Souligné attribut/opération de classe (statique) 19 Charles André - UNSA Relations • • • • • 20 L’association L’agrégation La composition La généralisation La dépendance • L’association exprime une connexion sémantique bidirectionnelle entre classes • Une association est une abstraction des liens qui existent entre les objets instances des classes associées Charles André - UNSA Exemple 21 Charles André - UNSA Nommage des associations • Indication du sens de lecture 22 Charles André - UNSA Nommage des rôles •Le rôle décrit une extrémité d’une association 23 Charles André - UNSA Multiplicité des rôles 1 0..1 M .. N * 0 .. * 1 .. * 24 Un et un seul Zéro ou un De M à N (entiers naturels) Plusieurs De zéro à plusieurs D'un à plusieurs Charles André - UNSA Visibilité des rôles • Public • Protégé • Private 25 Charles André - UNSA Navigabilité • étant donnée une association non décorée entre deux classes, on peut naviguer d'un type d'objet vers un autre type d'objet. • par défaut une association est navigable dans les deux sens. • une indication de navigabilité suggère en général qu'à partir d'un objet à une extrémité on peut directement et facilement atteindre l'un des objets à l'autre extrémité. • lors d'une mise en œuvre programmée, ceci peut suggérer par exemple qu'un objet source mémorise une référence directe aux objets cible. 26 • étant donné un utilisateur, on désire pouvoir accéder à ses mots de passe • étant donné un mot de passe, on ne souhaite pas pouvoir accéder à l'utilisateur correspondant Charles André - UNSA Exemple 27 Charles André - UNSA L’agrégation • Connexions sémantiques bidirectionnelles antisymétriques • Forme d’association qui exprime un couplage plus fort entre classes • Représentation des relations – maître et esclaves – tout et parties – composé et composant. 28 Charles André - UNSA La composition • Modélisation de la composition physique – Multiplicité au max de 1 du coté de l’agrégat – Propagation automatique de la destruction Compagnie Le tout 1 * Département 29 La partie Charles André - UNSA Hiérarchie de classes • Gérer la complexité – Arborescences de classes d’abstraction croissante Super-classe Classe plus générale Sous-classe Classe plus spécialisée 30 Charles André - UNSA Autres concepts présents dans les diagrammes de classes Dépendances • Relation très générale (peut être utilisée entre n’importe quel NamedElement). • Entre classes: la classe B dépend de la classe A. Si A change, B peut changer; mais pas l’inverse. Remarque: Les dépendances sont souvent stéréotypées 32 Charles André - UNSA Retour sur les attributs (1) • Les attributs peuvent – Inlined attributes – Attributes by relationship • Il n’y a pas de différence sémantique entre les deux • Remarque: Avec les relations on peut introduire plus d’information (e.g., composition) 33 Charles André - UNSA Retour sur les attributs (2) • Notation générale des inlined attributes visibility / name : type multiplicity = default { property strings and constraints } visibility ::= + | - | # | ~ multiplicity ::= [ lower .. upper ] / indique que l’attribut est dérivé. Sa valeur peut être calculée à partir des autres attributs de la classe. 34 Charles André - UNSA Retour sur les attributs (3) • Attribute multiplicity: quand plus qu’un, on peut préciser en plus { ordered, unique } Défaut: unique, non ordonné • Attribute properties: – readOnly – union – subsets attribute-name – redefines attribute-name 35 Charles André - UNSA Contraintes • Les contraintes représentent des restrictions imposées sur un élément. • Exprimées en langage naturel ou en langage formel (e.g., OCL) • Notation: la contrainte est placée entre { } après l’éléments contraint ou dans une note. 36 Charles André - UNSA Retour sur les opérations • Notation visibility name ( parameters ) : return-type { properties and constraints } visibility ::= + | - | # | ~ parameter ::= direction param-name type multiplicity = default-value { properties } direction ::= in | out | inout | return multiplicity ::= [ lower .. upper ] • Operation constraints – – – – 37 preconditions state before invocation postconditions state after execution body conditions constraints on the returned value query does not modify the state of the class Charles André - UNSA Objet • Un objet est une instance de classe. • Chaque instance peut avoir un nom ou bien être anonyme. Le nom (s’il est donné) est suivi de : et son type (souvent une classe). Une classe Une instance de la classe Car Remarque: commencer le nom d’une instance par une minuscule 38 Charles André - UNSA Classe abstraite • Une classe abstrait est utile pour identifier des fonctionnalités communes à plusieurs types d’objets. • Notation: Le nom d’une classes abstraite est écrit en italique. • Une classe abstraite ne peut pas être instanciée. Elle doit être sous-classée (spécialisée). Les sous-classes concrètes peuvent être instanciées. 39 Charles André - UNSA Les classes-associations (1) •Ajout d’attributs ou d’opérations dans la relation employé Personne société 0..2 * Société Emploi salaire augmenter() Le nom de la classe correspond au nom de l’association (problème: il faut choisir entre forme nominale et forme verbale) Attention: 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) 40 Charles André - UNSA Classes-associations (2) employé Personne sociétés Société 0..2 * Emploi e1 p1 salaire s1 Ci-dessus, une personne peut avoir deux emplois, mais pas dans la même société e1 p1 s1 e2 employé Personne 1 0..2 Emploi salaire * société 1 Société Ci-dessus, une personne peut avoir deux emplois dans la même société 41 Charles André - UNSA Associations qualifiées • Une association qualifiée met en relation deux classes sur la base d'une clef. • La technique associée de mise en œuvre est souvent un tableau associatif ou un dictionnaire. 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 * 42 Fichier Charles André - UNSA Interfaces (1) • Une interface est un classeur (classifier) qui des déclarations de propriétés et d’opérations mais pas d’implémentations. • On peut utiliser des interfaces pour grouper des éléments communs à plusieurs classeurs et fournir un contrat qu’un classeur qui implémente l’interface doit respecter. • Assez proche du concept d’interface en Java. 43 Charles André - UNSA Interfaces (2) Class that uses the interface Other notation: ball (provided interface) And socket (required interface) Class that implements the interface 44 Charles André - UNSA Templates • UML permet d’utiliser des abstractions pour les types de classes avec lesquels une classes peut interagir. Templated class Implicit template binding Explicit template binding 45 Charles André - UNSA Classifier • A classifier is a classification of instances, it describes a set of instances that have features (structural and/or behavioral) in common. • Kinds of Classifiers: Class, Actor, Component, DataType, Interface, Node, Signal, Subsystem, UseCase,… • Classes are the most general kind of classifiers. Other can be intuitively understood as similar to classes, with certain restrictions on content or usage. (Excerpts from [B2]) • Note that Classifier is an abstract metaclass 46 Charles André - UNSA Data types • A data type is a type whose instances are identified only by their value. A DataType may contain attributes to support the modeling of structured data types. Danger: A metamodel, not a user’s model • All copies of an instance of a data type and any instances of that data type with the same value are considered to be the same instance. Value ≠ Object 47 Charles André - UNSA Enumeration • A data type whose instances form a list of named literal values. • An enumeration is a user-definable data type. 48 Charles André - UNSA Bibliographie • [1] UML superstructure v 2.1.1, Feb. 2007 (http://www.omg.org/cgi-bin/doc?formal/07-02-05) • [2] UML infrastructure v 2.1.1, Feb. 2007 (http://www.omg.org/cgi-bin/doc?formal/07-02-06) • [3] Bran Selic. UML2 and SysML: Modeling Language Stndards for System Design. IBM, 2007 • [4] Jean Bézivin. Ingénierie des modèles logiciels. Cours #1. Nantes 2003. • [5] Jean-Marie Favre. UML Diagrammes de Classes – Concepts avancés. Cours. 49 http://www-adele.imag.fr/~jmfavre Charles André - UNSA Books • [B1] The Unified Modeling Language User Guide Grady Booch, James Rumbaugh, Ivar Jacobson Addison Wesley, 1999. • [B2] The Unified Modeling Language Reference Guide James Rumbaugh, Grady Booch, Ivar Jacobson Addison Wesley, 1999 • [B3] Real-Time UML Douglass B.P., Addison-Wesley, 1998. • [B4] Doing Hard Time Douglass B.P., Addison-Wesley, 1999. • [B5] Real-Time Design Patterns Douglass B.P., “Addison-Wesley, 2003. 50 Charles André - UNSA Books (continued) 51 Charles André - UNSA