2009-05-06 3 views
19

Sono confuso circa la differenza tra qualcosa che è uno "stereotipo" ed è una "superclasse" in UML.Qual è la differenza tra uno stereotipo e un'ereditarietà di classe in UML?

Diciamo che voglio creare un diagramma che coinvolge un "WidgetMaker". WidgetMaker è chiaramente un Actor così lo standard UML è quello stereotipo che l'attore:

<<Actor>> WidgetMaker 

ma sono cresciuto programmazione nel mondo Java/Rubino/C++. In quel mondo, il rapporto è:

class Actor 
end 

class WidgetMaker < Actor 
end 

che assomiglia a questo in UML:

Actor 
    ^
    | 
WidgetMaker 

Quindi la mia domanda è: perché UML hanno stereotipi a tutti quando si può altrettanto facilmente modellare quei concetti utilizzando l'ereditarietà di classe, che ha anche .

Una volta che abbiamo più "tipi" di attori, la questione diventa ancora più oscuro:

   Actor 
       ^
       | 
    ------------------------ 
    |   |   | 
    Person  Robot  Group 
    ^
    | 
WidgetMaker 

contro

<<Actor>> <<Person>> WidgetMaker 
+0

questo link potrebbe aiutare https://sites.google.com/site/assignmentssolved/mca/semester2/mc0069/10 – Premraj

risposta

1

uno stereotipo è lì e utilizzato per presentare ulteriori informazioni sul manufatto, che il documentazione o la classificazione dello stesso in un blocco specifico di artefatti non può dare. Ad esempio, hai identificato una classe di dati, potresti dargli il nome, spiegare gli attributi e le operazioni ma potrebbe non fornire tutte le informazioni. Nel momento in cui lo steriotipa come <, specifica le informazioni complete; Fino ad allora continua come qualsiasi altra classe per uno sviluppatore.

"Gli stereotipi sono utilizzati per estendere gli elementi di notazione UML, per classificare ed estendere le associazioni, le relazioni di ereditarietà, classi e componenti"

uno stereotipo fornisce la possibilità di creare nuovi tipi di elementi di modellazione. Gli stereotipi devono essere basati su elementi che fanno parte del meta-modello UML. Alcuni stereotipi comuni per una classe sono entità, limite, controllo, utilità ed eccezione. Lo stereotipo di una classe è mostrato sotto il nome della classe racchiuso tra i registri (ad esempio « e », pronunciato gee-may). Se desiderato, un'icona grafica o un colore specifico possono essere associati a uno stereotipo.

+0

Oltre all'icona e al colore, che cos'è questa "informazione completa?" Perché non può succedere solo sottoclassando una classe in cui sono definite le meta-proprietà del colore e dell'icona? E se voglio creare un tipo specifico di dati, come faccio a sapere se stereotipare lo <> o sottoclasse la classe Data? –

+0

Dovresti pensare agli stereotipi come a un modo di raggruppare le classi con uno scopo comune: classi limite, classi di controllo, classi di utilità, ecc. Non sta cambiando la natura della tua classe, ma piuttosto aiuta a documentarla. –

+0

Ciò lo rende più simile a un attributo statico. Ma WidgetMaker è un attore, non si comporta solo come un attore o ha un attore. –

6

Per quanto ne so, lo scopo principale degli stereotipi è di abilitare l'estensione di UML stesso (come linguaggio di modellazione) e non di modellare nulla.

Detto questo, penso anche che la tua domanda implichi un'altra possibile risposta valida: alcune persone preferiscono usare gli stereotipi per designare (informalmente!) Certe comunanze tra le classi. Potrebbero farlo solo perché è più facile della sottoclasse e "abbastanza buono" per gli scopi dei loro modelli.

Ad esempio, molti sistemi software hanno classi che rappresentano le cosiddette entità di dominio (cose come aziende, clienti, ordini di acquisto, prodotti, ecc.). Alla fine, è possibile che sia che desideri avere una classe comune come Entity per derivare Company, Customer ecc. Da. Ma inizialmente è probabile che sia sufficiente solo per utilizzare classi stereotipate come queste <<Entity>> Company, <<Entity>> Customer ecc.Essenzialmente, è solo una questione di convenienza (e costi/benefici!) Dei tuoi sforzi di modellazione.

2

Nel tuo esempio Attore probabilmente non ha bisogno di essere implementato come una classe, ma questo può essere o non essere sempre così. Gli stereotipi sono astrazioni che possono essere applicate alla maggior parte degli elementi UML e non solo alle classi.

essi racchiudono la semantica senza che ciò comporti come saranno fornite quelle semantica. Un altro esempio potrebbe essere un canale di comunicazione stereotipato come HTTP o RPC. Stanno comunicando con il lettore come qualcosa verrà fornito senza complicare il modello con dettagli inutili.

specifica UML fornisce una serie di stereotipi predefinito, ma il loro vero potere viene da essere in grado di definire il proprio attraverso i profili. È possibile etichettare un oggetto dominio come EJB per salvare se stessi specificando tutto il codice della piastra della caldaia.

1

Una buona indicazione l'intento dietro stereotipi può essere visto nel modo in cui l'OMG le ha applicate nei profili SysML o BPMN. Nello specifico, gli stereotipi descrivono un nuovo set di costrutti di modellazione come parte del linguaggio per specificare il tuo dominio. Ad esempio, un blocco in SysML è lo stereotipo applicato a Class. Porta con sé personalizzazioni di una classe da utilizzare nell'ingegneria dei sistemi. In questo caso sostituisce l'uso di Class e imposta nuove relazioni con altri elementi e tipi di diagrammi, ad es. Blocco < < soddisfa >> Requisito (relazione consentita) o un blocco può essere modellato utilizzando un diagramma a blocchi interno (comportamento consentito). Uno stereotipo non viene utilizzato per modellare lo spazio soggetto. Classifica l'uso dei costrutti di modellazione per un aspetto verticale o orizzontale della definizione dei sistemi.

0

Uno stereotipo estende la struttura del metamodello UML specificando esempio attributi specifici del dominio sugli elementi in un modello UML e non alterano la semantica del tempo di esecuzione del sistema che viene modellato, ma arricchiscono solo il linguaggio di modellazione.

buon esempio di questo sta dando un "ruolo" a una classe nel diagramma modello di progettazione. La funzionalità della classe è data all'interno della classe, non aggiunta dallo stereotipo - questo supporta la dichiarazione precedente.

Ora, la parte difficile è l'ereditarietà o le classi stereotipate; bene secondo UML 1.3 non sono ereditabili; tuttavia i vincoli attribuiti alla classe da "A" tramite alcuni stereotipi si applicano anche alla classe specializzata. A mio avviso questo non si applica ancora al runtime, quindi ancora una volta l'ambiguità rimane a livello semantico. Altro in this mail thread.

Problemi correlati