Modelli di architettura

L'architettura del software coinvolge la struttura di alto livello dell'astrazione del sistema software, utilizzando la scomposizione e la composizione, con stile architettonico e attributi di qualità. La progettazione di un'architettura software deve essere conforme ai principali requisiti di funzionalità e prestazioni del sistema, oltre a soddisfare i requisiti non funzionali come affidabilità, scalabilità, portabilità e disponibilità.

Un'architettura software deve descrivere il proprio gruppo di componenti, le loro connessioni, le interazioni tra loro e la configurazione di distribuzione di tutti i componenti.

Un'architettura software può essere definita in molti modi:

  • UML (Unified Modeling Language) - UML è una delle soluzioni orientate agli oggetti utilizzate nella modellazione e progettazione del software.

  • Architecture View Model (4+1 view model) - Il modello di visualizzazione dell'architettura rappresenta i requisiti funzionali e non funzionali dell'applicazione software.

  • ADL (Architecture Description Language) - ADL definisce l'architettura del software formalmente e semanticamente.

UML

UML è l'acronimo di Unified Modeling Language. È un linguaggio pittorico utilizzato per creare progetti software. UML è stato creato da Object Management Group (OMG). La bozza della specifica UML 1.0 è stata proposta all'OMG nel gennaio 1997. Serve come standard per l'analisi dei requisiti software e per i documenti di progettazione che sono la base per lo sviluppo di un software.

UML può essere descritto come un linguaggio di modellazione visuale per scopi generali per visualizzare, specificare, costruire e documentare un sistema software. Sebbene UML sia generalmente utilizzato per modellare il sistema software, non è limitato all'interno di questo confine. Viene anche utilizzato per modellare sistemi non software come i flussi di processo in un'unità di produzione.

Gli elementi sono come componenti che possono essere associati in modi diversi per creare un'immagine UML completa, nota come diagram. Quindi, è molto importante comprendere i diversi diagrammi per implementare la conoscenza nei sistemi della vita reale. Abbiamo due ampie categorie di diagrammi e sono ulteriormente suddivisi in sottocategorie, ad esStructural Diagrams e Behavioral Diagrams.

Diagrammi strutturali

I diagrammi strutturali rappresentano gli aspetti statici di un sistema. Questi aspetti statici rappresentano quelle parti di un diagramma che costituisce la struttura principale ed è quindi stabile.

Queste parti statiche sono rappresentate da classi, interfacce, oggetti, componenti e nodi. Gli schemi strutturali possono essere suddivisi come segue:

  • Diagramma di classe
  • Diagramma dell'oggetto
  • Schema dei componenti
  • Diagramma di distribuzione
  • Diagramma del pacchetto
  • Struttura composita

La tabella seguente fornisce una breve descrizione di questi diagrammi:

Sr.No. Diagramma e descrizione
1

Class

Rappresenta l'orientamento agli oggetti di un sistema. Mostra come le classi sono staticamente correlate.

2

Object

Rappresenta un insieme di oggetti e le loro relazioni in fase di esecuzione e rappresenta anche la vista statica del sistema.

3

Component

Descrive tutti i componenti, le loro interrelazioni, interazioni e interfaccia del sistema.

4

Composite structure

Descrive la struttura interna del componente comprese tutte le classi, le interfacce del componente, ecc.

5

Package

Descrive la struttura e l'organizzazione del pacchetto. Copre le classi nel pacchetto e i pacchetti all'interno di un altro pacchetto.

6

Deployment

I diagrammi di distribuzione sono un insieme di nodi e le loro relazioni. Questi nodi sono entità fisiche in cui vengono distribuiti i componenti.

Diagrammi comportamentali

I diagrammi comportamentali catturano fondamentalmente l'aspetto dinamico di un sistema. Gli aspetti dinamici sono fondamentalmente le parti mutevoli / mobili di un sistema. UML ha i seguenti tipi di diagrammi comportamentali:

  • Usa il diagramma dei casi
  • Diagramma di sequenza
  • Diagramma di comunicazione
  • Diagramma grafico di stato
  • Diagramma delle attività
  • Panoramica delle interazioni
  • Diagramma di sequenza temporale

La tabella seguente fornisce una breve descrizione di questi diagrammi:

Sr.No. Diagramma e descrizione
1

Use case

Descrive le relazioni tra le funzionalità e i loro controllori interni / esterni. Questi controller sono noti come attori.

2

Activity

Descrive il flusso di controllo in un sistema. Consiste di attività e collegamenti. Il flusso può essere sequenziale, simultaneo o ramificato.

3

State Machine/state chart

Rappresenta il cambiamento di stato guidato dagli eventi di un sistema. Fondamentalmente descrive il cambiamento di stato di una classe, interfaccia, ecc. Utilizzato per visualizzare la reazione di un sistema da fattori interni / esterni.

4

Sequence

Visualizza la sequenza di chiamate in un sistema per eseguire una funzionalità specifica.

5

Interaction Overview

Combina diagrammi di attività e sequenza per fornire una panoramica del flusso di controllo del sistema e del processo aziendale.

6

Communication

Uguale al diagramma di sequenza, tranne per il fatto che si concentra sul ruolo dell'oggetto. Ogni comunicazione è associata a un ordine di sequenza, numero più i messaggi passati.

7

Time Sequenced

