UML è un'opzione molto strong per rappresentare graficamente i programmi. Grady Booch e un team di altri hanno scritto un ottimo libro chiamato Analisi orientata agli oggetti e progettazione con applicazioni che introduce OOAD piuttosto rigorosamente trascorrendo circa 150 pagine discutendo concetti prima di immergersi nella notazione. Mentre in alcuni casi i diagrammi sono facili da comprendere senza molto addestramento, Booch è un maestro nel definire idee come la complessità, distinguendo tra modello di oggetto e modello di classe e classificazione. Il consiglio sulla complessità include la discussione di diversi strumenti come la decomposizione algoritmica, la decomposizione orientata agli oggetti, l'astrazione, la gerarchia e l'incapsulamento.
È importante ricordare che potrebbe essere necessario esaminare il software da diverse prospettive in modo da poter acquisire la struttura statica e il comportamento dinamico di oggetti e classi. Un diagramma di classe catturerebbe la struttura statica di una o più classi mentre un diagramma di sequenza catturerebbe il comportamento dinamico di due o più oggetti mentre interagiscono. Booch suddivide anche le categorie in diagrammi strutturali, comportamentali e di interazione.
Diagrammi UML
- Strutturale
- Package
- Class
- Componente
- distribuzione
- Oggetto
- Struttura composita
- comportamentale
- Usa caso
- attività
- Macchina di stato
- Interazione
- Sequenza
- Comunicazione
- Panoramica dell'interazione
- Timing
Per chiunque possa nominare solo tre o quattro diagrammi UML, questa dovrebbe essere una sveglia. Se trascorri un giorno o poche ore al giorno per una settimana, potresti non conoscere l'UML molto profondamente. Spesso, l'UML viene insegnato come un corso di quattro giorni e talvolta come tre o quattro giorni per l'analisi orientata agli oggetti seguita da tre o quattro giorni di progettazione orientata agli oggetti. I corsi universitari possono insegnare come corsi di uno o più corsi semestrali, o piegarli in una sequenza che seguiva il ciclo di vita del software cascata (requisiti e analisi (con casi d'uso), architettura software e / o design (con i diagrammi rimanenti) programmazione orientata agli oggetti (con Java, C ++, ecc.) e test (che rivisita casi d'uso o diagrammi di stato)).
Martin Fowler ha un libro che mi piace chiamato UML Distilled dove essenzialmente espone un pattern per ogni diagramma scrivi, elencando il nome, una breve descrizione, esempi del diagramma e cosa significano gli archi, i nodi e i decoratori e, soprattutto, quando usarli. Nel suo materiale introduttivo descrive UML come avente tre applicazioni: fare un progetto software, come un linguaggio di programmazione di livello superiore che genera codice (o talvolta ingegneri inversi dal codice, o trasmuta avanti e indietro nell'ingegneria del software round-trip), o il mio preferito, come uno schizzo che aiuta a comunicare tra gli sviluppatori alcuni aspetti localizzati e specifici del design.
Gli odiatori di UML hanno ragione su molte cose. Ad esempio, su quanto overhead può essere coinvolto nell'uso di UML per documentare un progetto (in modalità modello o linguaggio di programmazione). A volte dicono, un pazzo con uno strumento è ancora un pazzo. È una cattiva idea per uno sviluppatore sotto-addestrato saltare in un diagramma di creazione così come è per un programmatore FORTRAN iniziare a scrivere in C ++ o Java da una tabella che mostra quali istruzioni sono equivalenti. Con un editor di diagrammi UML dello strumento CASE (Computer Aided Software Engineering) (CASE ha subito molte critiche) è diventato possibile per i cattivi progettisti realizzare progetti di grosse dimensioni molto più velocemente.
Gli amanti di UML faranno notare che ci consente un linguaggio comune per comunicare il nostro design in modo visivo ed espressivo. Dato che rappresentiamo lo stesso design in più modi, ci dà una grande prova per il codice che scriveremo. Poiché è visibile, facilita una forma di comunicazione con gli altri che è più veloce (elaboriamo le informazioni visive molto più velocemente del verbale, e per via indiretta, rispetto al testo) e ci offre molte opportunità di revisione tra pari. Poiché utilizziamo più di una vista, ci consente di spostarci tra viste gerarchiche come diagrammi di distribuzione, diagrammi di pacchetti e diagrammi di classe. Possiamo vedere le stesse informazioni a riposo nel diagramma degli oggetti e in movimento nel diagramma di attività e nel diagramma di sequenza. Usando diagrammi correlati, possiamo rivelare i problemi con completezza e coerenza in anticipo, e talvolta usare una rappresentazione che è facilmente generata come un diagramma di stato per scoprire il contenuto necessario in un altro diagramma come un diagramma di sequenza.
