Occorre modellare l'analisi del documento?

5

Io uso UML

Io, come la maggior parte (credo), uso UML come set di strumenti per il diagramma principale. UML è chiaro e utile per rappresentare OOP e ha diagrammi sufficientemente diversi che c'è qualcosa per qualsiasi area si sta modellando; che si tratti di alberi di classi, relazioni di componenti o interazioni specifiche tra classi.

Ciò significa che ho un solo modello

UML è chiaramente progettato per rappresentare il dominio implementato.

I diagrammi di classi e oggetti sono piuttosto espliciti; comprendono metodi e proprietà che raramente possono essere definiti con certezza fino a quando non si decidono dettagli specifici dell'implementazione. Allo stesso modo, i diagrammi comportamentali presentano interazioni tra gli oggetti (messaggi inviati, l'ordine inviato, ecc.).

Tuttavia, i primi modelli analitici sono raramente così espliciti. Per il contesto, mi avvicino alla mia analisi iniziale come segue:

  1. Descrivi i casi d'uso da soddisfare; con scenari che descrivono l'input dell'attore e la risposta del sistema
  2. Descrivi le interazioni da soddisfare; questo componente / pacchetto / dominio deve avere l'interfaccia X e deve supportare una conversazione come ...
  3. Descrivi i processi realizzati dal dominio; questo dominio deve eseguire X e questo è il flusso di lavoro

Da qui ho una chiara serie di requisiti e inizio ad analizzare il dominio del problema stesso; definizione di oggetti / classi, le loro associazioni, il tipo di informazioni in loro possesso e i tipi di operazioni che supportano. Infine, passo alla progettazione dettagliata che fornisce tutte le classi a livello di implementazione, concretizza i metodi esatti e le proprietà delle classi definite nel dominio problematico, ecc.

Uso UML dall'inizio alla fine, ma finisco solo con il modello definito dalla parte di progettazione del processo. Tutto ciò che viene creato durante l'analisi finisce per essere rivisto e perfezionato, ottimizzato e sollecitato fino a quando non è lo stesso del progetto implementato. Vale a dire, ho solo un modello di implementazione, non un modello analitico .

Esiste un solo modello perché ...

In breve, UML incoraggia specifiche. Quando creo il mio modello analitico, le classi che creo hanno metodi con parametri ecc. Quando passo all'attuazione, questi cambiano e sembra assurdo lasciare due modelli direttamente in conflitto tra loro.

UML mi incoraggia a scrivere i dettagli di implementazione durante l'analisi perché gli stessi diagrammi, e quindi il linguaggio, vengono utilizzati durante entrambe le attività.

È auspicabile?

Dovrei adottare uno strumento di modellazione meno dettagliato per l'analisi in modo che non finisca per essere incluso nel modello di implementazione?

O è bello avere un solo modello?

    
posta Marvin 06.03.2016 - 23:55
fonte

2 risposte

4

Penso che i post di Martin Fowler sulle modalità UML - UML come schizzo , UML come note , UML come progetto e UML come lingua di programmazione ti sarà utile. Penso anche che il lavoro di Scott Ambler su Agile Modeling, in particolare i suoi scritti su Model Storming e Solo abbastanza buoni modelli e documenti , sono anche molto pertinenti.

Non sono d'accordo con la tua affermazione che "UML incoraggia specificità". UML non è un processo. Ci sono processi che sono incentrati su UML. Il Rational Unified Process, ad esempio, viene spesso insegnato in combinazione con i vari strumenti IBM Rational (che includono cose come Rational Rose o Rational Enterprise Architect per lo sviluppo guidato dal modello, l'ingegneria avanzata e il reverse engineering). Ma UML è, prima di tutto, una lingua. Ciò significa che ogni costrutto (ogni tipo di diagramma) ha un insieme specifico di regole che governano i simboli e il significato dietro quei simboli per consentire a tutti di avere una comprensione comune.

