Panoramica dello scenario: modificare la progettazione mediante visualizzazione e modellazione
Per assicurarsi che il sistema software soddisfi le esigenze degli utenti, utilizzare gli strumenti di visualizzazione e di modellazione Visual Studio Ultimate per aggiornare o modificare la progettazione del sistema. Questi strumenti includono diagrammi UML (unified modeling language), diagrammi di livello, grafici dipendenze basati sul codice, diagrammi sequenza e diagrammi classi. Ad esempio, è possibile utilizzare questi strumenti per eseguire queste attività:
Definire le esigenze degli utenti e i processi aziendali.
Visualizzare ed esplorare il codice esistente.
Descrivere le modifiche di un sistema esistente.
Verificare che il sistema soddisfi i requisiti.
Garantire la coerenza del codice con la progettazione.
In questa procedura dettagliata viene utilizzato uno scenario di esempio per raggiungere i seguenti obiettivi:
Fornire una panoramica generale degli strumenti e dei vantaggi da essi offerti in un progetto software.
Mostrarne il possibile utilizzo in uno scenario di esempio da parte di due team, indipendentemente dai relativi approcci di sviluppo.
Per ulteriori informazioni su questi strumenti e sugli scenari supportati, vedere:
In questo argomento
Sezione |
Descrizione |
|---|---|
Panoramica dello scenario |
Viene fornita una descrizione dello scenario di esempio e dei relativi partecipanti. |
Ruoli dei diagrammi dell'architettura e della modellazione nello sviluppo del software |
Vengono descritti i ruoli che questi strumenti possono svolgere durante il ciclo di vita dello sviluppo del software. |
Comprensione e comunicazione delle informazioni relative al sistema |
Viene fornita una panoramica generale delle modalità di utilizzo degli strumenti da parte dei partecipanti dello scenario. |
Aggiornamento del sistema mediante gli strumenti di visualizzazione e di modellazione |
Vengono fornite informazioni dettagliate su ciascuno strumento e su come può essere utilizzato nello scenario. |
Panoramica dello scenario
In questo scenario vengono descritti alcuni episodi dei cicli di vita dello sviluppo del software di due società fittizie: Dinner Now e Lucerne Publishing.Dinner Now fornisce un servizio di consegna pasti basato sul Web per l'area di Milano.I clienti possono ordinare e acquistare i pasti direttamente sul sito Web Dinner Now.Gli ordini vengono quindi inviati al ristorante locale designato per la consegna.Lucerne Publishing, una società con sede a Roma, gestisce varie attività sia sul territorio che sul Web.Ad esempio, gestisce un sito Web in cui i clienti possono inserire recensioni di ristoranti.
Lucerne ha recentemente acquisito Dinner Now e intende apportare le seguenti modifiche:
Integrare i siti Web delle due società aggiungendo funzionalità di recensione dei ristoranti a Dinner Now.
Sostituire il sistema di pagamento di Dinner Now con quello di Lucerne.
Espandere dinner now assistono l'area.
Dinner Now utilizza le metodologie SCRUM e eXtreme Programming.Dispone di procedure di code coverage del test dettagliate e la quantità di codice non supportato è esigua.Per ridurre al minimo i rischi, crea prima versioni ridotte ma perfettamente funzionali di un sistema, per poi aggiungervi in modo incrementale ulteriori funzionalità.Il codice viene sviluppato sulla base di iterazioni brevi e frequenti.In questo modo, il team di Dinner Now può affrontare le modifiche con fiducia, eseguire il refactoring del codice frequentemente ed evitare un eccessivo impegno iniziale di scrittura del codice.
Lucerne gestisce una raccolta molto più ampia e complessa di sistemi, alcuni dei quali risalenti a oltre quarant'anni fa.Le modifiche vengono apportate con estrema cautela a causa della complessità e della diffusione del codice legacy.Viene seguito un processo di sviluppo più rigoroso, preferibilmente progettando soluzioni dettagliate e documentando la progettazione e le modifiche apportate nel corso dello sviluppo.
Entrambi i team utilizzano i diagrammi di modellazione di Visual Studio Ultimate per sviluppare sistemi che soddisfino le esigenze degli utenti.Utilizzano Team Foundation Server insieme ad altri strumenti per pianificare, organizzare e gestire il lavoro.
Per ulteriori informazioni su Team Foundation Server, vedere:
Pianificazione e traccia del lavoro
Test, convalida e archiviazione del codice aggiornato
Ruoli dei diagrammi dell'architettura e della modellazione nello sviluppo del software
Nella tabella seguente vengono descritti i ruoli che questi strumenti svolgono durante varie fasi del ciclo di vita dello sviluppo del software:
Modellazione dei requisiti utente |
Modellazione dei processi aziendali |
Architettura e progettazione del sistema |
Visualizzazione ed esplorazione del codice |
Verifica |
|
|---|---|---|---|---|---|
Diagramma caso di utilizzo (UML) |
√ |
√ |
√ |
||
Diagramma attività (UML) |
√ |
√ |
√ |
√ |
|
Diagramma classi (UML) |
√ |
√ |
√ |
√ |
|
Diagramma componente (UML) |
√ |
√ |
√ |
√ |
|
Diagramma sequenza (UML) |
√ |
√ |
√ |
√ |
|
Diagramma DSL |
√ |
√ |
√ |
||
Diagramma livello, convalida dei livelli |
√ |
√ |
√ |
||
Grafico dipendenze (basato sul codice) |
√ |
√ |
√ |
||
Diagramma sequenza (basato sul codice) |
√ |
√ |
|||
Progettazione classi (basata sul codice) |
√ |
||||
Esplora architettura |
√ |
Per creare diagrammi UML e diagrammi livello, è necessario creare un progetto di modello in una soluzione esistente o nuova.Questi diagrammi devono essere creati nel progetto di modello.Gli elementi dei diagrammi UML fanno parte di un modello comune, del quale un diagramma UML rappresenta una visualizzazione.Gli elementi dei diagrammi livello si trovano nel progetto di modello, ma non sono archiviati nel modello comune.I grafici di dipendenze, i diagrammi sequenza e i diagrammi classi basati sul codice sono in genere esterni al progetto di modello.
Vedere:
Procedura: aggiungere diagrammi classi ai progetti (Progettazione classi)
SDK di visualizzazione e modellazione (linguaggi specifici di dominio)
Per mostrare visualizzazioni alternative dell'architettura, è possibile riutilizzare determinati elementi dello stesso modello in più diagrammi del medesimo tipo o di tipo differente.Ad esempio, è possibile trascinare un componente in un altro diagramma componente o in un diagramma sequenza per utilizzarlo come attore.Vedere Procedura: modificare modelli e diagrammi UML.
Entrambi i team utilizzano inoltre la convalida dei livelli per assicurare la coerenza del codice in corso di sviluppo con la progettazione.
Vedere:
Mantenimento della coerenza del codice con la progettazione
Descrizione dell'architettura logica: diagrammi livello
Convalidare il codice con diagrammi livello
[!NOTA]
Visual Studio Premium supporta la convalida dei livelli e l'utilizzo delle versioni di sola lettura di questi grafici e diagrammi a scopo di visualizzazione e modellazione.
Comprensione e comunicazione delle informazioni relative al sistema
Poiché non esiste un ordine prestabilito per l'utilizzo dei diagrammi di modellazione di Visual Studio Ultimate, è possibile utilizzarli nel modo più consono alle esigenze o all'approccio adottato.Generalmente, i team rivedono i propri modelli iterativamente e con frequenza nel corso del progetto.Ogni diagramma offre vantaggi caratteristici in termini di comprensione, descrizione e comunicazione dei differenti aspetti del sistema che si sta sviluppando.
Dinner Now e Lucerne utilizzano i diagrammi come linguaggio comune per comunicare tra di loro e con le parti interessate del progetto.Ad esempio, Dinner Now utilizza i diagrammi per effettuare le seguenti attività:
Visualizzare il codice esistente.
Comunicare con Lucerne in relazione alle storie utente nuove o aggiornate.
Identificare le modifiche richieste per supportare le storie utente nuove o aggiornate.
Lucerne utilizza i diagrammi per effettuare le seguenti attività:
Ottenere informazioni sul processo aziendale di Dinner Now.
Comprendere la progettazione del sistema.
Comunicare con Dinner Now in relazione ai requisiti utente nuovi o aggiornati.
Documentare gli aggiornamenti del sistema.
I diagrammi sono integrati con Team Foundation Server in modo che i team possano pianificare, gestire e tenere traccia del lavoro più facilmente. Ad esempio, utilizzano modelli per identificare i test case e le attività di sviluppo per stimare il lavoro.Lucerne collega gli elementi di lavoro di Team Foundation Server agli elementi dei modelli per monitorare lo stato di avanzamento e verificare che il sistema soddisfi i requisiti degli utenti.Ad esempio, collega i casi di utilizzo agli elementi di lavoro test case per assicurarsi che i primi vengano soddisfatti quando tutti i test vengono superati.
Prima di archiviare le modifiche, i team convalidano il codice in base ai test e alla progettazione eseguendo compilazioni che includono la convalida dei livelli e test automatizzati.Ciò consente di assicurarsi che il codice aggiornato non entri in conflitto con la progettazione, impedendo l'esecuzione di funzionalità precedentemente operative.
Vedere:
Comprensione del ruolo del sistema nel processo aziendale
Descrizione dei requisiti utente nuovi o aggiornati
Creazione di test dai modelli
Identificazione delle modifiche al sistema esistente
Mantenimento della coerenza del codice con la progettazione
Suggerimenti generali per la creazione e l'utilizzo dei modelli
Pianificazione e traccia del lavoro
Test, convalida e archiviazione del codice aggiornato
.gif "Ff183189.collapse_all(it-it,VS.110).gif")
Comprensione del ruolo del sistema nel processo aziendale
Lucerne intende approfondire la conoscenza del processo aziendale di Dinner Now.Il team crea pertanto i seguenti diagrammi per definire più chiaramente quanto appreso rispetto a Dinner Now:
Diagramma |
Oggetto di descrizione |
|---|---|
Diagramma caso di utilizzo (UML) Vedere: |
|
Diagramma attività (UML) Vedere: |
Il flusso dei passaggi eseguiti quando un cliente crea un ordine. |
Diagramma classi (UML) Vedere: |
Le entità business e i termini utilizzati nella discussione, nonché le relazioni tra queste entità.Ad esempio, Ordine e Elemento del menu sono due termini del vocabolario utilizzato in questo scenario. |
Ad esempio, Lucerne crea il seguente diagramma caso di utilizzo per avere una visione più chiara delle attività eseguite nel sito Web Dinner Now e dei soggetti che le eseguono:
.png "Diagramma caso di utilizzo UML")
Diagramma caso di utilizzo UML
Nel seguente diagramma attività viene descritto il flusso dei passaggi eseguiti quando un cliente crea un ordine nel sito Web Dinner Now.In questa versione, gli elementi di commento identificano i ruoli e le linee creano corsie che permettono di organizzare i passaggi in base al ruolo:
.png "Diagramma attività UML")
Diagramma attività UML
Nel seguente diagramma classi vengono descritte le entità implicate nel processo relativo all'ordine:
.png "Diagramma classi UML")
Diagramma classi UML
Descrizione dei requisiti utente nuovi o aggiornati
Lucerne desidera aggiungere al sistema di Dinner Now funzionalità che consentano ai clienti di leggere e inviare recensioni dei ristoranti.Pertanto, il team aggiorna i seguenti diagrammi in modo da poter descrivere il nuovo requisito e poterne discutere con Dinner Now:
Diagramma |
Oggetto di descrizione |
|---|---|
Diagramma caso di utilizzo (UML) Vedere: |
Un nuovo caso di utilizzo "Recensione di un ristorante". |
Diagramma attività (UML) Vedere: |
I passaggi eseguiti quando un cliente desidera scrivere una recensione di un ristorante. |
Diagramma classi (UML) Vedere: |
I dati necessari per archiviare una recensione. |
Ad esempio, il seguente diagramma caso di utilizzo include un nuovo caso di utilizzo "Scrittura recensione" che rappresenta il nuovo requisito.Il caso di utilizzo è evidenziato in arancione nel diagramma per facilitarne l'identificazione:
.png "Diagramma caso di utilizzo UML")
Diagramma caso di utilizzo UML
Nel seguente diagramma attività, i nuovi elementi sono visualizzati in arancione per descrivere il flusso dei passaggi del nuovo caso di utilizzo:
.png "Diagramma attività UML")
Diagramma attività UML
Nel seguente diagramma classi sono visualizzate una nuova classe Recensione e le sue relazioni con le altre classi per consentire ai team di discuterne i dettagli.Si noti che a un cliente e a un ristorante possono essere associate più recensioni:
.png "Diagramma classi UML")
Diagramma classi UML
Creazione di test dai modelli
Entrambi i team concordano sulla necessità di eseguire un set completo di test per il sistema e i relativi componenti prima di apportare qualsiasi modifica.Lucerne dispone di un team specializzato che esegue i test a livello di sistema e di componente.Vengono riutilizzati i test creati da Dinner Now, strutturandoli mediante i diagrammi UML:
Ogni caso di utilizzo viene rappresentato da uno o più test.Gli elementi del diagramma caso di utilizzo vengono collegati a elementi di lavoro test case in Team Foundation Server.
Ogni flusso in un diagramma attività o diagramma sequenza a livello di sistema viene collegato almeno a un test.Il team di test verifica sistematicamente che venga testato ogni possibile percorso del diagramma attività.
I termini utilizzati per descrivere i test sono basati sui termini definiti dai diagrammi caso di utilizzo, classi e attività.
Man mano che i requisiti cambiano e i diagrammi vengono aggiornati, si procede ad aggiornare anche i test.Un requisito viene considerato soddisfatto solo quando i test pertinenti sono stati superati.Quando è possibile o opportuno, i test vengono definiti e basati sui diagrammi UML prima dell'implementazione.
Vedere:
Identificazione delle modifiche del sistema esistente
Dinner Now deve stimare il costo delle operazioni necessarie per soddisfare il nuovo requisito.Tale costo dipende in parte dall'impatto che tale modifica avrà su altre parti del sistema.Per facilitare il compito, uno degli sviluppatori di Dinner Now genera i grafici e i diagrammi seguenti dal codice esistente:
Grafico o diagramma |
Oggetto di descrizione |
|---|---|
Grafico dipendenze Vedere: |
Dipendenze e altre relazioni nel codice. Ad esempio, il team di Dinner Now potrebbe iniziare col rivedere i grafici dipendenze assembly per ottenere una panoramica degli assembly e delle relative dipendenze.Potrebbe analizzare i grafici per esplorare gli spazi dei nomi e le classi di tali assembly. Inoltre, Dinner Now può creare grafici per l'esplorazione di aree particolari e altri tipi di relazioni nel codice.Per individuare e selezionare le aree e le relazioni interessanti viene utilizzato Esplora architettura o Esplora soluzioni. |
Diagramma sequenza basato sul codice Vedere Visualizzare il codice generando diagrammi di sequenza. |
La sequenza delle interazioni tra le istanze. I diagrammi sequenza vengono generati dalle definizioni di metodo e sono utili per comprendere in che modo il codice implementa il comportamento del metodo. |
Diagramma classi basato sul codice Vedere Procedura: aggiungere diagrammi classi ai progetti (Progettazione classi). |
Le classi esistenti nel codice. |
Ad esempio, lo sviluppatore utilizza Esplora architettura per selezionare gli spazi dei nomi desiderati su cui concentrarsi e creare un grafico di dipendenze dal codice.Quindi, ne modifica l'ambito limitandolo alle aree che saranno interessate dal nuovo scenario.Tali aree risultano selezionate ed evidenziate nel grafico:
.png "Grafico delle dipendenze dello spazio dei nomi")
Grafico dipendenze spazio dei nomi
Lo sviluppatore espande gli spazi dei nomi selezionati per visualizzarne le classi, i metodi e le relazioni:
.png "Grafico delle dipendenze dello spazio dei nomi esteso")
Grafico dipendenze spazio dei nomi espanso con i collegamenti tra gruppi visibili
Lo sviluppatore esamina il codice per individuare le classi e i metodi interessati.Genera diagrammi sequenza e diagrammi classi dal codice per descrivere e discutere le modifiche.Vedere Visualizzazione e comprensione del codice.
.gif "Suggerimento") Suggerimento |
|---|
Per verificare in tempo reale gli effetti di ciascuna modifica, generare nuovamente i grafici dipendenze e i diagrammi sequenza dal codice dopo ciascuna modifica. |
Per descrivere le modifiche apportate ad altre parti del sistema, ad esempio componenti o interazioni, si potrebbe disegnare questi elementi su lavagne.Inoltre, si potrebbe creare i seguenti diagrammi in Visual Studio in modo da consentire l'acquisizione, la comprensione e la gestione dei dettagli da parte di entrambi i team:
Diagrammi |
Oggetto di descrizione |
|---|---|
Diagramma attività (UML) Vedere: |
Il flusso dei passaggi eseguiti quando il sistema rileva che un cliente effettua un nuovo ordine presso un ristorante già utilizzato in precedenza e gli propone pertanto di scriverne la recensione. |
Diagramma classi (UML) Vedere: |
Le classi logiche e le relative relazioni.Ad esempio, viene aggiunta una nuova classe per descrivere una Recensione e le relative relazioni con altre entità, ad esempio Ristorante, Menu e Cliente. Per associare recensioni a un cliente, è necessario che nel sistema siano archiviati i dettagli del cliente.Un diagramma classi UML consente di definire più chiaramente tali dettagli. |
Diagramma classi basato sul codice Vedere Procedura: aggiungere diagrammi classi ai progetti (Progettazione classi). |
Le classi esistenti nel codice. |
Diagramma componente (UML) Vedere: |
Le parti generali del sistema, quali il sito Web Dinner Now e le relative interfacce.Queste interfacce definiscono le modalità di interazione reciproca dei componenti tramite i metodi o i servizi che forniscono e utilizzano. |
Diagramma sequenza (UML) Vedere: |
La sequenza delle interazioni tra le istanze. |
Ad esempio, il seguente diagramma componente mostra il nuovo componente, parte del componente sito Web Dinner Now.Il componente ElaborazioneRecensioni gestisce la funzionalità di creazione delle recensioni ed è evidenziato in arancione:
.png "Diagramma dei componenti UML")
Diagramma componente UML
Nel seguente diagramma sequenza viene mostrata la sequenza delle interazioni che si verificano quando nel sito Web Dinner Now viene verificato se il cliente ha già precedentemente effettuato un ordine presso un ristorante.In caso affermativo, richiede al cliente di scrivere una recensione, che verrà quindi inviata al ristorante e pubblicata dal sito Web:
.png "Diagramma di sequenza UML")
Diagramma sequenza UML
Mantenimento della coerenza del codice con la progettazione
Il team di Dinner Now deve assicurare la coerenza del codice aggiornato con la progettazione.Crea diagrammi livello che descrivono i livelli delle funzionalità del sistema, specificano le dipendenze consentite tra tali livelli e associano ai livelli gli elementi della soluzione.
Diagramma |
Oggetto di descrizione |
|---|---|
Diagramma livello Vedere: |
L'architettura logica del codice. Un diagramma livello organizza e mappa gli elementi di una soluzione di Visual Studio a gruppi astratti denominati livelli.Questi livelli identificano i ruoli, le attività o le funzioni svolte nel sistema da tali elementi. I diagrammi livello sono utili per descrivere la progettazione desiderata del sistema e, in base a questa, convalidare il codice in corso di sviluppo. Per creare livelli, trascinare gli elementi da Esplora soluzioni, da grafici dipendenze o da Esplora architettura.Per disegnare nuovi livelli, utilizzare la casella degli strumenti o fare clic con il pulsante destro del mouse sulla superficie del diagramma. Per visualizzare le dipendenze esistenti, fare clic con il pulsante destro del mouse sulla superficie del diagramma livello e scegliere Genera dipendenze.Per specificare le dipendenze desiderate, disegnare le nuove dipendenze. |
Ad esempio, nel seguente diagramma livello vengono illustrate le dipendenze tra i livelli e il numero di elementi associati a ciascuno di essi:
.png "Diagramma dei livelli di un sistema di pagamenti integrato")
Diagramma livello
Per assicurarsi che non si verifichino conflitti con la progettazione durante lo sviluppo del codice, i team utilizzano la convalida dei livelli su compilazioni che vengono eseguite in Team Foundation Build.Inoltre, creano un'attività di MSBuild personalizzata per richiedere la convalida dei livelli nelle relative operazioni di archiviazione.Per raccogliere gli errori di convalida, vengono utilizzati i rapporti di compilazione.
Vedere:
Suggerimenti generali per la creazione e l'utilizzo dei modelli
La maggior parte dei diagrammi consiste di nodi connessi tramite linee.Per ogni tipo di diagramma, nella casella degli strumenti sono disponibili tipi differenti di nodi e linee.
Per aprire la casella degli strumenti, scegliere Casella degli strumenti dal menu Visualizza.
Per creare un nodo, trascinarlo dalla casella degli strumenti nel diagramma.È necessario trascinare determinati tipi di nodi su nodi esistenti.Ad esempio, in un diagramma componente è necessario aggiungere una nuova porta a un componente esistente.
Per creare una linea o una connessione, fare clic sullo strumento appropriato nella casella degli strumenti, quindi sul nodo di origine e infine sul nodo di destinazione.È possibile tracciare alcune linee solo tra tipi determinati di nodi.Quando si sposta il puntatore su una possibile origine o destinazione, viene indicato se è possibile creare una connessione.
La creazione di elementi nei diagrammi UML comporta anche l'aggiunta di tali elementi a un modello comune.I diagrammi UML in un progetto di modello rappresentano visualizzazioni del modello stesso.Gli elementi di un diagramma livello fanno parte del progetto di modello, anche se non sono archiviati nel modello comune.
Scegliere Finestre dal menu Architettura, quindi selezionare Esplora modelli UML.
In alcuni casi, è possibile trascinare determinati elementi da Esplora modelli in un diagramma UML.Alcuni elementi dello stesso modello possono essere utilizzati in più diagrammi del medesimo tipo o di tipo differente per mostrare visualizzazioni alternative dell'architettura.Ad esempio, è possibile trascinare un componente in un altro diagramma componente o in un diagramma sequenza per utilizzarlo come attore.
Visual Studio Ultimate supporta UML 2.1.2.In questa procedura dettagliata sono descritte solo le funzionalità principali dei diagrammi UML nella versione corrente. Per un approfondimento di UML e del relativo utilizzo, si rimanda alle numerose pubblicazioni in commercio.
Vedere Sviluppo di modelli per la progettazione software.
Pianificazione e traccia del lavoro
I diagrammi di modellazione finali di Visual Studio sono integrati con Team Foundation Server in modo da pianificare, gestire e tenere traccia del lavoro più facilmente. Entrambi i team utilizzano modelli per identificare i test case e le attività di sviluppo e stimare il lavoro.Il team di Lucerne crea e collega gli elementi di lavoro di Team Foundation Server a elementi del modello, come casi di utilizzo o componenti.In tal modo è possibile monitorare lo stato di avanzamento e tenere traccia del lavoro in riferimento ai requisiti degli utenti,assicurandosi così che le modifiche continuino a soddisfare tali requisiti.
Man mano che il lavoro procede, i team aggiornano gli elementi di lavoro includendovi il tempo dedicato alle varie attività.Inoltre, monitorano e segnalano lo stato del lavoro tramite le seguenti funzionalità di Team Foundation Server:
Rapporti di burn-down giornalieri che mostrano se il lavoro pianificato verrà completato nei tempi previsti.Altri rapporti analoghi vengono generati da Team Foundation Server per tenere traccia dei bug.
Un foglio di lavoro delle iterazioni basato su Microsoft Excel consente al team di monitorare e bilanciare il carico di lavoro fra i membri.Questo foglio di lavoro è collegato a Team Foundation Server e fornisce un elemento di focalizzazione tematica per la discussione durante le riunioni periodiche sullo stato di avanzamento.
Una dashboard di sviluppo basata su Office Project che consente al team di tenersi al corrente sulle informazioni importanti del progetto.
Vedere:
Creare, personalizzare e gestire rapporti per Visual Studio ALM
Pianificare le attività e assegnare le risorse tramite Microsoft Project
Test, convalida e archiviazione del codice aggiornato
Quando i team completano ogni attività, controllano il codice nel controllo della versione di Team Foundation e ricevono promemoria da Team Foundation Server, se si dimenticano.Prima che le archiviazioni vengano accettate da Team Foundation Server, i team devono eseguire gli unit test e la convalida dei livelli per verificare il codice in base ai test case e alla progettazione.Utilizzano Team Foundation Server per eseguire le compilazioni, gli unit test automatizzati e la convalida dei livelli.Ciò consente di verificare che il codice soddisfi i criteri seguenti:
Il codice viene eseguito regolarmente.
Il codice non impedisce l'esecuzione di codice precedentemente funzionante.
Il codice non è in conflitto con la progettazione.
Dinner Now dispone di una raccolta molto ampia di test automatizzati, che nella quasi totalità dei casi possono essere riutilizzati da Lucerne in quanto applicabili ai nuovi scenari.Lucerne può inoltre estendere questi test e aggiungerne di nuovi per analizzare nuove funzionalità.Entrambi i team utilizzano Visual Studio Ultimate per eseguire i test manuali.
Per assicurarsi che il codice sia conforme alla progettazione, i team configurano le compilazioni in Team Foundation Build per includere la convalida dei livelli. Se si verifica un conflitto, viene generato un rapporto con i dettagli.
Vedere:
Aggiornamento del sistema mediante gli strumenti di visualizzazione e di modellazione
Lucerne e Dinner Now devono integrare i relativi sistemi di pagamento.Nelle sezioni seguenti sono indicati i diagrammi di modellazione di Visual Studio ultimate che consentono di eseguire questa attività:
Comprensione dei requisiti utente: diagrammi caso di utilizzo
Comprensione del processo aziendale: diagrammi attività
Descrizione della struttura del sistema: diagrammi componente
Descrizione delle interazioni: diagrammi sequenza
Visualizzazione del codice esistente: grafici dipendenze
Definizione di un glossario di tipi: diagrammi classi
Descrizione dell'architettura logica: diagrammi livello
Vedere:
Comprensione dei requisiti utente: diagrammi caso di utilizzo
I diagrammi caso di utilizzo riepilogano le attività supportate ed eseguite da un sistema.Lucerne utilizza un diagramma caso di utilizzo per ottenere le seguenti informazioni sul sistema di Dinner Now:
I clienti creano gli ordini.
I ristoranti ricevono gli ordini.
Il gateway esterno per l'elaborazione dei pagamenti, utilizzato dal sistema di Dinner Now per convalidare i pagamenti, non rientra nell'ambito del sito Web.
Il diagramma mostra anche la suddivisione di alcuni dei principali casi di utilizzo in casi di utilizzo più piccoli.Lucerne desidera utilizzare il proprio sistema di pagamento.Il team evidenzia pertanto il caso di utilizzo Elaborazione dei pagamenti in un colore differente per indicare che sono richieste modifiche:
.png "Evidenziazione di Elaborazione dei pagamenti in un diagramma caso di utilizzo")
Evidenziazione di Elaborazione dei pagamenti nel diagramma caso di utilizzo
Se il tempo a disposizione per lo sviluppo è scarso, il team può discutere l'opportunità di fare in modo che i clienti paghino direttamente i ristoranti.Per mostrare questo approccio, sostituirà il caso di utilizzo Elaborazione dei pagamenti con un altro esterno ai limiti del sistema di Dinner Now.Quindi, collegherà Cliente direttamente a Ristorante, indicando così che Dinner Now si limiterà a elaborare gli ordini:
.png "Modifica dell'ambito di Pagamento ristorante nel diagramma caso di utilizzo")
Modifica dell'ambito di Pagamento ristorante nel diagramma caso di utilizzo
Vedere:
Creazione di un diagramma caso di utilizzo
Le caratteristiche principali di un diagramma caso di utilizzo sono le seguenti:
Attori: rappresentano i ruoli svolti da persone, organizzazioni, computer o sistemi software.Sono ad esempio attori Cliente, Ristorante e il sistema di pagamento di Dinner Now.
Casi di utilizzo: rappresentano le interazioni tra gli attori e il sistema in corso di sviluppo.Possono rappresentare interazioni di qualsiasi dimensione, da un semplice clic del mouse o messaggio a una transazione di più giorni.
Associazioni: collegano gli attori ai casi di utilizzo.
Un caso di utilizzo più grande può includere casi di utilizzo più piccoli; ad esempio, Creazione dell'ordine include Selezione del ristorante.È possibile estendere un caso di utilizzo, aggiungendo obiettivi e passaggi, per indicare che il caso di utilizzo si verifica solo a determinate condizioni.I casi di utilizzo possono inoltre ereditare l'uno dall'altro.
Sottosistema: rappresenta il sistema software in corso di sviluppo o uno dei suoi componenti.È rappresentato da una grande casella che contiene i casi di utilizzo.Un diagramma caso di utilizzo consente di definire gli elementi interni o esterni ai limiti del sottosistema.Per indicare che l'utente deve portare a termine determinati obiettivi in altri modi, creare questi casi di utilizzo all'esterno dei limiti del sottosistema.
Elementi: collegano gli elementi del diagramma ad altri diagrammi o documenti.
Vedere:
Riepilogo: vantaggi dei diagrammi caso di utilizzo
I diagrammi caso di utilizzo consentono di visualizzare:
Le attività supportate o meno da un sistema.
Le persone e i sistemi esterni che eseguono tali attività.
I componenti principali del sistema che supportano ciascuna attività e che è possibile rappresentare come sottosistemi annidati nel sistema padre.
La divisibilità di un caso di utilizzo in casi di utilizzo o variazioni più piccole.
Relazione con altri diagrammi
Diagramma |
Oggetto di descrizione |
|---|---|
Diagramma attività |
Il flusso dei passaggi di un caso di utilizzo e i soggetti che li eseguono. I nomi dei casi di utilizzo rispecchiano spesso i passaggi di un diagramma attività.I diagrammi attività supportano elementi quali le decisioni, le unioni, gli input e gli output, i flussi simultanei e così via. Vedere: |
Diagramma sequenza |
La sequenza delle interazioni tra i partecipanti di un caso di utilizzo. Vedere: |
Diagramma classi (UML) |
Le entità o i tipi che partecipano al caso di utilizzo. Vedere: |
Comprensione del processo aziendale: diagrammi attività
I diagrammi attività descrivono il flusso dei passaggi di un processo aziendale e consentono di comunicare facilmente un flusso di lavoro.Un progetto di sviluppo può disporre di più diagrammi attività.Generalmente, un'attività include tutte le azioni che sono il risultato di un'azione esterna, ad esempio l'ordinazione di un pasto, l'aggiornamento di un menu o l'aggiunta di un nuovo ristorante all'attività commerciale.Un'attività potrebbe anche descrivere i dettagli di un'azione complessa.
Il team di Lucerne aggiorna il seguente diagramma attività per mostrare che la società elabora il pagamento e paga il ristorante.Il sistema di pagamento di Dinner Now viene sostituito con quello di Lucerne come evidenziato:
.png "Sistema di pagamento di Lucerne nel diagramma delle attività")
Sostituzione del sistema di pagamento di Dinner Now nel diagramma attività
Il diagramma aggiornato consente a Lucerne e Dinner Now di verificare in quale fase del processo aziendale entra in funzione il sistema di pagamento di Lucerne.Nella versione corrente, i commenti sono utilizzati per identificare i ruoli che eseguono i passaggi.Le linee sono utilizzate per creare corsie, le quali permettono di organizzare i passaggi in base al ruolo.
I team potrebbero prendere in esame una storia alternativa, in cui il cliente paga il ristorante alla consegna.Questa modifica produrrebbe una variazione dei requisiti del sistema software.
In precedenza, il team di Dinner Now disegnava questi diagrammi su una lavagna o in PowerPoint.Adesso, li crea utilizzando anche Visual Studio Ultimate, in modo che entrambi i team possano acquisire, comprendere e gestire i dettagli.
Vedere:
Creazione di un diagramma attività
Le caratteristiche principali di un diagramma attività sono le seguenti:
Nodo iniziale: indica la prima azione dell'attività.
Il diagramma deve disporre sempre di uno di questi nodi.
Azioni: descrivono i passaggi in cui l'utente o il software esegue un'attività.
Flussi di controllo: mostrano il flusso del controllo tra le azioni.
Nodi decisione: rappresentano rami condizionali del flusso.
Nodi fork: suddividono i singoli flussi in flussi simultanei.
Nodi finali attività: mostrano la fine dell'attività.
Per quanto facoltativa, l'inclusione di questi nodi nel diagramma è utile per mostrare dove termina l'attività.
Vedere:
Riepilogo: vantaggi dei diagrammi attività
I diagrammi attività consentono di visualizzare e descrivere il flusso del controllo e delle informazioni tra le azioni di un'azienda, di un sistema o di un programma.Sono uno strumento semplice e utile per descrivere il flusso di lavoro quando si comunica con altre persone.
Relazione con altri diagrammi
Diagramma |
Descrizione |
|---|---|
Diagramma caso di utilizzo |
Un riepilogo delle attività eseguite da ciascun attore. Vedere: |
Diagramma componente |
Il sistema come raccolta di parti riutilizzabili che forniscono o utilizzano il comportamento tramite un set ben definito di interfacce. Vedere: |
Descrizione della struttura del sistema: diagrammi componente
I diagrammi componente descrivono un sistema come una raccolta di parti separabili che forniscono o utilizzano il comportamento tramite un set ben definito di interfacce.Tali parti possono essere di qualsiasi dimensione e possono essere connesse in qualsiasi modo.
Per aiutare Lucerne e Dinner Now a visualizzare e discutere i componenti del sistema e le relative interfacce, i team creano i seguenti diagrammi componente:
.png "Componenti esterni del sistema di pagamento")
Componenti del sistema di pagamento di Dinner Now
Questo diagramma mostra i differenti tipi di componente e le relative dipendenze.Ad esempio, per convalidare i pagamenti, tanto il sito Web Dinner Now quanto il sistema di pagamenti di Lucerne necessitano del gateway esterno per l'elaborazione dei pagamenti.Le frecce che connettono i componenti rappresentano le dipendenze, che indicano quali componenti richiedono le funzionalità di altri componenti.
Per utilizzare il sistema di pagamento di Lucerne, il sito Web Dinner Now deve essere aggiornato per l'utilizzo delle interfacce ApprovazionePagamenti e InserimentoCrediti nel sistema di pagamento di Lucerne.
Il seguente diagramma mostra una specifica configurazione di componenti per il sito Web Dinner Now.La configurazione indica che ogni istanza del sito Web è costituita da quattro parti:
ElaborazioneClienti
ElaborazioneOrdini
ElaborazioneRecensioni
ElaborazionePagamenti
Queste parti sono istanze dei tipi di componente specificati e sono connesse come segue:
.png "Componenti interni al sito Web Dinner Now")
Componenti interni al sito Web Dinner Now
Il sito Web delega il comportamento a queste parti, che ne gestiscono le funzioni.Le frecce che connettono il componente padre e i relativi componenti membro mostrano le deleghe, che indicano quali parti gestiscono i messaggi che il padre riceve o invia tramite le relative interfacce.
In questa configurazione, il componente ElaborazionePagamenti elabora i pagamenti dei clienti.Pertanto, deve essere aggiornato per integrarsi con il sistema di pagamento di Lucerne.In altri scenari, più istanze di un tipo di componente potrebbero esistere nello stesso componente padre.
Vedere:
Creazione di un diagramma componente
Le caratteristiche principali di un diagramma componente sono le seguenti:
Componenti: rappresentano porzioni separabili di funzionalità del sistema.
Porte dell'interfaccia fornite: rappresentano gruppi di messaggi o di chiamate implementate dai componenti e utilizzate da altri componenti o sistemi esterni.
Porte dell'interfaccia richieste: rappresentano gruppi di messaggi o di chiamate inviate dai componenti a altri componenti o sistemi esterni.Questo tipo di porta descrive le operazioni minime previste per un componente da parte di altri componenti o sistemi esterni.
Parti: membri dei componenti e generalmente istanze di altri componenti.Una parte è una porzione della progettazione interna del componente padre.
Dipendenze: indicano i componenti che richiedono le funzionalità di altri componenti.
Deleghe: indicano le parti di un componente che gestiscono i messaggi inviati o ricevuti dal componente padre.
Vedere:
Riepilogo: vantaggi dei diagrammi componente
I diagrammi componente consentono di visualizzare:
Il sistema come una raccolta di parti separabili indipendentemente dal linguaggio o dallo stile di implementazione.
I componenti con interfacce ben definite, rendendo la progettazione più facile da comprendere e da aggiornare in caso di variazione dei requisiti.
Relazione con altri diagrammi
Diagramma |
Descrizione |
|---|---|
Grafico dipendenze |
L'organizzazione e le relazioni nel codice esistente. Per identificare i candidati per i componenti, creare un grafico dipendenze e raggruppare gli elementi in base alla funzione che svolgono nel sistema. Vedere: |
Diagramma sequenza |
La sequenza delle interazioni tra i componenti o le parti di un componente. Per creare una linea di vita in un diagramma sequenza da un componente, fare clic con il pulsante destro del mouse sul componente e scegliere Crea linea di vita. Vedere: |
Diagramma classi (UML) |
Le interfacce sulle porte fornite o richieste e le classi che implementano le funzionalità dei componenti. Vedere: |
Diagramma livello |
L'architettura logica del sistema in relazione ai componenti.Utilizzare la convalida dei livelli per assicurare la coerenza del codice con la progettazione. Vedere: |
Diagramma attività |
L'elaborazione interna eseguita dai componenti in risposta ai messaggi in arrivo. Vedere: |
Visualizzazione del codice esistente: grafici dipendenze
I grafici dipendenze mostrano l'organizzazione e le relazioni correnti nel codice.Gli elementi sono rappresentati nel grafico mediante nodi e le relazioni mediante collegamenti.I grafici dipendenze consentono di effettuare i seguenti tipi di attività:
Esplorare il codice con cui si ha poca familiarità.
Comprendere dove e in che modo una modifica proposta potrebbe influire sul codice esistente.
Individuare aree di complessità, livelli o modelli naturali o altre aree suscettibili di miglioramento.
Ad esempio, si supponga che Dinner Now debba stimare il costo dell'aggiornamento del componente ElaborazionePagamenti.Tale costo dipende in parte dall'impatto che tale modifica avrà su altre parti del sistema.Per facilitare il compito, uno degli sviluppatori di Dinner Now genera i grafici dipendenze dal codice e ne modifica l'ambito limitandolo alle aree che potrebbero essere interessate dalla modifica.
Il seguente grafico mostra le dipendenze tra la classe ElaborazionePagamenti e le altre parti del sistema di Dinner Now, che appaiono selezionate:
.png "Grafico delle dipendenze per il sistema di pagamento di Dinner Now")
Grafico dipendenze per il sistema di pagamento di Dinner Now
Lo sviluppatore esplora il grafico espandendo la classe ElaborazionePagamenti e selezionandone i membri per visualizzare le aree potenzialmente interessate:
.png "Metodi interni a ElaborazionePagamenti e dipendenze")
Metodi interni alla classe ElaborazionePagamenti e relative dipendenze
Viene generato il grafico seguente per consentire il controllo delle classi, dei metodi e delle dipendenze del sistema di pagamento di Lucerne.Il team si rende conto che potrebbe essere necessario apportare modifiche anche al sistema di Lucerne, per consentirne l'interazione con le altre parti di Dinner Now:
.png "Grafico delle dipendenze per il sistema di pagamento di Lucerne")
Grafico dipendenze per il sistema di pagamento di Lucerne
I due team collaborano per determinare le modifiche richieste per integrare i due sistemie decidono di effettuare il refactoring di parte del codice per facilitarne l'aggiornamento.La classe RespApprovazionePagamenti verrà spostata nello spazio dei nomi DinnerNow.Business e richiederà alcuni nuovi metodi.Le classi di Dinner Now che gestiscono le transazioni disporranno di uno spazio dei nomi distinto.I team creano e utilizzano elementi di lavoro per pianificare, organizzare e tenere traccia del lavoro.Ove sia utile, collegano gli elementi di lavoro agli elementi del modello.
Dopo avere riorganizzato il codice, i team generano un nuovo grafico dipendenze per verificare la struttura e le relazioni aggiornate:
.png "Grafico delle dipendenze con codice riorganizzato")
Grafico dipendenze con codice riorganizzato
Questo grafico mostra come la classe RespApprovazionePagamenti si trovi ora nello spazio dei nomi DinnerNow.Business e disponga di alcuni nuovi metodi.Le classi di transazione di Dinner Now dispongono adesso di uno spazio dei nomi SistemaPagamento distinto, che faciliterà in seguito la gestione del codice.
Creazione di un grafico dipendenze
Per una rapida panoramica del codice sorgente, attenersi alla seguente procedura per generare un grafico dipendenze:
Scegliere Genera grafico dipendenze dal menu Architettura, quindi Per soluzione.
Per una rapida panoramica del codice compilato, creare un grafico dipendenze vuoto, quindi trascinare file di assembly o file eseguibili nella superficie del grafico.
Vedere Visualizzare le dipendenze di codice nei grafici dipendenze.
Per esplorare elementi specifici del codice o della soluzione, utilizzare Esplora architettura o Esplora Soluzioni per selezionare gli elementi e le relazioni che si desidera visualizzare.Sarà quindi possibile generare un nuovo grafico o aggiungere elementi selezionati a un grafico esistente.
Vedere Visualizzare le dipendenze di codice nei grafici dipendenze e Trovare codice con Esplora architettura.
Per esplorare agevolmente il grafico, ridisporre il layout in base ai tipi di attività che si desidera eseguire.
Ad esempio per visualizzare i livelli nel codice, selezionare un layout con struttura ad albero.Vedere Cercare e ridisporre grafici dipendenze.
Per concentrarsi su aree specifiche del grafico, modificarne l'ambito filtrando gli elementi o personalizzandone l'aspetto.Vedere Modificare e personalizzare grafici dipendenze.
Riepilogo: vantaggi dei grafici dipendenze
Con i grafici dipendenze è possibile:
Ottenere informazioni sull'organizzazione e sulle relazioni nel codice esistente.
Individuare le aree sulle quali potrebbe influire una modifica proposta.
Individuare aree di complessità, modelli, livelli o altre aree suscettibili di miglioramento, per rendere il codice più facile da gestire, modificare e riutilizzare.
Relazione con altri diagrammi
Diagramma |
Oggetto di descrizione |
|---|---|
Diagramma livello |
L'architettura logica del sistema.Utilizzare la convalida dei livelli per assicurare la coerenza del codice con la progettazione. Per identificare più facilmente i livelli esistenti o desiderati, creare un grafico dipendenze e raggruppare gli elementi correlati.Per creare un diagramma livello, trascinare gli elementi dal grafico o da Esplora architettura. Vedere: |
Diagramma componente |
I componenti e le relative interfacce e relazioni. Per identificare più facilmente i componenti, creare un grafico dipendenze e raggruppare gli elementi in base alla funzione che svolgono nel sistema. Vedere: |
Diagramma classi (UML) |
Le classi e i relativi attributi, operazioni e relazioni. Per identificare più facilmente questi elementi, creare un documento grafico in cui siano visualizzati. Vedere: |
Diagramma classi (basato sul codice) |
Le classi esistenti nel codice. Per visualizzare e modificare una classe esistente nel codice, utilizzare Progettazione classi. Vedere Procedura: aggiungere diagrammi classi ai progetti (Progettazione classi). |
Descrizione delle interazioni: diagrammi sequenza
I diagrammi sequenza descrivono una serie di interazioni tra le parti di un sistema.Tali parti possono essere di qualsiasi dimensione,da singoli oggetti di un programma a grandi sottosistemi o attori esterni.Le interazioni possono essere di qualsiasi dimensione e tipo,da singoli messaggi a transazioni estese e da chiamate di funzione a messaggi di servizio Web.
Per aiutare Lucerne e Dinner Now a descrivere e discutere i passaggi del caso di utilizzo Elaborazione dei pagamenti, viene creato dal diagramma componente il seguente diagramma sequenza.Le linee di vita rispecchiano il componente Sito Web Dinner Now e le relative parti.I messaggi visualizzati tra le linee di vita seguono le connessioni sui diagrammi componente:
.png "Diagramma sequenza per il caso di utilizzo Elaborazione dei pagamenti")
Diagramma sequenza per il caso di utilizzo Elaborazione dei pagamenti
Il seguente diagramma sequenza mostra come, quando il cliente crea un ordine, il sito Web Dinner Now chiama ElaboraOrdine su un'istanza di ElaborazioneOrdini.Quindi, ElaborazioneOrdini chiama ElaboraPagamento su ElaborazionePagamenti.Tale processo continua finché il gateway esterno per l'elaborazione dei pagamenti non convalida il pagamento.Solo a quel punto il controllo torna al sito Web Dinner Now.
Lucerne deve stimare il costo di aggiornamento del sistema di pagamento per l'integrazione con il sistema di Dinner Now.Per facilitare il compito, uno degli sviluppatori genera i diagrammi sequenza dal codice per visualizzare le interazioni esistenti.
Vedere:
Creazione di un diagramma sequenza
Le caratteristiche principali di un diagramma sequenza sono le seguenti:
Linee di vita verticali: rappresentano attori o istanze di oggetti del software.
Per aggiungere un simbolo Attore, che indica un partecipante esterno al sistema in corso di sviluppo, fare clic sulla linea di vita.Nella finestra Proprietà impostare Actor su True.Se la finestra Proprietà non è visualizzata, premere F4.
Messaggi orizzontali: rappresentano chiamate ai metodi, messaggi di servizio Web o altre comunicazioni.Occorrenze dell'esecuzione: rettangoli ombreggiati verticali che vengono visualizzati sulle linee di vita e rappresentano i periodi durante i quali gli oggetti riceventi elaborano le chiamate.
Durante un messaggio sincrono, l'oggetto mittente attende che il controllo passi a <<torna>>, come in una normale chiamata di funzione.Durante un messaggio asincrono, il mittente può continuare immediatamente.
Utilizzare i messaggi di tipo <<crea>> per indicare la costruzione di oggetti da parte di altri oggetti.Dovrebbe essere il primo messaggio inviato all'oggetto.
Vedere:
Riepilogo: vantaggi dei diagrammi sequenza
I diagrammi sequenza consentono di visualizzare:
Il flusso del controllo trasferito tra attori o oggetti durante l'esecuzione di un caso di utilizzo.
L'implementazione di una chiamata a metodo o di un messaggio.
Relazione con altri diagrammi
Diagramma |
Descrizione |
|---|---|
Diagramma classi (UML) |
Le classi rappresentate dalle linee di vita e i parametri e i valori restituiti utilizzati in messaggi inviati tra le linee di vita. Per creare una classe da una linea di vita, fare clic con il pulsante destro del mouse sulla linea di vita, quindi scegliere Crea classe o Crea interfaccia.Per creare una linea di vita da un tipo in un diagramma classi, fare clic con il pulsante destro del mouse sul tipo e scegliere Crea linea di vita. Vedere: |
Diagramma componente |
I componenti rappresentati dalle linee di vita e le interfacce che forniscono e utilizzano il comportamento rappresentato dai messaggi. Per creare una linea di vita da un diagramma componente, fare clic con il pulsante destro del mouse sul componente e scegliere Crea linea di vita. Vedere: |
Diagramma caso di utilizzo |
Un riepilogo delle interazioni tra utenti e componenti in un diagramma sequenza sotto forma di caso di utilizzo, che rappresenta l'obiettivo di un utente. Vedere: |
Definizione di un glossario di tipi: diagrammi classi
I diagrammi classi definiscono le entità, i termini o i concetti che fanno parte del sistema e le reciproche relazioni.Ad esempio, è possibile utilizzare questi diagrammi durante lo sviluppo per descrivere gli attributi e le operazioni per ciascuna classe, indipendentemente dal linguaggio o dallo stile di implementazione.
Per aiutare Lucerne e Dinner Now a descrivere e discutere le entità che partecipano al caso di utilizzo Elaborazione dei pagamenti, viene creato il seguente diagramma classi:
.png "Entità Elabora pagamento nel diagramma classi")
Entità Elabora pagamento in un diagramma classi
Questo diagramma mostra che a un cliente possono essere associati più ordini e modalità di pagamento differenti.ContoBancario e CartaDiCredito ereditano da Pagamento.
Durante lo sviluppo, Lucerne utilizza il seguente diagramma classi seguente per descrivere e discutere i dettagli di ciascuna classe:
.png "Dettagli dell'entità Elabora pagamento in un diagramma classi")
Dettagli di Elabora pagamento nel diagramma classi
Vedere:
Creazione di un diagramma classi
Le caratteristiche principali di un diagramma classi sono le seguenti:
Tipi quali classi, interfacce ed enumerazioni:
Classe: una definizione di oggetti che condividono caratteristiche strutturali o comportamentali specifiche.
Interfaccia: una definizione di una parte del comportamento visibile esternamente di un oggetto.
Enumerazione: un classificatore che contiene un elenco di valori letterali.
Attributi: valori di un tipo determinato che descrivono ogni istanza di un classificatore.Un classificatore è un nome generale per tipi, componenti, casi di utilizzo e persino attori.
Operazioni: metodi o funzioni che possono essere eseguite dalle istanze di un classificatore.
Associazione: indica un tipo di relazione tra due classificatori.
Aggregazione: un'associazione che indica una proprietà condivisa tra classificatori.
Composizione: un'associazione che indica una relazione di una parte con il tutto tra classificatori.
Per mostrare aggregazioni o composizioni, impostare la proprietà Aggregation su un'associazione.Shared consente di mostrare le aggregazioni e Composite di mostrare le composizioni.
Dipendenza: indica che la modifica della definizione di un classificatore potrebbe comportare la modifica della definizione di un altro classificatore.
Generalizzazione: indica che uno specifico classificatore eredita parte della definizione da un classificatore generale.Realizzazione: indica che una classe implementa le operazioni e gli attributi offerti da un'interfaccia.
Per creare le relazioni, utilizzare lo strumento Ereditarietà.In alternativa, una realizzazione può essere rappresentata come simbolo.
Pacchetti: gruppi di classificatori, associazioni, linee di vita, componenti e altri pacchetti.Importazione: relazione che indica che un pacchetto include tutte le definizioni di un altro pacchetto.
Come punto di partenza per esplorare e discutere le classi esistenti, è possibile utilizzare Progettazione classi per creare diagrammi classi dal codice.
Vedere:
Riepilogo: vantaggi dei diagrammi classi
I diagrammi classi consentono di definire:
Un glossario di termini comune da utilizzare quando si discutono le esigenze degli utenti e le entità che partecipano al sistema.Vedere Modellazione dei requisiti utente.
I tipi utilizzati dalle parti del sistema, ad esempio i componenti, indipendentemente dall'implementazione.Vedere Modellazione dell'architettura di un sistema software.
Le relazioni tra tipi, quali le dipendenze.Ad esempio, è possibile mostrare che un tipo può essere associato a più istanze di un altro tipo.
Relazione con altri diagrammi
Diagramma |
Descrizione |
|---|---|
Diagramma caso di utilizzo |
I tipi utilizzati per descrivere gli obiettivi e i passaggi dei casi di utilizzo. Vedere: |
Diagramma attività |
I tipi di dati passati mediante nodi oggetto, pin di input, pin di output e nodi parametro attività. Vedere: |
Diagramma componente |
I componenti e le relative interfacce e relazioni.È possibile descrivere un componente completo anche tramite una classe. Vedere: |
Diagramma livello |
L'architettura logica del sistema in relazione alle classi. Utilizzare la convalida dei livelli per assicurare la coerenza del codice con la progettazione. Vedere: |
Diagramma sequenza |
I tipi di linee di vita e le operazioni, i parametri e i valori restituiti per tutti i messaggi che la linea di vita può ricevere. Per creare una linea di vita da un tipo in un diagramma classi, fare clic con il pulsante destro del mouse sul tipo e scegliere Crea linea di vita. Vedere: |
Grafico dipendenze |
L'organizzazione e le relazioni nel codice esistente. Per identificare le classi e le relative relazioni e metodi, creare un documento grafico che mostra quegli elementi. Vedere: |
Descrizione dell'architettura logica: diagrammi livello
I diagrammi livello consentono di descrivere l'architettura logica di un sistema organizzando gli elementi della soluzione in gruppi astratti o livelli.Gli elementi possono essere di vario genere, ad esempio spazi dei nomi, progetti, classi, metodi e così via.I livelli rappresentano i ruoli o le attività svolte nel sistema da tali elementi.È anche possibile includere la convalida dei livelli nella compilazione e operazioni di archiviazione per assicurare la coerenza del codice con la progettazione.
Per assicurarsi che il codice sia coerente con la progettazione, Dinner Now e Lucerne utilizzano il seguente diagramma livello per convalidare il codice di volta in volta modificato:
Diagramma livello di Dinner Now integrato con Lucerne
I livelli di questo diagramma sono collegati ai corrispondenti elementi delle soluzioni di Dinner Now e Lucerne.Ad esempio, il livello Business è collegato allo spazio dei nomi DinnerNow.Business e i relativi membri, che ora includono la classe RespApprovazionePagamenti.Il livello Accesso risorse è collegato allo spazio dei nomi DinnerNow.Dati.Le frecce, o dipendenze, specificano che solo il livello Business può utilizzare le funzionalità del livello Accesso risorse.Man mano che aggiornano il codice, i team eseguono regolarmente la convalida dei livelli per intercettare i conflitti che si verificano di volta in volta e risolverli prontamente.
I team collaborano per integrare e testare in modo incrementale i due sistemi.Prima di occuparsi di ElaborazionePagamenti, verificano il corretto funzionamento di RespApprovazionePagamenti con gli altri componenti di Dinner Now.
Il seguente grafico dipendenze mostra le nuove chiamate tra Dinner Now e RespApprovazionePagamenti:
.png "Grafico delle dipendenze aggiornato con il sistema integrato")
Grafico dipendenze con le chiamate a metodi aggiornate
Una volta verificato che il sistema funziona come previsto, il team di Dinner Now inserisce commenti nel codice di ElaborazionePagamenti.I rapporti di convalida dei livelli non segnalano problemi e il grafico dipendenze risultante mostra che non esistono altre dipendenze di ElaborazionePagamenti:
.png "Grafico delle dipendenze senza ElaborazionePagamenti")
Grafico dipendenze senza ElaborazionePagamenti
Vedere:
Creazione di un diagramma livello
Le caratteristiche principali di un diagramma livello sono le seguenti:
Livelli: descrivono gruppi logici di elementi.
Collegamento: un'associazione tra un livello e un elemento.
Per creare livelli dagli elementi, trascinare gli elementi da Esplora soluzioni, da grafici dipendenze o da Esplora architettura.Per disegnare nuovi livelli e collegarli agli elementi, utilizzare la casella degli strumenti o fare clic con il pulsante destro del mouse sulla superficie del diagramma per creare i livelli, quindi trascinare nei livelli gli elementi desiderati.
Il numero raffigurato sul livello indica il numero di elementi a esso collegati.Tali elementi possono essere spazi dei nomi, progetti, classi, metodi e così via.Quando si interpreta il numero degli elementi di un livello, tenere a mente quanto segue:
Se un livello è collegato a un elemento contenente altri elementi, ma non è collegato direttamente ad altri elementi, il numero include solo l'elemento collegato.Tuttavia, gli altri elementi vengono inclusi per l'analisi durante la convalida dei livelli.
Ad esempio, se un livello è collegato a un solo spazio dei nomi, il numero degli elementi collegati sarà 1, anche se lo spazio dei nomi contiene classi.Se il livello è collegato anche a ciascuna classe dello spazio dei nomi, il numero includerà le classi collegate.
Se un livello contiene altri livelli collegati a elementi, anche il livello contenitore sarà collegato a tali elementi nonostante il numero raffigurato sul livello contenitore non includa quegli elementi.
Per visualizzare gli elementi collegati a un livello, fare clic con il pulsante destro del mouse sul livello e scegliere Visualizza collegamenti per aprire Esplora livello.
Dipendenza: indica che un livello può utilizzare le funzionalità di un altro livello, ma non viceversa.Dipendenza bidirezionale: indica che un livello può utilizzare le funzionalità di un altro livello e viceversa.
Per visualizzare le dipendenze esistenti nel diagramma livello, fare clic con il pulsante destro del mouse sulla superficie del diagramma e scegliere Genera dipendenze.Per descrivere le dipendenze desiderate, disegnarne di nuove.
Vedere:
Riepilogo: vantaggi dei diagrammi livello
Con i diagrammi livello è possibile:
Descrivere l'architettura logica di un sistema in base alle funzionalità degli elementi.
Assicurarsi che il codice in corso di sviluppo sia conforme alla progettazione specificata.
Relazione con altri diagrammi
Diagramma |
Descrizione |
|---|---|
Grafico dipendenze |
L'organizzazione e le relazioni nel codice esistente. Per creare livelli, generare un grafico dipendenze e quindi raggruppare gli elementi del grafico come potenziali livelli.Trascinare i gruppi dal grafico nel diagramma livello. Vedere: |
Diagramma componente |
I componenti e le relative interfacce e relazioni. Per visualizzare i livelli, creare un diagramma componente che descrive le funzionalità dei differenti componenti del sistema. Vedere: |
Risorse esterne
Category |
Collegamenti |
|---|---|
Forum |
|
Blog |
|
Articoli e pubblicazioni tecniche |
|
Altri siti |
Vedere anche
Concetti
Visualizzazione e comprensione del codice
Sviluppo di modelli per la progettazione software
Utilizzo di modelli nel processo di sviluppo
Utilizzo di modelli in Agile Development