Rispondere alle domande un ordine che per me ha senso:
Are the identified processes sensible, or are they too abstract?
Gli elementi dell'elenco dei processi sono piuttosto brevi e mi sembrano più simili ai nomi delle intestazioni di scenario che ai processi. Mentre lo leggo, nei processi 4 + 1 sono essenzialmente in esecuzione programmi.
... At the highest level, the process architecture can be viewed as a set
of independently executing logical networks of communicating programs
(called “processes”) ... 4+1view-architecture.pdf
La vista del processo è una scomposizione delle interazioni tra i programmi (presumibilmente nel realizzare uno scenario). Potrebbero essere necessari diversi diagrammi dello stesso tipo e di tipi diversi.
Quindi, vorrai identificare singoli processi (ad es. programmi) che interagiscono per completare gli scenari.
Does this imply that I would need to develop 8 sequence or activity diagrams?
Is it sensible and clear to make , for example, 8 separate diagrams, or one diagram covering all the processes?
Non necessariamente. Molto probabilmente avrai bisogno di più di un diagramma; tuttavia, molti non ne hanno bisogno esattamente 8. Dopo aver identificato i programmi che stanno interagendo (per ciascuno degli scenari) si può scoprire che molti di loro collaborano attraverso due o più scenari. Ad esempio, potresti scoprire che puoi mostrare la ricerca e l'autenticazione degli account insieme in un unico diagramma di visualizzazione del processo (l'interazione tra il programma client e diversi programmi server).
Facciamo un esempio più semplice possibile: avete due processi (programmi) A e B. Per mostrare la loro interazione, usereste un singolo diagramma di visualizzazione del processo (forse un diagramma di sequenza, ma potreste usare anche la comunicazione o altro) . Quindi, due processi che interagiscono producono un diagramma, se vuoi.
How should the implementation of the Process View be performed, using either of the two diagrams proposed?
In primo luogo, come già accennato, la chiave è identificare i processi (programmi) che interagiscono, e quindi creare le viste del processo usando i diagrammi per mostrare quelli che interagiscono (per un dato scenario). Suggerirei di iniziare con i diagrammi di comunicazione, in quanto consentono di mostrare le interazioni tra i componenti in modo facile da leggere. Se è necessario mostrare l'ordine delle singole interazioni, utilizzare un diagramma di sequenza. Il diagramma delle attività dovrebbe essere conservato per i dettagli successivi. Per uno, i diagrammi di attività non indicano la parte "chi" dell'interazione tra i vari passaggi della logica aziendale (decisioni, ecc.) E nella vista del processo che si sta tentando di mostrare, almeno ai livelli più alti, il "chi" delle interazioni.
... Communication diagrams show which elements each one interacts with better, but sequence diagrams show the order in which the interactions take place more clearly. ... Communication diagrams, Wikipedia
Quando identifichi i componenti interagenti, tieni presente chi è responsabile o autorevole di quali informazioni. Non sembra esserci molto supporto morale in 4 + 1 per il modello informativo, che ritengo sia una componente critica della descrizione architettonica di un sistema, che possa essere compreso ad un livello elevato come chi è autorevole e responsabile di cosa contenuto (e ad un livello inferiore può essere elaborato in modo più o meno relazionale). Ad esempio, in un sistema di ordini, la componente responsabile per accettare gli ordini è la stessa che emette numeri di identificazione dell'ordine, memorizza gli ordini per il successivo recupero, l'ultimo dei quali va al modello di informazioni e all'aspetto della responsabilità delle informazioni del sistema. p>
Personalmente, mi piace Domain Driven Design , inoltre aggiungo una descrizione di livello superiore dei ruoli nell'ecosistema. (Anche se ho (dovuto) usare TOGAF , che ritengo non sia il migliore ma almeno più moderno di 4 +1, IMHO).