progettazione a componenti

8/8/2019 Progettazione a componenti

1/27

1

Progettazione a componentiing. R. Turco ([email protected])

Vantaggi di una progettazione a componenti

La progettazione a componenti, collocata in una corretta metodologia (Catalysis,Design Pattern, J2EE, COTS, etc) favorisce molteplici vantaggi progettuali:

La riusabilit nei progetti Lacquistabilit di componenti di alto livello (COTS) La flessibilit al cambiamento dei requisiti La creazione di architetture SOA La sostituibilit (incapsulamento) con un altro componente Laggiornamento di un componente con nuove funzionalit La realizzazione di prodotti basati su Java, che fanno uso di componenti di alto

livello (palette ad esempio di BusinessWorks TIBCO)

Componenti che devono rispettare molte esigenze, come sopra, tendono ad avere una

astrazione molto alta ed essere general purpose (COTS); se si riducono, invece, leesigenze da rispettare, allora il componente maggiormente calato sul business che

deve realizzare in ambito architetturale.

La progettazione a componenti si basa su tutti i principi dellOO vista in[DR2][DR3][DR4][DR5][DR8] e dei Design Pattern vista in [DR9]. Esiste una

sfumatura e/o una somiglianza tra i componenti ed i framework [DR13] ma, in questocaso, la cosa dipende molto da cosa si intende per componente, come vedremo in

seguito; in certi casi le due cose coincidono.

La progettazione dei componenti indipendente dalla tecnologia.

I tre principi elementari su cui poggiano i componenti sono:

Specifiche di interfaccia: Un componente un macro-oggetto con una specificadi interfaccia (pubblica) e una specifica di comportamento (privata), che agiscesu classi, metodi e dati, ed nascosta limplementazione, gli oggetti/classi, le
mailto:[email protected]:[email protected]:[email protected]:[email protected]


2/27

2

librerie, i file, la dislocazione di ogni partecipante al componente etc. In

sostanza di un componete nota la specifica di interfaccia o contratto duso e

cosa far o restituir.

Incapsulamento: Il client che chiama il componente dipende solo dalla specificadi interfaccia di questultimo e non deve interessarsi (n lo sa) come avviene ilfunzionamento interno al componente (memorizzazione dati in strutture dati,

metodi privati etc)

Identit: Il componente ha una identit unica indipendentemente dallo statointerno.

I tre principi di sopra consentono di:

lavorare in termini Object Oriented rendere indipendenti i client dal componente fisico favorire la sostituibilit o laggiornamento di un componente a parit di

interfaccia con minimo impatto dei client

Cosa si intende per componente?

Da un punto di vista teorico-progettuale (disegno) semplice parlare di un

componente logico: un insieme di classi correlate e cooperanti che forniscono unservizio finito; ma se si vuole comprendere cosa un componente fisico va

innanzitutto calato il discorso nella tecnologia da usare e nello standard in essadefinito per componenti.

In Java e in ambito J2EE, i componenti fisici sono degli EJB (Enterprise Java Beans)che possono essere sottoposti a deploying tramite un impacchettamento fisico

denominato EAR. SullEAR intervengo problemi di progettazione di impacchettamento

e deploying che sono diversi da quelli che individuano i componenti; difatti per gli EARsono importanti i problemi di building e Package coupling (vedi [DR8]). In J2EE,

attraverso lo studio dei J2EE Design Pattern (rielaborazione Java dei Design

Pattern), si comprende come progettare e organizzare gli EJB, che possono essere divari tipi: Session Bean, Entity Bean, Message Driven Bean, da usare secondo le

esigenze progettuali. Per essi lo standard la specifica EJB 3.0 che ha semplificatonotevolmente la implementazione degli EJB rendendo lo sviluppo pi semplice e snello.

In ambito Microsoft i COM+ sono dei componenti, che rispettano lo standard COM+.

In Tibco, ad esempio, una paletta in BusinessWorks un componente di basso livello e

general purpose.

Anche un servizio SOA un componente, che rispetta lo standard in uso dei Web

Service, WSDL etc.


3/27

3

Un componente fisico, per, pu essere di livello anche pi basso: pu essere una

libreria di oggetti compilati da riusare, un file di configurazione XML comune a pi

applicazioni, un file risorse DEV da aggiungere al compilatore nel progetto (vedi Dev-C++, Visual C++ etc), un framework da riusare in pi progetti (Struts, Spring, AOP,

JADE, etc) etc.

Da qui si comprende che i componenti fisici si presentano a due livelli logici:

alto livello, dove il componente ha quasi un aspetto strutturale/architetturalenel progetto e le caratteristiche che lo contraddistinguono sono

essenzialmente lauto-consistenza e la possibilit di essere sottoposto a run

basso livello, il componente ha un aspetto di risorsa, di framework, di libreria aoggetti (non eseguibile), un file di configurazione e le caratteristiche che lo

contraddistinguono sono uno scopo general purposee limpossibilit di essere

sottoposto a run

In quale layer del sistema sono usabili i componenti?I componenti sono i mattoni di base di una architettura e possono essere usati in:

Graphical User Interface (GUI)/ Web Front-end layer Back-end layer Db layer.

