Quale approccio è giusto facendo prima il caso d'uso o prima le classi? perché? [duplicare]

Casi d'uso sono la descrizione del problema da risolvere, quindi, devono venire prima di ogni altra fase del processo.

Direi che non è possibile rendere qualsiasi cosa significativa senza conoscere il problema.

I casi d'uso determineranno quindi che cosa disegni, indipendentemente dal fatto che tu crei diagrammi di classe prima di scrivere qualsiasi codice, tuttavia, è una preferenza personale.

Hai "dimenticato" di menzionarlo, ma presumo tu stia parlando della raccolta dei requisiti per un nuovo software usando UML, giusto?

Penso che il primo passo in questo dovrebbe essere sempre quello di capire i casi d'uso (e non sto parlando di schemi di casi di fantasia, sto parlando del processo di business dei tuoi utenti, di cosa essi stanno facendo e come il nuovo software deve essere integrato nel loro lavoro). Puoi farlo intervistando le persone, osservandole o lavorando con loro.

Per mettere al sicuro il risultato di questo processo puoi provare ad incorporare i diagrammi dei casi d'uso, ma questi diagrammi forniranno solo un'astrazione di livello molto alto di ciò che hai imparato nel passaggio precedente. Quindi dovrai aggiungere una descrizione più dettagliata a qualsiasi caso d'uso. Questa descrizione può utilizzare altri strumenti:

• descrizione verbale dei processi in linguaggio naturale
• esempi di scenari (detti anche "storie degli utenti")
• diagrammi di classi per la modellazione di entità aziendali e dati a un livello molto dettagliato
• diagrammi delle classi come una forma di modello di dominio come in " design basato sul dominio "
• diagrammi del flusso di dati (ancora mancanti in UML)
• Bozze dell'interfaccia utente
• casi di test
• altri diagrammi UML (sebbene IMHO sia di rado molto utile)
• [...]

Quindi se il tuo lavoro è quello di modellare una panoramica di alto livello del sistema, probabilmente creerai prima i diagrammi dei casi d'uso, ognuno con una descrizione più o meno piccola. Se hai intenzione di approfondire i dettagli di un certo caso d'uso, in cui i dati da elaborare sono modellati a livello di attributo, puoi iniziare con un solo caso d'uso e fare un sacco di modellazione bottom-up dettagliata (magari incorporando diagrammi delle classi come uno dei tanti strumenti) prima di passare al caso d'uso successivo. Quindi l'ordine per la modellazione dipende da quale è l'attività assegnata e da quanto è grande e complesso analizzare il software.

Essere consapevoli del fatto che molti progetti software in passato hanno fallito perché sono stati completamente analizzati - centinaia di pagine di specifiche create in mesi senza prima creare una riga di codice (ovviamente, altri progetti hanno fallito perché non erano stati ben analizzati ), quindi è importante trovare il giusto equilibrio. Sappi anche che la maggior parte dei sistemi software verrà creata per versione, quindi il compito di raccogliere i requisiti per la versione 1.0 è solo il primo passo. Per la versione 2,3,4,5, in genere devi descrivere solo i requisiti aggiuntivi rispetto alla versione precedente. Spesso l'insieme dei casi d'uso è per lo più stabile tra le versioni, ma le differenze dettagliate tra la versione n e n + 1 sono interessanti. Quindi gli strumenti che ho elencato sopra per la descrizione dettagliata del caso d'uso diventano in genere più importanti dei diagrammi dei casi d'uso dopo che la versione 1.0 è in produzione.

Prima i casi d'uso è l'approccio giusto perché tonnellate di ingegneri software prima di noi hanno già scoperto

Non ho sentito parlare di persone che preferiscono la prima codifica (diagrammi di classe) e pensarci solo dopo (casi d'uso) e sono ancora in grado di produrre software di lavoro non banale. Al contrario, ho sentito parlare di molti progetti che hanno fallito completamente, esaurito il budget ecc. Proprio per questo.

Ma forse ho frainteso l'intento originale della tua domanda.

Alcuni "cons contro delle classi prima" sono: lezioni apprese, immagine a grandezza naturale disponibile come Come i progetti realmente Lavoro - http://www.projectcartoon.com

Alcuni"professionisti dei casi d'uso prima" sono: perché la letteratura lo consiglia, ad es.

Scott W. Ambler nel suo libro online "Agile Modeling" nel capitolo "Requisiti Envisioning: una migliore pratica agile → Cosa dovrebbe Modelli inizialmente? " dice:

For the first release of a system you need to take several days to identify some high-level requirements as well as the scope of the release (what you think the system should do). The goal is to get a good gut feel what the project is all about. For your initial requirements model my experience is that you need some form of:

• Usage model
• Domain model
• User interface model(s)

3.1 Usage Model

Usage models enable you to explore how users will work with your system, which is absolutely critical if you're to understand what they need. Your usage model may be a collection of essential use cases or system use cases...

3.2 Domain Model

Part of your initial modeling efforts, particularly for a business application, will likely include the development of a conceptual domain model. This model should be very slim, capturing the main business entities and the relationships between them...your model doesn't need to be complete, it just needs to cover enough information to make you comfortable with the primary business concepts...

3.3 User Interface Model(s)

The user interface (UI) is the portion of software with which a user directly interacts. For most stakeholders the UI is the system so it is crucial to the initial success of your project to ensure that you understand what stakeholders expect of the UI. One way to explore the requirements for the UI is to create what are called essential UI prototypes, also known as an abstract prototypes or paper prototypes...