Modélisation orientée objet UML Le Langage de Modélisation objet Unifié

Les modèles UML Un modèle est une abstraction de la réalité. Un modèle est une vue subjective mais pertinente de la réalité. Un modèle caractérise : Un niveau métier du domaine d’application : connexion avec le vocabulaire du domaine. Différentes vues du modèle objet final.

Vues de modélisation Fonctionnel 3 axes de modélisation Statique Diagramme de Use Cases (Diagramme d’activités) (Diagramme de séquence) 3 axes de modélisation Statique Dynamique Diagramme d’états (Diagramme d’activités) (Diagramme de séquence) Diagramme de communication. Diagramme de Classes (Diagramme d’objets) Diagramme de composants (diagramme de déploiement

Cas d'utilisation (use cases) Les fonctions du systèmes sont représentées au travers des cas d’utilisation. Interaction entre le système et l’extérieur. Définissent les limites du système et les relations entre le système est l’environnement. Décrivent le comportement du système du point de vue d’un utilisateur, les acteurs. La structuration de la démarche s’effectue par rapport aux interactions d’une seule catégorie d’utilisateurs à la fois.

Principes et définitions de base Diagramme de communication, flux d’événements, ou de données entre des entités externes et le système à concevoir. Les use cases permettent de structurer les besoins des utilisateurs et les objectifs correspondants d'un système. Ils permettent de classer les acteurs et structurer les objectifs du système.

Les acteurs Rôle joué par une entité externe en interaction avec le système étudié. Identification: Utilisateurs humains directs. Les autres systèmes connexes. Représentation : <<actor>> SI banque Client

Cas d’utilisation Use Case : Identification : Ensemble de séquences, d’actions réalisées par le système et qui produisent un résultat intéressant pour un acteur particulier. Identification : Fonction métier du système selon le point de vue d’un de ses acteurs. Chercher le service fonctionnel du système en réponse à une action. Recenser les interactions entre les acteurs du système.

<<actor>> Cas d’utilisation Représentation : <<actor>> Acteur non Humain Cas d’utilisation 1 Acteur humain 1 Cas d’utilisation 2 Acteur humain 2

Exercice : Le GAB Services offerts par le GAB : Distribution d’argent à tout porteur de carte de crédit, va un lecteur de carte et distributeur de billets. Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients porteurs d’une carte de crédit de la banque. Toutes les transactions sont sécurisées. Il faut parfois recharger le distributeur!

Exercice : Le GAB Identifier les acteurs ; Identifier les cas d’utilisations ; Construire le diagramme des cas d’utilisations.

Correction <<actor>> Sys Auto <<actor>> Secondaire Secondaire <<actor>> SI Banque

Affinement des cas d’utilisation Détailler et organiser les cas d’utilisation : En ajoutant des relations d’inclusion et/ou d’extension. En regroupant en « packages » pour définir des blocs fonctionnel de plus haut niveau.

Relation d’inclusion

Relation d’extension

Structuration des cas d’utilisation en packages Plusieurs stratégies possibles : Regroupement par acteur; Regroupement par domaine fonctionnel…

<<actor>> Sys Auto Opérations non client Service support <<actor>> Sys Auto S’authentifier <<actor>> SI Banque Opérations client Maintenance

Acteur primaire (principal) ou secondaire Tous les acteurs n’utilisent pas forcément le système. Acteur principal : celui pour qui le cas d’utilisation produit un résultat observable. Acteur secondaire : participe au cas d’utilisation, sollicité pour des informations complémentaires. Informe ou consulte le système lors de l’exécution du cas d’utilisation.

Exercice : modélisation d’un magasin Le client entre dans le magasin, passe dans les rayons, demande éventuellement des renseignements ou procède à des essais, prend des articles (ou les réserve si le stock est insuffisant), passe à la caisse ou il règle ses achats. Il peut bénéficier d’une réduction ou d’un avoir. Il peut régler en liquide, par chèque (pour un montant supérieur à 15 euros, ou par carte pour un montant supérieur à 13 euros). Aucune référence n’est attribué au client, même si des renseignements sont conservés en cas de réclamation. Une livraison est possible pour les achats encombrants.

Diagramme de séquence Montrent des interactions entre objets selon un point de vue temporel. Pas de présentation explicite du contexte des objets. Dans la vue fonctionnelle sert à documenter les cas d’utilisation. Description des interactions entre objets sans détails de synchronisation.

indication de sonnerie Diagramme de séquence Représentation : Ligne téléphonique appelant appelant décroche tonalité numérotation indication de sonnerie sonnerie décroche Les Flèches correspondent à des évènements dans le domaine d’application Pas de distinction entre flots de données et flots de contrôle.

Diagramme de séquence… …en application Réalisez un diagramme de séquence qui décrit le scénario du cas d’utilisation « Retirer de l’argent ».

Diagramme d’activités UML permet de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d’utilisation, à l'aide de diagrammes d'activités. Une activité représente une exécution d'un mécanisme, un déroulement d'étapes séquentielles. Le passage d'une activité vers une autre est matérialisé par une transition. Les transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat d'une autre (elles sont automatiques).

Diagramme d’activités Représentation : transition Activité 1 Activité 2 Demander addition garde [Prix < somme disponible] [else] Régler note Faire vaisselle

Diagramme d’activités Synchronisation Synchronise des transitions : « barre de synchronisation » Ouvre et de ferme des branches parallèles au sein d'un flot d'exécution. Les transitions qui partent d'une barre ont lieu en même temps. Franchissement d’une barre après réalisation de toutes les transitions.

Diagramme d’activités Synchronisation : Appuyer touche ctrl Appuyer touche v Coller texte

Diagramme d’activités… …en action Réalisez un diagramme d’activités qui décrit le cas d’utilisation « retirer de l’argent avec une carte ».

Diagramme d’états transitions Visualise des automates déterministes. On ne représente pas les automates des objets qui ne changent pas (ou peu) d’état. Un objet est à tout moment dans un état donné. Un objet passe d’un état à un autre par les transitions. Les transitions sont déclenchées par un évènement.

Diagramme d’états transitions Représentation :

Etude d’une caisse enregistreuse Un système simplifié de caisse enregistreuse de supermarché : Un client arrive à la caisse avec des articles à payer Le caissier enregistre le numéro d’identification de chaque article, ainsi que la quantité si elle est supérieure à un. La caisse affiche le prix de chaque article et son libellé. Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente. La caisse affiche le total des achats. Le client choisit son mode de paiement : Liquide : le caissier encaisse l’argent reçu, la caisse indique la monnaie à rendre au client. Chèque : le caissier vérifie la solvabilité du client en transmettant une requête à un centre d’autorisation via la caisse. Carte de crédit : un terminal bancaire fait partie de la caisse. Il transmet une demande d’autorisation en fonction du type de carte. La caisse enregistre la vente et imprime le ticket Le caissier donne le ticket de caisse au client. Après saisie article le client peut présenter des coupons de réduction. Lorsque le paiement est termine, la caisse transmet les informations sur le nombre d’articles vendus au système de gestion des stocks. Tous les matins, le responsable du magasin initialise les caisses pour la journée.

Etude d’une caisse enregistreuse Identifiez les acteurs et les cas d’utilisation. Elaborez un diagramme des cas d’utilisation. Réalisez un diagramme de séquence décrivant le scénario du cas d’utilisation « Traiter passage en caisse ». Montrez par un diagramme d’états la succession des opérations pour le cas d’utilisation « Traiter passage en caisse ».

Correction <<actor>> Centre autorisation chèques Centre autorisation cartes

Quelques conseils… Identification des acteurs : Utilisateurs humains directs (admin, opérateur…); Les systèmes connexes interagissant avec le système étudié. Acteurs « logiques » au profit des acteurs physiques: L’acteur est celui qui bénéficie de l’utilisation su système. Permet de s’affranchir des technologies d’interfaces. Utilisez le plus souvent possibles les relations d’inclusions et d’extensions.

Quelques conseils… Les relations entre cas d’utilisation : Inclusion : évite de devoir décrire plusieurs fois le même enchaînement; Extension : Permet de séparer un comportement complexe optionnel ou rare du comportement obligatoire; Généralisation / Spécialisation : formalise des variations importantes sur le même cas d’utilisation. Complétez la description des cas d’utilisation par un ou plusieurs diagramme «dynamique » d’UML. Pour la dynamique des cas d’utilisation => diagramme d’activités. Ou un diagramme d’états pour les cas d’utilisation très interactifs. Pour décrire le scénario nominal, utilisez un diagramme de séquence.