Essi possono interagire tra loro e con altri componenti built-in come le Topic, le JMS,le Queue etc.

In ognuno dei layer suddetti un componente pu fornire due tipi di servizi:

Servizi di sistema, soddisfacendo requisiti non funzionali ma necessariallarchitettura, allusabilit/fruibilit del sistema, alla robustezza, etc.

Servizi di businessStati di un componente

Un componente pu trovarsi in varie fasi del suo ciclo di vita: fase progettuale: si dispone solo della specifica di interfaccia ed ancora un

componente logico

fase implementativa: si dispone di un componente fisico implementato fase di running: sulla macchina si dispone di una istanza attiva del componente

fisico o parte di essa sollecitata

fase di testing: si dispone di un componente fisico sottoponibile a run e testato fase di deploying: il componente fisico testato stato installato


4/27

4

Architetture di componenti

Un componente pu riusare i servizi di altri componenti, incapsulandone il

funzionamento. Ad esempio questo oggi un punto di forza dellunione dei concettiBPM e SOA.

Contratto duso

Anche quando si implementa in C, un grande progetto importante suddividere levarie parti e parallelizzare su pi persone, che poi devono riuscire in breve a integrare

il tutto.

Il componente o i componenti seguono la stessa idea di base: sufficiente che siano

ben definite le specifiche di interfaccia o contratto duso. Questo un elemento

chiave per una corretta e rapida integrazione tra il componente ed i suoi client.

Le specifiche di interfaccia prevedono:

Operazioni:

operazioni possibili da chiamare (prototipi, tipi e definizioni) e in che modo pre-condizioni da rispettare prima della chiamata per non ricevere errore post-condizioni da rispettare lato componente, cosa valorizza come dati a

seguito delloperazione

valori di ritorno in caso di errore o di normale funzionamentoModello delle informazioni:

la definizione dei vincoli da rispettare la definizione di tutte le informazioni da scambiare la definizione dello stato che viene memorizzato o meno tra una chiamata e la

successiva di uno stesso client

Il contratto duso definito in fase di analisi/progettazione che nellObject Oriented

sono fortemente unite, ma usato a run-time tra client e componente.

Contratto di realizzazione

Il contratto di realizzazione usato tra la fase di progettazione e implementazionesoltanto. Da le informazioni agli sviluppatori per poter realizzare il componente.

UML e livelli di modellazione dei componenti

NellUML quando si realizza un modello che coinvolge un componente esistono almenotre livelli di modellizzazione:

modello concettuale del componente, dove entrano in gioco solo i concetti di altolivello del dominio di interesse

modello di specifica, dove si introducono le specifiche di interfaccia; avendocio pi una visibilit dellesterno del componente


5/27

5

modello di implementazione, dove si introducono i dettagli implementativiinterni del componente

E da sottolineare che in questa modellazione top-down, una volta arrivati al livello di

specifica, individuato i componenti, le classi etc, si pu lavorare a dare flessibilit alprogetto esaminando la possibilit di far introdurre i Design Part e rispettare tutti i

migliori principi dellObject Oriented.

Processo di sviluppo

I componenti rientrano nei processi Rational Unified Process (RUP), ExtremeProgramming (XP), Catalysis etc, ma, qualunque sia il processo scelto, lobiettivo di

rispettare ed esaltare le necessit progettuali dei componenti, per poter ottenere la

massima peculiarit possibile secondo le migliori Best Practices dellObject

Oriented.

Nel seguito seguiamo i suggerimenti del processo Catalysis, che un processo confocus sui componenti, che lavora a tre livelli di modellazione.

Qualunque sia il processo usato, Catalysis suggerisce che abbiamo sempre la necessit

di disporre di macro-task di lavorazionee allinterno di ognuno di essi devono esisteredei workflow(insieme di task) capaci di farci produrre dei manufatti o degli elaborati

finiti e nella fattispecie componenti secondo le migliori Best Practices.

Per la realizzazione di componenti chiaramente consigliato un metodo top-down,

partendo dallarchitettura dei componenti fino a giungere alle classi necessarie.

Per i componenti avremo la necessit dei seguenti Macro-Task:


6/27

6

Requisiti, con un workflow Definizione dei requisiti Specifica, dove avremo tre sotto-task e tre workflow che li gestiscono:

o Identificazione dei componentio Interazione tra componentio Specifica dei componenti

Provisioning Integrazione

Catalysis esprime ci graficamente nella figura successiva.

In tutte le fasi di lavorazione molto importante disporre di strumenti RAD a

supporto di tutti le fasi della metodologia, compresa limplementazione; strumentiovviamente calati sul tipo di tecnologia necessaria a realizzare i componenti: ad

esempio Eclipse o NetBeans per Java NetBeans, Rational Rose per C++/Java, Modeler

Tibco per Tibco, BusinessStudio Tibco, etc.

Sebbene ci aspettavamo vari tipi di macro-task, chiariamo subito che Provisioning pu

significare varie cose:

Acquistare il componente software sul mercato Farsi sviluppare il componente software da un vendor Farsi prestare da un altro progetto, in base ad un catalogo aziendale, il

componente che ci interessa e che versionato su uno strumento come SVN,

