Written by Il termine architettura indica tre concetti che in realtà sono distinti:
- La struttura del sistema software (ad alto livello di solito)
- Processo di creazione della struttura del sistema software
- Documentazione della struttura del sistema software
È importante rendersi conto che la distinzione tra questi elementi è di fondamentale importanza, perché ci aiuta a tenere in mente che la descrizione dell’architettura del sistema non è affatto l’architettura del sistema: la descrizione dell’architettura è un deliverable, un prodotto concreto, che viene prodotto attraverso l’adottato processo di creazione della struttura. Così tale descrizione riportata nella documentazione architetturale diviene un fondamentale strumento per la condivisione delle informazioni su di essa da parte del team di sviluppo o di chiunque intenda volerne comprendere i dettagli.
Ciò che vogliamo fare è chiarire qualche dubbio che può far nascere una particolare modalità di documentazione dell’architettura presentato da Philippe Kruchten della Rational Software Corp. descritto in un famoso Blueprint pubblicato nel novembre del 1995 in IEEE Software 12(6): il cosiddetto “Modello 4+1”. Si tratta di una modalità di descrizione architetturale che è imperniato sulla modalità di presentazione dell’architettura attraverso 4+1 “viste”. In UML la cosiddetta vista è una porzione del modello che vuole rappresentare un particolare aspetto del sistema software. UML non definisce proprio in maniera formale il concetto di vista, ma questo concetto è stato storicamente usato molto comunemente, specialmente da Rational Rose (tool di modellazione software che è stato il principale punto di riferimento per l’affermazione dello standard). UML in sé non fornisce indicazioni su quali viste in particolare debbano essere inserite nella modellazione del sistema software in modo mandatorio per una descrizione esaustiva di un’architettura.
Nel 1995 Kruchten propose una versione modificata dell’approccio Rational (basato su quattro viste principali, comprendenti a loro volta una o più tipologie di diagrammi), che distingue cinque viste principali:
- Logical View: è il modello ad oggetti (nel caso di approccio object-oriented)
- Process View: intende catturare aspetti del design come concorrenza e sincronizzazione
- Physical View: descrive la mappatura del software sulla struttura hardware, ovvero la modalità in cui è distribuito su di esso
- Development View: descrive l’organizzazione statica del software nell’ambiente di sviluppo
- Use case View (Scenarios): descrive i requisiti di sistema
La descrizione di un’architettura (in termini delle decisioni prese per la sua strutturazione) può essere data efficacemente con le prime quattro viste, mentre la quinta (ecco perché la dizione ”4+1”) illustra quali requisiti tale architettura intende soddisfare, sancendo così in un certo senso la completezza della descrizione.
è da tenere presente che il “4+1” è un modello “generico”, nel senso che non prescrive una particolare notazione o tool da utilizzare (tantomeno UML: Kruchten stesso nel suo articolo utilizza la notazione di Booch), sebbene ormai venga proiettato principalmente nel mondo UML. Ciò è un particolare vantaggio perché indipendentemente da specifiche notazioni, cerca di focalizzare l’interesse di un particolare stakeholder sulla vista che lo interessa, ovvero cerca di fare in modo che tutti i gruppi che fanno parte del team di sviluppo abbiano le informazioni necessarie per comprendere il sistema in modo da poter fare il proprio lavoro. Ma tutto questo ha un’ulteriore risvolto: essendo l’attenzione posta sul fornire le informazioni corrette a seconda dello stakeholder e non essendoci una notazione di riferimento, nel momento in cui si intenda esprimere il contenuto informativo delle viste con diagrammi UML, non si individua un mapping univoco tra tali viste e tipologie di diagramma. Ad esempio infatti, nell’articolo “Role of UML sequence diagram constructs in object lifecycle concept” di Miroslav Grgee e Robert Muzar (Università di Zagabria, facoltà di informatica, UDK 004.43:004.45 Original scientific paper), viene riportata la seguente corrispondenza:
- Logical view: Class diagram, Object Diagram, Sequence Diagram, Collaboration Diagram, State Chart Diagram, Activity Diagram
- Development View: Package Diagram, Component Diagram
- Process View: Use Case Diagram, Class Diagram, Object Diagram, Sequence Diagram, Collaboration Diagram, State Chart Diagram, Activity Diagram
- Physical View: Deployment Diagram
- Use Case view: Use Case Diagram, Object Diagram, Sequence Diagram, Collaboration Diagram, State Chart Diagram, Activity Diagram
nell’articolo “Applying 4+1 View Architecture with UML2” di Veer Muchandi (FCG Software Services – FCGSS), le corrispondenze sono:
- Logical view: Class diagram, Object Diagram, State Chart Diagram, Composite Structures
- Development View: Component Diagrams
- Process View: Sequence Diagrams, Communication Diagrams, Activity Diagrams, Timing Diagrams, Interaction Overview Diagrams
- Physical View: Deployment Diagrams
- Use Case view: Use Case Diagram, Activity Diagrams
mentre su Wikipedia troviamo:
- Logical view: Class diagram, Communication Diagram, Sequence
- Development View: Component Diagram, Package Diagram
- Process View: Activity Diagrams
- Physical View: Deployment Diagram
- Use Case view: Use Case Diagram
Altrove potremmo riscontrare ulteriori giustapposizioni dei diagrammi menzionati. Quindi ecco che il fatto che il modello 4+1 non dia prescrizioni su notazioni e linguaggi di modellazione trova diverse interpretazioni a seconda di come si voglia la potenzialità espressiva dei singoli diagrammi UML: questi ultimi infatti possono sempre essere utilizzati in maniera polivalente, per cui è facile ritrovarli menzionati in viste diverse a seconda dell’enfasi che si voglia dare ai singoli elementi o comunque a seconda dello stile scelto dall’autore.
C’è da dire che l’approccio 4+1 era più in voga quando anche UML era poco più che agli albori. Al giorno d’oggi difficilmente si utilizzano più di 2 o te viste contemporaneamente. Le esigenze descrittive sono cambiate e tutte le viste menzionate sono generalmente decomposte per cogliere in maniera sintetica vari altri aspetti, come ad esempio le Service Realizations o le Landscape Maps. Per questo sono stati proposti altri framework, come ad esempio quello di Zachman, basato su sei Views e sei Viewpoints.
Il termine architettura indica tre concetti che in realtà sono distinti:
- La struttura del sistema software (ad alto livello di solito)
- Processo di creazione della struttura del sistema software
- Documentazione della struttura del sistema software
È importante rendersi conto che la distinzione tra questi elementi è di fondamentale importanza, perché ci aiuta a tenere in mente che la descrizione dell’architettura del sistema non è affatto l’architettura del sistema: la descrizione dell’architettura è un deliverable, un prodotto concreto, che viene prodotto attraverso l’adottato processo di creazione della struttura. Così tale descrizione riportata nella documentazione architetturale diviene un fondamentale strumento per la condivisione delle informazioni su di essa da parte del team di sviluppo o di chiunque intenda volerne comprendere i dettagli.
Ciò che vogliamo fare è chiarire qualche dubbio che può far nascere una particolare modalità di documentazione dell’architettura presentato da Philippe Kruchten della Rational Software Corp. descritto in un famoso Blueprint pubblicato nel novembre del 1995 in IEEE Software 12(6): il cosiddetto “Modello 4+1”. Si tratta di una modalità di descrizione architetturale che è imperniato sulla modalità di presentazione dell’architettura attraverso 4+1 “viste”. In UML la cosiddetta vista è una porzione del modello che vuole rappresentare un particolare aspetto del sistema software. UML non definisce proprio in maniera formale il concetto di vista, ma questo concetto è stato storicamente usato molto comunemente, specialmente da Rational Rose (tool di modellazione software che è stato il principale punto di riferimento per l’affermazione dello standard). UML in sé non fornisce indicazioni su quali viste in particolare debbano essere inserite nella modellazione del sistema software in modo mandatorio per una descrizione esaustiva di un’architettura.
Nel 1995 Kruchten propose una versione modificata dell’approccio Rational (basato su quattro viste principali, comprendenti a loro volta una o più tipologie di diagrammi), che distingue cinque viste principali:
- Logical View: è il modello ad oggetti (nel caso di approccio object-oriented)
- Process View: intende catturare aspetti del design come concorrenza e sincronizzazione
- Physical View: descrive la mappatura del software sulla struttura hardware, ovvero la modalità in cui è distribuito su di esso
- Development View: descrive l’organizzazione statica del software nell’ambiente di sviluppo
- Use case View (Scenarios): descrive i requisiti di sistema
La descrizione di un’architettura (in termini delle decisioni prese per la sua strutturazione) può essere data efficacemente con le prime quattro viste, mentre la quinta (ecco perché la dizione ”4+1”) illustra quali requisiti tale architettura intende soddisfare, sancendo così in un certo senso la completezza della descrizione.
è da tenere presente che il “4+1” è un modello “generico”, nel senso che non prescrive una particolare notazione o tool da utilizzare (tantomeno UML: Kruchten stesso nel suo articolo utilizza la notazione di Booch), sebbene ormai venga proiettato principalmente nel mondo UML. Ciò è un particolare vantaggio perché indipendentemente da specifiche notazioni, cerca di focalizzare l’interesse di un particolare stakeholder sulla vista che lo interessa, ovvero cerca di fare in modo che tutti i gruppi che fanno parte del team di sviluppo abbiano le informazioni necessarie per comprendere il sistema in modo da poter fare il proprio lavoro. Ma tutto questo ha un’ulteriore risvolto: essendo l’attenzione posta sul fornire le informazioni corrette a seconda dello stakeholder e non essendoci una notazione di riferimento, nel momento in cui si intenda esprimere il contenuto informativo delle viste con diagrammi UML, non si individua un mapping univoco tra tali viste e tipologie di diagramma. Ad esempio infatti, nell’articolo “Role of UML sequence diagram constructs in object lifecycle concept” di Miroslav Grgee e Robert Muzar (Università di Zagabria, facoltà di informatica, UDK 004.43:004.45 Original scientific paper), viene riportata la seguente corrispondenza:
- Logical view: Class diagram, Object Diagram, Sequence Diagram, Collaboration Diagram, State Chart Diagram, Activity Diagram
- Development View: Package Diagram, Component Diagram
- Process View: Use Case Diagram, Class Diagram, Object Diagram, Sequence Diagram, Collaboration Diagram, State Chart Diagram, Activity Diagram
- Physical View: Deployment Diagram
- Use Case view: Use Case Diagram, Object Diagram, Sequence Diagram, Collaboration Diagram, State Chart Diagram, Activity Diagram
nell’articolo “Applying 4+1 View Architecture with UML2” di Veer Muchandi (FCG Software Services – FCGSS), le corrispondenze sono:
- Logical view: Class diagram, Object Diagram, State Chart Diagram, Composite Structures
- Development View: Component Diagrams
- Process View: Sequence Diagrams, Communication Diagrams, Activity Diagrams, Timing Diagrams, Interaction Overview Diagrams
- Physical View: Deployment Diagrams
- Use Case view: Use Case Diagram, Activity Diagrams
mentre su Wikipedia troviamo:
- Logical view: Class diagram, Communication Diagram, Sequence
- Development View: Component Diagram, Package Diagram
- Process View: Activity Diagrams
- Physical View: Deployment Diagram
- Use Case view: Use Case Diagram
Altrove potremmo riscontrare ulteriori giustapposizioni dei diagrammi menzionati. Quindi ecco che il fatto che il modello 4+1 non dia prescrizioni su notazioni e linguaggi di modellazione trova diverse interpretazioni a seconda di come si voglia la potenzialità espressiva dei singoli diagrammi UML: questi ultimi infatti possono sempre essere utilizzati in maniera polivalente, per cui è facile ritrovarli menzionati in viste diverse a seconda dell’enfasi che si voglia dare ai singoli elementi o comunque a seconda dello stile scelto dall’autore.
C’è da dire che l’approccio 4+1 era più in voga quando anche UML era poco più che agli albori. Al giorno d’oggi difficilmente si utilizzano più di 2 o te viste contemporaneamente. Le esigenze descrittive sono cambiate e tutte le viste menzionate sono generalmente decomposte per cogliere in maniera sintetica vari altri aspetti, come ad esempio le Service Realizations o le Landscape Maps. Per questo sono stati proposti altri framework, come ad esempio quello di Zachman, basato su sei Views e sei Viewpoints.