UML: Extension Mechanism Corso IS I - 2002/03 Gianna Reggio Versione 0.0.

Presentazione sul tema: "UML: Extension Mechanism Corso IS I - 2002/03 Gianna Reggio Versione 0.0."— Transcript della presentazione:

1 UML: Extension Mechanism Corso IS I - 2002/03 Gianna Reggio Versione 0.0

2 v. 0.0 Suporto allestensione di UML UML è stato definito per essere estensibile, cioè ha già dei costrutti per definire delle sue versioni specializzate in modo standard (almeno a livello sintattico) –la semantica come sempre a parole meccanismo di base –definire una variante di un model element (cioè uno dei costrutti a livello di sintassi astratta di UML) *es. classifier, operation –per mezzo di tre costrutti *stereotype *tagged value *constraint (implicite che modificano la semantica/significato)

3 v. 0.0 Tagged Value è una coppia che permette di attaccare informazioni arbitrarie ad ogni model element (Tag, Value) –per esempio *informazioni su autore, data, versione, …. *opzioni per la generazione del codice *…. –linterpretazione di una tag è intenzionalmente al di fuori di UML *deve essere determinata dai tools o da convenzioni rappresentati come { tag1 = val1, …, tagn=valn} tag = nome (stringa) arbitrario

4 v. 0.0 Stereotype fornisce un modo di classificare (marcare) model elements, così che per certi aspetti si comportino come nuovi model element virtuali datatype sia S uno stereotipo di M –S conserva tutte le caratteristiche di M –S può soddisfare delle constraint addizionali e avere dei nuovi tagged values –S può semplicemente essere usato per definire una differenza nella semantica di M o nel modo duso di M notazione –standard si aggiunge > alla rappresentazione visuale di M –viene fornita una nuova rappresentazione utilizzando una nuova icona o una differente disposizione degli elementi di M

5 v. 0.0 Esempio datatype –si vuole avere un modo per rappresentare i tipi di dato (valori classificati dal tipo + funzioni per operare su di essi) – > stereotipo di classe *tutte le operazioni devono essere query (constraint statica) *le istanze sono valori e non oggetti, pertanto ˚non esistono due istanze differenti cha hanno gli stessi valori per tutti gli attributi *lo stato di una istanza non può essere modificato *notazione standard Carta seme: String valore: Int ritornaValore(): Int {query} >

6 v. 0.0 Esempio classi/oggetti attivi (~processi) –oggetti caratterizzati da un proprio thread of control –si vuole avere un modo per rappresentare questi oggetti speciali – > stereotipo di classe *differenza semantica *notazione Torneo ……. ………. > Torneo ……. ………. oppure

7 v. 0.0 UML profilo (1) variante di UML per –dominio applicativo particolare (WEB systems) –tecnologia particolare (Enterprise Java Beans, Corba) –metodo si sviluppo software particolare (quello che useremo nel corso) –uso particolare (modellazione del Business di unimpresa) –…..

8 v. 0.0 UML profilo (2) definizione –model element selezionati (quelli che verranno specializzati) –Stereotypes –Tagged Values –Constraints, specializzano la semantica (significato) di un model, ma tale interpretazione ha significato solo in tale profilo –Descrizione (a parole) della semantica usata dal profilo per i vari model element utilizzati –Heavyweight extensions (introduzione di model element completamente nuovi, non varianti di quelli esistenti) –Notation, il profilo può specializzare anche la notazione *es. nuove icone per gli stereotype –Rules (come si usa o cosa si fa con i modelli fatti con il profilo) *concernenti modi per trasformare i modelli in codice *per validare i modelli rispetto alluso supportato dal profilo (es. è vietato usare relazioni ternarie [certo tool, che non le supporta] o la specializzazione multiple [per Java]) *concernenti la presentazione visuale *per supportare luso di una certa metodologia [tutti gli attributi sono privati nel nostro metodo]

9 v. 0.0 Esempi quello usato dal nostro metodo per requisiti e design per usare EJB ….

10 v. 0.0 –Notation, il profilo può specializzare anche la notazione –es. nuove icone per gli stereotype –Rules (come si usa) *concernenti modi per trasformare i modelli in codice *per validare i modelli rispetto alluso supportato dal profilo (es. è vietato usare relazioni ternarie [certo tool, che non le supporta] o la specializzazione multiple [per Java]) *concernenti la presentazione visuale *per supportare luso di una certa metodologia [tutti gli attributi sono privati nel nostro metodo]