Tecniche di architettura

Approccio iterativo e incrementale

È un approccio iterativo e incrementale composto da cinque fasi principali che aiuta a generare soluzioni candidate. Questa soluzione candidata può essere ulteriormente perfezionata ripetendo questi passaggi e infine creare un progetto di architettura che si adatti al meglio alla nostra applicazione. Alla fine del processo, possiamo rivedere e comunicare la nostra architettura a tutte le parti interessate.

È solo un possibile approccio. Esistono molti altri approcci più formali che definiscono, riesaminano e comunicano la propria architettura.

Identificare l'obiettivo dell'architettura

Identificare l'obiettivo dell'architettura che forma l'architettura e il processo di progettazione. Obiettivi impeccabili e definiti enfatizzano l'architettura, risolvono i giusti problemi nella progettazione e aiutano a determinare quando la fase corrente è stata completata e pronti per passare alla fase successiva.

Questo passaggio include le seguenti attività:

• Identifica i tuoi obiettivi di architettura all'inizio.
• Identifica il consumatore della nostra architettura.
• Identifica i vincoli.

Esempi di attività di architettura includono la creazione di un prototipo per ottenere feedback sull'interfaccia utente di elaborazione degli ordini per un'applicazione Web, la creazione di un'applicazione di tracciamento degli ordini del cliente e la progettazione dell'autenticazione e dell'architettura di autorizzazione per un'applicazione al fine di eseguire una revisione della sicurezza.

Scenari chiave

Questo passaggio pone l'accento sul design che conta di più. Uno scenario è una descrizione ampia e esauriente dell'interazione di un utente con il sistema.

Gli scenari chiave sono quelli considerati gli scenari più importanti per il successo della tua applicazione. Aiuta a prendere decisioni sull'architettura. L'obiettivo è raggiungere un equilibrio tra gli obiettivi dell'utente, dell'azienda e del sistema. Ad esempio, l'autenticazione dell'utente è uno scenario chiave perché sono un'intersezione di un attributo di qualità (sicurezza) con funzionalità importanti (come un utente accede al sistema).

Panoramica dell'applicazione

Crea una panoramica dell'applicazione, che renda l'architettura più tangibile, collegandola a vincoli e decisioni del mondo reale. Consiste delle seguenti attività:

Identifica il tipo di applicazione

Identifica il tipo di applicazione se si tratta di un'applicazione mobile, un rich client, un'applicazione Internet avanzata, un servizio, un'applicazione web o una combinazione di questi tipi.

Identificare i vincoli di distribuzione

Scegli una topologia di distribuzione appropriata e risolvi i conflitti tra l'applicazione e l'infrastruttura di destinazione.

Identificare importanti stili di progettazione dell'architettura

Identifica importanti stili di progettazione dell'architettura come client / server, a strati, bus di messaggi, progettazione guidata dal dominio, ecc. Per migliorare il partizionamento e promuovere il riutilizzo del progetto fornendo soluzioni a problemi ricorrenti. Le applicazioni useranno spesso una combinazione di stili.

Identifica le tecnologie rilevanti

Identifica le tecnologie rilevanti considerando il tipo di applicazione che stiamo sviluppando, le nostre opzioni preferite per la topologia di distribuzione dell'applicazione e gli stili architettonici. La scelta delle tecnologie sarà anche diretta dalle politiche dell'organizzazione, dai limiti dell'infrastruttura, dalle competenze sulle risorse e così via.

Problemi chiave o hotspot chiave

Durante la progettazione di un'applicazione, gli hot spot sono le zone in cui vengono commessi più spesso gli errori. Identifica i problemi chiave in base agli attributi di qualità e alle preoccupazioni trasversali. I potenziali problemi includono la comparsa di nuove tecnologie e requisiti aziendali critici.

Gli attributi di qualità sono le caratteristiche generali dell'architettura che influenzano il comportamento in fase di esecuzione, la progettazione del sistema e l'esperienza dell'utente. Le preoccupazioni trasversali sono le caratteristiche del nostro design che possono essere applicate a tutti i livelli, componenti e livelli.

Queste sono anche le aree in cui vengono commessi più spesso errori di progettazione ad alto impatto. Esempi di problemi trasversali sono l'autenticazione e l'autorizzazione, la comunicazione, la gestione della configurazione, la gestione delle eccezioni e la convalida, ecc.

Soluzioni candidate

Dopo aver definito gli hotspot chiave, costruire l'architettura di base iniziale o il primo progetto di alto livello e quindi iniziare a compilare i dettagli per generare l'architettura candidata.

L'architettura candidata include il tipo di applicazione, l'architettura di distribuzione, lo stile architettonico, le scelte tecnologiche, gli attributi di qualità e le preoccupazioni trasversali. Se l'architettura candidata è un miglioramento, può diventare la linea di base da cui creare e testare nuove architetture candidate.

Convalida la progettazione della soluzione candidata rispetto agli scenari chiave e ai requisiti già definiti, prima di seguire iterativamente il ciclo e migliorare il progetto.

