Appunti d'uso Enterprise Architect (Sparx Systems)

Post date: Feb 11, 2015 7:12:17 PM

Scenario

Descrizione delle varie operazioni, dell'iterazione dal punto di vista del sistema e quello dell'utente.

Colonne della maschera di impostazione scenario

Step: Se selezioniamo l'omino indica l'attore che esegue un azione. Se selezioniamo il monitor, indica il sistema che esegue un azione. Nota: Se nella action scriviamo la parola "User" o "Actor", in automatico verrà proposta l'icona dell'omino. Se invece usiamo la parola "System", in automatico viene proposta l'icona del monitor.

Action: Descrizione dell'azione compiuta

Uses: Il nome di ogni elemento usato nello step corrente (gli elementi contenuti nel "Context Reference" sono evidenziati in blu)

Results: Indica il risultato che si ottiene al completamento dello step

State: Indica il nome dello stato in cui ci si troverà, dopo aver completato lo step

Stati dei requisiti

Proposed: Il nuovo requisito è stato proposto ed è in attesa di essere preso in considerazione.

Mandatory: Il requisito è stato proposto ed è obbligatorio da prendere in considerazione (meglio il prima possibile per non bloccare altri requisiti).

Approved: Il requisito è stato approvato ed è in fase di implementazione.

Implemented: Il requisito è stato implementato ed è in attesa di validazione.

Validated: Il requisito è stato testato sul campo in condizioni reali, quindi è validato può essere messo in produzione.

Stati dei problemi su cambiamenti e richieste e azioni correttive (Issue, Changes )

Proposed: Il problema presenta dei test collegati che non sono ancora stati eseguiti.

Implemented: I test del problema è stato eseguito ma non tutto è andato a buon fine.

Validated: I test sono stati eseguiti e sono andati tutti a buon fine.

Note varie

I requirements interni elementi sugli elementi "classe", sono considerati le responsabilità della classe.

I task di "Project Status" (menu: PROJECT in fondo) sono relativi solamente al progetto globale (non fanno parte dei modelli).

I task di "Specification manager" (menu: TOOLS) sono relativi ai requisiti (per oggetti che fanno parte del modello). Sono usati per l'assegnazione dei compiti alle risorse.

I task di "Requirements diagram" sono relativi agli elementi del progetto ed il loro stato

I "Maintenance diagram" indicano problemi o cambiamenti legati ad un elemento del progetto (requisito esterno, classi, interfaccia). Es.: per un problema di funzione software lo lego alla classe con <<Trace>>

Tutte le voci per le assegnazioni dei task al singolo elemento si trovano nel menu alla voce ELEMENT e sono:

• Testing

• Maintenance

• Project Management

• RISK: Che indica l'effort di un obiettivo incerto (quanto questo può incidere sul progetto, e quanto grande può essere)

Questi servono solamente a documentare il problema e la soluzione sul singolo elemento e gli avanzamenti in un release plan. Non sono usati per la pianificazione!

NOTA MOLTO BENE!!: Per rappresentare elementi con test o requisiti o maintenance task interni usare gli elementi stessi ed importarli nel diagramma configurato in maniera che evidenzi questi aspetti.

Per funzionalità di controllo condivise, creare elementi di categoria relatina es.: "Test Case" ed includere loro direttamente nel diagramma.

Definizione dei modificatori sulla definizione di metodi, funzioni

• Funzione PURE: Ritorna sempre lo stesso valore se si passa lo stesso argomento e non comporta side effects (chiamando tale funzione lo stato dell'oggetto non viene variato). Es.: sin(x).

• Funzione, metodo IS QUERY: Non comporta side effects, esegue solamente l'interrogazione per la restituzione di un valore (non modificabile o una copia, in modo da impedire che lo stato di un oggetto cambi da fuori di esso, tramite l'oggetto esposto e collegato intenamente).

• Funzione, metodo CONST: Non comporta side effects ed il compilatore ti avvisa se stai tentando di modificare un attributo, impedendoti di farlo.

• Funzione, metodo SYNCRONIZED: Un metodo o funzione dichiarata syncronized viene eseguita sequenzialmente in un contesto multithreading.

Definizione dei modificatori sulla definizione di attributi

• Containment:

• Static:

• Property:

• Const:

• Is literal:

• Transistent: True, quando si vuole che il dato rappresentato non venga serializzato

• Derived:

• Is ID:

• Multiplicity:

• Is collection:

• Container Type:

Voci dei tempi sulla "Resource Allocation"

• Expected time: Quanto tempo ci aspettiamo richieda il task per essere completato

• Allocated Time: Quanto tempo si può dedicare ad un task

• Time expended: Quando il task è completo al 100% questo è il tempo dedicato

Definizione dei requisiti

• Sono considerati i requisiti, le istruzioni elementari Es.: "Aggiungi utente"

Note sugli elementi di vario tipo

Ci sono molti elementi di vario tipo che sono in realtà la stessa cosa. Quello che cambia non è evidente, perché cambiano i tags specifici e quindi i report generati o le visualizzazioni predisposte in tal senso.

Es: Ci sono elementi "Requirement" o "ArchitecturalRequirement". Come forma e significato sono uguali ma uno non ha tags e l'altro si legati a concetti architetturali.

Project management

• Project status: Usato per inserire task e issues per tracciare richieste o correzione a livello alto di progetto. Es.: Non è possibile compilare il progetto e bisogna rimandare, in quanto la memoria necessaria del PC non è adeguata.

