Hope you can provide some help. I am using Enterprise Architect to do some UML modelling.
I have used the Extension relationship within the Metamodel Toolbox to extend Class 1 from metaclass Class (UML extension) so that Class 1 is a subtype of the Metaclass Class.
However, in the traceability window, when I select Class 1, I am unable to see the link/association to the metaclass from where it was extended from (which I expect to see).
I have looked into the example provided by EA and the example uses an association relationship with a stereotype of extends. With that provided example, I am able to view the traceability information and am able to see that Class 1 is Associated to Class.
For UML, is there a difference between using association relationship with extends stereotype (as in the EA UML stereotype example) vs. using the Extension relationship within the Metamodel Toolbox?
Many thanks for your help!
You are right. The Extend relation doesn't show up in the traceability view (just tested on version 15.0.1502)
You may consider that a bug and report it as such to Sparx Systems.
Using an association with stereotype «extends» is not the same thing. The extension relation is defined in the UML standard, whereas the stereotype «extends» is not defined at all. («extends» in the context of use cases is a keyword, not a stereotype and it definitely has a completely different meaning)
In UML, the ≪extend≫ stereotype is only defined in the context of use cases. There is no definition of such a stereotype when used for an association between two classes.
So, for extending metaclasses, the formally defined extension associations are preferred.
Related
In a UML diagram where one class is comprised by another class, is there an implicit association table, or does it need to be shown?
For example, if I have Chapters that are composition of Paragraphs, is this alone enough:
Or does the association class to be explicitly shown like so:
I've never seen it done like that latter example, so I'm assuming it's implied. Or maybe I haven't normalized the data properly (considering chapter both appears in the Chapter class and the Paragraph class).
Simply, there is no implication. If you need an association class, you need to define it. However, UML is not about diagraming, it's about modeling. You can omit your association class in a diagram if you want to. The association class will still exist in your model, though.
No, it is not implied.
The reason why you haven't seen this is that in most cases it simply doesn't make sense. In the association class the class part additionally describes the properties of the association. In your example you create an artificial object that actually brings little or nothing. This kind of approach can be useful for many-to-many relationships which are impossible for composition (each part can have at most one whole). Even if you wanted to show Foreign Key it would simply be on one of the classes. But that's implied by the association itself. According to UML specification an inline attribute is equivalent to an association.
Moreover on UML you can depict many to many relationship simply but applying appropriate multiplicities on association ends. You may want to show the class depicting that only when modelling on the code level.
No, it is not implied.
UML is not about tables, but about classes. The author of the class diagram should tell the audience how a class should be interpreted. Some UML diagrams model the real world, others model a piece of application functionality and yet others depict a physical implementation.
Apparently, reading your question, you are modeling a relational database, where a class is a physical table. In that case, I would expect that every table is explicitly modeled as a UML class.
The UML standard does not demand this.
By the way, the notation (PK) and (FK) is not in accordance with the UML standard.
I am trying to find a way of specifying how a given class attribute is persisted to an existing database model that I cannot modify at the moment. What i need to convey in a UML class diagram is how a class attribute is mapped to a given table column. Should I use stereotypes for this as illustrated below or is there a better way?
No, you should definitely not use stereotypes.
A stereotype denotes a meta-class that is an extension of a UML meta-class.
«table» is a commonly used stereotype used as an extension of the UML Class to indicate that this object is to be interpreted as a table rather then a generic Class.
Stereotypes can also define properties who will manifest in the model as tagged values. As such you could imagine a «column» stereotype that has a property mapping in which you can add a reference to the class attribute(s).
Some UML tools also have some sort of feature to link attributes to other attributes. UML doesn't really specify how this should be represented in a diagram, so the tools each have their own notation.
Enterprise Architect for example uses this notation:
(from the user manual)
I am using the Enterprise Architect and I saw in the properties of an element (> Related > Links) that there are displayed two meta informations for one element ("Element stereotype" and the other one for "Type"). Can someone explain me the difference between these two meta informations?
Thank you!
When EA refers to "Type" in this context, it approximates to a UML Metaclass, i.e. a kind of element defined by the UML specification (e.g. Class, Interface, Activity). A Stereotype extends a UML metaclass to define a kind of element NOT defined by the UML specification.
UML supports stereotypes, which are an inbuilt mechanism for logically extending or altering the meaning, display, characteristics or syntax of a basic UML model elements. You can apply stereotypes to a range of model element types. (Sparx)
Types are a common name for Classes and Interfaces and Enumerations and other such things if a language has them. Also is used without any exact definition.
On Wikipedia, I'm reading that an association relationship is an instance level relationship so we are talking about the relationship between the objects of two classes.
When we actually draw a class diagram, why do we use association on the class elements or blocks rather than objects? And there are also class level relationships for which we again use class elements. Since we don't have any way to show if we are talking about objects or classes I find this confusing. For example: I've heard people saying "Associate these two classes" Doesn't that sound wrong?
Links are to Associations as Objects are to Classes.
A Class is an abstraction that describes many specific objects. Similarly, an Association is an abstraction that describes many links between objects.
So your statement
an association relationship is an instance level relationship
isn't strictly correct because it mixes the abstraction (Association Relationship) with the instances it represents.
hth.
In fact, when you associate two or more classes it is done thanks to two or more UML Properties.
These latter are the "ends" of your associations and are "instance" i.e. they are typed by classe.
So an association is created between two classes on a class diagram but between each classes and the association you have a UML property.
Hoping it sounds clear ...
When you are making a class diagram you are defining types. Suppose you have a class User and a class Account, you use an association between User and Account to say: User instances can have link(s) with Account instances at runtime.
So, you use classes and associations at type level (class diagram) to define what can be possible at runtime (instance level).
The object is actually the Class that has been created virtualy. So a class is the "static" version of an Object. So, when we speak of UML, we speak about classes and not object.
But correct me if I'm wrong!
What kind of UML diagram is this?
(source: tripod.com)
This is a class diagram, with added stereotypes
This is Class Diagram in a very abstract or initial form because all relationship are shown as Association.
Usually we start with such class diagram and then keep on refining by converting association (arrow as shown above) into more stronger relationship like generalization,composition,implementation etc.
Association is considered as weaker form of relationship between classes. So final class diagram should have fewer associations.
What is the emphasis or goal of this diagram? If it's the classes and relationships, then it's a class diagram. If it's the mapping between the classes and layers of function or responsiblity in the system, then it looks like a layer diagram. Those columns look like layers: presentation, business logic, data...
Ok now I see the problem after a good sleep :-)
It seems it is a powerpoint and not a class diagram because you can not have straight line in a class diagram. I mean you can not have 3 separators like Presentation/ objectos .......etc
This powerpoint tried to use class diagram and have added titles in order to separate 3 layers. The problem is that the class diagram is incorrect and it is not because you present it with 3 layer that it would become correct !! This is a bad understanding of what means JPA stereotypes inside a class diagram.
It looks like a Class Diagram that uses "swimlanes" on the background to facilitate some kind of MVC.
This class diagram is not correct because there is confusion between Java EE stereotypes and class names!
What are the << class module>> , << module>> stereotypes and Session, Session persistence names should be Java EE stereotypes. If it persists in the database then it is an entity! Persistence etc...can be written on attributes.
This diagram doesn't make sense!
The main advantage of scheme in this diagram is that if you use a code generator such as AndroMDA, MIA software or Blue Age, then you can then generate your database directly from the model. These tools look at stereotypes during code generation.
If you don't want to generate code from a model but prefer to let hibernate mapping do the job, then the "entity" stereotype can be written as an annotation in your java code. Then thanks to live code and model synchronization, hibernate can take the annotation and produce a mapping.
This is why stereotyping is really very important and using the wrong stereotype can be a very serious mistake!