PCS, CVS, RCS, etc

Il cuore della metodologia per la progettazione del componente il macro-Task dellaSpecificache dettaglieremo nel seguito attraverso un esempio; ma che tuttavia benamalgamata n pu far a meno degli altri macro-Task e dei ricicli che possono nascere.


7/27

7

Processo di gestione

Il processo di gestione nel ciclo produttivo deve sempre prevedere i futuricambiamenti di requisiti, in base alla conoscenza del business della propria azienda, e

mitigare in fase di progettazione i cambiamenti previsti in modo da ridurre gli impattidi realizzazione e manutenzione futuri: in altri termini gestire per anticipare il

cambiamento. Il processo di gestione deve anticipare anche le esigenze diProvisioning.

Macro-Task Requisiti

Il workflow Definizione dei requisiti realizzabile in ambito UML con:

Una descrizione testuale del requisito/processo (obbligatorio) Un activity diagram, per vedere come si comporta il processo di business e le

responsabilit da attribuire agli attori e le automatizzazioni possibili delprocesso

Un class diagram come modello concettuale del business Use case, non sono strettamente necessari

Si lavora a due livelli:

Fase concettuale di alto livello Fase di raffinamento

Ognuno degli strumenti di sopra serve a dare un visione alternativa e utile ed ognunodeve essere usato solo se utile o se la situazione complessa e va dettagliata. Siritiene obbligatoria la descrizione testuale del requisito.

Facciamo adesso un esempio, che faccia da guida sulla progettazione dei componenti,su cui applicheremo concetti OO e di UML che riterremo gi noti e con cui il lettore,

attraverso i riferimenti, pu familiarizzarsi.

Supponiamo che il proprietario di un albergo ci chieda di descrivere e documentare,

come processo di business, le fasi di prenotazione di una camera dalbergo, per poidecidere insieme la creazione di un sistema software.

Descrizione testuale del processo: il processo innescato da un cliente, che descriveil tipo di camera desiderata. Si verifica prima la disponibilit e se la camera disponibile si effettua la prenotazione. Una e-mail inoltrata al cliente descriver tutti

i dettagli della prenotazione. A seguito di questo si possono verificare i seguentieventi:

Il cliente viene alla data prenotata Il cliente potrebbe cancellare la prenotazione


8/27

8

Il cliente potrebbe chiedere una modifica della prenotazione e una nuovo inoltrodella e-mail

Il cliente non si presenta alla data prenotata

Sia che il cliente si presenta o no, c un pagamento (una penale nel secondo caso).

Un activity diagram che riassume graficamente la descrizione testuale presentatonella figura seguente.

A questo punto serve esprimere i concetti di business coinvolti e quindi occorre un

modello concettuale che rappresentiamo come nella figura successiva.


9/27

9

Fin qui abbiamo applicato le solite fasi di analisi dei requisiti tipiche dellOO e

dellUML.

Come si vede dai diagrammi precedenti sono stati individuati solo i concetti, non cdefinizione di interfacce, metodi, dati, responsabilit che sono da individuare nella

fase di raffinamento che vediamo di seguito.

Fase di raffinamento dei requisiti

In questa fase spesso va aggiunta anche la parte non funzionale dei requisiti (basta

solo modificare o serve ad esempio anche cancellare?). In fase di raffinamento vannoaggiunte anche note su un processo come manuale e automatico, e responsabilit

di mettendo lattore coinvolto.


10/27

10

Nella figura di sopra abbiamo individuato le responsabilit con delle swimlane; ovvero

aree diverse di competenza degli attori. Con sistema abbiamo inteso unareapossibile di automatizzazione. Si poteva scegliere anche diversamente cosa

automatizzare: dipende dal finanziatore innanzitutto e dove possiamo rendere pi

rapido e semplice il lavoro dellalbergo.

Nella fase di raffinamento possono sbucare altre esigenze, inizialmente nascoste, e

non funzionali: importante, in questa fase, trovare i confini dellapplicazione, gliattori in gioco, il loro ruolo e le loro relazioni.

Ad esempio un Cliente pu essere un ospite (cio una persona pagante che non un

dipendente dellalbergo). Un Addetto alle prenotazioni pu essere un dipendente ma

anche un cliente cio che prenota da Internet; per cui un Addetto alle prenotazioni un cliente o un dipendente o entrambi. Questi fa nascere il ruolo di Addetto alle

prenotazioni per tenere distinti i ruoli.

Facendo mente locale davanti ad un bel foglio bianco, scriviamo le esigenze dei casi

duso, che devono coprire i vari task dellactivity diagram:

1. CreaPrenotazione, che deve coprire Controlla disponibilit, Crea prenotazione,Conferma prenotazione

2. CancellaPrenotazione, che copre Cancella prenot3. ModificaPrenotazione, che copre Modifica prenot, Conferma prenotazione4. ChiudiPrenotazione, che copre Chiudi prenot e Notifica pagamento5. GestioneArrivoMancato, che copre Gestione arrivo mancato e Notifica

pagamento


11/27

11

Se i primi quattro casi duso sono chiari, il 5 evidente che ambiguo o gli manca

