Architettura del software:
soluzioni del mondo reale
Andrea Saltarello
Software Architect @ Managed Designs S.r.l.
[email protected]
http://blogs.ugidotnet.org/pape
http://creativecommons.org/licenses/by-nc-nd/2.5/
Andrea Saltarello: chi era costui?
• Solution Architect @ Managed Designs S.r.l.
(http://www.manageddesigns.it)
• Presidente dello User Group Italiano .NET
(UGIdotNET – http://www.ugidotnet.org)
• Fondatore del Gruppo Italiano Utenti Solution
Architect (GUISA – http://www.guisa.org)
Agenda
•
•
•
•
Architettura: overview
Responsabilità dell’architetto
Architettura: luoghi comuni
Architettura vs. Mondo Reale
Cosa è l’Architettura?
Secondo la definizione ANSI/IEEE Std
1471-2000:
“L’organizzazione basilare di un sistema, rappresentato
dalle sue componenti, dalle relazioni che esistono tra di
loro e con l’ambiente circostante, e dai principi che
governano la sua progettazione e evoluzione."
Architettura: cosa?
L’architettura di un sistema *è* definita
durante la fase di progettazione.
L’architettura *non è* parte dell’analisi:
• l’analisi si concentra su cosa debba fare il sistema
• La progettazione si concentra su come debba
farlo
Architetto: le responsabilità
L’architetto:
• Recepisce i requisiti funzionali (emersi durante
l’analisi) e quelli non funzionali (es: HA, scalabilità,
security …)
• Effettua una analisi del rapporto costi/benefici per
determinare il miglior modo di soddisfare i requisiti,
eventualmente ricorrendo a componenti
commerciali o comunque già sviluppati
• Suddivide i grandi sistemi in (layer di) sottosistemi
individualmente assegnabili ad uno sviluppatore o
ad un gruppo di lavoro
• Genera “specifiche”: sketch, modelli o prototipi per
comunicare al gruppo di lavoro le modalità di
realizzazione
Architettura: luoghi comuni
• Architetto != Analista
• Architetto != Project Manager
• Architetto : Developer
– http://blogs.msdn.com/ramkoth/archive/2006/03/14/550363.aspx
• Architettura != Design
– Al limite… Design ∈ Architettura
Architettura vs. Mondo Reale
.NET Architectures in the Real World:
adottiamo come case study 3 progetti dei
quali sono l’architetto:
– GazzaTown
– Nirvana
– K2
Case Study #1: GazzaTown
https://csdev.fattorek.it/StarterSite/
http://creativecommons.org/licenses/by-nc-nd/2.5/
GazzaTown: credits
• [Realizzazione] K Group
(http://www.the-kgroup.com)
• [Sponsor] La Gazzetta dello Sport
(http://www.gazzetta.it)
• [Architettura] Managed Designs
(http://www.manageddesigns.it)
managed/designs
GazzaTown: overview
E’ la v1 del portale di commercio elettronico
de La Gazzetta dello Sport, e richiede
SLA e alta scalabilità
Deve integrarsi con il sistema gestionale del
fornitore di prodotti e servizi logistici
– Applicazione legacy
– Impossibilità pratica di modificare il codice
Possibilità di implementare i servizi in step
successivi
GazzaTown
Caratteristiche:
• Pipeline e-commerce gestita da Commerce Server 2007
• Integrazione con back-end gestita con BizTalk 2006
Pressochè totale assenza di design. In veste di
architetto, ho:
•
•
•
•
Recepito i requisiti
Scelto i sistemi da utilizzare
Specificato gli schemi XSD dei flussi dati
Scritto parte del codice per l’interfacciamento al gateway di
Banca Sella ☺
Case Study #2: Nirvana
http://creativecommons.org/licenses/by-nc-nd/2.5/
Nirvana: Credits
• [Realizzazione] Debug Software Tailoring
S.p.a. (http://www.debugswt.it)
• [Architettura] Managed Designs S.r.l.
(http://www.manageddesigns.it)
managed/designs
Nirvana: overview
E’ un tool/modeler per la realizzazione di
moduli applicativi in grado accedere e
modificare informazioni semi strutturate
memorizzate in sistemi diversi ed
incompatibili, e di visualizzarli su differenti
dispositivi di layout
E’ in grado di creare soluzioni basate su
moduli realizzati in modalità WYSIWIG,
abbattendo i tempi ed i costi propri delle
attività di programmazione e sviluppo
tradizionale
Nirvana
Nirvana
La struttura di un documento è definita mediante
un DOM (Document Object Model), interpretato e
visualizzato mediante opportuni rendering
engine.
Nirvana fornisce un tool di modellazione
(Document Studio), e i rendering engine
necessari a permettere il consumo dei documenti
da esso prodotti mediante differenti dispositivi
(HTTP User Agent, Thick Client Win32, PDA…).
Nirvana: architettura - 1/2
L’architettura generale è
Document/View:
…The idea is that you can model your application primarily
in terms of documents to store data and provide
interface-independent operations upon it, and views to
visualise and manipulate the data. Documents know how
to do input and output given stream objects, and views
are responsible for taking input from physical windows
and performing the manipulation on the document
data…
Il DOM è un Composite [GoF, 163]
Pattern “Composite” [GoF, 163]
Compose objects into
tree structures to
represent partwhole hierarchies.
Composite lets
clients treat
individual objects
and compositions
of objects
uniformly.
Nirvana: architettura - 2/2
L’elaborazione dei documenti avviene
mediante una pipeline basata su
Chain of Responsibility [GoF, 223]
Il design di Document Studio è
idiomatico, poiché basato su
Designer/DesignerHost dedicati al
DOM (che implementa
IComponent)
Pattern “Chain of Responsibility” [GoF, 223]
Avoid coupling the sender of a request to its
receiver by giving more than one object a
chance to handle the request. Chain the
receiving objects and pass the request
along the chain until an object handles it.
Il DOM di Nirvana
Nirvana Designer Architecture 1/2
Il design è decisamente idiomatico; in
sintesi:
La superficie di disegno ospita dei designer,
ognuno dei quali è associato ad una
istanza di un controllo disegnato. I
designer intercettano le gestures
dell’utente e le ripercuotono sui controlli.
La toolbox ed i menu interagiscono con la
superficie di disegno
Nirvana Designer Architecture 2/2
Technicalities:
• La superficie di disegno è una classe derivata di
Form, ed incapsula un designer host
• Il designer host è una classe che implementa
IDesignerHost e “ospita” i designer associati ai
controlli
• Tra i designer, uno è “root”: gestisce la superficie
ed il suo rapporto con menu/toolbox, ed è una
classe che implementa IRootDesigner e
IToolboxUser. Gli altri designer sono orientati al
singolo controllo ed estendono
ComponentDesigner
• Gli elementi del composite sono associati al
proprio designer mediante l’attributo
DesignerAttribute
• La toolbox implementa IToolboxService
• Il menù implementa IMenuService
Nirvana “unleashed”
Case Study #3: K2
http://creativecommons.org/licenses/by-nc-nd/2.5/
K2: Credits
• [Architettura] Managed Designs S.r.l.
(http://www.manageddesigns.it)
• [Realizzazione] Managed Designs S.r.l.
(http://www.manageddesigns.it)
managed/designs
K2: overview
K2:
• E’ un “classico” e “banale” gestionale
• Indipendenza dal database (tecnologia e
schema fisico)
• Indipendenza dalla GUI
K2: architettura
L’applicazione si basa su un Domain Model
[P of EAA, ] la cui persistenza è gestita da
una Unit of Work [P of EAA, 184] che
incapsula un Data Mapper [P of EAA,
165]
Per agevolare il supporto a GUI eterogenee,
l’architettura del presentation layer è
basata sul pattern Model View
Presenter
Pattern “Domain Model” [P of EAA, 116]
An object model of the domain that
incorporates both behavior and data.
At its worst business logic can be very
complex. Rules and logic describe
many different cases and slants of
behavior, and it's this complexity
that objects were designed to work
with. A Domain Model creates a web
of interconnected objects, where
each object represents some
meaningful individual, whether as
large as a corporation or as small as
a single line on an order form.
Unit of Work [P of EAA, 184]
When you're pulling data in and out of a
database, it's important to keep track of
what you've changed. Similarly you have
to insert new objects you create and
remove any objects you delete.
A Unit of Work keeps track of everything
you do during a business transaction that
can affect the database.
“Data Mapper” [P of EAA, 165]
A layer of Mappers (473) that moves data between objects and a
database while keeping them independent of each other and
the mapper itself.
The Data Mapper is a layer of software that separates the inmemory objects from the database. Its responsibility is to
transfer data between the two and also to isolate them from
each other. With Data Mapper the in-memory objects
needn't know even that there's a database present; they need
no SQL interface code, and certainly no knowledge of the
database schema. Since it's a form of Mapper, Data Mapper
itself is even unknown to the domain layer.
Data Mapper
Il Data Mapper di K2 è implementato usando
NHibernate, incapsulato nella Unit of
Work ed esposto mediante un Query
Object [P of EAA, 316]
“Query Object” [P of EAA, 316]
An object that represents a database
query.
A Query Object is an interpreter
[GoF], that is, a structure of
objects that can form itself into a
SQL query. You can create this
query by referring to classes and
fields rather than tables and
columns. In this way those who
write the queries can do so
independently of the database
schema and changes to the
schema can be localized in a
single place.
MVP – Passive view
Set state
Model
e
at
pd
U
t
en
ev
IView
Update view
View
Presenter
User action
•
•
•
•
Solo Presenter conosce Model
Solo Presente agisce verso Model
View è passiva (Passive View)
Model è indipendente da Presenter
K2 (reduced)
Per approfondire:
SharpDevelop è un ottimo esempio di
implementazione di un designer.
– http://www.sharpdevelop.net/OpenSource/SD/Default.a
spx
Il Northwind Starter Kit è una
applicazione open source con architettura
analoga a K2
http://www.manageddesigns.it/OpenSource.aspx
UGIdotNET web site (Special guest)
Link:
• GUISA: http://www.guisa.org
• Wiki UGIdotNET: http://wiki.ugidotnet.org
• MSDN Architecture Center:
http://www.microsoft.com/italy/msdn/riso
rsemsdn/architetti/default.mspx
Dubbi/Domande/Curiosità? ☺
