Case de candidature – Wikipedia

Hiérarchie des applications dans le style Cockburn

UN Application (Engl. cas d’utilisation ) regroupe tous les scénarios possibles qui peuvent se produire lorsqu’un acteur essaie d’utiliser le système en considération un certain objectif technique. objectif commercial ) atteindre. Il décrit ce qui peut arriver en termes de contenu lorsqu’il essaie d’atteindre l’objectif et abstrait par des solutions techniques concrètes. Le résultat de l’application peut être un succès ou un échec / démolition.

Les cas de candidature sont généralement nommés comme les objectifs sont du point de vue des acteurs: Registre des membres , retirer de l’argent , Verser une voiture .

La granularité des applications peut différer considérablement: à un niveau très élevé, une application ne décrit que ce qui se passe très grossièrement et ce qui se passe. Cependant, la technologie de la lettre d’application peut être affinée sauf au niveau des processus informatiques, de sorte que le comportement d’une application est décrit en détail. Cela contredit l’intention d’origine des cas d’utilisation, mais est parfois fonctionnel.

L’application et le processus métier sont souvent délimités les uns des autres. Cependant, la référence à la théorie du système montre que les applications et les processus métier décrivent chacun une vue différente du système à modéliser:

• cas d’utilisation Décrivez ce que l’environnement attend du système.
• UN Processus d’affaires Décrit une séquence d’activités individuelles qui sont effectuées progressivement afin d’atteindre un objectif commercial ou opérationnel.

Cette démarcation s’applique également quel que soit le type de système à modéliser pour les entreprises et les logiciels. Il n’est pas non plus équivalent à la distinction entre la modélisation de la boîte blanche et la modélisation de la boîte noire.

Les termes application commerciale (anglais cas d’utilisation de l’entreprise ) et l’application système (anglais cas d’utilisation du système ) D’un autre côté, décrivez le contenu du système considéré:

• En cas d’application système, le contenu est défini par le système à développer.
• En cas d’application commerciale, le contenu du contenu est défini par une unité organisationnelle, par exemple une entreprise ou un département.

Habituellement, les applications commerciales sont utilisées pour intégrer les applications système dans un contexte commun et découvrir d’autres exigences.

Les cas de candidature ont déjà été utilisés avant l’établissement de l’UML. Les connexions peuvent être affichées dans un schéma d’application. Un diagramme de contexte système est souvent créé avec cela.

Le contenu d’une application suit généralement au moyen d’un modèle à définir, qui doit être développé en fonction du contexte de l’utilisation ultérieure de l’application. Des modèles généralement formalisés sont également utilisés pour différentes phases d’analyse, de la description courte purement prosaïque à une application complète et élaborée.

Par exemple, un modèle à Cockburn doit être présenté ici:

Nom et numéro d’identification

Les cas de candidature ont un nom et sont numérotés en fonction des groupes de matériaux, par exemple B. UC 2.01.

Description (description)

Une brève description a lieu ici, qui se produit dans l’application. En bref, il y a deux ou trois lignes, rarement plus.

Participants impliqués (acteurs)

Les acteurs sont des personnes ou des systèmes impliqués à l’extérieur (!) Du système décrit. Par exemple, utilisateur, utilisateur enregistré, client, système, processus de facturation. Les acteurs sont précédemment montrés dans leur propre section. Jacobson distingue deux types d’acteurs: Acteurs principaux sont les utilisateurs réels du système. En plus de ceux-ci, il y a aussi acteurs secondaires (Aussi: “soutenir les acteurs”) qui surveillent le système, attendez et soutendent l’acteur principal dans sa réussite. ^[d’abord]

Statut

Le statut indique à quel point les travaux sur l’application ont progressé. En cours, prêt pour l’examen, dans la revue, rejeté et diminué des exemples.

Applications utilisées (comprend)

Si la demande revient à d’autres applications, ces cas sont répertoriés ici. Le nom et le numéro d’identification doivent être répertoriés.

déclencher (raisonnement ou déclencher)

La raison technique ou les raisons pour lesquelles cette demande est effectuée.

Conditions préalables (conditions préalables)

Toutes les conditions qui doivent être remplies afin que cette application puisse être exécutée. S’il n’y a pas de conditions préalables, il n’y en a “aucun”.

Invariant

Toutes les conditions qui peuvent ne pas être modifiées au sein et via l’application, c’est-à-dire même dans un scénario de défaillance ou d’erreur.

Configuration / résultat (Postconditions)

La condition attendue après un succès réussi de l’application.

Flux standard (flux normal)