qualcosa (lultima che ho detto!). Serve una regola di business da chiedere: ad esempioun mancato arrivo dichiarato tale se il cliente non arriva entro le 8 del mattino

successivo alla prenotazione. E anche evidente che questo evento legato ad untempo e pu essere gestito automaticamente dando lallarme ed lAddetto alle

prenotazioni che fa pagare la penale al cliente oppure anche questultimo puntopotrebbe essere automatico (a discrezione o secondo le regole dellalbergo); ma

supponiamo che avvenga manualmente per cui dobbiamo definire un attore

responsabile delle prenotazioni, non sarebbe saggio farlo fare ad un ospite!

Le ultime considerazioni portano ad un diagramma concettuale aggiuntivo sugli attori

come di seguito, che va vagliato opportunamente con il finanziatore del progetto, che

anche conoscitore del proprio dominio di business.


12/27

12

Nellanalisi dovremmo anche gestire il cambiamento. Cosa pu cambiare? Serve

conoscere bene le esigenze dellalbergo non solo in termini di business ma anche comeandr evolvendo la vita dellalbergo:

1) Lalbergo, se viene ristrutturato, pu aumentare il numero di camere e cambiareil tipo di camere; per cui meglio prevedere funzionalit per le camere: Aggiungi,Modifica, Rimuovi e per il Tipo (Aggiungi, Modifica, Rimuovi)

2) Un cliente pu cambiare indirizzo (Modifica Indirizzo)3) Un cliente pu essere cancellato (a discrezione del Responsabile)4) I dipendenti possono essere aggiunti, modificati e cancellati (da un

Responsabile)

Unaltra cosa importante di estrarre dagli use case gli aspetti comuni, trasversali

di .

Ad esempio CancellaPrenotazione, ModificaPrenotazione, ChiudiPrenotazione hanno un

aspetto comune: occorre identificare la prenotazione creata; per cui c un use casecomune.

Gli aspetti comuni sono aspetti general purpose e incentivano al riuso nel progetto.

Esistono anche aspetti trasversali architetturali (requisiti non funzionali) di questotipo e coadiuvati anche dalle tecnologie, come lAspect Oriented Programming (AOP) in


13/27

13

Java; il che migliora la manutenibilit di un progetto, incrementando la produttivit e

riducendo i bug.

Analisi delle relazioni del Modello concettuale

Conviene sempre fare anche lanalisi delle Relazioni del Modello concettuale perevitare sorprese inaspettate.

Albergo-Camera: una Camera fa parte solo dellalbergo e non di un altro albergo.

Albergo-Dipendente: un dipendente potrebbe essere assunto, andare in

pensione/licenziato, oppure potrebbe essere necessario modificare i suoi dati per cui giusto avere funzionalit di aggiunta, modifica, cancellazione per i dipendenti.

Nellesempio si ipotizza lesistenza almeno di 1 dipendente (cio nei casi minimi c una

persona che copre pi ruoli).

Albergo-Cliente: una relazione di non interesse. Lunico elemento comune tra

Albergo e Cliente la prenotazione.


14/27

14

Albergo-Prenotazione: una relazione importante. La Prenotazione una entit di

business cruciale attorno cui si sta creando il sistema e la cosa qui importante che

una prenotazione pu essere cambiata.

Cliente-Indirizzo: ci pu essere modifica di un indirizzo ed il Cliente ne pu dare solouno, quello che ritiene principale o importante in quel momento ai fini della

prenotazione

Prenotazione-Tipo Camera: importante. Una prenotazione concorda un solo tipo di

camera, ma potrebbe cambiare lesigenza del tipo di camera e cambiare laprenotazione

Prenotazione-Conto: non essenziale si potrebbe anche eliminare, per il discorso che

stiamo facendo.

Prenotazione-Camera: importante. Una prenotazione richiede una camera di un certotipo. Lassegnazione di solito per avviene allarrivo del cliente.

Conto-Pagamento: non necessario, perch fuori dal confine del sistema. Interessa isistemi di carta di credito ad esempio. In altri termini il pagamento o il conto

ritenuto chiuso manualmente a seguito della trasmissione dei dati via telematica ad unsistema di carta di credito.

TipoCamera Camera: non pu cambiare questa relazione se non cambia la camera. Unasingola non diventa magicamente una doppia se anche la camera non cambia

fisicamente per ristrutturazione.

Qualit del servizio

Tra i requisiti non funzionali a questo punto essenziale prevedere alcuni tipici:

sicurezza (username/password da Internet e protocolli sicuri HTTPS e SSL),affidabilit del sistema, database e prestazioni. A seconda di cosa si decide qua

possono apparire altre cose che arricchiscono il dominio della soluzione.

Descrizione testuale dei casi duso

In questa fase fondamentale scrivere le descrizioni testuali e si invita di esplicitarlegli use case.

Descrizione testuale del Caso duso CreaPrenotazioneAttore : Addetto alle prenotazioniScopo : Prenotare una camera dalbergo


15/27

15

Scenario principale

