UML

• un Langage pour la modélisation
  • Désambiguïser l ’analyse et la conception
  • formaliser les décisions stratégiques et tactiques
  • Outiller la compréhension du système
• Une méthode : Objectory de Ivar Jacobson

Pourquoi une Méthode

• Réduire les risques :
  • délais
  • coûts
  • faisabilité
  • Marketability, adéquation
• Assurer la qualité

Les Points forts

• Stratégie de réduction des risques au plutôt
• Compréhension du projet
  • Bonne définition de ce qu’il faut faire.
• Itérations
  • Des objectifs clairs à chaque étape
  • une mesure de l ’avancement

Vue synthétique

Planification & élaboration

• Planning, ressources, budget, etc.
• Rapport d’opportunité: motivation, alternatives, marché.
• Spécification des exigences (déclaratives)
• Glossaire, Prototypes
• Cas d’utilisation + diagrammes
• Brouillon de Modèle conceptuel

Objectifs de l ’Elaboration

• A. Construire le modèle des exigences du système : Définir la cible
• B. Définir les cas d ’utilisation et planifier la suite d ’itération qui vas permettre de les implanter : atteindre la cible

ME: Quatre éléments

• Les fonctions & les qualités
  • ce que fait le système
• Les acteurs
  • identifie ceci qui est extérieur au système
• Les Cas d’utilisation
  • description des interactions avec le système
• Le glossaire
  • une base pour la description du système

Modéliser les exigences

• Capturer l’ensemble des exigences
  • avec un point de vue utilisateur
  • en minimisant les oublis
• Synthétiser l’essentiel
  • pour organiser le développement
  • pour permettre la réutilisation
  • pour mesurer et réduire le risque

Un exemple de cas

• Un point de vente informatisé,
• les activités: enregistrer les achats et gérer les payements.
• Le système est composé d ’éléments matériels et logiciels.
• Supposons que nous avons été sollicités pour réaliser le logiciel de ce système (LexiCaisse).

Les Acteurs

• Un acteur est une entité externe au système qui participe d’une certaine façon à un des Cas d’utilisation (Use case).
• Un acteur est représenté par son Rôle pour le système : Client, Caissier, OS, etc.
• Fait des accès en lecture ou écriture

Les Cas d’utilisation

• Un cas d’utilisation est un document narratif qui décrit la séquences d’événement qui permet à un acteur de compléter un processus en utilisant le système.

Use Case: Acheter des Articles

• Use Case: Acheter des Articles
• Acteurs: Client, Caissier
• Type: Primaire (A discuter)
• Description: Un client arrive à la caisse avec des Articles à acheter. Le caissier enregistre les Articles et prend le paiement. Le client peut en suite partir avec les Articles.

Le Glossaire

• Le glossaire est un outil utilisé tout au long du développement. Il contient l’ensemble des termes utilisés pour les descriptions des modèles utilisés au cours de la construction du système.
• Les termes du glossaire devient en général la base des objets métiers important du système en cours de développement.

Le glossaire permet de réduire l’ambiguïté dans la communication entre les différents intervenant dans le cycle de développement.

• Le glossaire permet de réduire l’ambiguïté dans la communication entre les différents intervenant dans le cycle de développement.
• Le glossaire est construit au cours des différents phases de projet. C’est surtout dans la phase de modélisation des exigences qu’il est le plus utile car il permet de travailler avec les termes du client ou de l’expert métier, qui sont ainsi expliqués pour tous.
• La création du glossaire est une tâche coopérative.

Le glossaire LexiCaisse

• Article : ce qui est en vente dans le magasin
  • prix, Taux TVA, identifiant etc.
• caisse : poste de travail du caissier, composé d ’un ordinateur, un tiroir, un lecteur de code barre, etc.
• reçu : ticket indiquant date,heure, et chaque article, ainsi que la somme total, etc.

Les fonctions du système

Exemple de cas

Qualités du système

• Facile d ’utilisation
• Robuste
• Portable
• Coût
• Temps de réponse
• Interface intuitive
• Scalable

Exemple de cas

Les cas d’utilisation de l’élaboration

• Dans la phase d’élaboration les cas d’utilisation sont rapidement esquissés, mais tous les cas d’utilisation doivent être décrits.
• Il est possible si le système le demande de détailler les cas d’utilisation principaux.
• Plus de détails => plus d’informations
• Compromis : Meilleure compréhension, gestion des risques, estimation. Mais une plus grande complexité et plus de travail inutile en cas de changement.