Resource management

Questo permette al Project Manager di monitorare quanto manca allo sviluppo di un determinato componente e le classi, e come è progredito lo sviluppo. (a condizione i membri del team mantengono le loro figure professionali)

Effort management

Sforzo richiesto per completare un determinato dettaglio.

Es.: Eseguire lo unt testing: 2 ore

Risk Management

Rischi che comporta eseguire un determinato task.

Es.: Questo task comporto una lunga lavorazione e le tecnonogie potrebbero cambiare nel frattempo.

Metrics

Metriche d'impatto.

Es.: La complessità (di tipo: "Cambiamento"): Un cambiamento futuro può avere un grosso impatto sul progetto. (Peso: 2)

NOTE

• Su project gant view, c'è il report view per visualizzare i assieme i task assegnati ad un lavoratore, al dissopra o al disotto di una certa soglia di completamento

• Distinguere difetti di manutenzione da difetti di implementazione

• TASK: Rappresenta un lavoro in corso! (quindi non è un requisito).

• FEATURE: Una funzionalità è una serie di requisiti correlati che consentono all'utente di soddisfare un obiettivo o una necessità aziendali. (Cosa il sistema è in grado di fare)

• E' una funzionalità richiesta, l'elemento grafico, viene creato come indice di soddisfazione di un requisito (sono utilizzate nei diagrammi dei requisiti)

• Es.:

• Requisito=Utilizzare il pattern MVP

• Feature=Nell'architettura è usato il pattern MVP

• REQUIREMENT: Una dichiarazione di un bisogno del cliente o di un obiettivo o di una condizione o capacità che un prodotto deve possedere per soddisfare tale necessità o obiettivo. (Cosa il sistema può fare)

Maintenance

Gli elementi di manutenzione si applicano a livello di elemento (modello corrente), li applichiamo a livello di progetto (sistema corrente) solamente se hanno implicazioni più ampie per il progetto o identificano (ad esempio) un attore, attività o azione che richiede ulteriore definizione, o anche per allegarvi la documentazione relativa.

Nota: Differenziamo i problemi e difetti di implementazione (nel compito svolto), dai problemi e difetti task o cambiamenti per manutenzione (nel requisito, nella responsabilità).

Un difetto (Defect) può essere considerato come un fallimento, perché non viene soddisfatto un requisito (responsabilità) per l'elemento modello corrente.

Es.:E’un errore che si verfica solamente cambiando un input. Per esempio, se invece di scrivere "a >= 0", il programmatore ha erroneamente scritto "a > 0" in una istruzione, si può avere un malfunzionamento solo quando viene eseguita quell'istruzione mentre la variabile "a" vale zero.

Un difetto non crea un problema ma fa vedere qualcosa di inappropriato, incongruente ai requisiti.

Infatti su uno unit test che durante la fase di manutenzione non va a buon fine noi apriamo un defect e non un issue.

Un cambiamento (change) può essere considerato come un cambiamento nel requisito (responsabilità) per l'elemento modello corrente.

Un problema (Issue) registra un fattore di rischio che può influire sul progetto in fase di esecuzione per l'elemento modello corrente.

Es.:E’un problema (errore) software, che si verifica sempre passando per una determinata condizione

Un task, è un mezzo per registrare i lavori in corso e i lavori straordinari per l'elemento modello corrente.

Gli elementi di manutenzione di livello sistema, vengono linkati al modello, elemento che ha generato il problema (responsabile) con una relazione "Realization"

Project task list

E' una TODO list per elencare dei task di progetto che non sono gestiti altrove.

Può essere utilizzato per monitorare le cose, come ad esempio le richieste di incontri.

Project Issues

Usato per registrare problemi a livello di progetto da risolvere per non compromettere l'intero andamento.

Es.: Il materiale non è stato fornito in tempo e quindi adesso non possiamo proseguire e dobbiamo trovare un altra strada.

Bookmarks

Sono dei triangolini rossi sopra gli elementi modello. Si creano selezionando l'elemento e premendo "Shift" + "SpaceBar"

Requisiti da model wizard

Funzionali

• Business Rules: Regole ferree (che si possono applicare in vari contesti)

• Features: Realizzando i requisiti (io di solito elimino tale package e aggiungo le "Fearures" del diagramma dei requisiti)

• User interface: Disegno delle interfacce grafiche

Non funzionali

• Performance: Criteri misurabili del sistema, che governano la velocità generale e la reattività

• Scalability: Criteri relativi ai limiti causati dalla dimensione del sistema

• Security: Criteri di accesso ai dati e ai sistemi fisici

• Persistence: Criteri relativi alla memorizzazione di informazioni

• Transport: Criteri di definizione di vincoli e condizioni inerenti la trasmissione di informazioni tra i nodi (Es.: Reti: protocollo e qualità della comunicazione)

Defect e risoluzione

Per prima cosa creo un "Defect" e collego, tramite relazione "Dependency", l'oggetto che ne è afflitto con esso.

Poi creo un "Change" e collego, tramite relazione "Trace", il "Defect" con esso.

Sul "Change", descrivo il lavoro da effettuare per poter corregger il difetto e poi gli assegno la risorsa che dovrà lavorarci.

Dopo creo (su di esso) i "Testing" che dovranno essere verificati affinché il difetto possa essere considerato corretto.

In questo modo ottengo la notazione del difetto e ciò che è stato fatto per correggerlo