Caricare documenti e articoli online  
INFtube.com è un sito progettato per cercare i documenti in vari tipi di file e il caricamento di articoli online.
Meneame
 
Non ricordi la password?  ››  Iscriviti gratis
 

UML : UNIFIED MODELING LANGUAGE

management


Inviare l'articolo a Facebook Inviala documento ad un amico Appunto e analisi gratis - tweeter Scheda libro l'a yahoo - corso di



ALTRI DOCUMENTI

L'EQUIPE: RUOLO E COMPITI - GLI OPERATORI
LA CATENA DEL VALORE (di PORTER)
RAPPRESENTAZIONI DATI
IL MODELLO RELAZIONALE - ALGEBRA RELAZIONALE
AUTORIZZAZIONE E AFFIDAMENTO nei WF - DFD : diagramma flusso dati
NORMALIZZAZIONE
STORIA DEL PENSIERO ORGANIZZATIVO - LA QUESTIONE BUROCRATICA
LIBRO: NUOVI LAVORI, NUOVO WELFARE
UML : UNIFIED MODELING LANGUAGE

UML : UNIFIED MODELING LANGUAGE

L'UML è un formalismo molto ricco di diagrammi che consentono di descrivere a diversi livelli i molteplici aspetti di un'applicazione; è un formalismo che si incentra sugli oggetti.  Si usano i diagrammi delle classi per descrivere

le classi di oggetti e le loro relazioni; molte nozioni utilizzate si rifanno al modello E/R ma con l'uso dei diagrammi si consente di descrivere aspetti che prima non era possibile rappresentare(dinamica e comportamento).

Elementi fondamentali sono le classi e le associazioni che corrispondono all'entità e al 737i81h le relazioni del modello E/R.

Modello relazionale

UML



1)      consente di lavorare sui dati: si hanno due possibili viste estensionale(si enucleano i dati) ed intensionale( si descrivono le proprietà )

2)      descrivono gli attributi dei dati

1)      ogni oggetto è istanza di una classe e vive di vita propria: l'oggetto ha due strati:dati e funzioni

2)      descrivono le operazioni consentite su quegli elementi

Use Case Diagrams:Esso ci aiuta ad analizzare cosa vogliamo dalle applicazioni software da costruire; è il comportamento,cosa ci consente di fare il sistema, ignorando come si fa in quanto siamo a livello concettuale.

Ogni Use-case soddisfa più requisiti fondamentali: nella realtà i requisiti non funzionali rappresentano caratteristiche del sistema, non funzioni da svolgere (i requisiti di sicurezza, cioè che un sistema funzioni bene non sono delle funzioni, ma bensì dei requisiti non funzionali!).

I casi d'uso descrivono le interazioni tra utente(attore)e sistema; esso è descritto da un nome ma è composto da una serie di attività atomiche(o viene svolta o non viene svolta)che avvengono secondo determinate regole.
L'attore è il ruolo che l'utente del caso d'uso svolge nell'interagire con il sistema(livello concettuale).
Un attore sollecita il sistema con un qualche evento e ne riceve un output. Esso è esterno al sistema e può essere:

Una classe di persone fisiche (es. Fornitore),Un altro sistema software (es. Sistema di contabilità) Un dispositivo hardware esterno (es. Sensore).

Il caso d'uso:  Descrive il comportamento del sistema quando sollecitato da un attore Il comportamento è descritto in maniera testuale, come sequenza di transazioni del sistema(insieme atomico di attività che sono completate o non sono eseguite affatto). Un caso d'uso corrisponde ad un compito che l'attore o il sistema deve eseguire.

Diagramma dei Casi d'Uso

È Usato per modellare il contesto di un sistema, i requisiti funzionali(Ogni caso d'uso corrisponde a uno o più requisiti funzionali ed è coinvolto in una qualche relazione)ed ha Diversi livelli di dettaglio(decompos. gerarchica)

Attori(esterni al sistema), Casi d'uso(interni al sistema)Relazioni di associazione, dipendenza e generalizzazione;

Relazioni principali




1.      Association: identifica relazioni semplici tra attori e casi d'uso

2.      Include: fattorizza proprietà comuni.  Un comportamento comune a più casi d'uso diventa un caso d'uso che è incluso nei casi d'uso di partenza; L'inclusione evita di copiare la descrizione del comportamento comune nei differenti use case che lo coinvolgono. Avviene in un punto preciso della descrizione del caso d'uso includente. Il caso incluso non ha senso da solo. utilizzare incudes quando si sta ripetendo la descrizione di un comportamento presente già in uno o più use cases.(graficamente : <<include>>)

3.      Extend: identifica comportamenti simili (varianti). A può essere visto come una variante di B;    Comportamenti alternativi o eccezionali (opzionali) di un caso d'uso formano dei casi d'uso che estendono il caso d'uso generale:nel caso d'uso esteso viene inserito un punto d'estensione,  nei sottocasi d'uso si fa riferimento a questi punti.La relazione extends va utilizzata quando abbiamo uno use case simile ad un altro che però fa qualcosa in più.utilizzare extends quando si descrive una variazione al comportamento normale;

4.      Generalization si applica sia ad attori che ad  use case. A eredita il comportamento di B.

Per ogni use case deve essere effettuata la documentazione :

Titolo: Effettua chiamata diretta

Autori: Pluto e Topolino

Descrizione: L'utente compone il numero per effettuare una chiamata diretta

Attori: Utente

Pre-condizioni: Non identificate

Post-condizioni: Non identificate

Scenari:  Uno scenario è un'istanza di uno use case; È una "esecuzione" particolare dello use case. Rappresenta il comportamento (le azioni e gli eventi) del sistema nel caso particolare considerato. Definisce cosa accade nel sistema in seguito all'evento di innesco. Ogni use case dovrebbe essere corredato da un insieme di scenari:

Scenari principali (più possibile:Tutto funziona correttamente) e Scenari secondari (pochi e significativi,Eccezioni eventuali problemi o malfunzionamenti). Si devono definire tanti scenari quanti sono quelli necessari per capire il corretto funzionamento del sistema e le eccezioni che si ritengono significative durante l'analisi







Privacy

Articolo informazione


Hits: 1446
Apprezzato: scheda appunto

Commentare questo articolo:

Non sei registrato
Devi essere registrato per commentare

ISCRIVITI

E 'stato utile?



Copiare il codice

nella pagina web del tuo sito.


Copyright InfTub.com 2019