Une approche itérative de la construction

• Raffiner la planification de l’itération
• analyse
• conception
• implantation
• test

Une itération

• L’ensemble des opérations sont réalisées dans la fenêtre de pilotage.
• Une itération doit se terminer avec un logiciel
• évaluable.
• Pour avoir une itération bonne taille elle doit être définie par l’équipe de développement qui doit la contrainte temporelle.

Cas d’utilisation et Itérations

• Les itérations sont définies sur des cas d’utilisation.
• Les exigences d’un cas d’utilisation sont l’objectif d’une itération.
• Les cas d’utilisation principaux sont réalisé dans les première itérations.
• Certains besoins non évident doivent être placés dans les première itérations, des services de support, persistance, sécurité, etc.

Les 4 productions de l ’Elaboration

• Les Fonctions
• Les Acteurs
• Les Cas d ’Utilisation
• Le glossaire

Les autres Productions

• Diagrammes de Collaboration
• Diagrammes de séquences
• Diagramme de Use Case

Les Cas d’Utilisation

• Identifier et écrire les cas d ’utilisation
• dessiner les diagrammes de cas d ’utilisation
• Haut-Niveau vs détaillé (étendus)
• Essentiels vs réels

Haut Niveau

• Use Case: Acheter des Articles
• Acteurs: Client, Caissier
• Type: Primaire (A discuter)
• Description: Un client arrive à la caisse avec des articles à acheter. Le caissier enregistre les articles et prend le paiement. Le client peut en suite partir avec les articles.

Diagramme de UC (1)

Motivations

• Conserver dans un cas d ’utilisation Haut niveau simple et compréhensible
• Préparer la répartition des cas d ’utilisation sur les itérations
• Conserver le concept « Bout en Bout »

Etendu

• Use Case: Acheter des articles avec du liquide
• Acteur: Client(initiateur),caissier
• Objectif: enregistrer une vente avec son paiement en liquide.
• Résumé: Un client arrive à la caisse avec des articles à acheter. Le caissier enregistre les articles et prend le paiement. Le client peut en suite partir avec les articles.

Type: Primaire et essentiel

• Type: Primaire et essentiel
• Références: Fonctions 1.1, 1.2, 1.3, …
• Suite d’événements:
• (le Style conversationnel : comme une conversation entre les acteurs et le système)

Le format étendu

• Use Case: nom Acteur: initiateur et tous les acteurs
• Objectif:
• Résumé: Récupération du UC de haut niveau
• Références:

Les Acteurs

• Un acteur est une entité externe au système qui participe d’une certaine façon a un des Cas d’utilisation.
• Des accès en lecture ou écriture avec le système.
• Un acteur est représenté par son Rôle pour le système : Client, Caissier, OS, etc.

Un UC doit être complet

• Une erreur commune est de définir un cas d ’utilisation pour une étape, une opération, ou une transaction.

Trouver les UC

• A partir des acteurs
  • Identifier les acteurs
  • pour chaque acteurs identifier les UC qu ’ils initient ou auxquels il participent
• A partir des évènements
  • Identifier les évènements auxquels le système doit répondre
  • Relier l ’événement et les acteurs et UC.

UC et processus métier

• Retirer de l ’argent avec un DAB
• Commander un produit
• s’enregistrer a un enseignement
• Vérifier l ’orthographe d ’un document.
• Gérer un appel téléphonique
• Réserver une place

UC + Fonctions + Traceability

• Les fonctions du système identifiées dans la première étape doivent être allouées aux cas d ’utilisation (les références dans les use case permettent de vérifier qu ’il n ’y a pas d ’oublis).
• Ceci donne un bon outil de traceabilité entre les différents artefacts.
• Idéalement toutes les fonctions et cas d ’utilisation doivent pouvoir êtres tracé jusqu ’a l ’implémentation et les testes.

Les Diagrammes de UC (2)

Frontières

• Les UC décrivent des communications avec un système, quelles sont les frontières de ce système.
• Matérielles/Logicielles
• un département dans un organisation
• une organisation entière

Quelle frontière?

Essentiel vs Réels

Essentiel

