Panoramica
Nella guida al tool, le seguenti operazioni vengono effettuate per i casi d'uso da progettare nell'iterazione corrente.
Ulteriori informazioni sui tool
È possibile documentare elementi di progettazione, significativi da un punto di vista architetturale, in una vista
logica separata, che viene gestita quando vengono identificati elementi di progettazione. La raccomandazione generale è
di utilizzare pacchetti di <<prospettiva>>. Vedere Linee guida sulla struttura dei modelli per RSx per ulteriori informazioni su questo
argomento.
Le caratteristiche degli eventi, chiamate anche trigger in UML 2.0 , devono essere catturate per portare
all'identificazione degli elementi di progettazione che li gestiscono. Queste informazioni possono essere catturate in
modo informale, come, ad esempio, in un documento separato, piuttosto che come parte di un modello.
Gli eventi di comunicazione asincroni possono essere modellati come segnali per esprimere i dati che trasportano, o per
esprimere le relazioni tra segnali, quale ad esempio una relazione di generalizzazione. Le seguenti operazioni
secondarie descrivono come modellare i segnali:
-
Creazione di diagrammi di classe. Vedere
Aggiunta di diagrammi di classe agli elementi del
modello.
-
Aggiunta di segnali. Vedere
Creazione e modifica dei diagrammi di classe.
-
Aggiunta di una breve descrizione a ciascun elemento di progettazione. Vedere
Documentazione degli elementi del
modello.
-
Aggiunta di relazioni di generalizzazione tra segnali, se applicabile.
Per ulteriori informazioni sui diagrammi di classe, vedere Modellazione di una struttura
statica utilizzando i diagrammi di classe.
Gli elementi di progettazione vengono generalmente creati nelle tre seguenti modalità:
-
Espansione di un pattern
-
Modellazione
-
Codifica e reverse engineering
Tali approcci vengono illustrati nelle sezioni qui di seguito.
Espansione di un pattern
Un pattern rappresenta un tipo speciale di trasformazione ottimizzata per un'elaborazione a piccoli pezzi,
interattiva principalmente in un singolo metamodello, all'interno dello stesso livello di astrazione e spesso
all'interno dello stesso modello. Per ulteriori informazioni, fare riferimento a Meccanismi di
analisi.
Vedere Authoring di
pattern e Applicazione di pattern nella guida online.
Modellazione
Questo strumento supporta un approccio guidato dal modello allo sviluppo del software (vedere Model Driven Development e Model Driven Architecture eMeccanismi di analisi), in cui è stato costruito un'insieme di modelli che includono
eventualmente un modello di progettazione e genera artefatti di implementazione come il codice 3GL code, descrittori
ecc. Questi derivano dal fatto che il modello di progettazione utilizza trasformazioni. In alcuni casi, le
trasformazioni che generano il codice considereranno le analisi di classe come iput, ma principalmente questi saranno
guidati dagli elementi della progettazione. Per ulteriori informazioni, vedere Applicazione di trasformazioni.
In un approccio allo sviluppo tradizionale verranno creati diagrammi classe nel modello di progettazione per catturare
elementi di progettazione. Se si decide di gestire le classi di analisi, è possibile che si desideri stabilire la
tracciabilità utilizzando le dipendenze di "traccia" con le classi di analisi.
-
Creazione di diagrammi di classe. Vedere
Aggiunta di diagrammi di classe agli elementi del
modello.
-
Aggiungere sottosistemi e classi. Vedere
Creazione e modifica dei diagrammi di classe.
-
Aggiunta di una breve descrizione a ciascun elemento di progettazione. Vedere
Documentazione di elementi del
modello
-
(facoltativa). Aggiungere la tracciabilità alle classi di analisi utilizzando le dipendenze di "traccia" dagli
elementi della progettazione alle classi di analisi sulle quali erano basate. Vedere
Relazioni di astrazione
nella modellazione UML.
-
Organizzare gli elementi di progettazione in sottosistemi e pacchetti. Fare riferimento al white paper Linee guida sulla struttura dei modelli per RSx.
Per ulteriori informazioni sui diagrammi di classe, vedere Modellazione di una struttura
statica utilizzando i diagrammi di classe .
Codifica e reverse engineering
Nota: alcune delle capacità del tool menzionate in questa sezione non sono supportate in RSM.
Un approccio diverso è quello a "priorità di codice": il codice è la guida principale sia perchè già esiste (ad esempio
in cicli di sviluppo non-greenfield) sia perché il team ha l'esigenza di affrontare alcuni rischi del progetto
specifici codificando un prototipo per convalidare un concetto complesso. Come parte del supporto per il ripristino ed
rilevamento dell'architettura (vedere le linee guida Rilevamento, analisi e controllo strutturale), la capacità di visualizzazione del
codice può popolare automaticamente i diagrammi dell'argomento, come la struttura del pacchetto, gli elementi interni
della classe, le strutture ad albero dell'ereditarietà e le collaborazioni. Lo scopo di questo compito non è solo
quello di comprendere il codice esistente, ma anche di estrarre un modello dell'applicazione, il quale potrebbe essere
utilizzato insieme ad altri modelli specifici per generare la nuova versione dell'applicazione, utilizzando le
trasformazioni.
Una volta generato o composto il diagramma UML del codice esistente, per potenziare le rappresentazioni del codice come
parte del modello di progettazione sono disponibili le seguenti opzioni:
-
Raccogliere una rappresentazione UML di un elemento del codice nel modello di progettazione, come un vero elemento
di modello semantico. Ciò produce un nuovo elemento UML nel modello di progettazione che non ha connessioni con
l'elemento del codice che era stato raccolto. Ciò ha comunque delle proprietà (ad esempio attributi ed operazioni)
che riflettono le priorità dell'elemento del codice raccolto. Essendo un vero elemento semantico UML può generare
un nuovo codice (in altre parole ha nel modello di progettazione lo stesso stato di ogni elemento di progettazione
che sia stato definito mediante il processo di modellazione greenfield descritto in precedenza).
-
Inserire un riferimento visivo all'elemento del codice nel diagramma che risiede nel modello di progettazione.
Questo riferimento non ha di per sé significato semantico all'interno del modello di progettazione e non può
produrre nuovi codici. È, come indica il nome, solo un riferimento al vero elemento di codice. È comunque possibile
tracciare le relazioni tra il riferimento al codice e gli elementi di progettazione semantica nel modello di
progettazione. Quelle relazioni invece hanno significato semantico all'interno del modello di progettazione e
influenzano la generazione del codice.
Per ulteriori informazioni, fare riferimento a Modellazione di strutture statiche con diagrammi di
classe nella guida online.
Le seguenti operazioni si applicano a sottosistemi ad ampia granularità:
-
Per ciascun sottosistema, identificare un insieme di interfacce candidate. Se precedentemente sono state create
delle classi di analisi ed eseguito realizzazioni del caso d'uso a livello di analisi, ora si deciderà in che modo
queste operazioni debbano essere raggruppate ed esposte come interfacce di particolari componenti o servizi.
Aggiungere interfacce ad un diagramma del componente esistente oppure creare nuovi diagrammi del componente. Vedere
Aggiunta di
interfacce ai diagrammi di modellazione.
-
Aggiunta di dipendenze dell'interfaccia.
-
Mappatura di sottosistemi alle interfacce aggiungendo una relazione di realizzazione dal sottosistema
all'interfaccia.
-
Documentazione dell'interfaccia, compreso il comportamento richiesto. Vedere
Documentazione di elementi del
modello.
-
Aggiunta di operazioni all'interfaccia. Vedere
Aggiunta di operazioni ai classificatori nei
diagrammi.
-
Aggiunta di una descrizione a ciascuna operazione. Vedere
Documentazione di elementi del modello.
-
Aggiunta di parametri a ciascuna operazione. Vedere
Aggiunta di operazioni ai classificatori nei
diagrammi.
-
Organizzazione delle interfacce nei pacchetti.
In UML 2.0 i sottosistemi sono componenti grandi e potrebbero essere rappresentati come classi strutturate con porte
e/o interfacce. Vedere gli argomenti che la guida online dedica a UML 2.0.
Le modellazioni di capsule e di protocolli non sono supportate
Esercitazioni:
-
Applicazione di
un pattern
Esempi:
-
Pattern -
Modello UML semplice
|