1) Laddetto alle prenotazioni chiede al sistema di fare una prenotazione2) Laddetto seleziona albergo, data e tipo di camera3) Il sistema fornisce prezzo alladdetto4) Laddetto chiede di prenotare una stanza5) Laddetto fornisce nome e C. A. P.6) Laddetto fornisce un indirizzo e-mail come recapito7) Il sistema istanzia la prenotazione e gli associa una etichetta8) Il sistema fornisce letichetta alladdetto9) Il sistema crea un messaggio di conferma e lo inoltra per e-mail al recapito

Estensioni

3) Se la stanza non disponibile il sistema offre delle alternative alladdetto che pu

sceglierne una a cui pu seguire3a) Laddetto lascia stare e desiste dalla prenotazione

3b) Laddetto scegli lopzione e prosegue6) Se lindirizzo e-mail presente individuato da nome e CAP e non occorre inserirlo

Descrizione testuale del Caso duso IdentificaPrenotazioneAttore : varia

Scopo : Sempre incluso

Scenario principale1) Lattore fornisce letichetta della prenotazione2) Il sistema identifica la prenotazione

Estensioni2) Il sistema non trova la prenotazione con letichetta

2a) Lattore fornisce nome e CAP

2b) Il sistema identifica lospite e fornisce la lista delle prenotazioni attive2c) Lospite seleziona la prenotazione giusta

2d) Stop2) La prenotazione si riferisce ad un altro albergo2a) fallimento

2) Non ci sono prenotazioni attive2a) Fallimento

Descrizione testuale del Caso duso ChiudiPrenotazioneAttore : OspiteScopo : Fare il check in

Scenario principale


16/27

16

1) Lospite arriva in albergo e chiede della prenotazione2) Includi IdentificaPrenotazione3) Lospite conferma la data, la durata e il tipo di stanza4) Il sistema assegna la stanza5) Il sistema notifica al sistema di pagamento che c un nuovo cliente

Estensioni3) Il sistema non identifica la prenotazione con letichetta

3a) Fallimento

Workflow Identificazione dei componenti (WIC) Macro-Task Specifica

E il workflow pi importante e cuore della progettazione dei componenti, per cui va

dedicata molta attenzione e cura per ottenere il massimo vantaggio.

Lobiettivo di questo workflow di:

Creare un primo modello di specifiche di interfacce e di componenti in modo dacreare una prima architettura a componenti di base

Le successive fasi saranno di raffinamento del modello a componenti dipartenza

In input al Workflow WIC abbiamo:

Modello concettuale di business Activity Diagram Use case

I vincoli al Workflow WIC sono:

Interfacce preesistenti


17/27

17

Risorse preesistenti Pattern architetturali che si vogliono realizzare

Gli output che si vogliono ottenere sono:

Interfacce di sistema Modello di business Interfacce di business Specifiche dei componenti e architettura

Il WIC si occupa, quindi, di far interagire Input-Vincoli per ottenere gli Output,vediamo come nel seguito.

Identificare le interfacce nel WIC

Sappiamo che le interfacce sono di due tipi: Interfacce di sistema Interfacce di business

Le interfacce di sistema emergono dallanalisi degli use case e dallattivazione di

questi ultimi da parte di attori. In altri termini dipendono dalla interazione degliattori col sistema. Solitamente ci porta a comprendere che serve una GUI o una

interfaccia Web e, quindi, si progetta in modo da gestire gli Use case visti. Leinterfacce di business, invece, sono legate al modello concettuale di business.

Identificare le Interfacce di sistema nel WIC

Per ogni caso duso devo avere, in prima approssimazione, almeno una interfaccia

(interface) e per ogni interfaccia delle operazioni possibili da fare su essa, come

nellesempio.

Dopo questa prima fase si deve prendere ogni use case e verificare se ci sono delle

responsabilit da modellare. Se si individuano responsabilit occorre rappresentarlecon delle operazioni in una o pi interfacce (interface) opportune.

Sono, quindi, fondamentali le descrizioni testuali dei casi duso in questa fase edesaminiamo innanzitutto gli scenari di successo.

Use case CreaPrenotazione Scenario di successo: al passo 2 il sistema deve fornirealladdetto una lista di alberghi, poi col passo 3 a seguito della selezione di un albergo

deve fornire i dettagli di prezzo e disponibilit. Le operazioni associate potremmochiamarle getDettagliAlbergo() e getInfoCamera(). A seguito della consultazione delleinformazioni, al passo 7 lAddetto fa la prenotazione con creaPrenotazione() fornendo

in input i dati e loperazione deve restituire letichetta.


18/27

18

Use case ChiuderePrenotazione Scenario di successo: al passo 3 del check-in il

cliente esibisce letichetta della prenotazione. Per cui serve un getPrenotazione(), poi

si deve allocare una stanza e confermare il periodo di permanenza; per cui serve unmetodo inizioPermanenza(), che segner la data di inizio e il periodo di permanenza.

Finora non abbiamo definito i parametri. Lo faremo quando avremo una maggiore

visibilit nella fase di interazione; questo perch stiamo lavorando ancora a livello diastrazione maggiore o a livello concettuale alto.

Identificare le Interfacce di business nel WIC

Per individuare le interfacce di business necessario:

1) Produrre un modello di business, raffinamento del modello concettuale e calatosul sistema e evidenziazione dei vincoli

