what is the differences between
stereotype properties and tagged value in UML?
i read about them but i don't know the main differences
A stereotype in UML is represented using French quotes (e.g. «User»), whilst a tagged value is represented using curly brackets ({something}). Stereotypes can be attached to any UML element, whist tagged values, since UML 2.0, are actually stereotype attributes.
So, you annotate elements with a stereotype, an you can attach tagged value to the stereotype.
UML2.x has no tagged values. They are still defined in MOF but are removed for UML. Stereotypes have standard Properties. And those Properties are displayed as Properties of the extended Element (not with curly braces). They can be displayed using French quotes but can be any other way.
Stereotypes are a mighty concept to extend any Metaclass with additional Properties, Constraints and Dependencies. They are not comparable to the tagged values other than they are a extension mechanism as well.
A hands-on eclipse tutorial for UML2 stereotypes can be found here. You can scan through it to get an impression on the complexity.
A stereotype cannot be used by itself, but must always be used with one of the meta-classes it extends. Stereotype cannot be extended by another stereotype. And also Stereotype can change the graphical appearance of the extended model element by using attached icon.
tag represents a particular kind of property applicable to one or many kinds of model elements. and Both the tag and the value are usually encoded as strings though UML tool allow to use other data types for values.
For example,
{author="Joe Smith", deadline=31-March-1997, status=analysis}
Tag values could be shown in attached comment under stereotype name.
Stereotype Computer applied with tag values in comment note
Related
UML defines a property to be either an attribute of a classifier, or the member end of an association, or both at the same time. At the same time, an attribute is a property that is owned by a classifier. So the line between the two is very thin. For a class, the usual notation for an attribute is to appear in the attribute compartment of the class:
But The UML 2.5.1 specification allow a graphical notation as well (chapter 9.5.4, page 114):
In a Classifier, an attribute may also be shown using association notation, where only an aggregation adornment (hollow or filled diamond) may be shown at the tail of the arrow.
Shall we understand this clause as meaning, that the association notation for an attribute requires the aggregation notation as follows?
If yes, wouldn't this be confused with an aggregated property? And wouldn't this contradict UML 2.5.1 when it says that there is no semantic for shared aggregation?
No, the sentence tries to define, what can be shown on an association like notation for an attribute. This applies to attributes, that are not at the same time association ends. In absence of an association, there can be no information about the opposite end. Therefore, only adornments that belong to the attribute itself can be shown. Since the aggregation kind is a property of the attribute, it can be shown.
Composition: A class can have references to objects of other classes as members. This is called composition and is sometimes referred to as a has-a relationship.
By Deitel P.J., Deitel H.M. - Java How to Program 9th Edition.
This viewpoint is discussed in this topic:
Prefer composition over inheritance?
Composition: Composite aggregation (composition) is a "strong" form of aggregation with the following characteristics:
*it is binary association,
*it is a whole/part relationship,
*a part could be included in at most one composite (whole) at a time, and
*if a composite (whole) is deleted, all of its composite parts are "normally" deleted with it.
Found on http://www.uml-diagrams.org/composition.html
(actually, Deitel presents UML examples following this idea, in the same book, but did not bother to explain the difference).
This viewpoint is discussed in this topic:
What is the difference between association, aggregation and composition?
Fine, BOTH ARE CORRECT. And this introduces the problem of homonym concepts.
For instance: don't draw a UML model with composition arrows to exemplify the first definition: In UML, any association is a composition by Deitels' the first definition.
Here are some aspects of my question that may help in the correct answer:
How I can say (and know) which composition are we talking about?
Where we draw the line between the two definitions (in contextual terms)?
Can I say that the first is object oriented programming and the second is software engineering/modeling?
Is the UML composition a model-only concept/jargon?
Is the UML composition an UML exclusive thing? or is also applied in the programming field?
How to avoid miscommunication of "what composition are we talking about" in a team?
Please, answer with references, evidences, it is not a philosophical/opinion problem, it is a "scope" problem that I´m trying to address.
And it is not "what is composition" question.
Edit: I´m thinking if the distinction is verb x adjective: "to compose" a class (first def.) and "a composite relation" (second def.).
I found it hard to explain the difference between UML association and implementation references without explaining at least a little bit what UML associations actually are, and what they can do, so here we go.
Association & Link
Lets start by looking at what a UML Association and a link (Association's instance) are.
[11.5.3.1] An Association specifies a semantic relationship that can occur between typed instances.
[11.8.1.1] A link is a tuple of values that refer to typed objects. An Association classifies a set of links, each of which is an instance of the Association. Each value in the link refers to an instance of the type of the corresponding end of the Association.
So the following is a valid implementation of a limited association.
class Brain { }
class Head { }
a = new Brain;
b = new Head;
link = (new Array).add(a).add(b);
Ownership
[9.5.3] When a Property is owned by a Classifier other than an Association via ownedAttribute, then it represents an attribute of the Classifier.
(Note: Class is a subclass of a Classifier.)
Navigability
[11.5.3.1] An end Property of an Association that is owned by an end Class or that is a navigableOwnedEnd of the Association indicates that the Association is navigable from the opposite ends; otherwise, the Association is not navigable from the opposite ends. Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.
Why are those concepts relevant? Imagine the following example.
We see that brain is an attribute of Head class (the black dot signifies ownership by the opposite Class), and that it is navigable (the arrow).
We also see that head is NOT an attribute of Brain (no black dot ⇒ not owned by the Brain class ⇒ not an attribute of Brain), however it is still navigable. This means that in UML the head Property is held by the association itself.
The implementation could, for example, look like this (the association itself is represented by a tuple of two references (see link description earlier)).
class Head {
public Brain brain;
}
class Brain {
}
h = new Head;
b = new Brain;
h.brain = b;
link = (new Array).add(h).add(b);
So as you hopefully start to see, UML association is not such a simple concept as a has-a relationship.
Composition
Lets add another piece, composition.
[11.5.3.1] A binary Association may represent a composite aggregation (i.e., a whole/part relationship). Composition is represented by the isComposite attribute
[9.9.17] The value of isComposite is true only if aggregation is composite.
With the aggregation being
none - Indicates that the Property has no aggregation semantics.
shared - Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite -- Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects
Again we see, that a UML association is explicitly specifying concepts that are hard to perceive from implementation (e.g. who is responsible for object management/destruction).
Model Composition vs Object Implementation Composition
So from the description above we can construct a more precise description of what an implementation composition (has-a relationship) would be.
[Deteils] Composition: A class can have references to objects of other classes as members. This is called composition and is sometimes referred to as a has-a relationship.
McConnell [Code Complete 2, 6.3] also refers to has-a relationship as a Containment.
Neither of them however talk about HOW the objects (container-contained, composer-composite) are related to one another, who is responsible for lifecycles, or whether the contained element knows about the container.
So just by saying that objects have a has-a relationship (and call it composition), you could actually mean any of these (and several more)
So if you call something composition in programming, you can mean pretty much any relationship/reference (or rather not an inheritance), so the word by itself is not very useful.
In UML on the other hand you are trying to capture all such information about how the objects are related to one another. Therefore there's a focus on giving terms a more precise meaning. So when you call something composition in UML you have in mind a very specific has-a relationship, where the container is responsible for the lifecycle of the contained items.
Implementation of UML associations
All those extra concepts information mean that there is really no precise way how to even implement associations. This makes sense as the implementation would depend on the target programming language or environment (e.g. executable models, where the UML concepts are used as the final product).
As an example I can recommend a paper describing UML association implementation in Java with enforced concepts such as multiplicity, navigability, and visibility Implementing UML Associations in Java.
More subquestions
How I can say (and know) which composition are we talking about?
By context, or you can just ask (which is always a good thing to do when unsure). Personally I've heard the use of composition as "has-a relationship" only when differentiating from inheritance; and in the rest in terms of UML. But then again I am in academia, so my view is biased.
Where we draw the line between the two definitions (in contextual terms)?
As the "programming" term composition doesn't actually mean anything (only that it is has-a), I'd recommend drawing the line yourself and pushing others to use more precise terminology.
Can I say that the first is object oriented programming and the second is software engineering/modeling?
More or less, with all the nuances mentioned in this answer.
Is the UML composition a model-only concept/jargon?
Is the UML composition an UML exclusive thing? or is also applied in the programming field?
No, you can use it in programming to mean the same thing as it means in UML, but you might need to state it more obviously. E.g. "This class is a composite for those classes, because it manages their lifecycle.".
The point is to teach people to differentiate between regular-old has-a relationships, and relationships that have more precise semantics.
How to avoid miscommunication of "what composition are we talking about" in a team?
This is a very broad question that you could apply to any term to which you want attach special meaning (what even is software engineering?), and there is no best way. Have a team-shared vocabulary (you are probably already having a lots of specific terms in your domain), and guide people to use more precise terminology.
numbered quotes refers to sections in UML 2.5 Specifications.
To cite the UML 2.5 specification on page 110:
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. To represent such circumstances, a Property has an aggregation property, of type AggregationKind; the instance representing the whole group is classified by the owner of the Property, and the instances representing the grouped individuals are classified by the type of the Property. AggregationKind is an enumeration with the following literal values:
none: Indicates that the Property has no aggregation semantics.
shared: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
Personally I see it the way that notion of a composite aggregation is about object lifetime, not about static relation. A composite aggregation kills aggregate members when their parent dies. None leaves this open. And shared aggregation is a bastard that OMG should not have introduced at all since it's semantics is domain dependent.
I am designing a class diagram for an assignment. In this design, I use a separate class called Currency, to define currency values and their functionality. there are at least four other classes have to use this Currency class.
How can I show it in the class diagram ? I mean, do I need to draw relationships (connecting lines) from the Currency class to all the others ?
Is there a better way ?
What am I doing wrong here ?
There is nothing wrong and a reusability of a class is valuable. Actually that's a standard situation.
If you use this class in another class as an attribute you have two options to depict that:
draw an association relationship (line) from the class using to the class that is used.
put the attribute in a proper compartment of a class that is using and as a type of an attribute (after a colon) put the name of the used class.
The benefit of the first approach is that you immediately see the dependency between the classes.
If you use a class but not directly as an attribute type you use other relationship types that suit best to the situation you want to describe.
As I imagine one of your concerns is that you'll have a lot of relationships pointing to your class (in your case Currency). Don't worry about that. You don't have to put everything in a single diagram. Put a full specification of your class on one diagram with those relationships where it uses something else and then put only the class box with a name (without any compartment) on diagrams defining those elements that use your class. It will make your model readable. And with a support of some CASE tool you will be able to see all relationship and dependencies of this class anyway. By the way that's how the UML specification is written. Look for example how Namespace is used in the diagrams there (and many others as well).
Of course I'm not suggesting creating one diagram per one element to define it. No. Collect them in logical Packages (hey - that's exactly what Packages are for!) and make a class diagram per Package. If the Package becomes too large - you might need to split it into smaller subpackages.
For Currency your Package would be probably something like Utils. It can also contain other elements like Date, Address etc. Note - these are typical examples, probably every analyst/designer/programmer sooner or later has to cope with those elements. If you build them well, you'll be really able to reuse them in future applications as well.
One last thought. While you build "package based" Class diagram you might also need a diagram that shows just specific parts coming from several Packages to clarify some bit of your system/business/whatsoever. This is also absolutely fine. Again a benefit of CASE tool here is that it keeps consistency in your model.
Is the mechanism how fields are shadowed/hidden by inheritance and later resolved part of the JVM spec? I know it is part of the Java spec, and can be found in many blog posts and SO questions. However, when I actually look at the JVM spec for field resolution, the words "hiding" or "shadowing" do not appear anywhere in the pdf of the JVM spec.
I ask this because I am writing my own JVM, and discovered that this field shadowing is a property of the bytecode/VM and not just part of the Java compiler or Java-the-language. I want to know the proper, authoritative way this should be implemented at the VM level. Surely a (mis?)feature of the JVM this important needs to be formally documented somewhere?
The term shadowing usually refers to when one identifer shadows another. I.e a given name could refer to multiple variables, so there has to be a mechanism to disambiguate it. This is mostly a language level construct because it contains a lot more names. Local variable names don't appear in the bytecode at all except as optional debugging information for instance.
From the bytecode point of view, you already have an explicit reference to a class, name, and descriptor. The only question is whether the field you're describing is actually declared in the class you specified, or whether it was inherited from one of it's superclasses.
As you already discovered, Field Resolution is explained in section 5.4.3.2 of the standard. The terms hiding and shadowing are not used because they apply to source code, not classfiles.
Is the arrow read like "Arena depends on LeagueStore" ? How is this implemented ? Here is a similar question, but it doesn't include such an arrow.
picture taken from slide 9
The UML relationship "depends on" is deliberately wide in scope. It means that some aspect of the "classifier" (class, interface, package, ...) referenced by the relationship is used by the classifier at the other end of the relationship. This can include calling a method, using a type, including a package and so on.
In this case I think it can clearly be interpreted as "uses", that is, calls one or more of its methods. Today, this relationship has its own UML representation as a stereotype called "uses" on the dependency relationship to make it a little more specific.
The diagram is not a very good example of a bridge. The name comes from the whole idea that there are two hierarchies connected at the top. All this diagram is depicting is the fact that the outer class (Arena) manipulates the LeagueStore through an outer class. That's not even a pattern, that's the Envelope-Letter Idiom from Coplien's Advanced C++.
Bridge would be LeagueStore having a delegate inside (impl, as depicted), but then also having specializations of LeagueStore. For example, if you had a class called Report, it would have ReportImpl inside, that could have subclasses like JasperReport and BirtReport, but then Report could have subclasses like CrosstabReport.