Qual è l'ordine di disegno del diagramma in un disegno?

7

Sono nuovo con OOP e UML e ho un po 'di confusione qui. Mi piacerebbe sapere da dove cominciare, voglio dire, qualcuno viene da te e ti chiede di fare qualcosa (implica ovviamente la progettazione del software), una volta che hai determinato cosa deve essere fatto, qual è l'ordine in cui devi avviare l'architettura del software? Voglio dire, è prima il diagramma del caso d'uso o il diagramma delle classi? o dovrei disegnare alcuni diagrammi in parallelo?

Ma in sostanza, da dove dovrei iniziare? e quale diagramma UML è il primo? Grazie per l'aiuto !!

    
posta Manuel Malagon 11.06.2012 - 06:07
fonte

3 risposte

9

Non esiste un ordine fisso. Tutto si basa su ciò che pensi sia più utile per te / la tua squadra.

Inizialmente, ci dovrebbe essere una serie di requisiti. Se inizi con l'architettura SW una volta che qualcuno ti dice di fare un software per X, allora hai già perso il passaggio più importante.

Durante la fase di ingegnerizzazione dei requisiti, non tutti i diagrammi UML hanno ancora senso. Ma alcuni hanno molto senso, in particolare i diagrammi dei casi d'uso. Ho spesso visto diagrammi del caso d'uso come base per le discussioni da cui sono poi stati determinati i requisiti.

Allo stesso modo, le macchine a stati sono già popolari anche a livello di requisiti.

Una volta che hai una serie di requisiti e in effetti inizi a pensare alla tua architettura e successivamente al design, sempre più diagrammi cominceranno a dare un senso. Ovviamente, il diagramma di classe è utile su livelli di dettaglio più bassi, ma altri, come i diagrammi di sequenza, possono avere senso se si hanno sequenze complesse nella propria architettura.

Stai sviluppando un sistema distribuito o qualcosa in cui i componenti devono comunicare molto tra loro? Prova il diagramma di comunicazione.

A meno che il tuo processo non richieda in qualche modo di utilizzare uno specifico diagramma UML, non c'è nessuno che ti obblighi a farlo. Ricorda sempre di non modellare il tuo software in UML per il suo stesso interesse. Se non hai voglia ti aiuterà, allora semplicemente non farlo.

Ovviamente, ci vuole un po 'di esperienza per decidere questo. Vi suggerisco di investire almeno del tempo per provare i diagrammi di stato, di classe, di attività e di sequenza, poiché sono quelli più popolari. Se hai abbastanza tempo, dai uno sguardo anche agli altri.

    
risposta data 11.06.2012 - 08:31
fonte
4

Anche se sarei d'accordo sul fatto che non esiste una regola ferrea, ho elaborato una serie di passaggi dopo aver letto il libro di Martin Fowler su UML.

1) Analizza prima gli attori (un diagramma uml sugli attori e come interagiscono con il sistema)

2) Use-Case Diagrams

3) Analisi di fattori esterni che potrebbero avere un impatto su un sistema (non proprio un diagramma incluso solo per motivi di informazione)

4) Analizzare i rischi nei sistemi e stimarne l'impatto (ancora una volta non proprio un diagramma)

5) Diagrammi di sequenza (con flusso di dati in essi)

6) Diagrammi di classe

Dal libro: "con un grande sistema ... È più facile ... arrivare prima alla lista degli attori, e poi ... i casi d'uso per ogni attore." ~ Martin Fowler - UML Distilled

Raccomanda questo libro come una buona introduzione ai diagrammi.

Un altro consiglio del libro: è meglio avere alcuni diagrammi che si mantengono aggiornati piuttosto che avere molti diagrammi che sono meno aggiornati

    
risposta data 11.06.2012 - 18:48
fonte
0

Non esiste una regola rigida, ma alcune linee guida.

La maggior parte degli sviluppatori / analisti inizieranno, a seconda dello scenario.

Molti analisti iniziano con i diagrammi "use cases" e alla fine aggiungono altri diagrammi, solitamente diagrammi architettonici, come pacchetti o componenti.

E, quindi, con diagrammi "Classi", "Attività", "Sequenza".

Saluti.

    
risposta data 11.06.2012 - 18:20
fonte

Leggi altre domande sui tag