architettura software

Parlare di architettura software ha senso solo quando si tratta di capire il livello di servizio richiesto e dare risposte misurabili ai requisiti. Tutto il resto è fuffa, sostiene Tom Gilb in questo video.

In ogni processo di sviluppo software pragmatico, requisiti e architettura evolvono insieme.

"The Twin Peaks of Requirements and Architecture" è il tema centrale del numero di marzo / aprile 2013 di IEEE Software.

Gli aspetti "non funzionali" di un sistema software, come le prestazioni, i carichi e i volumi da sostenere, la sicurezza, l'usabilità, hanno un'importanza che viene spesso sottostimata.
L'attenzione dei progetti si concentra soprattutto sulle funzionalità, mentre le altre caratteristiche sono trascurate o definite in modo generico sia dagli stakeholder che dagli analisti IT.

Questa disattenzione è rischiosa, perché sono proprio gli aspetti non funzionali (o "attributi di qualità", come vengono chiamati negli ultimi anni) a influenzare e condizionare le scelte architetturali. E quando non vengono presi in considerazione all'inizio possono poi portare a scelte architetturali sbagliate, molto onerose da modificare quando i progetti sono in stato avanzato di sviluppo.

"Functionality and capability are critically important, but the architecture must be driven by the quality attributes. Specifying and addressing quality attributes early and evaluating the architecture to identify risks is key to success", come afferma Mike Gagliardi in un recente webinar del Software Engineering Institute, Architecting in a Complex World.

Use of Architecture Centric Engineering for Improving a Software System, ottimo webinar gratuito offerto dal Software Engineeering Institute (SEI) e tenuto da Felix Bachmann, uno degli autori di Documenting Software Architectures.

Bachmann sottolinea nel webinar l'utilità degli strumenti di modellazione e di UML per la progettazione architetturale. Ma soprattutto affronta in modo persuasivo il tema di come valutare e confrontare le diverse ipotesi di design.

Le architetture orientate ai servizi (Service Oriented Architecture: SOA) sono state un tema centrale nel campo dello sviluppo software negli ultimi anni.

Un articolo recente su IEEE Software July/August 2012, Service-Oriented Architectures: Myth or Reality?, di Haresh Luthria e Fethi A. Rabhi, esplora esperienze reali di applicazione dei principi SOA evidenziando luci e ombre.

Le conclusioni degli autori:

"Most of the available literature on SOA is broadly optimistic, leading potential users to mistakenly assume that moving to it is a relatively small step. This general misconception was well captured by the application architect for one firm in our study. Talking about the academic viewpoint and his business team's expectations for SOA, he said, "They think, 'Buy SOA, and you're set. All your problems will be solved.' This is not so."

We aren't suggesting that SOA isn't all that it's made out to be. In fact, the analytical arguments promoting it are quite sound in describing its potential benefits. But there are some constraints and issues associated with its implementation. SOA neither exacerbates nor alleviates the lack of proper systems engineering, project management, and program governance. Potential users shouldn't assume that the burden of such discipline can be eschewed just because the processes have been defined as granular services. SOA is an approach to building business systems that requires significant investment in process management and governance mechanisms for the service life cycle, and it might not necessarily be an instant solution to all an enterprise's business problems."

Software Architecture cheat sheet, di Jacob Gorban.

Utile.

Il termine analisi viene dal greco antico. "Ana" è ciò che sta sopra.
"Lisi" è lo scioglimento, la scomposizione. La scomposizione di ciò che
sta sopra.

"Ciò che sta sopra" è il problema da risolvere, oppure l'oggetto da
esaminare. Considerato, in partenza, nella sua globalità, come un
tutt'uno. Una scatola nera.

Compito dell'analisi è capire le caratteristiche dell'oggetto esaminato,
trasformarlo da opaco (la scatola nera) in trasparente, rivelando gli
elementi da cui è composto. Ad esempio, se esaminiamo un processo,
individuando le attività che lo costituiscono. Se esaminiamo un sistema,
individuandone le parti. Scomponendo.

