Guida al tool: Identificazione di elementi di progettazione utilizzando Rational Software Architect
Questa guida descrive il modo in cui identificare elementi di progettazione mediante l'ambiente di modellazione RSA.
Strumento: Rational Software Architect
Estende: Identificazione degli elementi di progettazione mediante Rational Software Development Platform
Relazioni
Descrizione principale

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.

Identificazione di eventi e segnali

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:

  1. Creazione di diagrammi di classe. Vedere icona della guidaAggiunta di diagrammi di classe agli elementi del modello.
  2. Aggiunta di segnali. Vedere icona della guidaCreazione e modifica dei diagrammi di classe.
  3. Aggiunta di una breve descrizione a ciascun elemento di progettazione. Vedere icona della guidaDocumentazione degli elementi del modello.
  4. Aggiunta di relazioni di generalizzazione tra segnali, se applicabile.  

Per ulteriori informazioni sui diagrammi di classe, vedere icona della guidaModellazione di una struttura statica utilizzando i diagrammi di classe.

Identificazione di classi, classi attive e sottosistemi

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 icona della guidaAuthoring di pattern e icona della guidaApplicazione 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 icona della guidaApplicazione 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.

  1. Creazione di diagrammi di classe. Vedere icona della guidaAggiunta di diagrammi di classe agli elementi del modello.
  2. Aggiungere sottosistemi e classi. Vedere icona della guidaCreazione e modifica dei diagrammi di classe.
  3. Aggiunta di una breve descrizione a ciascun elemento di progettazione. Vedere icona della guidaDocumentazione di elementi del modello
  4. (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 help booicona della guidaRelazioni di astrazione nella modellazione UML.
  5. 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 icona della guidaModellazione 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 icona della guidaModellazione di strutture statiche con diagrammi di classe nella guida online.

Identificazione di interfacce di sottosistema

Le seguenti operazioni si applicano a sottosistemi ad ampia granularità:

  1. 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 icona della guidaAggiunta di interfacce ai diagrammi di modellazione.
  2. Aggiunta di dipendenze dell'interfaccia. 
  3. Mappatura di sottosistemi alle interfacce aggiungendo una relazione di realizzazione dal sottosistema all'interfaccia.
  4. Documentazione dell'interfaccia, compreso il comportamento richiesto. Vedere icona della guidaDocumentazione di elementi del modello.
  5. Aggiunta di operazioni all'interfaccia. Vedere icona della guidaAggiunta di operazioni ai classificatori nei diagrammi.
  6. Aggiunta di una descrizione a ciascuna operazione. Vedere icona della guidaDocumentazione di elementi del modello.
  7. Aggiunta di parametri a ciascuna operazione. Vedere icona della guidaAggiunta di operazioni ai classificatori nei diagrammi.
  8. 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.  

Identificazione dei protocolli delle capsule

Le modellazioni di capsule e di protocolli non sono supportate

Ulteriori informazioni sui tool

Esercitazioni:

  • icona della guidaApplicazione di un pattern

Esempi:

  • icona della guidaPattern - Modello UML semplice