Notes de cours GETI 2351 Séminaire d’informatique Jean Vanderdonckt vanderdonckt@isys.ucl.ac.be http://www.isys.ucl.ac.be/bchi/members/jva

Plan Présentation d’UML UML et le design du logiciel interactif Modèles et architectures typiques Aspect statiques : modèles de classes et Design Patterns Aspects dynamiques : programmation par événements et StateCharts UML et le design de l’interaction Use Cases Processus de conception centré sur l’utilisateur

Historique d’UML Fin des années 80 : compétition des méthodes d’analyse et de conception OO Booch : particulièrement adaptée au design et à l’implémentation OOSE (Jacobson) : expression des besoins OMT-2 (Rumbaugh) : analyse et applications orientées-données 1994 : Rumbaugh rejoint Booch chez Rational 1995 : Jacobson rejoint Rational 14 novembre 1997 : UML adopté par l’OMG

Qu’est-ce qu’UML ? « UML est un langage pour visualiser, spécifier, concevoir et documenter les artefacts d’un système à base logicielle » Langage : lexique (graphique), syntaxe (diagrammes), sémantique Visualiser : représentation graphique Spécification : précis, complet, non-ambigu Construction : translation vers des langages de programmation Documentation : des besoins aux tests

Le Langage langage = syntaxe + sémantique syntaxe = Règles par lesquelles les éléments du lexique (e.g., mots) sont assemblées en expressions (e.g., phrases, clauses) sémantique = Règles par lesquelles on donne un sens aux expressions syntaxiques UML Notation Guide – définit la syntaxe graphique d'UML UML Semantics – définit la sémantique d'UML

Les briques de base de l’UML Des choses… Structurelles Classe, Interfaces, Collaborations, Use Cases… Comportementales Messages et machines à états Des relations Dépendances, Associations, Généralisation, Réalisation Des diagrammes

Concepts unificateurs dichotomie classifieur-instance e.g., un objet est l’instance d’une classe OU une classe est le classifieur d’un objet dichotomie spécification-réalisation e.g., une interface est une spécification d'une classe OU une classe est une réalisation d’une interface

Les diagrammes de l’UML Diagramme de Classe Diagramme d’Objets Diagramme Use Case Diagrammes d’interactions Diagramme de Séquence Diagramme de Collaboration StateCharts Diagramme d’Activité Diagrammes de Composants Diagramme de Déploiement isomorphes

UML par lui-même © Chuck Suscheck 2000, communication personnelle Presentation title Friday, March 31, 2017 UML par lui-même © Chuck Suscheck 2000, communication personnelle Conference acronym

Fonction des diagrammes Diagrammes prescriptifs : décrivent le système tel qu’il doit être ou se comporter à tout moment Classe, StateCharts, Use Cases, Activités, Composants, Déploiement Diagrammes descriptifs : illustrent un état ou un comportement possible et typique du système Objet, Séquence, Collaboration

Modèles structurels Qu'est-ce qu'un modèle structurel ? Concepts Diagrammes structurels Quand produire des modèles structurels Trucs et astuces

Modèle structurel Une vue d'un système qui met l'accent sur la structure des objets, avec leurs classificateurs, leurs relations, leurs attributs et leurs opérations

Éléments de modélisation structurelle

Éléments de modélisation structurelle (suite) ¹ Mécanisme d’extension.

Modélisation structurelle: Relations

Modélisation structurelle: Relations (suite)

Diagrammes structurels Montrent la structure statique d'un modèle Les entités qui existent (e.g., classes, interfaces, composants, nœuds) Leur structure interne Leurs relations avec d'autres entités Ne montrent pas Des informations temporelles ou dynamiques Catégories Diagrammes structurels statiques diagramme de classe diagramme d'instances Diagrammes d'implémentation diagrammes de composants diagrammes de déploiement

Définition d'une classe Description d'un ensemble d'objets qui ont même structure et même sémantique Nom Attributs Opérations Responsabilités Exprimées en langage naturel

Classes Fig. 3-17, UML Notation Guide

Opérations (méthodes) Implémentation d'un service offert par l'objet, correspondant à une partie de ses responsabilités Accesseurs : une opération qui renvoie une information sur l'état de l'objet (fonction) Modifieur : une opération qui modifie l' état de l'objet (procédure) Constructeur : une opération de la classe qui permet d'initialiser une nouvelle instance

