Notes de cours GETI 2351 Séminaire d’informatique

Présentation au sujet: "Notes de cours GETI 2351 Séminaire d’informatique"— Transcription de la présentation:

1 Notes de cours GETI 2351 Séminaire d’informatique
Jean Vanderdonckt

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

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

12 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

13 Éléments de modélisation structurelle

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

15 Modélisation structurelle: Relations

16 Modélisation structurelle: Relations (suite)

17 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

18 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

19 Classes Fig. 3-17, UML Notation Guide

20 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

21 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...

22 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)

23 Interfaces Fig. 3-24, UML Notation Guide

24 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é

25 Associations

26 Associations

27 Associations ternaires
Fig. 3-31, UML Notation Guide

28 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

29 Composition Fig. 3-36, UML Notation Guide

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

31 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

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

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

34 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

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

36 Objets Fig. 3-29, UML Notation Guide

37 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

38 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

39 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

40 Éléments des Use Cases

41 Use case : Relations <<extend>>

42 Use Case : relations <<include>>

43 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

44 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>>

45 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

46 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

47 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

48 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

49 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.

50 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

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

52 Presentation title Friday, March 31, 2017 Ressources Web "CHI'98 Workshop "From Task to Dialogue: Task-Based User Interface Design" Web page, April paderborn.de/fachbereich/AG/szwillus/chi98ws/ "Experimental Object Technologies - xjCharts." Web page, "For Use - Constantine & Lockwood, Ltd. home page for practitioners of usage-centered design." Web page, "Incorporating Work, Process and Task Analysis Into Commercial and Industrial Object-Oriented Systems Development." Web page, "Use Cases Still Dangerous : Editorial : uidesign.net." Web page, Conference acronym