Sembra che tu stia cercando di includere troppi dettagli nella fase iniziale. UML è una lingua. Solo perché il linguaggio, ad esempio, costruisce in un diagramma di classe non solo le relazioni tra classi, ma anche le variabili e i metodi di membro pubblici, privati e protetti in una classe, non è necessario utilizzare tutti questi costrutti di linguaggio tutti il tempo.

Penso che il tuo flusso di processo complessivo sia buono. Sembra funzionare generalmente per te. Penso che ci siano due modifiche che devi considerare per essere più efficaci, però.

Consiglierei comunque di guardare cose diverse da UML, comunque. Per i casi d'uso, suppongo che tu abbia qualcosa di più di un diagramma del caso d'uso. Probabilmente acquisisci storie d'uso o casi d'uso in formato tabellare. Infatti, in UML Distilled , Martin Fowler addirittura scoraggia l'uso dei diagrammi dei casi d'uso di UML a favore o testuali o tabulari metodi per catturare i casi d'uso poiché sono molto più utili e preziosi. Scott Ambler fornisce una serie di elementi di modellazione che possono essere utili per mostrare diversi aspetti del sistema.

Dovresti considerare la progettazione come un processo iterativo. Il fatto che i modelli che si utilizzano per l'analisi dei requisiti debbano essere revisionati e perfezionati o lanciati successivamente è normale. Il tuo progetto inizia contemporaneamente allo sviluppo dei tuoi requisiti: dovresti pensare al contesto del tuo sistema (pensa ai diagrammi delle macchine a stati UML, ai diagrammi dei componenti, ai diagrammi di implementazione, ai diagrammi di interazione). Man mano che le tue esigenze diventano più chiare, puoi aggiungere ulteriori dettagli. Tuttavia, non è possibile avere un diagramma completamente accurato finché non si dispone del codice e tale diagramma è accurato solo se il codice non cambia.

Recentemente, ho iniziato a difendere codice come progetto . Agile Modeling sostiene una singola fonte di informazioni . Idealmente, quella fonte dovrebbe essere il codice (e test). Tuttavia, in un sistema complesso, è difficile leggere il codice e testare e comprendere le interazioni tra i componenti e il modo in cui il sistema si adatta a sistemi ancora più grandi. In questi casi, si desidera che tutti i modelli di progettazione visiva (UML o altre notazioni) vengano generati dal codice, idealmente automaticamente, ma in alcuni casi la creazione manuale è OK.

    
risposta data 07.03.2016 - 14:35
fonte
0

Basarsi sulla risposta di Thomas Owens ...

Vi incoraggio a considerare la differenza tra "Model-Driven" (l'obiettivo è generare direttamente il prodotto dal modello) e "Model-Based" (l'obiettivo è creare "una singola versione della verità" per gli stakeholder umani )

Mi capita di lavorare principalmente su SysML (un profilo su UML) e sono fermamente nel campo "basato su modelli". Se sei in questo campo, le uniche cose di cui hai bisogno nei tuoi diagrammi sono cose che aiutano specificamente un determinato gruppo di stakeholder a capire come funziona il sistema. Ad esempio, puoi mettere un sacco di cose in un diagramma di classe, ma farlo è raramente utile per i tuoi stakeholder umani.

Allo stesso modo, devi riflettere attentamente sui tuoi obiettivi per i diagrammi di sequenza. Devi davvero decidere da che parte stai (basato sul modello o guidato dal modello) prima di iniziare a provare a creare il diagramma. Lo scorso autunno al QA & Test 2015, ho avuto una grande discussione con un giovane ingegnere olandese che stava lavorando su modelli in fase di test. Come dice lei: "Se il diagramma è chiaro e utile per gli umani, non ha abbastanza informazioni per l'esecuzione del computer. Se aggiungi abbastanza informazioni in modo che il computer possa eseguirlo, il diagramma diventa incomprensibile per gli umani. "

Spero che questo aiuti,

    
risposta data 07.03.2016 - 21:24
fonte

Leggi altre domande sui tag