Utilisation des attributs Utilisation plus limitée que dans une modélisation de type entité-association La définition d'un attribut contraint l'implémentation future de la classe Préférer des accesseurs / modifieurs A réserver à des types primitifs (entier, réel) ou des « structures de données » simples (string, date) Ne pas utiliser de structures de type tableau, liste, … Sauf exception...

Visibilité des attributs / Méthodes Public (+) Visible et utilisable par toute autre classe (utilisation très limitée) Protected (#) Visible et utilisable par toute spécialisation de la classe Private (-) Visible uniquement par la classe elle-même Sinon ? On utilisera la sémantique de java (package)

Interfaces Fig. 3-24, UML Notation Guide

Associations Expriment une relation permanente entre instances de 2 ou plusieurs classes Nom de l'association Sens de lecture Cardinalités et rôles Visibilité des rôles Navigabilité

Associations

Associations

Associations ternaires Fig. 3-31, UML Notation Guide

Relation de composition Relation « du tout à la partie » Plus forte que l'association : implique une relation de cycle de vie entre les instances (la création/destruction du tout entraîne celle de ses parties) Navigabilité souvent asymétrique : les parties ne connaissent pas le tout

Composition Fig. 3-36, UML Notation Guide

Agrégation / Composition Fig. 3-32, UML Notation Guide

Généralisation Relation de spécialisation (est-un, is-a-kind-of) entre classes La classe spécialisée (sous-classe) hérite des méthodes et des attributs de la classe-générale (super-classe) Elle peut ajouter des attributs / méthodes Elle peut redéfinir le comportement des méthodes (mais pas les attributs !) Principe de substituabilité de Liskov

Généralisation Fig. 3-38, UML Notation Guide

Spécialisation multiple Fig. 3-39, UML Notation Guide

Dépendance Une relation transitoire entre classes, qui n'est pas représentable par association ou composition Un objet sert à créer des objets d'une autre classe (factory object) Un objet utilise un autre sans qu'il fasse partie de ses attributs Il peut recevoir un objet en tant que paramètre ou valeur de retour d'une méthode

Dépendances Fig. 3-41, UML Notation Guide

Objets Fig. 3-29, UML Notation Guide

Diagramme d’objets : Point coordX : 100 coordY : 200 P1: Polygone estVisible : true : Point coordX : 150 coordY : 250 : Point coordX : 300 coordY : 300 G: AttibutGraphique couleurTrait : ROUGE Epaisseur : 2 Remplissage : VERT : Point coordX : 90 coordY : 30

Use Cases Les Use Cases permettent d’analyser les besoins, en décrivant comment le système doit être utilisé et dans quel but. Forte similarités avec les techniques d’analyse de la tâche. Support UML pour les Use Cases : Nouvelle Commande

Définition des Use Cases Presentation title Friday, March 31, 2017 Définition des Use Cases Jacobson, 1992 « … une façon spécifique d’utiliser le système en utilisant une partie de sa fonctionnalité. [Un use case] constitue une séquence complète d’interaction qui a lieu entre un acteur et le système » Rumbaugh et al, 1999: 488 « …la spécification de séquences d’actions, pouvant inclure des variantes ou des séquences d’erreur, qu’un système, sous-système ou classe peuvent exécuter en interagissant avec des acteurs extérieurs » Fowler, 1997: 43 « … une interaction typique entre un utilisateur et un système informatique … [qui] capture une fonction d’intérêt pour l’utilisateur … [et qui] permet d’atteindre un but discret pour l’utilisateur » Conference acronym

Éléments des Use Cases

Use case : Relations <<extend>>

Use Case : relations <<include>>

Diagrammes de Use Cases Permettent d’organiser les Use Cases qui décrivent un système de manière structurée Use Cases Acteurs (plutôt rôle !) Relations : dépendance, généralisation, association

Exemple de diagramme Titulaire stagiaire Operateur System Boundary Box Commande Express Valider Utilisateur Vérification mot de passe Nouvelle Commande identification rétinienne Gérer les commandes 1 <<extends>> <<includes>>

Presentation title Friday, March 31, 2017 Narration « continue » A cash withdrawal transaction is started from within a session when the customer chooses cash withdrawal from the menu of possible transaction types. The customer chooses a type of account to withdraw from (e.g., checking) from a menu of possible accounts, and then chooses a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request. If not, it reports a failure to the session, which initiates the Failed Transaction Extension to report the problem. If there is sufficient cash, it sends the customer's card number, PIN, chosen account and amount to the bank, which either approves or disapproves the transaction. If the transaction is approved, the machine dispenses the correct amount of cash and issues a receipt. If the transaction is disapproved due to an incorrect PIN, the Incorrect PIN extension is executed. All other disapprovals are reported to the session, which initiates the Failed Transaction Extension. The bank is notified whether or not an approved transaction was completed in its entirety by the machine; if it is completed then the bank completes debiting the customer's account for the amount. [Bjork, 1998] The problems with this style of narrative are numerous. There is no clear separation between the user side of the interchange and the system side. The narrative intermixes internal and external requirements and jumps erratically between external and internal perspectives. Elements that are essential to the nature of the problem (e.g., “the machine dispenses the correct amount of cash”) are co-mingled with implicit decisions about the design of the user interface (e.g., “customer… chooses a dollar amount from a menu of possible amounts”). The lack of structure forces the reader to trace through the entire text just to get an idea of the general nature of what is happening. Portions of the narrative that are important for the design of the user interface are buried among descriptions that are irrelevant. Conference acronym

Séquence Numérotée Withdraw Money Presentation title Friday, March 31, 2017 Séquence Numérotée Withdraw Money 1. The use case begins when the Client inserts an ATM card. The system reads and validates the information on the card. 2. System prompts for PIN. The Client enters PIN. The system validates the PIN. 3. System asks which operation the client wishes to perform. Client selects “Cash withdrawal.” 4. System requests amounts [sic]. Client enters amount. 5. System requests type. Client selects account type (checking, savings, credit). 6. The system communicates with the ATM network to validate account ID,PIN, and availability of the amount requested. 7. The system asks the client whether he or she wants a receipt. This step is performed only if there is paper left to print the receipt. 8. System asks the client to withdraw the card. Client withdraws card. (This is a security measure to ensure that Clients do not leave their cards in the machine.) 9. System dispenses the requested amount of cash. 10. System prints receipt. Conference acronym

Narration Partitionnée Action utilisateur Réponse du système insert card in ATM read card request PIN enter PIN verify PIN display option menu select option display account menu select account prompt for amount enter amount display amount confirm amount return card take card dispense cash if available

Autres techniques Pseudo-Code Diagrammes d’interaction until customer_done repeat if valid_user_code then do…end_do else do…end_do end_if Diagrammes d’interaction

Pré et Post-Conditions Place Order Preconditions: A valid user has logged into the system. Flow of events: Basic Path 1. The use case starts when the customer selects Place Order 2. The customer enters his or her name and address. 3. If the customer enters only the zip code, the system will supply city and state. 4. The customer will enter product codes for the desired product. 5. The system will supply a product description and price for each item. 6. The system will keep a running total of items ordered as they are entered. 7. The customer will enter credit card information. 8. The customer will select Submit. 9. The system will verify the information, save the order as pending, and forward payment information to the accounting system. 10. When payment is confirmed, the order is marked Confirmed, an order ID is returned to the customer, and the use case ends. Alternative paths In step 9, if any information is incorrect, the system will prompt the customer to correct the information. Postcondition: The order has been saved and marked confirmed.

Presentation title Friday, March 31, 2017 Références Rumbaugh, J., Jacobson, I., and Booch, E. (1999) The Unified Modeling Language Reference Manual. Reading, MA: Addison-Wesley. Jacobson, I., Christerson, M., Jonsson, P., and Övergaard, G. (1992) Object-Oriented Software Engineering: A Use Case Driven Approach. Reading, MA: Addison-Wesley. Fowler, M. (1997) UML Distilled: Applying the Standard Object Modeling Language. Reading, MA: Addison-Wesley. Constantine, L. L., & Lockwood, L. A. D. (1999) Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Boston: Addison-Wesley. Conference acronym

Source R. Bastide, Introduction à UML, Tutoriel n°11, Conférence IHM-HCI’2001

Presentation title Friday, March 31, 2017 Ressources Web "CHI'98 Workshop "From Task to Dialogue: Task-Based User Interface Design" Web page, April 1998. http://www.uni- paderborn.de/fachbereich/AG/szwillus/chi98ws/ "Experimental Object Technologies - xjCharts." Web page, http://xjtek.com/products/xjcharts/ "For Use - Constantine & Lockwood, Ltd. home page for practitioners of usage-centered design." Web page, http://www.foruse.com/default.htm "Incorporating Work, Process and Task Analysis Into Commercial and Industrial Object-Oriented Systems Development." Web page, 1998. http://www.primaryview.org/CHI98/BulletinFinal.html "Use Cases Still Dangerous : Editorial : uidesign.net." Web page, http://www.uidesign.net/1999/imho/oct_imho.html. Conference acronym