Descrive le modifiche in base ai messaggi di stato, condizione ed eventi.

Modello di visualizzazione dell'architettura

Un modello è una descrizione completa, di base e semplificata dell'architettura software composta da più viste da una particolare prospettiva o punto di vista.

Una vista è una rappresentazione di un intero sistema dal punto di vista di un insieme correlato di preoccupazioni. Viene utilizzato per descrivere il sistema dal punto di vista di diversi stakeholder come utenti finali, sviluppatori, project manager e tester.

4 + 1 Visualizza modello

Il modello di visualizzazione 4 + 1 è stato progettato da Philippe Kruchten per descrivere l'architettura di un sistema ad alta intensità di software basato sull'uso di visualizzazioni multiple e simultanee. È unmultiple viewmodello che affronta le diverse caratteristiche e preoccupazioni del sistema. Standardizza i documenti di progettazione del software e rende il progetto facilmente comprensibile da tutte le parti interessate.

È un metodo di verifica dell'architettura per studiare e documentare la progettazione dell'architettura del software e copre tutti gli aspetti dell'architettura del software per tutte le parti interessate. Fornisce quattro viste essenziali:

  • The logical view or conceptual view - Descrive il modello a oggetti del progetto.

  • The process view - Descrive le attività del sistema, cattura gli aspetti di concorrenza e sincronizzazione del progetto.

  • The physical view - Descrive la mappatura del software sull'hardware e ne riflette l'aspetto distribuito.

  • The development view - Descrive l'organizzazione o la struttura statica del software nel suo sviluppo dell'ambiente.

Questo modello di visualizzazione può essere esteso aggiungendo un'altra visualizzazione chiamata scenario view o use case viewper utenti finali o clienti di sistemi software. È coerente con altre quattro viste e viene utilizzata per illustrare l'architettura che funge da vista "più una", modello di vista (4 + 1). La figura seguente descrive l'architettura del software utilizzando il modello di cinque viste simultanee (4 + 1).

Perché si chiama 4 + 1 invece di 5?

Il use case viewha un significato speciale in quanto descrive in dettaglio i requisiti di alto livello di un sistema mentre altre vedono i dettagli: come vengono realizzati tali requisiti. Quando tutte le altre quattro visualizzazioni sono state completate, è effettivamente ridondante. Tuttavia, tutte le altre visualizzazioni non sarebbero possibili senza di essa. L'immagine e la tabella seguenti mostrano in dettaglio la visualizzazione 4 + 1 -

Logico Processi Sviluppo Fisico Scenario
Descrizione Mostra il componente (Oggetto) del sistema e la loro interazione Mostra i processi / le regole del flusso di lavoro del sistema e il modo in cui questi processi comunicano, si concentra sulla visualizzazione dinamica del sistema Fornisce viste dei blocchi predefiniti del sistema e descrive l'organizzazione statica dei moduli del sistema Mostra l'installazione, la configurazione e la distribuzione dell'applicazione software Mostra che il progetto è completo eseguendo la convalida e l'illustrazione
Visualizzatore / titolare della posta Utente finale, analisti e designer Integratori e sviluppatori Programmatore e project manager software Ingegnere di sistema, operatori, amministratori di sistema e installatori di sistema Tutti i punti di vista delle loro opinioni e dei valutatori
Ritenere Richieste funzionali Requisiti non funzionali Organizzazione del modulo software (riutilizzo della gestione del software, vincolo degli strumenti) Requisito non funzionale relativo all'hardware sottostante Coerenza e validità del sistema
UML - Diagramma Classe, Stato, Oggetto, sequenza, Diagramma di comunicazione Diagramma di attività Componente, diagramma del pacchetto Diagramma di distribuzione Usa il diagramma dei casi

Linguaggi di descrizione dell'architettura (ADL)

Un ADL è un linguaggio che fornisce sintassi e semantica per la definizione di un'architettura software. Si tratta di una specifica di notazione che fornisce funzionalità per modellare l'architettura concettuale di un sistema software, distinta dall'implementazione del sistema.

Gli ADL devono supportare i componenti dell'architettura, le loro connessioni, interfacce e configurazioni che sono l'elemento costitutivo della descrizione dell'architettura. È una forma di espressione da utilizzare nelle descrizioni dell'architettura e fornisce la capacità di scomporre i componenti, combinare i componenti e definire le interfacce dei componenti.

Un linguaggio di descrizione dell'architettura è un linguaggio di specifica formale, che descrive le funzionalità del software come processi, thread, dati e sottoprogrammi, nonché componenti hardware come processori, dispositivi, bus e memoria.

È difficile classificare o differenziare un ADL e un linguaggio di programmazione o un linguaggio di modellazione. Tuttavia, ci sono i seguenti requisiti per classificare una lingua come ADL:

  • Dovrebbe essere appropriato per comunicare l'architettura a tutte le parti interessate.

  • Dovrebbe essere adatto per attività di creazione, perfezionamento e convalida dell'architettura.

  • Dovrebbe fornire una base per un'ulteriore implementazione, quindi deve essere in grado di aggiungere informazioni alla specifica ADL per consentire di derivare la specifica del sistema finale dall'ADL.

  • Dovrebbe avere la capacità di rappresentare la maggior parte degli stili architettonici comuni.

  • Dovrebbe supportare capacità analitiche o fornire implementazioni di prototipi di generazione rapida.