I have a child class which wants to add more functionality to a base class function, how can I represent that it also does the base class function not just the newly added functionality?
Interesting question. I tried that with Enterprise Architect. It did let me select the parent's operation but the display in the diagram did not change. It seems like you need to use notes for that:
As you can see Class2 inherits from Class1. The SD shows a call to Class2's operation a(). The call to the super-class's Class1.a() as internal call shows the same signature. A note clarifies the situation.
Maybe there's something else possible with this. But that's what I came up with immediately.
P.S. I've looked up the specs. P. 575 of UML 2.5 says
The message-name appearing in a request-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation or Signal referenced by the signature. Otherwise the name is unconstrained.
That would put in the option to specify the operation in question as Class1:a() or the like. Actually Enterprise Architect shows it that way in the properties of the message but shortens it to just the basic name. Just a border case, I'd guess.
I have a child class which wants to add more functionality to a base class function, how can I represent that it also does the base class function not just the newly added functionality?
Interesting question. I tried that with Enterprise Architect. It did let me select the parent's operation but the display in the diagram did not change. It seems like you need to use notes for that:
As you can see Class2 inherits from Class1. The SD shows a call to Class2's operation a(). The call to the super-class's Class1.a() as internal call shows the same signature. A note clarifies the situation.
Maybe there's something else possible with this. But that's what I came up with immediately.
P.S. I've looked up the specs. P. 575 of UML 2.5 says
The message-name appearing in a request-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation or Signal referenced by the signature. Otherwise the name is unconstrained.
That would put in the option to specify the operation in question as Class1:a() or the like. Actually Enterprise Architect shows it that way in the properties of the message but shortens it to just the basic name. Just a border case, I'd guess.
I'm newbie in MagicDraw and I'd like to know how to specify a class as {abstract}.
I know about de property "Is abstract" in the Specification of Class, but I'd like that it appears in the header.
The place where you set isAbstract in MagicDraw is in the specification window for the class. To open that window, either right-click on the class or press enter while it is selected. The window will look like this:
You didn't specifically ask for more information, but I'll provide it in case you find it helpful.
The model you want to create will look like this:
Notice that Abstract Class is written in italics to indicate it is abstract. Also notice that {complete, disjoint} is specified for the generalization set. (Just FYI, {complete} is also known as a covering axiom.)
Beware that if you do not specify {complete}, you're creating a conflict with the isAbstract meta-property. The reason there's a conflict is that in UML, the default is {incomplete}, which means that you are allowed to create an instance of the super-class without it also being an instance of one of the sub-classes. That conflicts with isAbstract.
I am currently teaching myself RDFa Core 1.1 after successfully learning RDFa Lite rather easily. Straight to the point, I can't understand two things: the difference between property and rel, and the difference between resource and about.
Please explain to me in simpler terms than the spec :)
property vs. rel:
Both attributes indicate a predicate of a triple, e.g. rel="http://purl.org/dc/terms/creator, which is the predicate ... has as a creator: ....
The difference is, from where they take their object. Slightly simplified, the rules for property are: The object is taken ...
from a valid content attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid resource attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid href attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid src attribute or, if this is not present in the tag,
from the inner content of the element started by the tag.
Slightly simplified, rel differs in two aspects:
It takes its object only from a resource or a href or a src attribute.
It takes its object not only from an attribute of the same tag, but may also take it from descendant tags. The whole mechanism is called "chaining": "This is the main difference between #property and #rel: the latter induces chaining, whereas the former, usually, does not." 1 Usually, but property can induce chaining if used with typeof (cf. 2).
about vs resource:
about is the attribute to indicate the subject of a triple. The rules for resource are more complicated: It may indicate a subject or an object, and chaining plays a role here, too.
IMHO, chaining is the most complicated and confusing part of RDFa (and does not give you more than syntactic sugar). I would avoid chaining. This is possible by avoiding the attributes rel, rev, resource and typeof, which brings some further simplification at the same time. Thus, I use only the following attributes:
about for the subject
property for the predicate
content or href or src (or the inner content of the element) for the object, following the rules outlined above
lang for a language tag for object literals, e.g. lang="en"
datatype for a datatype tag for object literals
prefix (but only once in a document), so that I can abbreviate URLs by prefixing, e.g. property="dc:creator"
vocab (rarely and at the most once in a document), so that I can abbreviate URLs implicitly, e.g. property="creator".
(And I use the tag <base href="..."> to indicate the URL base value of the document.)
This is a strict, safe, easy-to-use and easy-to-parse subset of RDFa and allows to express any triple you want.
I would personally recommend to ignore / avoid using rel and about, they are not really necessary to write RDFa if you follow the rule of thumb that you should not try to be too smart by stuffing as many attributes as possible in a given HTML element. There are around for backward compatibility reasons. The other attributes from 1.1 are worth learning though: content and datatype.
Stephan's advice is in general conformance with RDF Lite 1.1, which does not include #rel or #about for precisely these reasons.
Another good rule of thumb is to not try to include markup of more than one entity on a given element, which was often an example of specifying an images license.
#property and #rel are very similar to each others, but served different purposes in RDFa 1.0, but this was confusing, even for experts. (Formerly, #rel was used for specifying objects which are other nodes, and #property was used for specifying literal values. While there are some remaining differences, but sticking to non-clever markup, you can do everything with #property that you could do with #rel.
Similarly, #about can be avoided to just use #resource. The difference is that #about sets the current subject and #resource the current object, but for child nodes the parent object (taken from the parent's current object becomes the current subject. There were another minor differences concerning the presence of #typeof, but if you only use #resource, it pretty much does what you want.
To summarize the best practices from RDFa Lite 1.1 you can also check out the RDFa 1.1 Primer:
stick to #vocab, #prefix, #property, #resource, and #typeof
avoid making more than one statement in a given element
In ArgoUML, I have the ability to put a class Type to any property of a class. For example, I can declare a customer property with a Customer type in the Order class.
I can also easily draw a relationship from class to class:
But I can't figure out how to "draw" the link from the customer property to the Customer class. The link is never really connected to the property, but rather to the entire Order class.
I can move the position of the link manually:
But it's never really "locked" to the customer property, and can be moved automatically by the software at any moment.
Is there a way to do this?
You can not have an association in UML which is not connecting the entire two classes. It is not possible to touch the property inside the class.
Workarounds are:
add a note linked to the property
add an icon to the property which would be designed like an association.
I don't know if this advanced icons customization is available in this free tool but it is in other tools.
I found a flash demo which shows the association attribute with an icon. Look at : http://www.download-omondo.com/show_association_member.swf
If you need to understand what mean an association in UML and code generation in Java then have a look at this demo: http://www.download-omondo.com/association.swf
Hope this help.
ArgoUML follows the UML specification. Associations are drawn from one class to another. Attributes are drawn inside the 2nd compartment of a class.
The association type closest in meaning to an attribute is composition, but they are not equivalent.
You should never portray something AND as an attribute of a class, AND as a separate class associated to it.
E.g. 1. an Order may have a Number, that may be used by the customer to identify his Order. The Number is best portrayed as an attribute (in the 2nd compartment of the class).
E.g. 2. an Order may be associated to the Customer who placed the order. The Customer is best portrayed as a separate class, since it has its own lifespan (behavior), associated with the Order. This allows to show multiplicities and roles at both ends of the association line.