Either the above notation indicates Uni-Directional Association (both strong [solid lines] and weak [dotted lines]), or the notation is inconsistent with traditional UML and is trying to indicate an Interface with the dotted lines (without appropriate 'arrowheads'). What do you guys think?
One simple look tells that the author has no idea of UML. Look at the dependency between Part and Product. Clearly it's the wrong way around. Further, an abstract class must be concretized somewhere, which is not the case (I guess the two lower associations should be generalizations). Ask the author what he wanted to say.
Related
I work in the aviation industry, and I am trying to understand this UML diagram. I did a little bit of UML in college. Can you help me to interpret this diagram?
What is the difference between << extend >> and << select >>?
What do the big black arrows mean?
I didn't understand how to read the graph.
«extend»and «select» are stereotypes which were given a certain meaning in the domain of that model. Usually a profile is used to define the sterotypes and their meaning. So the best is you contact the author of the diagram and ask about it. There is no general answer. It looks a bit like these are meant to be requirements.
The "black arrows" with the lozenge are associations that are given a composite aggregation attribute. The lozenge-side is responsible for the lifetime of the other side. Means it will destroy them when it is destroyed itself.
Fun note about the «class» (as per comment from Axel Scheithauer from p. 99 of UML 2.5:
If the default notation is used for a Classifier, a keyword corresponding to the metaclass of the Classifier shall be shown in guillemets above the name. The keywords for each metaclass are listed in Annex C and are specified in the notation for each subclass of Classifier. No keyword is needed to indicate that the metaclass is Class.
So putting that keyword there is like painting "car" on a car to make it a car, obviously.
A Class has slash at front and is an Abstract. I have seen derived attributes in class with slash at the beginning but I don't know what does it mean when we have slash before a Class name.
The only mention of a slash in front of a classifier name in the UML2 spec concerns interfaces of components. In ch. 8.3.1, p. 155:
Interfaces that are exposed by a Component and notated on a diagram, either
directly or through a port definition, may be inherited from a supertype
component. These interfaces are indicated on the diagram by preceding the name
of the interface by a forward slash.
This seems unlikely to be the case in your example however. So my best guess would be that it's some non-normative use. Apparently some people use a slash to indicate the classifier to be an interface. But again, that's non-normative - the correct presentation would be using the «interface» keyword.
I think you kind of answered this yourself. A slash in front of an attribute means that the attribute is derived. The value of a derived class is calculated from the value of other base classes in the diagram.
This is sometimes denoted by an operation like convertToDC():DerivedClass listed in the object to send information from the base class to the derived class.
Here's a little more information that might help you out.
A slash in front of a class name is imo not allowed by the UML spec. So this seems to be an error. You should ask the author of the diagram (or tool which created it) about the slash.
(Regarding the derived attributes you are correct. But they are not defined by the superclass but a computation rule.)
I started writing some code for a 2D game, created a class "objets" trying to keep it as generic as possible. I have a few methods and attributes that are common to every kind of element (buldings, ppl, interface buttons, etc) like (w, h, x, y ...you know) but most of them only make sense when applied to and specific type of item.
So I would have to inherit a new class for every type of actor in the game?
Just wondering if this is a common practice, or maybe i should manage it in a different way.
Thanks in advance.
If you're introducing behaviour then subclass, however if the difference is attribute based then don't e.g.
Animal (has .colour and .makeSound) -> Dog (has .eatOwnPoop) -> RedDog (no, too specific, covered by colour)
Notice how I had ".makeSound" in Animal. I could have put .bark in dog, but then I'd have to put .meow in cat etc. The subclass can simply override and provide a concrete sound.
However, you can use interfaces to better cross-cut your code, but that's quite a lengthy topic and probably overkill for your needs (although it could help any unit testing you do).
It sounds like you are over-using inheritance. It is certainly a red flag when you simultaneously say "common attributes like ..." and "...only make sense when applied to a specific type." Also, it is a red flag that domain objects such as building share a common base class with an interface object like button. Finally, it is quite unusual to define your own objet (object?) class from which every class in your system derives. It's not inconceivable, but in combination with your other comments, it sounds like you've started down an unproductive path.
You might want to refer to a good tutorial on object-oriented design and analysis such as "Head First OOA&D"
You do not HAVE to do anything. Generally, it is useful to use derived classes if they exhibit some kind of commonality but become more specialised in nature requiring specific functionality at each level of inheritance. It is also good to use if you want to have polymorphic behaviour. You have asked a very open ended question but basically do not feel that you HAVE to use inheritance as not every problem requires it and indeed some people overuse inheritance, introducing it in places where it really is not needed. All in all, I would really recommend that if you haven't already that you read a good book on object oriented design as this will then get you to think about your code from a different perspective and greatly improve the way you view software and design it. It may sound like a cop out but this kind of question is very hard to answer without knowing all details of what you are doing.
Does any programming language provide such a thing?
Where could this be used?
For example:
note that somethingStrange is not a class, its an instance (its underlined) and this is an object diagram
Spec (section 7.3.22) says:
An instance specification is depicted using the same notation as its classifier, but in place of the classifier name appears an underlined concatenation of the instance name (if any), a colon (‘:’) and the classifier name or names.
The convention for showing multiple classifiers is to separate their names by commas.
So im stuck with "multiple classifiers".
Any language with extensional rather than intensional typing will allow such constructs.
For example, in RDF two sources could make claims about a web resource which are completely conflicting, or in a 'duck type' language an object could have all the characteristics of two otherwise unrelated types.
Extensional languages classify objects by their properties - if it has prongs it's a fork, if it's got a handle and a bowl it's a spoon, if it has both prongs and a bowl it is both a fork and a spoon.
The difference between such languages and class oriented intensional languages such as C++/Java/C# to which UML is more commonly applied, is that you don't need a spork class to define things which are both spoons and forks - whether things belong to a classifier is defined by whether they meet the requirements of the classifier.
That's multiple inheritance if you're referring to classes (except that you should use solid edges for generalization), nothing wrong with that ;)
Note that an interface is also a classifier, so also the text of your question needs a bit of refinement -- nothing wrong with generalizing more than one interface, after all.
It's is a Dependency.
Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time. One class depends on another if the latter is a parameter variable or local variable of a method of the former. This is different from an association, where an attribute of the former is an instance of the latter.
In other words your somethingStance class will use both Cat and Panzer
The below it is just an example of how it might look like
Public class SomethingStrange{
public Cat CatDependency{get;set;}
public Panzer PanzerDependency{get;set;}
}
UML does allow an object to be instance of several different classes (even if they are unrelated) at the same time. The fact that this is not the normal convention and not supported by programming languages is a different issue. UML tries to be as broad as possible even if specific technologies only can implement a subset of it.
I'm trying to read UML Class diagrams used to document design patterns. I understand aggregation and composition - and aggregation uses the open diamond and composition uses the filled diamond.
I've read somewhere that a dotted line implies instantiation - i.e. if one class instantiates another then you use a dotted line from the instantiator to the instantiated. First, wouldn't composition use this as well as I thought composition implied ownership?
Second, I've seen lines drawn between classes which are not aggregate or composition - i.e. there's no diamnad at all. Here's an example where they are documenting the observer pattern:
http://www.dofactory.com/Patterns/PatternObserver.aspx
they show a line from subject to observer without any diamond. What's all this about?
thanks
Ray
A UML association is used to convey a relationship between two or more classifiers (e.g. classes). Compositions and aggregations are specialized forms of association.
Associations are often used in class diagrams to indicate that instances of one class can have references to instances of another class. For example, in the diagram to which you link, the association between ConcreteObserver and ConcreteSubject implies that a ConcreteObserver instance can have a reference to a ConcreteSubject instance (note the directionality of the association).
Dotted line implies dependency. There are many different types of dependency, one of them being instantiation. As said before, associations are a way to describe relationship between a classs having a property of another class. When it comes to relationships between classes in classs diagram, it is good to start from most concrete and go to more general. So start with composition, aggregation, association and dependency.