Let's take 2 UML class model entities: One represents an actual Order and another represents an Orede Type. Any Order corresponds to one Type. A 2-way-naviglabe many Orders to one Type relation is meant. Order Type instances are, for example, "Request availability", "Request price", "Preorder", "Buy", "Cancel", "Request support", etc. Order Types are to be addable and editable in the resulting application. Should I model Order Type as Class or as Enumeration? From the data perspective I can't see the difference actually.
I would prefer an enumeration. Classes should define properties and behaviour. In this case the type represents only a value with no need of methods.
Conclusion:
The usage of a class would surely possible but not necessary if you only want to represent values. Also, it would create a lot of extra coding work. You would have to write and maintain a bunch of classes that only represent one value when you could use an enumeration, which is surely the best and shortes way to represent typed values.
Related
I have a hard time understanding the concept of association class as explained in UML 2.5 specification. The thing that confuses me the most is the following sentence taken from page 199:
NOTE. Even when all ends of the AssociationClass have isUnique=true, it is possible to have several instances associating the same set of instances of the end Classes.
As noted here: https://issues.omg.org/issues/UMLR-757 this single sentence seems to undermine the usefulness of the concept. At the same time, it makes pretty much every text explaining the concept written before 2.5 version of the UML spec obsolete – see for example the discussion here: UML association class - clarifying
But how can this actually work conceptually? Assuming all ends of the association class have isUnique=true, how can one have more than one instance of association class associating the same set of instances of the end classes, when isUnique property of member ends clearly forbids existence of such links?
I’ve always thought that an association class is just a regular association with extra attributes and/or operations. That interpretation seems to invalid now. So what exactly is association class? How can it have uniqueness independent from that of association member ends? There seem to be some unspoken multiplicity lurking somewhere (uniqueness is irrelevant property without maximum multiplicity higher than 1), but I can't figure out where.
In very short
Indeed, this is not super-clear and would deserve a better explanation. To make it short: it’s just a consequence of the lack of integration in the dual semantics defined for the association class.
Detailed explanation
What is uniqueness for an association
According to UML 2.5.1 section 11.5.3.1, page 197:
When one or more ends of the Association have isUnique=false, it is possible to have several links associating the same set of instances.
We can deduct using logical contraposition that:
If it is not possible to have several links associating the same set of instances, all ends of the association have isUnique=true.
So we'd expect this to apply to an assocation class as well, since the association class is also an association.
Association classes are two distinct things at the same time
According to UML 2.5.1 section 11.5.3.2:
An AssociationClass is both an Association and a Class, and preserves the static and dynamic semantics of both.
So, an association class is not just "an association with extra attributes". If it were that simple, the association class could perfectly be a generalization of an association: the specialized association would just inherit the extra attributes. But this is explicitly prohibited page 199:
An AssociationClass cannot be a generalization of an Association or a
Class.
because any specialization into a class would loose the association semantics, and any specialization into an association would loose the class semantics.
And this duality, is the cause of our issue.
Impact of this duality on instances
According to UML section 11.5.3.2, page 199 (formatting from me):
An instance of an AssociationClass has the characteristics both of a link representing an instantiation of the AssociationClass as a kind of Association, AND of an object representing an instantiation of the AssociationClass as a kind of Class.
If isUnique=true for all association ends, the instances of the association are guaranteed to be unique. Remind however that the association is only about tuples made out of the association ends:
An Association declares that there can be links between instances whose types conform to or implement the associated types. A link is a tuple with one value for each memberEnd of the Association, where each value is an instance whose type conforms to or implements the type at the end.
However, nothing in the specs requires that the class instantiation (object) representing the association instantiation needs to be unique.
Imagine for example, that we have an association class between class A and class B, and a and b are instances of these classes. Imagine that the association ends have isUnique=true. This means that there can be only one tuple (a,b) since the association is guaranteed to be unique.
Let P be a property of the association class, and let (a,b,p1) and (a,b,p2) be two instances of the class in the association-class. The class knows no association-ends: from the point of view of the class, there is no unicity requirement. And from the point of view of the association, we have only one tuple (a,b) , so it's ok as well.
The NOTE just explains that this (unfortunate and ambiguous) situation is possible.
Are there contradictions or inconsistencies?
Formally, there is no contradiction. This is the result of the way the association class is defined: a class and an association at the same time, without further defining the relationship between the respective instances.
But this creates some issues in regard of the semantics of associations having non-unique ends:
When one or more ends of the Association have isUnique=false, it is possible to have several links associating the same set of instances. In such a case, links carry an additional identifier apart from their end values.
More precisely, this makes the the association-class with unique ends useless, since the same result can be achieved with non-unique ends:
for a simple association with non-unique ends, you can have duplicates, i.e. several links associating the same instances of the association ends that are distinguished with an additional identifier.
for association classes with unique ends, according to the note you can have duplicates, i.e. several objects (class instances) corresponding to a link made of unique association ends (association instances).
for an association-class with non-unique ends, you could have duplicates, i.e. several object instances correspond to the same set of member ends. It makes no difference if you interpret this as several links associating the same instances of the association ends, each associated with a single object, or, if you interpret this as one link associating a unique set of instances of the association end, that would be each be associated to mutliple object instances.
IMHO, this is unfortunate:
it does not match our mental model in which an association class with all association ends having isUnique=true should have a unique object instance of the class for a unique combination association ends. This clearly goes against the principle of least astonishment: I started with deny and it took me a while to accept this, since it was so terribly different from the traditional ways to implement association classes.
two different models, one with unique association ends, and one without could in fact express the same situation.
A simple solution to this issue would be to require a unique class instance (object corresponding to the association class) to correspond to a link that uniquely associates association ends. In that way, unique association ends would imply unique association object, without requiring other changes to the UML specs.
In my UML class diagrams I usually do object collections by placing the attribute name above the arrow that relates both classes (as opposed to the other notation that just adds the attribute with brackets indicating the multiplicity).
But I have cases in which there are more than one collection of the same kind of object. For example (a very simple example off the top of my head):
Let's say there is a course that has some students who applied for it (so I have a collection of students, let's say an attribute that is an ArrayList of Student, called "applied"). But also, I need to keep a separate collection of the students who actually attended the course (let's say, "attended": another attribute that is an ArrayList, or even a different collection type, like a Vector, of Student).
Should I just add all attribute names on the relationship line?
I'm looking to do this the standard UML way. Only clarifying this because I know UML rules can be flexible when we need them to.
UML does allow for multiple associations between classes using roles.
You would simply draw two arrows:
See here for a similar question where the diagram is taken from.
As i read through UML specification that:
class has a set of attributes/operations
and data type has a set of attributes/operations
1)with regards to attributes/operations of data type
what this means?
because i don't know how such a data type has attributes and operations?
2)What’s the main difference between a class and a datatype?
according to UML 2.4.1 specification
A data type is a special kind of classifier, similar to a class. It
differs from a class in that instances of a data type are identified
only by their value. All copies of an instance of a data type and any
instances of that data type with the same value are considered to be
equal instances. Instances of a data type that have attributes (i.e.,
is a structured data type) are considered to be equal if the structure
is the same and the values of the corresponding attributes are equal.
If a data type has attributes, then instances of that data type will
contain attribute values matching the attributes.
1)Attributes/operations of data type have the same meaning than attributes/operations of classes i.e. attributes represent the structure of your data type and operations represent the method available on your data type.
2)The main difference between a class and a datatype is that it is not possible to have two instances of a datatype with the same values (these instance would be one unique instance).
Hoping it helps,
RB
In the Object Oriented
(OO)
approach
,
systems
,
including software
,
are
made up of numerous
objects
that work
together by exchanging information in
the form of data values and ‘messages’
. An object is a specific instance of a
Class
like your dog (an object) is specific instance of the class of all dogs.
Classes define what an object is like, and
objects are practical instances that can be used and manipulated.
As a definition, a class defines what properties will
be used to describe every object based on this class. Within the object each of these properties will have a value that
contributes to its description. Two objects of the same class will have the same properties, but they will have at least
one property that
has a different value in each of the objects
–
if all the properties have the same values in both of the
two objects then they are the same object.
A data type refers to the attributes of an object and what type of data each attribute is, such as string, boolean, integer etc.
Operations or methods is what an object can do such as for a dog:
growl();
bark();
fetch();
etc.
Have a look at this explanation of a Class Diagram, it will make more sense.
I have two private data structures and five functions in my class, How can I represent the relation between the functions and the data structures in class. Eg: Two of those functions uses the First data structure and three other functions uses the second data structure.
Also How can I represent relation between the functions in the class. eg : among the 5 functions two are public and three are private, one public function in the class calls the other three private functions.
If this is not relevant in class diagram then what is the best solution to represent this in UML.
the interaction of functions and fields is not displayed in a Class Diagram.
Therefore you should use a sequence diagramm. But normaly you do not show the interaction of fields within an Object. You display the interaction on the level of function calls between Objects.
Two things. First, there's a good reason UML doesn't provide notation for depicting relationships & structure within a class. Classes are supposed to be cohesive abstractions of data and function. So if you have any significant structure within a class, you should question whether it should be split into 2 (or more) cohesively abstracted classes.
OK. So that's the backdrop. From your description, how about:
Draw one class for each data structure with one attribute for each structure member
Add a method to each class for each function that operates on the data structure
Add an association between the classes that captures their relationship
Place all the bits above in a package to represent the module
The final point - as in all these things - is to use the tool to illustrate what you want. Don't be overly constrained by the rules of the modelling language. The important thing is that the diagram communicates effectively to you & your collaborators. Satisfying the 'language lawyers' should be much less of a consideration.
hth.
Are interfaces a layer between objects(different objects) and actions(different object types trying to perform same action)? and Interface checks what kind of object is it and how it can perform a particular action?
I'd say that it's better to think of an interface as a promise. In Java there is the interface construct that allows for inheritance of an API, but doesn't specify behavior. In general though, an interface is comprised of the methods an object presents for interacting with the object.
In duck-typed languages, if an object presents a particular set of methods (the interface) specific to a particular class, then that object is like the specifying class.
Enforcement of interface is complicated, since you need to specify some set of criteria for behavior. An interesting example would the design-by-contract ideas in Eiffel.
Are you asking about the term "interface" as used in a specific language (such as Java or Objective-C), or the generic meaning of the term?
If the latter, then an "interface" can be almost anything. Pour oil on water -- the line between them is an "interface". An interface is any point where two separate things meet and interact.
The term does not have a rigorous definition in computing, but refers to any place where two relatively distinct domains interact.
To understand interfaces in .net or Java, one must first recognize that inheritance combines two concepts:
Implementations of the derived type will include all fields (including private ones) of the base type, and can access any and all public or protected members of the base type as if it were its own.
Objects of the derived type may be freely used in place of objects of the base type.
Allowing objects to use members of more than one base type as their own is complicated. Some languages provide ways of doing so, but there can often be confusion as to which portion of which base object is being referred to, especially if one is inheriting from two classes which independently inherit from a third. Consequently, many frameworks only allow objects to inherit from one base object.
On the other hand, allowing objects to be substitutable for more than one other type of object does not create these difficulties. An object representing a database table may, for example, allow itself to be passed to a routine that wants a "thing that can enumerate contents, which are of type T (IEnumerable<T> in .net)", or a routine that wants a "thing that can have things of type T added to it" (ICollection<T> in .net), or a thing that wants a "thing that wants to know when it's no longer needed (IDisposable in .net)". Note that there are some things that want notification when they're no longer needed that do not represent enumerable collections, and there are other things that represent enumerable collections that can be abandoned without notification. Thus, neither type of object could inherit from the other, but if one uses an interface to represent "things which can enumerate their contents, which are of type T", or "things that want to know when they are no longer needed", then there's no problem having classes implement both interfaces.