Analisi orientata agli oggetti - Peter Coad / Notazione Edward Yourdon

Question

Analisi orientata agli oggetti - Peter Coad / Notazione Edward Yourdon

#1 da (1 voti)

4

Nell'approccio all'analisi orientata agli oggetti definito in Oggetto- Analisi orientata di Peter Coad / Edward Yourdon (Yourdon Press, 1991) , viene fornito un metodo per analizzare e modellare domini di problemi complessi usando "soggetti".

Un soggetto è un gruppo di classi strettamente correlate e amp; oggetti che sono rappresentati come una singola entità al fine di semplificare il modello. In genere, un soggetto rappresenterebbe il livello superiore di una specifica di gen o di un albero di una classe intera. Per questo motivo, i diagrammi soggetto sono utili come una vista di "livello superiore" per guidare il programmatore attraverso diagrammi di classe più dettagliati per ciascuna area "soggetto".

Questo sarebbe un utile approccio analitico per un progetto al momento sto lavorando (è un dominio problematico piuttosto ampio).

Nel libro, viene suggerita una notazione per l'uso insieme all'approccio all'analisi, in quanto è stato riconosciuto che un metodo analitico necessita di una notazione di supporto per renderlo pratico. Tuttavia, la notazione sostenuta come parte dell'approccio OOA di Peer Coad / Edward Yourdon è stata in gran parte sostituita dall'introduzione di UML poco dopo.

Domanda

In UML, come dovrebbero i diagrammi dei soggetti essere modellati?

Considerazioni finora

Il mio primo pensiero riguardava i diagrammi dei componenti , ma ho sempre considerato i componenti principalmente come un problema di implementazione piuttosto che come parte del dominio del problema. Mentre le definizioni dei componenti normalmente coincidono con le divisioni naturali nel dominio del problema, sembra errato parlare di interfacce ecc. Come parte dell'analisi del dominio del problema.

Ho anche considerato diagrammi dei pacchetti ma anche questo sembra inappropriato. Uso i diagrammi dei pacchetti come parte della decisione su come i componenti devono essere raggruppati in termini di repository del codice sorgente; questo è strettamente correlato alla mia strategia di implementazione poiché ogni pacchetto sarà destinato alla distribuzione su un server particolare.

Quindi, esiste un equivalente "Diagramma soggetto" in UML? Altrimenti, posso usare la notazione di Peter Coad / Edward Yourdon o anche solo un diagramma di classe semplificato; ma volevo assicurarmi che non fosse qualcosa in UML che mi mancava ... dopotutto è unificato .

uml ooad

posta Marvin 29.02.2016 - 21:54

fonte

1 risposta

Leggi altre domande sui tag uml ooad

Devo utilizzare lo stesso oggetto per singole istanze e raccolte? Oggetti mutabili: setter e getter

score 1 · Accepted Answer

Se sei disposto ad ampliare la tua ricerca, prenderei in considerazione il diagramma di definizione del blocco SysML (che deriva dal diagramma della struttura composita di UML). Non esiste una granularità specifica per un blocco: potrebbe essere un altro sistema, un sottosistema, un componente, una classe e così via. SysML è un'estensione e una modifica di un sottoinsieme di UML, quindi non credo che sarebbe un grande passo in avanti prendere in considerazione l'introduzione di elementi di SysML se comunichi con persone che hanno già familiarità con UML.

Se vuoi rimanere all'interno di UML, non eliminerei i diagrammi dei pacchetti così velocemente. Anche se hai ragione che normalmente corrispondono a qualcosa come i pacchetti di Java o lo spazio dei nomi di C ++ o una struttura di directory, non hanno bisogno di essere usati in quel modo. Quello che stai descrivendo potrebbe essere visto, da una prospettiva, come un "pacchetto". La discussione di Scott Ambler sui diagrammi dei pacchetti in Agile Modeling supporta anche questa prospettiva.

Personalmente, non ho problemi nel mixare le notazioni. In IEEE 1016: 2009, che definisce gli standard per la descrizione dei progetti di sistemi software, i progetti vengono catturati da vari punti di vista. Un punto di vista mostra il design dalla prospettiva di un particolare stakeholder, utilizzando una o più viste. Le viste possono essere in qualsiasi forma, ma di solito sono grafiche (e talvolta tabulari) con testo di supporto. Lo standard afferma che "in un SDD devono essere utilizzati" solo linguaggi di progettazione standardizzati e ben consolidati (vale a dire, progettati in precedenza e convenientemente disponibili ") e che non limitano l'utente a un linguaggio di progettazione. Se il tuo pubblico capirà la notazione Coad-Yourdon o puoi indirizzarli verso una fonte di riferimento che possono facilmente ottenere, usa quella notazione.