L'analisi scompone il proprio oggetto in elementi più semplici. E se gli
elementi individuati sono ancora troppo complessi, troppo a "grana
grossa", si può analizzarli a loro volta, scomponendoli, fino a
individuare elementi a "grana fine", semplici quanto basta. Un sistema
viene scomposto in sottosistemi, un sottosistema in componenti, un
componente in moduli, e così via, fino al punto in cui riteniamo che non
valga la pena di scomporre ulteriormente.

Quando usiamo la lingua inglese, chiamiamo questo procedimento
"top-down". Di nuovo, come in greco antico, "scomposizione di ciò che è
sopra".

Ma come bisogna scomporre? O meglio, esiste un modo giusto, corretto,
per effettuare la scomposizione (l'analisi)? Un unico modo?

No. Ogni oggetto da analizzare può, anzi deve essere esaminato da
diversi punti di vista. Secondo diverse tecniche.

Ad esempio, in linguistica, una frase può essere sottoposta ad analisi
grammaticale, analisi logica, analisi del periodo.

Analizzando una specifica dei requisiti per la progettazione di un
sistema, possiamo valutare il livello di coerenza, di completezza, di
precisione, eventuali aree di ambiguità.

Nelle architetture software, l'analisi può affrontare gli aspetti
strutturali (la strutturazione del sistema in parti), gli aspetti
dinamici (come le parti interagiscono tra loro), le dimensioni di
qualità (ad esempio gli aspetti di sicurezza, di prestazioni, di
affidabilità, di usabilità).

Gli approcci più maturi e più utili a disposizione degli architetti
software, come quello delle viste architetturali "4+1" di Philippe
Krutchen, e quello del gruppo di "Documenting Software Architectures"
del Software Engineering Institute, evidenziano che l'analisi di sistemi
complessi – come quelli software - va affrontata da diversi punti di
vista, non da uno soltanto.

"Computer science focuses more on the realm of the ones and zeros, but software engineering attends to the delicious dance between the technical and the social, between the ones and zeros and the human stories.
[...] it's how we organize the humans who develop/deliver/deploy/evolve those bits that are at the heart of software engineering".

Grady Booch, "The Professional Architect", IEEE Software Jan/Feb 2012.

Forse la danza tra aspetti tecnici e aspetti umani non è sempre deliziosa, ma questa distinzione tra i due ambiti, computer science e software engineering, è precisa.

In questi giorni è in corso la più importante conferenza internazionale sulle architetture software, Saturn (SEI Architecture Technology User Network), organizzata dal Software Engineering Institute.

Tra gli interventi, una keynote di Michael Stal: Win-Win With Agile Architecture.

Prendersi cura dell'architettura, nel tempo, come se fosse un giardino. "Gardening Your Architecture" è il titolo di due articoli di Frank Buschmann su IEEE Software, July/August e September/October 2011.

Analogie e differenze tra refactoring (ristrutturazioni locali, limitate, mirate), reengineering (ristrutturazioni complessive) e rewriting (rifacimento) delle applicazioni.

In particolare vengono elencate le motivazioni per il reengineering, "an activity that protects existing core investments":
"There are four main reasons to contemplate reengineering:

• Refactoring is insufficient for achieving the required qualities.
• Bug fixes in one place repeatedly cause bugs in other places.
• New operational or functional requirements can't be realized appropriately within the given architecture.
• The business case for the system changed."

Buschmann conclude con un confronto tra le tre forme di intervento:

• "Continuously practice refactoring. It's cheap and (mostly) under the radar, and helps minimize the need for reengineering.
• Consider reengineering when refactoring doesn't help or is inappropriate. But be aware that it's expensive and requires much ritual.
• Consider rewriting when reengineering doesn't help. But know that it's often very risky."