Che cos'è un'architettura software e come rappresentarla?

Esistono molte definizioni per ciò che è un'architettura software. Il Software Engineering Institute ha una raccolta di definizioni di architettura software che include definizioni bibliografiche tratto da documenti e articoli nel database SEI, definizioni pubblicate prese da vari libri e altri scritti, definizioni classiche di opere più importanti o influenti, definizioni moderne di opere più recenti e definizioni fornite dalla comunità.

Non esiste una definizione corretta, ma tendo a favorire quelli che menzionano le decisioni. Sento che la definizione di Rational Unified Process cattura al meglio ciò che considero architettura:

An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition.

Sulla base di questa definizione di architettura, è necessario rappresentare tutte le decisioni importanti e le loro motivazioni, gli elementi strutturali e le interfacce di tali elementi strutturali e il modo in cui gli elementi strutturali sono composti insieme per creare sistemi più grandi.

Considererei una decisione importante come costosa (in termini di tempo, impegno o costo monetario) da cambiare. Un esempio potrebbe significare scegliere un determinato linguaggio di programmazione, mirando a un ambiente specifico (ambiente hardware, sistema operativo, dispositivi per scopi speciali), metodi di trasmissione e memorizzazione dei dati. Puoi registrare queste decisioni utilizzando qualsiasi numero di strumenti testuali o grafici, che vanno da un wiki a verbali di riunioni formali e l'uso delle matrici decisionali .

Gli elementi strutturali possono essere catturati usando qualsiasi numero di rappresentazioni. SysML e UML sono comuni. BMPN può essere utile per rappresentare i processi aziendali. Object-Process Methodology può essere utilizzato durante la fase di progettazione del sistema per acquisire gli oggetti e le azioni che compongono il sistema. Se hai un sistema pesante, il Entity-Relationship Modelling è anche utile. Io preferisco usare un linguaggio di modellazione standard e ben documentato perché (idealmente) è una cosa in meno da comunicare alle persone che la usano - chiunque non sia familiare dovrebbe essere in grado di ottenere una quantità significativa di informazioni su come comprendere la notazione di modellazione dalle fonti esistenti. Sebbene sia scritto per UML, le modalità UML di Martin Fowler possono anche essere applicate a questi altri linguaggi di modellazione formale - i tuoi modelli possono variare in fedeltà dagli schizzi ai progetti e può essere avviato prima dello sviluppo e completato dopo il fatto di mostrare le informazioni appropriate al pubblico di destinazione previsto.

Se vuoi saperne di più, ho trovato che Architettura software in pratica e Documentazione architetture software: viste e oltre sono ottime risorse per comprendere il processo di creazione, manutenzione e documentazione dell'architettura dei sistemi software.

Architettura significa "scatole grandi" che compongono la tua applicazione e come queste interagiscono tra loro per far funzionare l'applicazione. Poiché queste "scatole" sono specifiche per ogni progetto, non esiste una definizione universalmente accettata di architettura software applicabile a tutti i progetti (ciò che è buono per l'architettura software per un progetto potrebbe essere un disastro per un altro) e quindi non esiste un modo standard per rappresentarlo .

Martin Fowler ha una breve presentazione in cui parla di cosa sia l'architettura software, in termini di caratteristiche comuni: "Making Architecture Matter" (link youtube qui ).

Alcuni punti salienti del talk:

• l'architettura del software è ciò che è importante;
• sono le decisioni che devi prendere in anticipo;
• l'architettura riguarda la qualità interna che non può essere scambiata per il costo (o finirai per perdere a lungo andare perché una cattiva architettura rende difficile aggiungere nuove funzionalità che rendono il tuo prodotto competitivo);
• sono le decisioni che sono difficili da cambiare;

cos'è l'architettura software?

L'architettura software è la struttura di livello superiore di un sistema, ovvero la modalità scelta per decomporsi software nei suoi elementi costitutivi e per tenere insieme i pezzi.

Ecco una bella citazione del libro di Martin Fowler " Patterns of enterprise application architecture ":

Architecture is a term that lots of people try to define, with little agreement. There are two common elements: one is the highest level breakdown of a system into its parts; the other, decision that are hard to change.

Esempio di architetture

Al livello più alto, l'architettura è spesso rappresentata con i suoi strati e i confini con il mondo esterno. Esempio:

• architettura pulita di Martin
• L' architettura esagonale di Cockburn
• livelli di origine dei dati del dominio di presentazione di Fowler
• e un sacco di altri livelli di approccio

Come rappresentare l'architettura?

Come l'architettura di edifici con diverse sfaccettature (es. rappresentazione volumetrica dell'edificio nel suo ambiente, vista generale della facciata dell'edificio, progetto di ogni piano, ecc ...), l'architettura del software gestisce anche viste differenti sullo stesso sistema .

Ti aiuto, c'è UML. Al livello più alto:

• il sistema nel suo ambiente è rappresentato con un caso d'uso di alto livello : questo mostra i confini, le funzioni principali e la relazione con attori esterni (umani o altri sistemi)
• i blocchi predefiniti possono essere rappresentati con un diagramma dei componenti
• un diagramma di implementazione può dare una panoramica di come i componenti possono essere distribuiti nel software ambiente
• diagrammi a struttura composita, per mostrare la struttura interna di un componente.

Man mano che i livelli diventano più dettagliati, gradualmente il campo dell'architettura finirà nel design, usando diagrammi di classe, diagrammi di sequenza, diagrammi di attività e diagrammi di comunicazione.

L'architettura è la parte di un sistema che è impossibile cambiare senza ricominciare da capo.

In altre parole, quelle parti che sono davvero costose da cambiare.

Questo significa che la progettazione di un sistema può essere l'architettura di un altro sistema e viceversa.

Ad esempio, se credi in 3 livelli e metti tutte le cose che contano nel livello aziendale, considerando il tuo database come un semplice contenitore di file e colonne che dovrebbe essere facilmente sostituibile, l'RDBMS non farà parte di la tua architettura.

D'altro canto, se si considerano i dati come la parte centrale del proprio sistema, con le applicazioni che sono solo degli stupidi strumenti che potrebbero richiedere set di risultati una volta che sono stati autenticati e autorizzati, è probabile che l'RDBMS diventi la vostra architettura e il tuo stupido jolly totalmente sostituibile o qualsiasi componente client non lo sarà.