Download - 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] -
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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
-
8/8/2019 Progettazione a componenti
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
-
8/8/2019 Progettazione a componenti
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:
-
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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
-
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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
-
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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
-
8/8/2019 Progettazione a componenti
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
-
8/8/2019 Progettazione a componenti
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
-
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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
-
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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 []
-
8/8/2019 Progettazione a componenti
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:
-
8/8/2019 Progettazione a componenti
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:
-
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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.
-
8/8/2019 Progettazione a componenti
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/