2) Specificare le regole di business3) Identificare i Tipi di dati di business di base per le interfacce4) Creare interfacce di business per ogni tipo di dato di business5) Aggiungere le responsabilit al modello

Per il punto 1) dobbiamo ritornare al modello concettuale e raffinarlo. Vediamo cosa

Eliminiamo alcune cose, perch il livello di astrazione sul problema fatto

precedentemente ci suggeriva:

Eliminare Conto

Eliminare Pagamento Eliminare Indirizzo, perch lanagrafica dei clienti potrebbe essere fatta a

parte, rispetto alla gestione delle prenotazioni

Dipendente non ci serve se abbiamo LAddetto alle prenotazioni.In pi aggiungiamo i dati e il tipo.


19/27

19

Assicurarsi che le molteplicit siano corrette e se esistono tutte le dipendenze. Sopra

abbiamo aggiunto anche la relazione tra Albergo e Tipo Camera.

Per il punto 2) sono evidenziati tre regole di business con le note.

Il punto 3) delicato. Cosa vuol dire identificare i tipi di dati di business di base perle interfacce?

Significa:1) identificare i tipi del dominio,

2) che sono indipendenti, ovvero senza associazioni obbligatorie (un 1 come minimo dallato opposto dellassociazione)3) non sono di un tipo categorizzante. Categorizzante un tipo che fa una

classificazione di altri tipi

Esaminiamo il dominio di business ottenuto. Camera potrebbe non essere un tipo base

perch TipoCamera la categorizza. Sicuramente Camera ha una associazione

obbligatoria con Albergo (C l1) per cui Camera da scartare dai tipi base perlinterface.

Mentre Albergo e Cliente possono essere tipi base per le interfacce per le te regole

che ci siamo fissati.

Adesso dobbiamo affrontare punto 4) e 5); la regola creare una interfaccia di

business per ogni tipo base trovato. Abbiamo due tipi base per cui servono due

interface di business, che modelliamo sul modello di business direttamente.


20/27

20

Al modello abbiamo aggiunta anche una navigabilit da Prenotazione a Cliente. Questo

vuol dire che essendo Cliente indipendente Prenotazione che fa riferimento aCliente e ci lo evidenzia maggiormente nel modello di business; ma attenzione questovuol dire anche che sar linterfaccia IHotelMgt a registrare il Cliente tramite

Prenotazione.

Nella progettazione a componenti una Best Practices il fatto di ridurre al minimo

necessario le dipendenze.

Specifiche iniziali delle interfacce

Le interfacce di sistema non vanno nel modello di business. A questo punto convieneidentificare i package in cui inserire le varie cose.

Una idea progettuale della suddivisione in package degli artefatti che produciamo laseguente:

Package Specifiche che conterr

Modello del tipi di business e dati di business, derivato dalle interfacce dibusiness

Specifiche di interfaccia, che conterr a sua volta:o Interfacce di sistemao Interfacce di business


21/27

21

A questo punto occorre completare lultimo passo del WIC.

Specifiche dei componenti e architettura

Serve un componente per ogni specifica di interfaccia. In pratica per lesempio incorso avremo due componenti per le specifiche di interfaccia di sistema:

Componente Sistema di prenotazioni che offre linterfaccia con i metodiiCreaPrenotazione e iChiudiPrenotazione e richiama i componenti di sistema e di

Business: IPagamenti, ICustomerMgt, IHotelMgt

Componente Sistema pagamenti che offre linterfaccia col metodo IPagamentiAvremo, poi, per lesempio due componenti per le specifiche di business:

Componente CustomerMgt, che offre linterfaccia ICustomerMgt, Componente HotelMgt, che offre linterfaccia IHotelMgt Componente Sistema pagamenti che offre linterfaccia col metodo IPagamenti

Quindi larchitettura a componenti la seguente:

Con questo abbiamo completato il Workflow Individuazione componenti (WIC);

difatti abbiamo individuato i componenti, larchitettura e il modello di business.

Workflow di Interazione tra componenti (WITC)

Questo workflow si pone lobiettivo di individuare i prototipi dei metodi, i tipi, gli inpute gli output sostanzialmente per ogni componente e in base allinterazione tra

componenti.

Si pu usare una tecnica di modellazione comportamentale, visto che il workflow si

concentra sul cosa deve fare il componente e come interagisce con gli altri.


22/27

22

In input al WITC abbiamo le interfacce di sistema e di business, il modello di

business, i componenti e larchitettura.

In output dobbiamo ottenere in output un affinamento dellinterazione

comportamentale dei componenti, in sostanza le interfacce definitive e complete di

ogni componente dellarchitettura.

Durante questa fase non si deve escludere la possibilit di individuare dei pattern

comuni e di operazioni generali che rimpiazzano quelle dedicate, incentivando il riuso.

Per applicare il metodo dobbiamo prendere in esame ogni componente e i suoi metodi

finora individuati.

Metodo getDettagliAlbergo() del componente Sistema prenotazioni

Sappiamo che il metodo deve fornire una lista di alberghi da cui lAddetto puscegliere, a fronte di un input anche parziale del nome dellalbergo desiderato.