Le scénario typique est montré ici, ce qui est facile à comprendre ou le cas le plus courant. À la fin, la réalisation de l’objectif de l’acteur principal. Les étapes de drain sont numérotées et principalement décrites dans une langue structurée. Cependant, les plans de planification peuvent également être utilisés s’ils semblent attachés. À l’aide de l’UML, ces étapes de drainage peuvent être présentées dans des diagrammes d’activité ou des diagrammes de séquences orientés vers l’application.

Étapes de drain alternatives (flux alternatif)

Ce sont des scénarios qui peuvent également se produire en dehors du processus standard dans la réalisation (tentée) de l’objectif de l’application. Ils sont principalement représentés comme des branches conditionnelles des étapes de drain normales. À la fin, il y a un échec, la réalisation de l’objectif du joueur principal ou un retour au processus standard.

Astuces

De courtes explications pour une meilleure compréhension, des indications des effets secondaires, de l’échafaudage de quantité si nécessaire et de tout ce qui ne peut pas être montré ci-dessus.

Changer l’historique (Historique des cas d’utilisation)

Version, nom de l’auteur, date

Cet article ou section doit être révisé. Plus de détails devraient être donnés sur la page de discussion. Veuillez aider à l’améliorer, puis supprimer ce marquage.

Une application décrit les interactions entre l’utilisateur et le système nécessaire à un Pour réaliser l’objectif technique de l’utilisateur. Les processus décrits ne doivent pas devenir trop complexes. Le test de pause café décrit par Alistair Cockburn peut servir d’indice: l’application est trop complexe si “l’utilisateur prenait une pause-café pendant les interactions”.

Dans le développement de logiciels Agile, en particulier dans la programmation extrême (XP), les cas d’utilisation sont écrits sous une forme encore plus rare en raison des caractéristiques organisationnelles. En raison de cette forme encore plus fréquente de la représentation, ils ne portent pas le cas d’utilisation du nom, mais sont appelés User Story. Une histoire d’utilisateurs de XP ressemble plus à la courte description d’un cas d’utilisation classique. ^[2]

En décembre 2011, Ivar Jacobson, Ian Spence et Kurt Bittner ont publié le concept du cas 2.0. Il décrit une technologie agile évolutive pour le développement d’exigences qui peuvent être utilisées pour contrôler le développement incrémentiel du système. Les principes du nouveau concept sont:

• Décrivez juste des choses – avec des histoires (“histoires”)
• Comprendre la “vue d’ensemble”
• Concentrez-vous sur les avantages
• Construire le système tranché (“en tranches”)
• Livrer le système en incrément
• S’adapter aux besoins de l’équipe

La résolution de problèmes pour la planification du projet Agile avec un cas d’utilisation fournit la technologie de “tranchage” – la coupe d’un cas d’utilisation en unités plus petites, qui peuvent ensuite être réalisées dans un sprint.

• Avec l’analyse de la robustesse, les propriétés spéciales des cas d’utilisation peuvent être examinées.

• Kurt Bittner, Ian Spence: Modélisation de cas d’utilisation . Addison-Wesley Pearson Education, Boston 2003, ISBN 0-201-70913-9.
• Alistair Cockburn: Créer efficacement les cas d’utilisation . MITP, Bonn 2003, ISBN 3-8266-1344-9.
• Ivar Jacobson U. un.: Génie logiciel orienté objet . Addison-Wesley, Wokingham UK 1993, ISBN 0-201-54435-0.
• Christoph Kecher: UML 2.0, le manuel complet . Galileo Computing, 2006, ISBN 978-3-89842-738-8.
• Daryl Kulak, Eamonn Guiney: Cas d’utilisation: exigences en contexte . 2e édition. ACM Press, New York 2004, ISBN 0-201-65767-8.
• Robert Morys: Modélisation de la qualité basée sur la métrique des spécifications des exigences basées sur les cas d’utilisation . (PDF; 1,5 Mb) Thèse de diplôme Rwth Aachen; Consulté en octobre 2012
• Doug Rosenberg: Modélisation d’objets axée sur les cas d’utilisation avec UML – Théorie et pratique . Je suis APRRESS U.S.A, 2007, ISBN 978-1-59059-774-3.
• Chris Rupp et les sophistes: Exigences Ingénierie et gestion professionnelle des exigences itératives professionnelles pour la pratique . 6. Édition. Hanser, Munich 2014, ISBN 978-3-446-43893-4.
• Hartmut Umbach, Pierre Metz: Cas d’utilisation par rapport aux processus métier . Dans: Spectre , 29 (2006) NR. 6, p. 424–432, Deux: 10.1007 / S00287-006-0106-8 .

1. ↑ Ivar Jacobson U. un.: Acteurs . Dans: Génie logiciel orienté objet . Addison-Wesley, Wokingham UK 1993, ISBN 0-201-54435-0, S. 157–159 .
2. ↑ Cockburn: Créer efficacement les cas d’utilisation . MITP, Bonn 2003, S. 231.