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.
Related
So lets say I have a class CelebrityDog. CelebrityDog can either be a BigDog or a SmallDog depending on what the user wants.
It will inherit the properties of one of them, but not of both. How would I depict this in a UML diagram?
UML perspective
I am sorry to come with an unpleasant answer, but this is not possible in UML according to the UML 2.5 standard, section 9.2.4.1:
Generalizations define generalization/specialization relationships
between Classifiers. Each Generalization relates a specific Classifier
to a more general Classifier.
...
An instance of a Classifier is also an (indirect) instance of each of
its generalizations. Any Constraints applying to instances of the
generalizations also apply to instances of the Classifier.
In other words, an inheritance relation in UML is a relationship between a generalization and a specialization. A class can be the specialization of several more generalization class but always in the same time (i.e. multiple inheritance.
Design perspective
I'll add to the already unpleasant answer, that this is anyways a very bad desgin, that you will not be able to implement in most of the mainstream languages.
You can improve with a model that is closer to the reality of the relationsips:
CelebrityDog is a Dog (inheritance, this is always true)
Dog has a DogSize (association, i.e. composition when implementing) which can change over time
DogSize can be specialized into BigDogSize or SmallDogSize
Et voilà !
Dog is the top level class. It does not contain a size attribute.
CelebrityDog derives from Dog (as do normal, EverydayDogs).
BigDog and SmallDog derive from CelebrityDog. Perhaps change their class names to BigCelebrityDog and SmallCelebrityDog.
It is possible to use multiple inheritance to solve this, but that can be confusing.
I've read that UML assumes by default that :
a class can inherit several others
an object is an instance of only one class
an object of a given class cannot change to another class
This leads me to the question : as there are 3 hypothesis, there are 2^3 possible combinations. Could you give me languages which would be examples of each of them ?
I mean for me Java is "false-true-true" and C++ is "true-true-true". What about the 6 others ? Or did I misinterpret the assumptions ?
Let's look at the UML 2.5 standard of the OMG, to have a definitive answer:
1.Class inheritance
The UML 2.5 standard clearly defines that a class can have none or several superclasses and, that conversely, a class can be superclass of none or several classes (see section 11.4.2 and 11.8.3.6).
So UML definitively allows multiple inheritance (as in C++ or Python). But you may as well restrict yourself and use only single inheritance and several interface implementations, like in Java and C#. You'd use a realization relationship to show the "inheritance" from an abstract interface (the inheritance arrow is then dotted).
2. Objects and classes
9.8.1: InstanceSpecifications represent instances of Classifiers in a modeled
system. They are often used to model example configurations of
instances.
FYI: the terms used in the standard are a little more general, but an object is an instance, and a class a classifier. This definition is then further refined in the semantcs in chapter 9.8.3 :
The InstanceSpecification may represent: • Classification of the
instance by one or more Classifiers, any of which may be abstract.
So UML allows objects to be an instantiation of several classes. I don't know languages that allow this, but if you do don't hesitate to comment ;-).
3. Changing class of object
I must admit that I can't answer this answer 100%. I don't think so, because, becoming an instance of another class would mean to re-insantiate a class, so it's not corresponding anymore to the definition of an instantiation.
Furthermore (see 9.8.3):
An InstanceSpecification may represent an instance at a point in time
(a snapshot). Changes to the instance may be modeled using multiple
InstanceSpecification, one for each snapshot.
This is somewhat ambiguous: a given object in a given diagram can't change classes. However, you can represent several times the object in different diagrams (snapshot) to show a change.
Conclusions
So your assumption 1 is true, 2 is false, and 3 true or false depending if you're reasoning at diagram or model level.
I'm making a class diagram for a project.
How can I describe vectors, lists, files or unsigned types?
I would like to make a detailed diagram so I need to specify the types of the members and the input/output parameters of the methods.
Thank you all!
For more detailed description of the inner structure of the class you need a Composite Structure Diagram. There you can describe your methods as "ports". And your fields as attributes. You can show there really almost everything!
For detailed description of the specific instances of the class and their mutual behaviour you need an Object diagram.
At the links applied you can see a bit how to make them. But take it as a start only.
The class diagram is too common to describe the inner structure of the class. It is tooled for the description of the inter-classes relations. So, you can put your information into the model of the class, but some of it won't be seen on the diagram. But I would advise you to start from the class diagram and make it as detailed as it can show and only later go to more detailed diagrams. Maybe you won't need them after all.
Edit:
You can make a port on the border of your class, name it fileName and connect it to io interface you use. (Composite Structure Diagram only)
As for vector/list, it is easier, and could be done in a Class Diagram. If you want to show that some attribute is a vector or list, simply write: someAttr:List or put a List block on the diagram, draw association to it and name its end "someAttribute". You could do it with File, too, but there you should draw more, I think, to show the used io interface.
For showing attributes in class diagram also look here.
You should use an uml class diagramm. [Link][1]
In a class diagramm you can relate class members with types, functions with parameters and signatures.
[1] http://www.holub.com/goodies/uml/
(Somebody can format this? IMHO SO app can not handle links..)
Your question is not clear to me. There are two variants:
you need to define what type of collections (vector, list etc) in specific programming language should be used to implement multicity element ([N], [0..N] ordered or unordered, unique or nonuniqu)
It is not possible to explicitly define in UML. You can only declare, what type it is. For example in note or constraint
You need simply define types of collection
Use ordinary class or DataType element to define
Standard syntax for member (attribute, port etc.) is following: +name:Type[Multiplicity]{contraints}
The same syntax is used for parameters (all types) of operation (methods in programming language)
I was self-studying various UML diagrams and I understood most of them except for Class Diagram and Object Diagram.
I can not get my head around how they wil be converted into code.
The trick that I learnt is this: all nouns become classes and verbs become methods of the classes.
All good till there but after that, how is the diagram converted into code?
Have a look at a diagram here that I got from the internet:
So, assuming that the language is Java, how will you code a software based on this?
A UML diagram solely describes the internal architecture of a given piece of software.
The information contained in your UML diagram is therefore:
What classes are contained
What methods and properties do they contain
How do they relate to each other
Each block with a header ("Train" for instance ) represents a class, listing its properties and methods.
As such the UML diagram does not state anything about a GUI or how the user interacts with the software. It is up to you or a UI/UX designer to create an interface you can implement, that uses the functionality outlined in this UML diagram.
You can think of a UML diagram as a description of the architecture of a piece of software, that is very shallow but is well suited for an overview of the project.
It is not a recipe.
I hope this was useful to you.
When you have a class diagram, you have a representation of the classes (and its members) that you should have in code.
So, your noun/verb analysis (what you were talking about), has already been done when you have a class diagram.
A class diagram is just a visual representation of your classes, converting them to code is just easy if you know the syntax of the language that you want to use.
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.