Inserendo cio una stringa parziale verranno fuori tutti gli alberghi il cui nome inizia

per quella stringa e verranno visualizzate le info relative, con un identificativo unico

dellalbergo. Poich sono informazioni correlate, qui si decide che verranno mostrati

per ogni albergo: lIdAlbergo, il nome, una lista di tipi camera; per cui conviene chetutto ci sia una struttura dati apposita di tipo DettagliAlbergo, che contenga

lIdAlbergo, nome e tipiCamera[] e il metodo deve restituire una lista di

DettagliAlbergo, per ogni albergo.

Il metodo quindi diventa

ICreaPrenotazione::getDettagliAlbergo(in corrisp:String): DettagliAlbergo []


23/27

23

Ora dobbiamo guardare linterazione tra il componente Sistema prenotazioni e il

componente HotelMgt; questo ci porta subito a dire che anche HotelMgt nella suainterfaccia deve avere il metodo getDettagliAlbergo.

Metodo getInfoCamera() del componente Sistema prenotazioni

Anche qui occorre passare in input un elemento di tipo DettagliAlbergo (lalbergoscelto) e ricevere in output la disponibilit (boolean) e il prezzo.

Il metodo quindi diventaICreaPrenotazione::getinfoCamera(in info:DettagliAlbergo,

out disp:Boolean,

out prezzo:Integer

)

Tale metodo deve allora esistere anche nellinterfaccia del componente HotelMgt.

Metodo creaPrenotazione() del componente Sistema prenotazioni

Il metodo deve creare la prenotazione e notificare la cosa via email al cliente. Ilmetodo deve riuscire a riconoscere la prenotazione fatta e il cliente, quindi gli

servono in input udue strutture dati:

struttura dati Dettagli Prenotazione che conterr lidAlbergo di tipo Integer,tipoCamera (String) e date di tipo intervallo Date;

struttura dati DettagliCliente che conterr nome (String), CAP[0..1], e-mail[0..1]

Con [0..1] intendiamo o non c oppure esiste almeno 1.

In output deve restituire una etichetta della prenotazione (String). Poi dobbiamo

gestire un valore Integer di ritorno per gestire lo status cio se le cose sono andate

OK oppure no; ad esempio 0=OK, 1 il cliente non esiste e non si potutto aggiungereperch manca CAP e e-mail, 2=non c CAP e il nome corrisponde a pi clienti

Il metodo quindi diventaICreaPrenotazione::crePrenotazione(in pren:DettagliPrenotazione,

in cli: DettagliCliente,out etic:String

): Integer

Quindi linterfaccia HotelMgt deve avere questo metodo. Per abbiamo anchecompreso che dobbiamo anche riconoscere il Cliente (responsabilit di CustomerMgt)

e ci serve un altro metodo:


24/27

24

iCustomerMgt::getClienteCorrispondente( in cli: DettagliCliente, out idC: ClientId):

Integer

Abbiamo deciso di ricevere un id del cliente in output e uno status che corrisponde a:

0=OK, 1=Non esiste, 2=Non c CAP o email

Serve a questo punto un altro metodo quello di notifica al cliente (quindiresponsabilit di CustomerMgt):riceve lid del cliente e una stringa di informazione di

conferma per cui il metodo :

iCustomerMgt::notificaCliente( in idC: ClientId, in s: String): Integer

Notare che abbiamo deciso di passare gli id del cliente sia a HotelMgt che

CustomerMgt ed responsabilit del component Sistema Prenotazioni di produrli, inquesto modo non c interdipendenza tra HotelMgt e CustomerMgt e sono riusabili

anche in altri contesti.

Responsabilit emerse finora

ICreaPrenotazione delega la creazione della prenotazione a IHotelMgt ma gestisce leassociazioni col cliente.

iHotelMgt responsabile delle camere, dei tipi di camera, di associare i tipi camere ei prezzi alle prenotazioni.

iCustomerMgt responsabile dei clienti e dei loro dettagli e della gestione dellenotifiche ai clienti.

Vincoli architetturali di numerosit dei componenti

Finora non abbiamo ancora detto nulla sulla numerosit di tali componenti.

Per se avessimo ad esempio due CustomerMgt ognuno che agisse su un insieme

diverso di clienti avremmo il problema dellid del cliente che non sarebbe univoco e lostesso con HotelMgt. Per cui questo un vincolo. Possiamo avere pi Sistemi di

prenotazioni ma un solo HotelMgt, e un solo CustomerMgt. Per cui per come abbiamoprogettato le cose in questo esempio esiste tale vincolo.

Integrit referenzialeAbbiamo visto che HotelMgt registra le identit dei clienti (gli idClient) come partedella prenotazione. Che succede se cancelliamo un cliente?

In poche parole i riferimenti inter-componente devono rimanere sempre validi.

In generale esistono varie soluzioni che elenchiamo:


25/27

25

assegnare le responsabilit d un solo componente. Nel nostro esempio vorrebbedire che tutte le cancellazioni di cliente devono essere gestite da HotelMgt per

aggiustare le cose sulla prenotazione (probabilmente da eliminare) e poi passata aCustomerMgt per la cancellazione del Cliente

