Mappatura tra 4 + 1 modello di visualizzazione architettonica e UML

Anche se in generale sono d'accordo con la risposta di Bart van Ingen Schenau , ritengo che alcuni punti necessitino di un'ulteriore elaborazione.

Il vantaggio del modello di vista 4 + 1 è che associa le parti interessate al tipo di informazioni di cui hanno bisogno, senza richiedere l'uso di specifiche notazioni di modellazione. L'accento è posto sulla garanzia che tutti i gruppi abbiano le informazioni per comprendere il sistema e continuare a fare il loro lavoro.

Il modello 4 + 1 di architettura software è stato descritto in di Philippe Kruchten paper Architectural Blueprints - Il "4 + 1" View Model of Software Architeture originariamente pubblicato su IEEE Software (novembre 1995). Questa pubblicazione non fa riferimenti specifici a UML. In effetti, la carta utilizza la notazione Booch per la vista logica, le estensioni della notazione Booch per la visualizzazione del processo e la vista di sviluppo, richiama l'uso di "varie forme" di sviluppo di una vista fisica e una nuova notazione per gli scenari.

Invece di provare a mappare ciascuna vista a particolari tipi di diagrammi, considera chi sono i destinatari di ciascuna vista e quali informazioni hanno bisogno. Sapendo questo, guarda i vari tipi di modelli e quali forniscono le informazioni richieste.

La vista logica è progettata per rispondere alle preoccupazioni dell'utente finale di garantire che tutte le funzionalità desiderate vengano acquisite dal sistema. In un sistema orientato agli oggetti, questo è spesso a livello di classe. Nei sistemi complessi, potrebbe essere necessaria una vista pacchetto e scomporre i pacchetti in più diagrammi di classe. 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 del sistema, le interfacce con il mondo esterno e / o tra i componenti all'interno del sistema, i messaggi inviati e ricevuti e il modo in cui vengono affrontate le prestazioni, la disponibilità, la tolleranza agli errori e l'integrità.

La visualizzazione dello 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 progettisti di sistemi e amministratori 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 tutti gli stakeholder comprendano come si intende utilizzare il sistema.

Una volta compreso ciò che ciascuna vista dovrebbe fornire, è possibile scegliere le notazioni di modellazione da utilizzare e il livello di dettaglio richiesto. L'ultimo paragrafo di Bart è particolarmente vero: puoi mostrare vari livelli di dettagli nei tuoi modelli UML concentrandoti su particolari elementi di design o combinando vari tipi di diagrammi in un set. Inoltre, potresti considerare di andare oltre l'UML ad altre notazioni di modellazione per descrivere meglio la tua architettura di sistema - SysML , Modellazione di relazione entità o IDEF .

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

Quello che tutti quegli autori stanno cercando di dire con i loro 'mapping' è che per ogni vista, c'è un diverso set di diagrammi UML che può essere utile per trasmettere le informazioni che vuoi dire in quella vista.

Inoltre, alcuni diagrammi UML possono essere utilizzati in diversi modi, sottolineando diversi elementi nel diagramma, che li rendono utili per più viste. Ma anche se un tipo di diagramma UML può essere utilizzato in più viste, devi disegnare un diagramma diverso (o una serie di diagrammi) per ciascuna vista.

Utilizzi ancora il videoregistratore che hai acquistato nel 1995? 4 + 1 era applicabile al momento in cui il software era nella sua infanzia. Ma anche allora nessuno ha mai usato più di 2 o 3 "viste". Negli ultimi 20 anni l'ingegneria del software è cambiata. Oggigiorno, ambito / contesto e concettuale, logico, fisico e ... sono tutti differenziati. Molte soluzioni COTS devono essere integrate e così via. Oggi parliamo di mappe del paesaggio, realizzazioni di servizi e dozzine di altre viste e punti di vista. Il modo migliore per esaminarlo è attraverso una semplice struttura di tassonomia come Zachman: 6 viste e 6 punti di vista. Lascia che sia il tuo punto di partenza. 6 visualizzazioni sono: contestuale concettuale o aziendale logico o sistema fisica o tecnologia consegna o artefatti impresa funzionante

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

Diamo un'occhiata a 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, creeremo un modello semantico per il CRM. Il modello sarà concettuale, concetti di informazioni aziendali piuttosto che oggetti dati. Successivamente, nella vista logica produrremo un modello di dati logici dal nostro modello concettuale di CRM. Possiamo usare la metodologia ER per produrre modelli di dati logici. Quindi, nella vista fisica, produrremo un modello di dati fisici. Qui, definiremo i tipi di dati concreti per la piattaforma db di nostra scelta, gli indici, ecc. Infine, nella visualizzazione di consegna avremo il nostro script DDL, mentre nella visualizzazione aziendale funzionante avremo un file binario distribuito su alcuni server di database e mappato in strutture di dati interne del fornitore DBMs. Lo ripetiamo per ogni punto di vista o colonna. Inoltre, se ci sono più di uno stakeholder creeremo più di un modello per ogni combinazione di punti di vista / vista. Ora che hai questa tassonomia, puoi definire i tuoi punti di vista e le tue viste e allinearli in questa tassonomia. Ad esempio, per iniziative a livello aziendale i seguenti punti di vista sono tutti importanti: cooperazione attore comportamento dell'applicazione cooperazione applicativa struttura dell'applicazione utilizzo dell'applicazione funzione aziendale processo di business cooperazione dei processi aziendali implementazione e implementazione struttura informativa infrastruttura utilizzo dell'infrastruttura mappa del paesaggio panoramica stratificato organizzativa realizzazione del servizio etc

Il 4 + 1 di Krutchen non ha potuto soddisfare tutte queste esigenze