Mappatura tra 4 + 1 modello di vista architettonica e UML

Sono un po 'confuso su come il modello di vista architetturale 4 + 1 si associ a UML.

Wikipedia fornisce la seguente mappatura:

• Vista logica: diagramma di classe, diagramma di comunicazione, diagramma di sequenza.
• Vista di sviluppo: diagramma dei componenti, diagramma del pacchetto
• Vista del processo: diagramma delle attività
• Vista fisica: diagramma di distribuzione
• Scenari: diagramma dei casi d'uso

Il ruolo cartaceo dei costrutti del diagramma di sequenza UML nel concetto del ciclo di vita degli oggetti fornisce la seguente mappatura:

• Vista logica (diagramma di classe (CD), diagramma di oggetto (OD), diagramma di sequenza (SD), diagramma di collaborazione (COD), diagramma di stato (SCD), diagramma di attività (AD))
• Vista di sviluppo (diagramma del pacchetto, diagramma dei componenti),
• Vista del processo (utilizzare il diagramma dei casi, CD, OD, SD, COD, SCD, AD),
• Vista fisica (diagramma di distribuzione) e
• Vista caso d' uso (diagramma caso d'uso, OD, SD, COD, SCD, AD) che combina i quattro sopra menzionati.

La pagina Web UML 4 + 1 Visualizza materiali presenta la seguente mappatura:

Infine, il white paper Applicazione di 4 + 1 View Architecture con UML 2 fornisce un'altra mappatura:

• Diagrammi di classi della vista logica , diagrammi di oggetti, diagrammi di stato e strutture composite
• Diagrammi di sequenza della vista di processo , diagrammi di comunicazione, diagrammi di attività, diagrammi di temporizzazione, diagrammi di panoramica delle interazioni
• Diagrammi dei componenti della vista sviluppo
• Diagramma di distribuzione della vista fisica
• Vista caso d' uso diagramma caso d'uso, diagrammi di attività

Sono sicuro che ulteriori ricerche riveleranno anche altre mappature.

Mentre varie persone di solito hanno diverse prospettive, non vedo perché questo è il caso qui. In particolare, ogni diagramma UML descrive il sistema da un aspetto particolare. Quindi, ad esempio, perché il "diagramma di sequenza" è considerato come descrittivo della "vista logica" del sistema da un autore, mentre un altro autore lo considera come descrittivo della "vista di processo"?

La prego di aiutarmi a chiarire la confusione?

Sebbene in generale concordi con la risposta di Bart van Ingen Schenau , ritengo che alcuni punti necessitino di ulteriori elaborazioni.

Il vantaggio del modello 4 + 1 View è che associa gli stakeholder al tipo di informazioni di cui hanno bisogno, senza richiedere l'utilizzo di specifiche notazioni di modellazione. L'enfasi è sul garantire che tutti i gruppi dispongano delle informazioni per comprendere il sistema e continuare a fare il proprio lavoro.

Il modello di architettura software 4 + 1 View è stato descritto nell'articolo Architectural Blueprints di Philippe Kruchten - Il modello di architettura software "4 + 1" View, originariamente pubblicato in IEEE Software (novembre 1995). Questa pubblicazione non fa riferimenti specifici a UML. In effetti, il documento utilizza la notazione Booch per la vista logica, le estensioni alla notazione Booch per la vista del processo e la vista di sviluppo, richiama l'uso di "diverse forme" per sviluppare una vista fisica e una nuova notazione per gli scenari.

Invece di provare a mappare ciascuna vista su particolari tipi di diagrammi, considera chi è il pubblico di destinazione di ciascuna vista e quali informazioni sono necessarie. Sapendo ciò, guarda i vari tipi di modelli e quali forniscono le informazioni richieste.

La vista logica è progettata per rispondere alle preoccupazioni dell'utente finale riguardo alla garanzia che tutte le funzionalità desiderate vengano acquisite dal sistema. In un sistema orientato agli oggetti, questo è spesso a livello di classe. In sistemi complessi, potrebbe essere necessaria una vista del pacchetto e scomporre i pacchetti in diagrammi di più classi. In altri paradigmi, potresti essere interessato a rappresentare i moduli e le funzioni che forniscono. Il risultato finale dovrebbe essere una mappatura della funzionalità richiesta ai componenti che forniscono tale funzionalità.

La vista del processo è progettata per le persone che progettano l'intero sistema e quindi integrano i sottosistemi o il sistema in un sistema di sistemi. Questa vista mostra le attività e i processi che il sistema ha, le interfacce verso il mondo esterno e / o tra i componenti all'interno del sistema, i messaggi inviati e ricevuti e come vengono affrontate le prestazioni, la disponibilità, la tolleranza agli errori e l'integrità.

La vista di sviluppo è principalmente per gli sviluppatori che costruiranno i moduli e i sottosistemi. Dovrebbe mostrare dipendenze e relazioni tra i moduli, come i moduli sono organizzati, riutilizzati e portabili.

La vista fisica è principalmente per i progettisti e gli amministratori di sistema che devono comprendere le posizioni fisiche del software, le connessioni fisiche tra i nodi, la distribuzione e l'installazione e la scalabilità.

Infine, gli scenari aiutano a catturare i requisiti in modo che tutte le parti interessate comprendano come si intende utilizzare il sistema.

Dopo aver compreso cosa dovrebbe fornire ciascuna vista, è possibile scegliere quali notazioni di modellazione utilizzare e a quale livello di dettaglio è richiesto. L'ultimo paragrafo di Bart è particolarmente vero: puoi mostrare vari livelli di dettagli nei tuoi modelli UML concentrandoti su elementi di design particolari o combinando vari tipi di diagrammi in un set. Inoltre, potresti considerare di andare oltre UML ad altre notazioni di modellazione per descrivere meglio l'architettura del tuo sistema: SysML , modellazione Entity-Relation o IDEF .