assegnare la responsabit a chi owner della cancellazione, quindi a CustomerMgtche poi dovrebbe attivare HotelMgt (meccanismo ad esempio Publish-Subscribe

detto anche Observer) per aggiustare le cose

assegnare la responsabilit ad un componente gestore (Sistema prenotazioni) chequando cancella il cliente su CustomerMgt va ad aggiustare le cose su HotelMgt

si pu proibire la cancellazione finch la prenotazione attivaNel nostro esempio la prima opzione non funziona, per la dipendenza che abbiamo

scelto, anche perch vogliamo mantenere indipendenti HotelMgt e CustomerMgt.

Lultima non risolve niente perch quando la prenotazione non attiva rimane ilproblema. Tra seconda e terza opzione pi semplice la terza.

Se usiamo la terza opzione allora nel componente Sistema di prenotazioni

necessario:

il metodo cancella Cliente(in idC:ClientId): Integer

ed esso deve essere presente anche in CustomerMgt.

Completare i metodi rimanenti

Servono ancora:

iCustomerMgt::creaCliente(in cli: String, out id:Integer)se un nuovo cliente crea la prenotazione

A causa di ChiudiPrenotazione ci serve anche:iHotelMgt::getPrenotazione(in etich:String, out det:DettagliPrenotazione,

out:DettagliCliente): Booleanqui il boolean false se la prenotazione non viene trovata

Raffinare e fattorizzare le interfacceQuesta fase pu essere utile. Fattorizzare le interfacce significa suddividere i tipisu pi interfacce in modo di avere responsabilit uniche e coerenti e possibilmente

generali. Qui lobiettivo NON gestire il cambiamento, perch si possonofacilmente aggiungere interfacce eventualmente. Il nostro esempio era abbastanzasemplice e tale fase non necessaria.


26/27

26

Specifica dei componenti

Lultima fase del WITC.

In questa fase vanno riviste tutte le operazioni e i dati scambiati, i vincoli, le

regole di business, pre-condizioni, post-condizioni e gli invarianti.

Le pre-condizioni prima di chiamare il metodo offerto da un componente affinchla chiamata sia valida e le post-condizioni offerte dopo la chiamata al metodo e con

pre-condizione rispettata affinch il client operi correttamente sui dati ritornati.Infine se ci sono invarianti (un vincolo associato ad un tipo e vero sempre), ad

esempio tra Prenotazione e Cliente c un invariante perch ogni prenotazione deve

essere associata ad un solo cliente.

Per avere idee chiare su pre-condizioni e post-condizioni pu essere utile fare una

istantanea (tecnica snapshot o di debugger logico) prima e dopo delle istanze

tramite dei diagrammi e comprendere i cambiamenti di stato oppure ragionandosui valori assunti prima e dopo a partire dai metodi.

Workflow Provisioning

E una fase opzionale, da usare se necessaria. Si tratta di avere le idee chiare, disolito dopo la progettazione, su quale componente tecnologico ad alto contenuto di

know-how occorre investire come acquisto sul mercato o farsi prestare perch gi

disponibile in azienda.

Workflow di IntegrazioneIl workflow di Integrazione diventa notevolmente importante se necessario ilworkflow di Provisioning.


27/27

Occorre analizzare bene cosa si va ad acquistare come componente: i metodi e i

dati offerti, la tecnologia, il linguaggio, i vincoli, le regole di business, pre-condizioni e post-condizioni, per essere certi che sia integrabile e riusabile

nellambito del proprio progetto. Inoltre va valutato anche se il riuso ottenuto o ilknow-how eventualmente assente riesce a giustificare il costo sostenuto.

Buon Lavoro

RIFERIMENTI

[DR1] Martin Fowler UML Distilled Prima edizione italiana

[DR2] Rosario Turco Concetti di base Object Oriented[DR3] Rosario Turco Principi di Disegno[DR4] Rosario Turco Usabilit e ripetibilit dei processi produttivi software[DR5] Rosario Turco Modellare con lUML ed i colori[DR6] Rosario Turco Risoluzione di problemi con UML[DR7] Rosario Turco Tradurre le relazioni UML in C++[DR8] Rosario Turco - Refactoring: la teoria in pratica[DR9] Rosario Turco Disegno per il riuso e con il riuso[DR10] Robert C. Martin Design Principles and Design Patterns[DR11] Gamma, Helm, Johnson,Vlissides Design Patterns Elementi per il riuso di softwarea oggetti Prima edizione italiana[DR12] Rosario Turco - OO - Design Pattern-e-book

[DR13] Rosario Turco Framework e UML[DR14] Rosario Turco Il Business AS IS Modeling con UML[DR15] Kent Beck Programmazione estrema Introduzione[DR16] Rosario Turco Extreme Programming[DR17] Rosario Turco Rational Unified Process[DR18] Rosario Turco BPM, SOA e Business Rules Engine, lultima frontiera[DR19] John Cheesman, John Daniels UML Components[DR20] Catalysishttp://www.catalysis.org/
http://www.catalysis.org/http://www.catalysis.org/http://www.catalysis.org/http://www.catalysis.org/

progettazione a componenti

Documents