Rappels Génie logiciel RUP, phases milestones, disciplines Philippe Dugerdil 09.10.2008 Rappels Règles métier Processus itératif & incrémental? Certification, CMM? Modification des specification en cours de projet Pourquoi? Poids de la maintenance dans le cycle de vie. Besoin-Feature-Spécification Glossaire Vision Business Modeling
Règle métier- definition A business rule is a statement that defines or constrains some aspect of the business. It is intended d to assert business structure or to control or influence the behavior of the business. [The Business Rules Group - Defining Business Rules. What Are They Really? Final report, 2000. www.businessrulesgroup.org] Examples de business rule Total cost = purchase cost * margin Special sales cannot last more than 3 months. Customer can become privileged customer when he spends more than 2000.- in the same year. Discount on cash sale is 3% until 1000.- and 4% beyond 1000.- When a customer asks for a credit bigger than 500.- this must be approved by the sales manager. The customers must have a unique identification number. Two customer are considered duplicate if they have the same identification number Discipline: spécification «S assurer qu on a bien compris» Storyboards Faire «jouer» les scénarios Item1 Iten2 Item3 Item4 Figures: Copyright 1987-2003 Rational Software Corporation
Traçabilité des spécifications Stakeholder requests Storyboards Business rules Vision La spécification par use-cases Système: vue externe Modèle des use-cases 2 éléments Acteurs et use-cases Nom du use-case Acteur
But de l acteur Acteur Représentent les personnes ou les «choses» qui interagissent d une façon ou d une autre avec le système. But Rôle (compétence, responsabilité) Acteur interactions Système Limite externe du système Ce qui n est pas inclus dans le système Ce avec quoi le system communique Acteur Use-case No m d u u s e - c a s e Système et cas d utilisation Quand un acteur interagit avec le système, Il effectue une séquence d étapes d actions Qui conduisent à un résultat tangible. Cette séquence est appelée Use-Case. Elle est exprimée sous forme verbale (français, anglais,...).
Acteurs primaire et secondaires Contraintes Système UseCase UseCase1 Actor1 Acteur primaire Acteur secondaire UseCase2 Actor3 Actor2 UseCase3 Sens de la flèche: initiative iti de la communication Actor4 18 1 seul acteur primaire Tout use-case possède au moins un acteur Tout acteur est associé à au moins un use-case Use-cases: une vision uniforme Exemple: modèle métier Entreprise Métier Système Environnement
Rappel: spécification «Analyse du problème» Modèle système: identifier les acteurs 3.6 users profiles 4.1 product perspective Vision A cteur Figures: Copyright 1987-2003 Rational Software Corporation Discipline: spécification «définir le système» Structurer les concepts métier: le modèle des objets du domaine (MOD) Business Modeling Retirer de l'argent Utilisateur Proprietaire CompteEC 1 + getnom ( ) - solde 0..1 1 + getsolde ( ) 1 * 1 CarteEC Monnaie + getcomptecash ( ) + getcodeiso ( ) + getnumerocompte ( ) + gettauxchange ( ) + getbanqueemettrice ( ) + getnumerocarte ( ) 1 1 Transaction * * + getheure ( ) + getmontant ( ) Figures: Copyright 1987-2003 Rational Software Corporation
Modèle objet du domaine Identifier les use-cases Quels sont les scénarios principaux du système pour chacun des acteurs Choisir le nom en fonction du résultat attendu par l acteur principal Les UC sont identifiés par leur nom (but, objectif de l acteur primaire) et sont accompagnés d une courte description si nécessaire pour la compréhension des buts et résultats tangibles attendus 25 Exemple: UC pour bancomat Use-case: format Nom: Acteurs: primaires et secondaires Déclencheur: Flot de base 1. 2. 3. 4. Flot alternatifs
Flot: forme et fond Nom: retirer de l argent Acteurs: primaire: utilisateur, secondaires: lecteur de cartes, distributeur de billets Déclencheur: l utilisateur insère une carte dans le lecteur de carte Flot de base: 1. Le lecteur de carte indique qu une carte est insérée 2. Le système affiche: veuillez introduire i votre code personnel 3. L'utilisateur entre son code personnel 4. Le système demande au lecteur de valider le code saisi 5. Le lecteur de carte confirme l égalité des codes 6. Le système affiche le menu des opérations 7. L'utilisateur sélectionne le retrait d'argent sans quittance 8. Le système affiche: veuillez entrer le montant désiré 9. L'utilisateur introduit le montant 10. Le système demande au lecteur de restituer la carte 11. Le système demande au distributeur d éjecter les billets demandés Pour chaque étape d action : Forme grammaticale : <sujet> <verbe> <compléments> On doit clairement savoir qui fait l action (acteur ou système) Le sujet est actif (forme active) Conserver le même niveau d objectif pour les étapes d action. Indiquer l intention de l acteur, pas ses gestes. Dire ce que l acteur fait, pas comment il le fait Eviter toute description d interface utilisateur. C est le spécialiste des interfaces qui doit s en charger Eviter toute description de données Les champs et leur format sont décrits dans des documents annexes (spécifications supplémentaires. voire glossaire) Les variantes techniques ou technologiques d une action ne sont pas dans le scénario nominal Les mettre dans des annexes (extension, paragraphe spécifique). Exemple : régler une facture par carte bancaire, chèque ou cash, avec les contraintes associées. Flot: forme et fond II Indiquez «valider que» plutôt que <vérifier si > Ne pas inclure de condition (si ) dans les étapes d action. Inclure les alternatives dans un paragraphe d extension. Si une étape simple se répète, indiquer cette répétition directement dans l étape, en texte libre. Si plusieurs étapes se répètent, indiquer la répétition en texte libre après l ensemble d étapes qui se répètent, t en référençant leur numéro. Ecrire un use-case: étapes 1. Identifier les acteurs et leurs buts 2. Assigner un nom 3. Identifier la condition de déclenchement Comment le UC est-il lancé? 4. Écrire le flot de base Eviter de détailler les règles de gestion complexes. Elles prennent place dans le document des règles de gestion. Ne pas mettre d action métier, en dehors de la portée du système (toute action doit impliquer le système).
Modèle des use-cases Vue haut niveau de la fonctionnalité d un système Passage entre vues métier et informatique Entreprise Métier Informatique Système informatique Realisation d un processus métier: les objets métier Passage du modèle métier au modèle informatique client Faire développer un logiciel Rôles d individus Métier Ingénieur commercial Faire développer un produit Informatique Vision Ingénieur commercial Etablir l offre Un client exprime ses besoins à l ingénieur i commercial afin d établir le cahier des charges du produit à développer.
Exercice Créer le use-case: chargement de compte cash sur la carte EC, avec impression de quittance. Solution Nom: Charger le compte Cash Acteurs : Utilisateur (principal), lecteur de carte, imprimante. Déclencheur : L'utilisateur insère sa carte dans le lecteur de carte Flot de base : 1. Le lecteur de carte indique qu une carte est insérée 2. Le système affiche: veuillez introduire votre code personnel 3. L'utilisateur entre son code personnel 4. Le système demande au lecteur de valider le code saisi 5. Le lecteur de carte confirme l égalité des codes 6. Le système affiche le menu des opérations 7. L'utilisateur sélectionne le chargement du compte cash 8. Le système affiche: entrez le montant désiré 9. L'utilisateur introduit le montant 10. Le système enregistre le débit du compte courant 11. Le système demande au lecteur de charger la carte avec le montant 12. Le système vérifie que l imprimante est disponible et affiche: voulez-vous une quittance? 13. L utilisateur répond par l affirmative 14. Le système demande au lecteur de restituer la carte et affiche: retirer la carte 15. Le lecteur de carte indique que la carte est retirée 16. Le système demande à l imprimante d imprimer la quittance.