• UC détaillés d ’une forme idéal qui ne prend pas en compte les questions technologiques.
• Les décisions de conceptions sont reportés et abstraites.Typiquement celles ce reportant à l ’interface utilisateur.
• Activités essentielles et motivation pour le cas d ’utilisation

Les UC de haut-niveau sont par nature essentiels.

• Les UC de haut-niveau sont par nature essentiels.
• Ex: Un Distributeur Automatique de Billets
• le système d ’identification peut changer au court du temps c ’est une décision de conception.

Il sont Essentiels

• Cours, créer au début, ils ont une longue durée de vie. Il aide à la compréhension du système, ils posent les bases.
• Simples a construire car indépendant de la conception.
• Ils servent de base a la conservation du savoir et du savoir faire.

Les réels

• Description du processus en les termes de la conception courante, définis sur des choix technologiques d ’entrée/sorties, etc.
• Les interfaces sont décrites (dessinées)

UC et planning

• 1. Liste des fonctions, frontière, identification des acteurs et des cas d ’utilisation
• 2. Ecrire mode Haut-Niveau tous les UC
• 3. Dessiner les Diagrammes de UC
• 4. Relations entre UC
• 5. Versions détaillés pour les UC les plus risqués
• 6. Si nécessaire ecrire des UC réels*
• 7. Ordonner les UC.

UC et itérations

• Phase d ’Analyse : Une version détailleé et essentielle des UC développés pendant l ’itération pour la
• Phase de Conception :Une version détaillée réelle

Et notre point de vente ?

• Frontière : les limites du matériel
• Les acteurs (non exhaustif) et UC
  • Caissier (login , faire la caisse)
  • Client (acheter articles, retourner articles)
  • Directeur (Lancer , fermer)
  • Administrateur (ajouter un utilisateur)

Use case : lancer

• Use case : lancer
• Acteur : Directeur
• Type : primaire
• Description: Le directeur allume le point de vente pour le préparer pour l ’utilisation par un caissier. Le directeur valide la date et l ’heure, après quoi le point de vente est près pour être utilisé par un caissier.

Ordonnancement des Cas d ’Utilisation

• Hiérarchiser les cas d ’utilisation
• allouer les cas d ’utilisation aux itérations
• éventuellement créer des cas d ’utilisation simplifiés

Allouer des UC aux itération

Hiérarchiser les UC

• Objectif réaliser les UC les plus haut en premier de façons a réduire le risque
• Une bonne stratégie est de commencer par les UC qui ont le plus d ’impact sur architecture centrale (core).

Éléments de comparaison

• A. impact important sur l ’architecture de conception.ex: ajout de beaucoup de classes ou services de persistance (données p.)
• B. De bonnes informations et d ’intuition sur la conception sont obtenus avec peu d ’effort.
• C. Contient des Fonctions risqués, complexe ou avec des contrainte de vitesse.
• D. Nécessite un effort de recherche, d ’apprentissage ou une technologie risqué
• E. Représente la base du processus métier réalisé
• F. Augmente les revenus ou réduit les coûts

Évaluation

Ordonner les cas d ’utilisation

• Ex:
  • 1 Acheter articles simplifié
  • 2,3,4 Acheter articles avec plusieurs mode de payement
  • 5 Mise à jours de l ’inventaire

Architecture

Un exemple

• Première étapes les Cas d’Utilisation
• Use Case : Jouer une partie
• Acteurs : Joueur
• Description: Le jeu démarre quand le joueur prend les dés et les lancent. Si le Total est égal à 7 le joueur gagne sinon il perd.

Deuxième étape le modèle conceptuel

• Deuxième étape le modèle conceptuel
• c’est une description des objets du domaine, pas d’éléments informatiques.

Construire un diagramme de Collaboration.

• Construire un diagramme de Collaboration.
• Ici des nous spécifions des objets logiciels qui réaliser les exigences grâce à une décomposition objet. Les diagrammes de collaboration montre le flot des messages entre instance et les méthodes invoquées.

Diagramme de Classes

• Diagramme de Classes
• Comment les Objets sont connectés.
• Quelles sont les Méthodes à définir

Choisir sa propre méthode

• Le plus important est de créer une bonne conception.
• Ceci vient d’une bonne maîtrise de principes et d’heuristiques pour identifier et abstraire les bons objets et de leurs affecter les bonnes responsabilités.