Utilisation Diagramme de cas (UML): Le stockage de la base de données devrait-il être un cas de sous-utilisation (dans ce diagramme)?
Application Fond
Une brève description de ce que l'application doit faire
[.____] Je développe une application qui analyse les séquences d'ADN. L'utilisateur charge Un certain fichier contenant une séquence d'ADN. Ensuite, l'utilisateur peut cliquer sur un bouton sur Rechercher des orfs (parties de la séquence d'ADN avec des fonctionnalités spécifiques). Ces orfs peuvent alors être blasted (recherche d'une annotation sur ces séquences dans une base de données publique). Une exigence importante était que la séquence d'ADN (chargée par l'utilisateur), les ORFS (trouvées par l'application) et le résultat forment l'explosion sera enregistré dans une base de données .
processus
Je vais d'abord décrire ce que j'ai fait et pourquoi j'ai changé de choses pour clarifier pourquoi le diagramme est tel qu'il est maintenant. Je suis juste neuf à utiliser UML et chaque commentaire est la bienvenue .
[.____] Usage Schéma de cas version 1.0
[.____] 
[.____] J'ai douté de "dire" que la base de données est un acteur, basé dans cette question J'ai décidé que la base de données est juste pour le stockage et je l'ai omis. entraînant la version finale de mon diagramme.
[.____] Use utilisation diagramme version 1.1
[.____] 
[.____] J'ai parlé à certaines personnes à propos de UC_07, certains diront que ce serait " trop technique". Cependant, ma vision est que l'extraction de cette étape commune montre clairement les limitations de la demande; Bien que la base de données ne fonctionne pas (en raison d'une erreur par exemple), tous les trois cas d'utilisation (2,3,4) seraient atteints de cela.
question doit que UC_07 soit un cas séparé (sous) utiliser ou non? En outre comme décrit ci-dessus (la base de données n'est pas un acteur Si c'est juste utilisé pour le stockage), mais Comment peut-on décrire UC_07 si la base de données ne peut pas être vue comme un acteur? car en général, cela ressemblera à quelque chose comme ça: 1. le L'application ouvre la connexion de la base de données 2. L'application envoie les données 2. La base de données stocke les données
Autres suggestions/améliorations sur le diagramme de cas d'utilisation sont également vraiment appréciées
Modifier en raison de commentaires sous la réponse d'AMON
Supposons que je décide de télécharger UC_07 Devrais-je mentionner le stockage des données dans la base de données dans l'UC_2-4 ou non:
[.____] 
Le diagramme de cas d'utilisation nous donne un aperçu des exigences et illustre la manière dont divers acteurs interagissent via le système.
Il existe de nombreuses façons de capturer réellement des cas d'utilisation. Un important est une phrase unique histoires d'utilisateurs. Par exemple: "En tant qu'utilisateur, je souhaite chercher l'ORFS". Ceci est un cas d'utilisation valide. Vous proposez maintenant un cas d'utilisation comme "en tant qu'utilisateur, je souhaite enregistrer des données dans la base de données". C'est mai être un cas d'utilisation valide mais cela ne semble vraiment pas comme ça.
Ceci est plus clair si nous utilisons un format de cas d'utilisation tabulaire. Ici, nous énumérons explicitement les étapes que l'utilisateur effectue et comment le système répond. Par exemple:
Rechercher orfs
Précondition: un fichier est chargé.
Acteur principal: Utilisateur
Déclencheur: L'utilisateur clique sur le bouton "Recherche".
Scénario:
- L'utilisateur entre dans une ORF dans la zone de recherche et soumet la recherche.
- Le système affiche une liste de toutes les séquences correspondantes dans le fichier chargé.
PostCondition: le système peut recevoir la prochaine requête de recherche.
Certaines étapes de ce scénario peuvent être si complexes qu'elles sont décrites dans un autre cas d'utilisation qui serait alors inclus. Mais un cas d'utilisation est toujours une interaction du système acteur. Si vous avez une case "Enregistrer des données dans la base de données", utilisez le cas où l'utilisateur clique sur un bouton "Enregistrer sur DB", vous pouvez avoir un cas d'utilisation réel. Sinon, la base de données est juste un détail de mise en œuvre.
Que la base de données semble être importante pour que vos utilisateurs puissent signifier que vous n'avez pas réellement capturé tous les cas d'utilisation. Vous mentionnez la contrainte que la base de données doit être exécutée pour que ces cas d'utilisation fonctionnent - c'est une condition préalable, ou peut-être un scénario d'exception. Nous pourrions étendre le cas d'utilisation détaillé ci-dessus avec un flux alternatif:
Exceptions:
- Si la base de données est hors ligne ou renvoie une erreur, le système affiche un message d'erreur à l'utilisateur.
Si une vérification "La base de données est hors ligne" est courante à de nombreux cas d'utilisation, vous pouvez extraire cette étape commune dans un cas d'utilisation partagée. Par exemple. Pour les applications Web, nous extraire "l'utilisateur est connecté" vérifier dans un cas d'utilisation séparé au lieu de répéter cela dans chaque cas d'utilisation.
Quel est l'intérêt de l'utilisateur ici? Ils ne veulent pas entrer dans une recherche si cela ne peut pas être répondu. Ainsi, le cas d'utilisation est "en tant qu'utilisateur, je souhaite voir un avertissement lorsque la base de données est" ou "en tant qu'utilisateur, je veux être empêchée de rechercher lorsque la base de données est en panne".
Je dirais que UC_07 n'est peut-être pas nécessaire du tout si elle fait partie du système global.
De plus, beaucoup de vos cas d'utilisation se lisent comme une séquence d'étapes qui appartiennent plus correctement à un diagramme de séquence. Mais cela dépend vraiment du nombre de diagrammes UML que vous utilisez.
Vous pouvez également établir un cas pour supprimer les applications de démarrage et de fermeture car il s'agit d'une donnée si vous utilisez l'application elle-même.
Utiliser des cas et l'utilisation Les modèles de cas sont destinés à décrire certains aspects du fonctionnel exigences d'un système. En tant que tels, ils se concentrent sur quoi Le système est censé faire du point de vue de l'entreprise. Surtout, ils ne devraient pas être sur Comment Le système fonctionne en interne, qui est une question de conception logicielle .
Des trucs techniques comme l'ouverture des connexions de base de données et la gestion des erreurs inattendues appartiennent principalement au domaine de la conception plutôt que des exigences.