Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Analyse du problème - Spéciﬁcation des besoins Gerson Sunyé - gerson.sunye@univ

Analyse du problème - Spéciﬁcation des besoins Gerson Sunyé - gerson.sunye@univ-nantes.fr 1 Plan • Aperçu du processus. • Techniques de modélisation. • Concepts de base. • Analyse du problème. • Spéciﬁcation des besoins. 2 • Modéliser, concevoir, implémenter et tester, périodiquement • Diﬀérent chemins possibles à l’intérieur de la méthode • Le processus est non-linéaire, itératif et parallèle Aperçu du processus 3 Techniques de modélisation 4 Techniques de modélisation • Dictionnaire • Carte conceptuelle (Concept Map) • Diagrammes UML (rappel) • Instantanés (Snapshots) • Cas d’utilisation • DSL 5 Dictionnaire (1/2) • Permet de ﬁger la terminologie du domaine d’application. • Constitue le point d’entrée et le référentiel initial du système. • Outil de dialogue informel, évolutif et simple à réaliser. 6 Dictionnaire (2/2) 100 © 1997-2001 J.-M. Jézéquel Exemple de dictionnaire – Dictionnaire d'un simulateur de vol Notion Définition Nom informatique Traduit en ... Pilotage Action de piloter un avion en enchaînant des manoeuvres élémentaires Pilotage Package Manette des gaz Instrument qui permet d'agir sur la quantité de carburant injectée dans le moteur Classe abstraite Manette_gaz Classe Instrument Instrument Organe d'interaction entre le pilote et l'avion ou entre l'avion et le pilote Mettre_a_fond Opération Mettre les gaz à fond Action qui permet d’injecter le maximum de carburant pour atteindre la vitesse maximale Action Définition Nom informatique Traduit en ... Exemple pour un simulateur de vol : 7 Carte conceptuelle (1/3) [Novak 84] • Une carte conceptuelle est une représentation graphique d’une base de connaissances déclaratives qui possède une organisation hiérarchique. 8 Carte conceptuelle (2/3) • Représentation informelle (bien que structurée) des termes en relation d’un domaine. 9 Carte conceptuelle (3/3) Vidéothèque Client Video Membres Catalogue Loue, achète, réserve prix réservé emprunté 10 UML - Diagramme de classes • Sans détails • Analyse • Conception • Propriétés groupées selon leur visibilité HTML Page HTML Page title : String size : Integer render() save() HTML Page + title : String + /size : Integer ~ version : Integer # contents : String - visibility : Boolean = true - tags : String [1..*] + render() + save() - optimize() HTML Page public title : String /size : Integer package version : Integer protected contents : String private visibility : Boolean = true tags : String [1..*] public render() save() private optimize() 11 • Similaire à celle d’une classe • Le nom de l’instance et celui de la classe sont soulignés et séparés par “:” • Les deux noms sont facultatifs UML - Diagramme d’instances Arnaud : Etudiant adresse = "13 r du pont" age : Integer = 38 : Département nom = "Informatique" appartient 12 Instantanés (1/2) • Un diagramme d’instances représentant l’état d’un système à un moment donnée. • Représentation du problème (métier), non obligatoirement un logiciel: • Les objets et liens peuvent représenter aussi bien des ﬁches en papier que des tuples d’une base de données. 13 Instantanés (1/2) lessive:Matière repassage:Matière jardinage:Matière cirage:Matière laurent:Etudiant nom = "Dupont" prenom = "Laurent" age = 32 aurelie:Etudiant nom = "Montaigne" prenom = "Aurélie" age = 37 14 15 Les cas d’utilisation (use-cases) • Un cas d’utilisation est une manière particulière d’utiliser le système • séquence d’interactions entre le système et un ou plusieurs acteurs • Ils s’expriment par des diagrammes de séquences 15 16 Les cas d’utilisation • La compilation des cas d’utilisation décrit de manière informelle le service rendu par le système • fournissent une expression “fonctionnelle” du besoin • peuvent piloter la progression d’un cycle en spirale • Les cas d’utilisation sont nommés en utilisant la terminologie décrite dans le dictionnaire 16 Cas d’utilisation • Un cas d’utilisation est un texte. • Écrire des bons cas d’utilisation est surtout une question de style. 17 Canevas de description [Cockburn] • Use Case: <number> <the name should be the goal as a short active verb phrase> • Goal in Context: <a longer statement of the goal, if needed> • Scope: <what system is being considered black-box under design> • Level: <one of: Summary, Primary task, Subfunction> • Primary Actor: <a role name for the primary actor, or description> • Priority: <how critical to your system / organization> • Frequency: <how often it is expected to happen> 18 Canevas de description (suite) • MAIN SUCCESS SCENARIO • EXTENSIONS • SUB-VARIATIONS • Superordinate Use Case: <optional, name of use case that includes this one> • Subordinate Use Cases: <optional, depending on tools, links to sub.use cases> 19 Exemple (1/4) Use Case: 5 Buy Goods -------------------------------------------------- CHARACTERISTIC INFORMATION Goal in Context: Buyer issues request directly to our company, expects goods shipped and to be billed. Scope: Company Level: Summary Preconditions: We know Buyer, their address, etc. Success End Condition: Buyer has goods, we have money for the goods. Failed End Condition: We have not sent the goods, Buyer has not spent the money. Primary Actor: Buyer, any agent (or computer) acting for the customer Trigger: purchase request comes in. 20 Exemple (2/4) MAIN SUCCESS SCENARIO 1. Buyer calls in with a purchase request. 2. Company captures buyer’s name, address, requested goods, etc. 3. Company gives buyer information on goods, prices, delivery dates, etc. 4. Buyer signs for order. 5. Company creates order, ships order to buyer. 6. Company ships invoice to buyer. 7. Buyers pays invoice. EXTENSIONS 3a. Company is out of one of the ordered items: 3a1. Renegotiate order. 4a. Buyer pays directly with credit card: 4a1. Take payment by credit card (use case 44) 7a. Buyer returns goods: 7a. Handle returned goods (use case 105) 21 Exemple (3/4) SUB-VARIATIONS 1. Buyer may use phone in, fax in, use web order form, electronic interchange 7. Buyer may pay by cash or money order check 22 Exemple (4/4) RELATED INFORMATION Priority: top Performance Target: 5 minutes for order, 45 days until paid Frequency: 200/day Superordinate Use Case: Manage customer relationship (use case 2) Subordinate Use Cases: Create order (use case 15) Take payment by credit card (use case 44) Handle returned goods (use case 105) Channel to primary actor: may be phone, ﬁle or interactice Secondary Actors: credit card company, bank, shipping service Channels to Secondary Actors: ---------------------------- OPEN ISSUES What happens if we have part of the order? What happens if credit card is stolen? --------------------------- SCHEDULE Due Date: release 1.0 23 DSL • Domain speciﬁc language. • Spéciﬁcation d’un langage à partir du vocabulaire du domaine. 24 Concepts de base Objets et Actions 25 Concepts de base • Objet: information + fonctionnalité. • Action: quelque chose qui se passe. • Les actions sont (ou peuvent être) indépendantes des objets. Elles seront liées aux objets plus tard. • Les actions modiﬁent les objets. 26 Concepts de base • Les actions sont au même niveaux que les objets • Une conception bien découpée demande une réﬂexion précise sur les actions et ce qu’elles réalisent 27 Fractales • Une image fractale a la même apparence à tous les niveaux • Objets: départements d’aﬀaires, machines, composants logiciels, concepts de langage de programmation. • Actions représentent les interactions entre objets: accords d’aﬀaires, appels téléphoniques, tours en vélo, etc. 28 Actions (1/2) • Actions == collaborations • Les collaboration sont utilisées pour modéliser: • ce qu’il se passe à l’intérieur d’un composant logiciel. • interaction entre composants. • modélisation du domaine: comment les objets du monde réel interagissent? 29 Actions (2/2) • Les Actions ont des participants (objets) • Combien d’objets sont nécessaires? Autant qu’il faut pour décrire les actions. • Les associations fournissent un vocabulaire utilisé pour décrire les eﬀets d’une action 30 Deux sortes d’actions • Localisée (ou opération) • orientée (un émetteur, un destinataire) • Conjointe. • symétrique, à n participants • dite «Cas d’utilisation» (Use Case) pour l’analyse du problème 31 Les objets participent aux actions enseigne Étudiant Enseignant Type d’action (cas d’utilisation) Type d’objet • Un diagramme seul n’est pas suﬃsant. Il doit être accompagné par une explication dans un dictionnaire séparé 32 Concepts de base • Les responsabilités ne sont pas assignées aux objets dès le début. Étapes: • Ce qu’il se passe • Quel objet est responsable du déclenchement de ce qu’il se passe 33 Les Actions aﬀectent les Objets • Les objets sont utilisés pour décrire l’eﬀet des action sur les participants • Les actions sont caractérisées par ce qu’elles accomplissent • De nouveaux termes sont introduits pour décrire l’eﬀet (ou la post-condition) action(étudiant, enseignant)::enseigne(matière) post -- cette matière a été ajoutée aux compétences de l’étudiant 34 Les Actions aﬀectent les Objets • De nouveaux termes sont introduits pour décrire l’eﬀet (ou la post-condition) • Les étoiles indiquent qu’un étudiant peut avoir plusieurs compétences • La ﬁgure est une indication (optionnelle) qu’un étudiant est un rôle Étudiant Matière compétence * * 35 Les Actions aﬀectent les Objets • Utilisation d’instantanés (snapshots) pour visualiser une action • Les lignes épaisses sont utilisées pour représenter une création de lien Laurent:Étudiant Aurélie:Étudiant lessive:Matière repassage:Matière jardinage:Matière cirage:Matière action(Aurélie, unEnseignant)::enseigne(repassage) 36 Les Actions aﬀectent les Objets • Généralement, les modiﬁcations sont présentées en gras (ou en couleurs) • Les associations représentent des relations du monde réel uploads/Industriel/ besoins.pdf