Il motivo per cui non è possibile trovare un mapping uno a uno tra le viste del modello architettonico 4 + 1 e i vari diagrammi UML è perché tale mapping non esiste.

Ciò che tutti quegli autori stanno cercando di dire con le loro "mappature" è che per ogni vista esiste una serie diversa di diagrammi UML che possono essere utili per trasmettere le informazioni che si desidera comunicare in quella vista.

Inoltre, alcuni diagrammi UML possono essere utilizzati in diversi modi, enfatizzando diversi elementi nel diagramma, il che li rende utili per più viste. Ma anche se un tipo di diagramma UML può essere utilizzato in più viste, disegneresti un diagramma diverso (o un insieme di diagrammi) per ogni vista.

Anche se sono d'accordo con Thomas Owens risponde all'approccio per soddisfare le esigenze degli utenti finali, una cosa che non viene menzionata è che il motivo per cui la definizione originale di "4 + 1 View Model Architecture" di Kruchten non rende riferimenti specifici a UML sono perché l'articolo è stato scritto nel 1995 (come afferma la risposta), ma UML non è stato adottato come standard fino al 1997 .

L'uso continuo della notazione Booch nell'articolo suggerisce che potrebbe essere appropriato mettere in relazione ciascuna delle viste dei modelli con uno specifico diagramma UML, poiché Grady Booch era una delle persone coinvolte nello sviluppo di UML.

È per questo che così tanti autori diversi considerano diversi diagrammi UML applicabili a ciascuna vista, dal momento che più diagrammi UML potrebbero essere considerati in una certa quantità di "astrazioni" della Notazione Booch che la definizione originale del modello 4 + 1 si basa su per rappresentare ogni vista.

Spero che questo chiarisca le cose un po 'di più per chiunque lo stia guardando.

Usi ancora il videoregistratore che hai acquistato nel 1995.? 4 + 1 era applicabile allora quando il software era agli inizi. Ma anche allora, nessuno ha mai usato più di 2 o 3 "viste". Negli ultimi 20 anni l'ingegneria del software è cambiata. Al giorno d'oggi, ambito / contesto e concettuale e logico e fisico e ... sono tutti differenziati. Molte soluzioni COTS devono essere integrate e così via. Oggi parliamo di mappe paesaggistiche, realizzazioni di servizi e dozzine di altre viste e punti di vista. Il modo migliore per osservarlo è attraverso un semplice quadro di tassonomia come Zachman: 6 punti di vista e 6 punti di vista. Lascia che sia il tuo punto di partenza. 6 punti di vista sono: concettuali contestuali o logici di business o sistemi fisici o tecnologici di consegna o artefatti aziendali funzionanti

6 punti di vista sono: dati o quale funzione o come rete o dove persone o chi tempo o quando motivazione o perché

Diamo un esempio. Se siamo interessati solo ai dati, inizieremo con la vista dell'ambito e diremo "Il nostro ambito è CRM". Nella vista concettuale per il punto di vista dei dati verrà fornito un modello semantico per CRM. Il modello sarà concettuale, concetti di informazioni commerciali piuttosto che oggetti di dati. Successivamente, nella vista logica, produrremo un modello di dati logici dal nostro modello concettuale di CRM. Possiamo usare la metodologia ER per produrre un modello di dati logici. Quindi, nella vista fisica, produrremo un modello di dati fisici. Qui, definiremo tipi di dati concreti per la nostra piattaforma db di nostra scelta, indici ecc. Infine, nella vista di consegna avremo il nostro script DDL, mentre nella vista aziendale funzionante avremo un file binario distribuito su alcuni server di database e mappato in strutture di dati interne del fornitore DBM. Lo ripetiamo per ogni punto di vista o colonna. Inoltre, se esiste più di un stakeholder, creeremo più di un modello per ciascuna combinazione di punti di vista / vista. Ora che questa tassonomia è in atto, è possibile definire i propri punti di vista e viste e allinearli a questa tassonomia. Ad esempio, per le iniziative a livello aziendale i seguenti punti di vista sono tutti importanti: attore cooperazione comportamento dell'applicazione applicazione cooperazione cooperazione struttura dell'applicazione utilizzo dell'applicazione funzione aziendale processo aziendale processo di business cooperazione implementazione e implementazione struttura informativa infrastruttura utilizzo infrastruttura panorama paesaggistico panoramica organizzazione organizzativa a strati realizzazione servizio ecc Ora che questa tassonomia è in atto, è possibile definire i propri punti di vista e viste e allinearli a questa tassonomia. Ad esempio, per le iniziative a livello aziendale i seguenti punti di vista sono tutti importanti: attore cooperazione comportamento dell'applicazione applicazione cooperazione cooperazione struttura dell'applicazione utilizzo dell'applicazione funzione aziendale processo aziendale processo di business cooperazione implementazione e implementazione struttura informativa infrastruttura utilizzo infrastruttura panorama paesaggistico panoramica organizzazione organizzativa a strati realizzazione servizio ecc Ora che questa tassonomia è in atto, è possibile definire i propri punti di vista e viste e allinearli a questa tassonomia. Ad esempio, per le iniziative a livello aziendale i seguenti punti di vista sono tutti importanti: attore cooperazione comportamento dell'applicazione applicazione cooperazione cooperazione struttura dell'applicazione utilizzo dell'applicazione funzione aziendale processo aziendale processo di business cooperazione implementazione e implementazione struttura informativa infrastruttura utilizzo infrastruttura panorama della città panoramica organizzazione a livelli realizzazione servizio ecc

Il 4 + 1 di Krutchen non poteva assolutamente soddisfare tutte queste esigenze