I'm using Visual Paradigm for UML
I'm drawing a class diagram and I want to mark a struct (instead of a class). There is no such thing there, but instead I found smt called <<primitive>>.
What is it?
Is it a dumb-data-holder?
Kind regards
The «primitive» stereotype means the type has no internal structure, and is defined externally to UML. An integer would be a primitive; its operations are defined by the implementation language.
The «datatype» stereotype is analogous to a C# struct or a value type - instances of the type may have internal structure, but do not have identity and are considered equal if the values of all their properties are equal. A complex number, with real and imaginary parts, would be a data type.
Related
In the UML specification there are plenty occurrences of the word "redefine". Not a single mention of what redefinition means. Perhaps it's too simple? Anyway, if someone could explain it even simpler that'd be just great.
Snapshot from UML 2.5.1, Intervals:
I found a clue to what it does using a modelling tool (Sparx Enterprise Architect). If having an interface sub-class of another interface, I get the option to "redefine" operations and attributes of that interface.
I made a wild guess on what it might be used for and redefined it with more parameters. The extra parameter represented the "number of output arguments" added by the Matlab compiler when compiling a Matlab function to a C# library. Then I went ahead and made another sub-class for CLI and redefined arguments accordingly (int return value, all inputs are strings).
The UML 2.5.1 defines redefinition in section 9.2.3.3 (page 100):
Any member (that is a kind of RedefinableElement) of a generalization of a specializing Classifier may be redefined instead of being inherited. Redefinition is done in order to augment, constrain, or override the redefined member(s) in the context of instances of the specializing Classifier.
For a feature such as an attribute, a property, or an operation:
Feature redefinitions may either be explicitly notated with the use of a {redefines <x>} property string on the Feature or implicitly by having a Feature which cannot be distinguished using isDistinguishableFrom() from another Feature in one of the owning Classifier’s more general Classifiers.
Suppose for example that you have a class Node with two attributes: from: Node[*] and to[*]: Node. You could then have a specialization FamilyMember (a node in your genealogy) and you could redefine the members: parent : FamilyMember[*] {redefines from} and child : FamilyMember[*] {redefines from}
Another example: you have a polymorphic class Shape with an abstract operation draw(). You can specialize that class into a class Circle that will have its own draw(). You could leave the redefinition implicit (just mentioning the operation), or you could be very explicit with draw() {redefines draw()}.
The abstract syntax diagrams apply UML to the UML metamodel. The redefinition have the same meaning, but it is explained in a shorter manner in section 6.
Let's take an example in your diagram: let's take IntervalConstraint:
IntervalConstraint inherits from Contraint. A Constraint is composed of a property specification:ValueConstraint (page 36), so IntervalConstraint inherits this property.
Your diagram tells that IntervalConstraint is composed of a property specialization: Interval that redefines the more general specification of the constraint. It's a redefinition, because it narrows down its type (fortunately, Interval inherits from ValueSpecification so there's no risk of inconsistency).
How can I know if class A is an interface, an abstract class or a concrete class (super class)?
According to answers, there are no direct instances of A so I assume that is an abstract class.
However, in this second image :
B should also be an abstract, if the first theory is right... but it can't because in the last answer there are direct instances of B class.
If A would be abstract in image1 it would be shown with the name in italics and/or the string {abstract} next to it. This is not the case here. Therefore A can have direct instances. I guess there is a mistake in image1.
Please note that even if B in image2 would be abstract, it is meaningful to specify an instance of B. An instance specification is not an instance, and as such can be incomplete and abstract. An object will have complete features and a concrete class. For example I could have a red Basketball. In the model I might have an instance specification classified by Ball{abstract} and without a slot for the color, because I don't care which type and color it is. So any instance of Basketball or Handball will fit this instance specification.
As per UML specification, Section 9.2.3.2:
The isAbstract property of Classifier, when true, specifies that the Classifier is abstract, i.e., has no direct instances: every instance of the abstract Classifier shall be an instance of one of its specializations.
The notation is described a bit further, in Section 9.2.4.1:
The name of an abstract Classifier is shown in italics, where permitted by the font in use. Alternatively or in addition, an abstract Classifier may be shown using the textual annotation {abstract} after or below its name.
Neither of the two is indicated in the first diagram, so the answer is simply erroneous.
Note, one more indirect indication of the abstract class (though it is not directly mentioned, just comes from the general description) could be using a Generalization Set. There are a couple of notations used here, you can read about them in Section 9.7.4 (the entire Section 9.7 is about Generalization Sets). This notation also isn't used so still - there is nothing to indicate class A is abstract.
First diagram
You cannot deduct from the diagram if A is an interface, an abstract class or a concrete class:
A could be a concrete class that is further specialized by B and C
A could be an abstract class and B and C be abstract or concrete specializations. One would expect A to be in italic or followed with an {abstract} adornment, but these are not mandatory.
A could even be an interface under some circumstances. In this case, B and C would be specialized interfaces. This possibility has however a low probability because the «interface» keyword would be expected above A. This notation was not mandatory in earlier UML 2 versions but the current UML 2.5 requires it (see Axel's comment).
So if the UML notation would be used with all possible accuracy, A would be a concrete class, but you can objectively not be 100% certain.
Important note: the provided answer claiming that "there is no instance for A" is hearsay. No element in the diagram allows to draw this conclusion
Second diagram
We have seen that the answers to the first questions are flawed, and likewise, B is not necessarily an abstract class.
Important revelation: you need to know that b : B is possible even if B was abstract, because in an object diagram you may chose arbitrarily to show membership to one class, event if the object would be more specialized:
UML 2.5 - Section 9.8.3: An InstanceSpecification represents the possible or actual existence of instances in a modeled system and completely or partially describes those instances.
In case of doubt, a few lines later, you'll read:
The InstanceSpecification may represent: - Classification of the instance by one or more Classifiers, any of which may be abstract.
Keeping this in mind, the answers to the second diagram are all correct, whether B is abstract or not.
I am learning OOP concepts, which do not really have well-established definitions.
I heard different things about polymorphism and can not decide what is right.
Most people will say that it is a type-theory. Meaning that a function is able to accept multiple types of parameters that have something in common.
Ad hoc polymorphism is about different overloads of the same function.
Parametric polymorphism is generic functions.
Subtyping polymorphism is that if a function accepts a certain class as parameter, it can also accept its subclasses. (Of course only those can be passed as parameter which are not abstract but concrete).
There is a seemingly different definition. There are those who say polymorphism means that a function can have different implementations (morphs/forms).
In that sense...
- interface functions,
- abstract classes’ abstract functions,
- and virtual functions that can be overridden by the subtype
...are all considered polymorphic.
As I was told, polymorphism in this sense can be defined as having different results if the same function is called on different objects.
And adding to the confusion, someone said only virtual functions are polymorphic because they already have an implementation.
For me the first way I presented polymorphism and the second seem completely different, but maybe they both fit the definition of polymorphism and it is just me being unable to understand it.
So what is polymorphism in programming? Is it just a type-theory?
In this question I would like to refer to this question:
https://stackoverflow.com/questions/25163683/polymorphism-and-interfaces-clarification#=
It raises almost the same problem, but I could not really make out the conclusion.
Yes and No.
Yes, in classic inherited languages it works that way.
No, since in other languages the calling of a method on an object might be dynamically resolved. (e.g. by runtime code searching in a list of objects as a field, so called aggregate in COM terms)
IOW that that method exists in the type of the object is not defined in type theory. At least not universal. The language might not even be typed.
For a statically inherited object model, it is however true. IOW Typing (subtyping/inheritance, de concept of virtual methods) is an implementation of polymorphism in languages with such object model. But not all languages do.
Some have dispatch polymorphism, and can add methods runtime (like objective C) or figure out of the method exists at all (e.g. COM IDispatch )
The classic test of polymorphism is the "the duck quacks". Where you have a generic "animal" and call a method for "makesound", and if you assigned a duck it "quacks". So you call a method (pass a message in old OO jargon) on an generic object, and you get the behaviour of the more specialized object assigned to it.
What constitutes a "generic" object depends on the language. In statically inherited languages the generic object must have the method declared, sometimes with special modifiers (virtual) to signal overridability.
In other languages the generic object can be the root object, and the runtime will figure out if it has a makesound method.
I can not find an answer in the official documentation (https://www.omg.org/spec/UML/2.5.1/). What happens when I merge two packages which contain classes of the same name, which contain attributes of the same name but different types. Let's also assume these attributes have their own setter methods.
UML Diagram:
UML (2.5) says about package merges (§ 12.2.3.3 General Package Merge Rules, p 242)
Matching typed elements (e.g., Properties, Parameters) must have
conforming types. For types that are Classes or Datatypes, a
conforming type is either the same type or a common supertype. For all
other cases, conformance means that the types must be the same.
So because the type of uniqueID Integer is not the same or a subtype of String, your package merge is invalid.
The operation setUniqueID(Integer) doesn't pose a problem as the two operations setUniqueID(Integer) and setUniqueID(String) can coexist as overloaded operations.
Two R questions:
What is the difference between the type (returned by typeof) and the class (returned by class) of a variable? Is the difference similar to that in, say, C++ language?
What are possible types and classes of variables?
In R every "object" has a mode and a class. The former represents how an object is stored in memory (numeric, character, list and function) while the later represents its abstract type. For example:
d <- data.frame(V1=c(1,2))
class(d)
# [1] "data.frame"
mode(d)
# [1] "list"
typeof(d)
# list
As you can see data frames are stored in memory as list but they are wrapped into data.frame objects. The latter allows for usage of member functions as well as overloading functions such as print with a custom behavior.
typeof(storage.mode) will usually give the same information as mode but not always. Case in point:
typeof(c(1,2))
# [1] "double"
mode(c(1,2))
# [1] "numeric"
The reasoning behind this can be found here:
The R specific function typeof returns the type of an R object
Function mode gives information about the mode of an object in the sense of Becker, Chambers & Wilks (1988), and is more compatible with other implementations of the S language
The link that I posted above also contains a list of all native R basic types (vectors, lists etc.) and all compound objects (factors and data.frames) as well as some examples of how mode, typeof and class are related for each type.
type really refers to the different data structures available in R. This discussion in the R Language Definition manual may get you started on objects and types.
On the other hand, class means something else in R than what you may expect. From
the R Language Definition manual (that came with your version of R):
2.2.4 Classes
R has an elaborate class system1, principally controlled via the class attribute. This attribute is a character vector containing the list
of classes that an object inherits from. This forms the basis of the “generic methods” functionality in R.
This attribute can be accessed and manipulated virtually without restriction by users. There is no checking that an object actually contains the components that class methods expect. Thus, altering the class attribute should be done with caution, and when they are available specific creation and coercion functions should be preferred.