Several questions about UML:
Do I include the main class in my UML diagram?
If I do include it, and it instantiates objects, do I draw an empty arrow (such as ->) from my main class to the classes it instantiates?
When do I use the diamond vs. the arrow?
I'm just curious about those 3 things... While an article would also be very helpful, could someone address those three questions?
Thank you so much.
Do I include the main class in my UML diagram?
There are many types of UML diagrams, but I suspect here you mean a class diagram. The answer to your question is literally: if you want to. The beauty of UML is that you can make many diagrams, that vary in detail. Some diagrams will show just a few classes, some many. The idea is that you diagram different parts of the system, at different views, for different audiences. Diagram as much or as little as you like. If you are making a very small application with just a few classes, then it probably will make sense to show the main class. Give it a stereotype or use a comment that identifies it as a "main application class."
If I do include it, and it instantiates objects, do I draw an empty arrow (such as ->) from my main class to the classes it instantiates?
You certainly may, again "if you want to," There will be a dependency here in a way: the main class "depends on" the other classes because it uses them somehow. That is, if main class A instantiates objects of class B, then class A needs class B to compile, so you may show this as a dependency if you wish.
When do I use the diamond vs. the arrow?
The diamond shows aggregation or composition and is used as follows: if class A has a field of class B, then an arrow from A to B with a diamond on the A side is called for. The "plain arrow" just shows a relatively unspecificed dependency. You can use it from class A to class B when class A uses, somehow class B. Perhaps a method of class A uses an instance of class B as a local variable. No containment (composition or aggregation) of a B in an A is implied with the plain dependency.
It seems that you are not an UML expert but this is not a problem. What I would recommend is to simply reverse engineer your code into class diagrams and then add your own notes inside a yellow rectangle having a connector linked to what you consider important.
You will get a graphical representation of your code and would be able to add value comments without having real UML knowledge.
UML class diagram is really simple and can cover all needs of a project. If you don't know UML then just do class diagram by reversing your code and enjoy :-)
Related
I know the following:
OCL is a constraint language that to specify constraints on my class diagram models
I know, that in the OMG world for class diagrams there are 3 levels of models: M1 (model), M2 (meta-mode), M3 (meta-meta model)
M3: defines what a class diagram is and what it consists of
M2: Is the meta-model of my problem/domain (e.g.: meta-model of a shelf that contains books)
M3: is the model instance (e.g: a Shelf that contains two specific books)
What i would like to know:
Is there a a common meta-model for class diagrams and OCL; basically something that defines the relationship between model elements and constraints
I suppose it should somehow be defined at M1 level
I am asking because:
I would like to define a meta-model for a constraint language (lightweight OCL) that would allow for me to reason about my model elements (books on the shelf).
How would i connect the meta-models of my domain and of my constraint language?
The OCL specification [1] defines a metamodel for OCL, however there are a variety of problems that mean that practical tools have to 'improve' upon it in proprietary ways. The new Pivot variant of Eclipse OCL prototypes solutions to OMG specification problems and produces an XMI serialization that is credible. It uses an Xtext grammar [2] that you might use as a starting point. This will reveal how much semantic resolution is necessary to resolve the parts of "a.b.c.d". Not easy.
The common metamodel [3] for Pivot OCL is autogenerated by a merge of UML and OCL contributions.
Since OCL may be used to constrain stereotypes or metamodels or even run-time, OCL can be between and pair of Mn/Mn+1 levels.
If you succeed in coming up with an accurate complete lightweight parser, please share.
[1] https://www.omg.org/spec/OCL/2.4
[2] https://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.xtext.essentialocl/src/org/eclipse/ocl/xtext/essentialocl/EssentialOCL.xtext
[3] https://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.pivot/model/Pivot.ecore
I’m trying to understand one of uml test questions. The associations are different between base and inherited classes, but do inherited classes also inherit the association between base classes, I mean, do inherited classes actually have two associations?
I also have different statements, from which I need to choose the correct one. The right answer is A, but I don’t understand why A is correct and other are not, so if it is possible, please explain every statement.
A) An instance of the ConcreteSubject class might have a reference to zero or more objects of the Observer type.
B) Each instance of the Observer class has a reference to exactly one instance of the Subject class.
C) Each instance of the Subject class has a reference to exactly one instance of the Observer class.
D) An instance of the ConcreteSubject class cannot have any reference to an instance of any other class.
E) An instance of the ConcreteObserver class might have a reference to zero or more instances of the ConcreteSubject class.
Thank you!
[This question and answer hopefully creates some pressure on universty teachers to care about the quality of their exam/quiz questions.]
First, it is important to note that the class diagram has several flaws. The role names "subject" and "object" are at the wrong (opposite) association end. Then, as you have wondered, the subject-objects association has been duplicated, since it is inherited.
Concerning the questions, both answers A and B are correct, while all others are wrong. This follows directly from reading the multiplicity constraints of the one-to-many subject-objects association.
Btw, the wording of answer options B and C is kind of flawed: it may be confusing to say "each instance of the Observer (or Subject) class", since these classes are abstract (visualized by names in italics), which implies that they do not have their own (direct) instances. However, in a general sense, one can say that they do have instances, namely all instances of their concrete subclasses. Therefore, these two answer options are confusing. But it is an important fairness requirement for any kind of exam not to use confusing questions.
I guess that your teacher considers answer B as wrong because it is about instances of the abstract classes Observer and Subject. However, in its current form, answer B is correct. It would only be incorrect, if it would be reworded as "each direct instance of the Observer (or Subject) class".
Answer C is incorrect because an instance of the Subject class may have no link to any Observer (this is implied by the 0 in the 0..* multiplicity expression).
Answer D is incorrect because the model does not contain any such constraint (which, btw, doesn't make any sense).
Answer E is incorrect because it contradicts the multiplicity constraint that any observer must observe exactly one subject, expressed by the multiplicity expression 1.
I am part of a working group that is developing an IEEE standard. The problem domain of the standard is expressed as an object-oriented model. The model is independent of any particular implementation language but does use UML to express aspects of the model. In many places in the text there are references to "instances of Foo" where Foo is an abstract class. What is really meant is, "instances of any instantiable subclass of Foo".
It has always been my experience that the "instances of Foo" was understood to mean "instances of any instantiable subclass of Foo". Is this understanding something that most people versed in object-oriented models would share? If so, is there some good reference that we can point to that would support this understanding? If this isn't something that is commonly understood then we need to change a lot of text, but that's the way it goes.
The question has two aspects, firt what is correct in senso of UML and second how is it understood in reality.
Let us start with the simpler aspect. The UML standard clearly states that any instance of a classifier is also an instance of any of its generalizations
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.
This just gives a very static view on it. But and is not the compelete answer, because it does not say anything about how the instances can be used dynamically. But the standard also states that any instance can be used as an instance of any its generalized classifiers:
Type conformance means that if one Type conforms to another, then any
instance of the first Type may be used as the value of a TypedElement
whose type is declared to be the second Type. A Classifier is a Type,
and conforms to itself and to all of its generalizations.
So in that case the standard is quite clear.
Second aspect, the reality. In reality most of the practically applied OOP languages support polymorphism. Simplified spoken, any object of class can be treated as if it were an object of any of its super classes. Thus most people intepretete it like you meant it.
Therefore I would propose to use it in the proposed way in your standard and additionally write this in an introductionary chapter as an help for interpretation.
All refernces are to OMG UML 2.5.1.
Having just gone back (again) to the OMG standard for UML and searched through it again I found this text:
An instance of a Classifier is also an (indirect) instance of each of
its generalizations.
Furthermore, in clause 9.7.5 it uses the text
each instance of Person
in reference to a model shown in Figure 9.22.
In Figure 9.22, class Person is abstract. I think this pretty clearly resolves this in favor of , "instances of Foo," being completely correct and acceptable.
I have some objects that I want to draw a UML diagram for. The first, A, is an interface, and second, B, is an abstract class which is derived from A. The other class are C and D. C and D are subclasses of B.
B has a list of E class objects.
F is a class which all operations are performed in it. C and D class objects creates in the class according to polimorphism operations and then calls its methods according to users input.
Of course, there is a main class. The main class only creates F class object.
I want to draw a UML class diagram. What should the image be like? How can I draw F class ?
The uml class diagram which is writen by my is here.
By the way I know that's the very basic image, I'll edit it after you response.
Based on your description, this is what I think the UML diagram would look like.
For this statement "F is a class which all operations are performed in it. C and D class objects creates in the class according to polimorphism operations and then calls its methods according to users input."
It sounds like you would need to make a relationship between A and F because you are talking about polymorphism. A should have methods. B and C could have those same methods. F doesn't need a relationship to B or C because the relationship to A implies there is a class implementing A but the concrete class name is irrelevant.
Since I can not add a comment. I would suggest two points:
- Maybe the aggregation could be changed in composition if Main class gets an attribute of type F, otherwise a dependency would modelize better the relation between Main and F.
It would be more precise if a cardinality were defined on B side in the relation between B and E.
Hoppe this help to improve the good answer of ProgrammersBlock
I have 2 questions about class diagram. firstly if i have used an object of class A in my class B , in drawing the class diagram i should associate class A with B . or association is just used when a class uses a method of the other class.
my other question is almost similar. if in class A i have a dictionary< class B, Class C> , then in class diagram should i associate the class A with B and C and say 'use'in connection?
In my view, in both cases it is a Dependency you show, not an Association.
In UML, the relationships tend to cover:
Dependency
Association
Generalization
Relization
In your case, the closest is a Dependency from Class A on B and C (represented with dashed line with arrowhead pointing to B and C). You're not directly associating (via aggregation or composition), you're not generalising A into B or C (or vice versa) nor are B or C realizing A (or vice versa).
If in doubt, I strongly suggest using a UML reverse-engineering tool and writing the source-code skeleton you know of, and see what it suggests. I use, but don't necessarily recommend, Enterprise Architect.
Associations are used when the A class "will" have an attribute of type B. I.e. at the UML level this is indicated using associations. At the code level, e.g. Java, these associations are transformed into attributes in the participant classes (one or two depending on the navigability properties of the association)