Architettura del software: soluzioni del mondo reale - Andrea Saltarello Software Architect @ Managed Designs S.r.l ...

 
Architettura del software:
              soluzioni del mondo reale

Andrea Saltarello
Software Architect @ Managed Designs S.r.l.
andrea.saltarello@manageddesigns.it
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 part-
 whole 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 in-
   memory 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

                                U
                                 pd
                                   at
                                     e
IView

                                       ev
                                         en
                                           t
                         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à? ☺
Puoi anche leggere
Prossima slide ... Annulla