Prerequisito in un caso d'uso

Question

Im creare un caso d'uso per un progetto per la scuola. Im un po 'confuso sulla scheda pre-condizionale.

In un certo senso v'è infatti una condizione preliminare come "hanno essere loggato" o "ha bisogno di un account"

Ma cosa succede se il download è una configurazione locale?

A me suona logica che una premessa è che "il software deve essere installato"

Ma d'altra parte questo presupposto sembra strano, perché altrimenti non avrebbe questo caso d'uso, in primo luogo.

Quindi la mia domanda è breve. I requisiti di sistema o l'installazione del software possono far parte di una precondizione?

Answer 1

Davvero una buona domanda che affronta il cuore dei problemi UML: è semantica debole. La risposta alla tua domanda è quindi - potrebbe essere giusto, potrebbe essere sbagliato. UML imposta le regole notazionali e definisce solo la semantica degli elementi di base (ad es. "Una precondizione deve essere soddisfatta nell'ordine ...").

Potremmo anche andare oltre con precondizioni come "il sistema operativo dovrebbe essere configurato correttamente" o anche peggio - "il computer ha elettricità" ... Queste discussioni possono facilmente diventare filosofiche. :)

Nella mia esperienza c'è un modo per rendere efficienti i casi d'uso - costruire un altro modello UML, complementare, che sarebbe usato per formulare precondizioni, postcondizioni e persino usare scenari di casi (la stessa domanda che hai fatto per le condizioni preliminari può essere fatto anche per gli scenari - che è una corretta astrazione per uno scenario? O è "accendi il computer?" un passo valido in uno scenario?).

Per ottenere questo utilizzo normalmente utilizzo diagrammi concettuali di classe: modifico il mio dominio e quindi esprimo condizioni e scenari pre/post in termini di questi elementi (classi e relativi attributi) E UTILIZZO SOLO DI QUESTI ELEMENTI. Questo ha molto senso, soprattutto sapendo che le pre/post-condizioni interrogano lo stato del sistema, rispecchiato in modo pulito da oggetti/valori.

Tornando al tuo esempio, se ti chiedi quale sia il presupposto "il software deve essere installato", ti chiedi semplicemente "Ho davvero bisogno di una classe" Software "con un attributo" Installato "?"

Quindi molto probabilmente ti rendi conto che probabilmente non hai bisogno di questa condizione preliminare perché è semplicemente troppo "di basso livello" e fuori dall'ambito del mio dominio. Ora hai solo bisogno di definire il tuo dominio. :) Ecco un semplice esempio di una situazione simile, dimostrando l'idea (tenere presente che utilizzano modelli cassa e di classe sono disegnati diagrammi separate):

Questo metodo non solo rende più facile l'uso specificando casi, ma anche fare un modello di classe complementare che permetta la specificazione del dominio, l'identificazione delle regole di business e una prima astrazione della progettazione del sistema.

Buona fortuna e buon divertimento!

Answer 2

Per me, i requisiti di sistema e/o l'installazione del software possono far parte di una precondizione ma, come sempre, devono essere pertinenti nel contesto del vostro caso d'uso. Ad esempio, il sistema avrà un comportamento diverso se un hardware o un terzo strumento è o non è installato.

Answer 3

Teniamo presente che i casi d'uso sono davvero requisiti di alto livello su ciò che il software/i sistemi devono implementare. In questo modo, le precondizioni dovrebbero riguardare solo il software (o il sistema) che stai creando e non gli elementi esterni (ad esempio, "il computer è connesso e acceso" non è una buona condizione preliminare). Quando inizi a realizzare i tuoi casi d'uso come diagrammi di sequenza o di attività, ad esempio, le condizioni preliminari ti forniscono un indizio sul fatto che potrebbe essere necessario un controllo nel software, forse richiedendo una chiamata ad un'altra operazione/modulo/classe. Questo esercizio di realizzazione ti aiuterà a determinare la forma che assumerà la condizione preliminare, e anche se è ancora necessaria a seconda della struttura della tua applicazione.

Per fare un esempio, la precondizione "deve essere registrato" potrebbe essere necessaria se si prevede un comportamento diverso se l'utente è connesso o meno, o se sono richiesti privilegi diversi per l'operazione.

Quindi, alcuni requisiti di sistema potrebbero essere precondizioni (ad esempio, connettività a un dispositivo) e alcune installazioni software potrebbero essere una precondizione (ad esempio, una necessaria integrazione del prodotto companion), ma solo se hanno un effetto diretto sul caso d'uso si. L'installazione del software per la tua app non dovrebbe essere una condizione preliminare: l'app non può controllare se non è installata in quanto non può essere eseguita e viene eseguita quindi è ovviamente installata ...