Potremmo utilizzare i picchi architettonici per scoprire le aree specifiche del progetto o per convalidare nuovi concetti. I picchi architettonici sono un prototipo di progettazione, che determinano la fattibilità di uno specifico percorso di progettazione, riducono il rischio e determinano rapidamente la fattibilità di approcci diversi. Testa i picchi architettonici rispetto a scenari e hotspot chiave.

Revisione dell'architettura

La revisione dell'architettura è il compito più importante per ridurre il costo degli errori e per trovare e risolvere i problemi architettonici il prima possibile. È un modo consolidato ed economico per ridurre i costi del progetto e le possibilità di fallimento del progetto.

• Rivedere l'architettura frequentemente in occasione delle principali tappe del progetto e in risposta ad altre modifiche architettoniche significative.

• L'obiettivo principale di una revisione dell'architettura è determinare la fattibilità delle architetture di base e candidate, che verificano correttamente l'architettura.

• Collega i requisiti funzionali e gli attributi di qualità con la soluzione tecnica proposta. Aiuta anche a identificare i problemi e riconoscere le aree di miglioramento

Le valutazioni basate su scenari sono un metodo dominante per la revisione di un progetto di architettura che si concentra sugli scenari che sono più importanti dal punto di vista aziendale e che hanno il maggiore impatto sull'architettura. Di seguito sono riportate le metodologie di revisione comuni:

Metodo di analisi dell'architettura software (SAAM)

È stato originariamente progettato per valutare la modificabilità, ma in seguito è stato esteso per la revisione dell'architettura rispetto agli attributi di qualità.

Metodo di analisi del compromesso dell'architettura (ATAM)

È una versione raffinata e migliorata di SAAM, che rivede le decisioni architettoniche rispetto ai requisiti degli attributi di qualità e al modo in cui soddisfano particolari obiettivi di qualità.

Active Design Review (ADR)

È più adatto per architetture incomplete o in fase di sviluppo, che si concentrano maggiormente su una serie di problemi o su singole sezioni dell'architettura alla volta, piuttosto che eseguire una revisione generale.

Revisioni attive di progetti intermedi (ARID)

Combina l'aspetto ADR della revisione dell'architettura in corso con un focus su una serie di questioni e l'approccio ATAM e SAAM della revisione basata su scenari incentrata sugli attributi di qualità.

Metodo di analisi costi-benefici (CBAM)

Si concentra sull'analisi dei costi, dei vantaggi e delle implicazioni di pianificazione delle decisioni architetturali.

Analisi della modificabilità a livello di architettura (ALMA)

Stima la modificabilità dell'architettura per i sistemi informativi aziendali (BIS).

Metodo di valutazione dell'architettura familiare (FAAM)

Stima le architetture della famiglia dei sistemi informativi per l'interoperabilità e l'estensibilità.

Comunicare l'architettura Design

Dopo aver completato la progettazione dell'architettura, dobbiamo comunicare la progettazione alle altre parti interessate, che includono il team di sviluppo, gli amministratori di sistema, gli operatori, i titolari di aziende e altre parti interessate.

Esistono diversi metodi ben noti per descrivere l'architettura ad altri: -

Modello 4 + 1

Questo approccio utilizza cinque viste dell'architettura completa. Tra questi, quattro visualizzazioni (illogical view, il process view, il physical view, e il development view) descrivono l'architettura da diversi approcci. Una quinta visualizzazione mostra gli scenari e i casi d'uso del software. Consente agli stakeholder di vedere le caratteristiche dell'architettura che li interessano specificamente.

Architecture Description Language (ADL)

Questo approccio viene utilizzato per descrivere l'architettura del software prima dell'implementazione del sistema. Affronta le seguenti preoccupazioni: comportamento, protocollo e connettore.

Il vantaggio principale di ADL è che possiamo analizzare l'architettura per completezza, coerenza, ambiguità e prestazioni prima di iniziare formalmente l'uso del progetto.

Modellazione agile

Questo approccio segue il concetto che "il contenuto è più importante della rappresentazione". Assicura che i modelli creati siano semplici e di facile comprensione, sufficientemente accurati, dettagliati e coerenti.

I documenti del modello agile si rivolgono a clienti specifici e soddisfano gli sforzi di lavoro di quel cliente. La semplicità del documento garantisce la partecipazione attiva degli stakeholder nella modellazione del manufatto.

IEEE 1471

IEEE 1471 è l'abbreviazione di uno standard formalmente noto come ANSI / IEEE 1471-2000, "Recommended Practice for Architecture Description of Software-Intensive Systems". IEEE 1471 migliora il contenuto di una descrizione architettonica, in particolare, dando un significato specifico al contesto, alle viste e ai punti di vista.

Linguaggio di modellazione unificato (UML)

Questo approccio rappresenta tre viste di un modello di sistema. Ilfunctional requirements view (requisiti funzionali del sistema dal punto di vista dell'utente, inclusi i casi d'uso); the static structural view(oggetti, attributi, relazioni e operazioni inclusi i diagrammi delle classi); e ildynamic behavior view (collaborazione tra oggetti e modifiche allo stato interno degli oggetti, inclusi sequenza, attività e diagrammi di stato).