Use functions of a class by after including third class - uml

Sorry for the naming of the title because I don't know how to name this situation.
There are three classes A, B and C. Class A need the function of class C. Class B is an instance collection of class C. So the operation should be class A calls the static method of class B to get the instance of class C.
//in class A
Class C = B.getCInstance("[instance name]")
C.doSth();
Then what is the relationship between class A, B and C in UML? When I draw a UML class diagram, should I need to build all of the relationship between A, B and C? for example:
A class A uses a class B.
A class B has A class C.
A class A has A class C.

According the definition of the UML Usage dependency, I would say that class A uses both Class B and C and Class B uses Class C as depicted below
A Usage is a Dependency in which one NamedElement requires another NamedElement (or set of NamedElements) for its full
implementation or operation. The Usage does not specify how the client uses the supplier other than the fact that the supplier is used
by the definition or implementation of the client.

Related

UML class diagram association properties {subsets < Association end > } | {union} | {redefines}

I don't quite understand what {subset} stands for when it comes to the association between class diagrams in UML. I've found this PDF that talks about it on page 4: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.138.5537&rep=rep1&type=pdf.
Here is the diagram & text that you can also find on page 4:
I read this and I'm not 100% about what {subsets < class > } is about.
It says that "The slot representing d will be a subset of the slot representing b. Elements of type B can be inserted into slot b and elements of type D can be inserted into slots b and d."
So, is {subset} some kind of polymorphism ? I think that thorugh "slot" they mean like the argument of a method that is of type B. And because D subsets b that means that D is like the sub-class of b so it can be passed down as "b" in arguments because of Polymorphism.
So the question is :
What is {subsets < class > } exactly, is it representing a sub class ?
On top of that I have other questions:
What are {union}, {redefines < class > }, {nonunique} & {sequence}. What do does stand for ?
Some examples in code would make it easier to understand.
So the question is : What is {subsets < class > } exactly, is it representing a sub class ?
It is not {subsets < class >} but {subsets < property name >}
In the given diagram D is the only visible class specializing B, and if they are no other classes specializing B then all the instances of B are instances of D and then {subset b} is equal to b.
But having at least :
all the instances of B are not necessary instances of D (including of classes specializing D), this is why d only concerns a subset of the instances of B concerned by b.
In your diagram and mine the subsets are not really useful, but there are for instance in case of redefinition e.g. {subsets a, redefines a} {subsets b, redefines b}
What are {union}, {redefines < class > }, {nonunique} & {sequence}
referring to formal/2017-12-05 ยง9.5.4 page 113 and 114 :
union means that the property is a derived union of its subsets.
nonunique: means that there may be duplicates in a multi-valued property. This is the opposite of unique meaning there is no possible duplicates. For instance supposing b is {nonunique} then some instances of B can be present several times in b. If the property is implemented in C++ by a std::set it is {unique}.
sequence means that the property represents an ordered bag, this is a shortcut of {nonunique, ordered}. This is the case of std::vector and std::list in C++.
{redefines < property-name > } (not {redefines < class >}) means that the property redefines an inherited property identified by < property-name >. If in your diagram the {subsets b} is replaced by {redefines b} then the classes C only has the slot (e.g. attribute in C++ etc) d. This is not like having b private so not accessible from C, that really means d is a redefinition of b.

How to draw UML diagrams passing parameters through super constructor

I have a superclass called A and a subclass called B that inherits from A. The superclass's constructor looks like this:
A(String name, char displayChar, int hitPoints, Behaviour behaviour)
{
this.name = name;
this.displayChar = displayChar;
this.hitPoints = hitPoints
addBehaviour(behaviour);
}
A has attributes of name, displayChar, hitPoints, behaviour and has a method that calls addBehaviour which adds the behaviour to the object.
The subclass, B's constructor looks like this:
B(String name) {super(name, char 'b', 10, new WalkBehaviour()); }
Now my question is, does subclass B have an attribute of WalkBehaviour?
How would the UML diagram look like for this scenario? I know B inherits from A and A has Behaviour but does B has WalkBehaviour in this case? Since B doesn't have an instance variable of type WalkBehaviour in its class but only passes WalkBehaviour through its superclass's constructor.
does subclass B have an attribute of WalkBehaviour?
No. There is none declared. The superclass will do something with that new object but obviously it's hidden in the mist of its implementation.
Inheritance is nothing that involves multiple object creation. Your B instance is just a single one which does have attributes and operations like its super class.
Thus, in a SD, you will see only one life line for B:
As you can see the B instance will just issue a self-call to the super class's constructor.
Note: as #AxelScheithauer pointed out in the comment the super class will invoke addBehavior which can (but must not) be shown in the SD:

super() call in sequence diagram

How do you represent a super() call in a sequence diagram? I create a class "Bar", which is a subclass of "Foo". While creating this class Bar, the default constructor of Foo gets called to. How do you draw that in a sequence diagram?
A super call represents a call to some method of the superclass, so if class A extends from class B then:
class A extends B{
public A (){
super();
}
}
And
class B {
public B (){
...
}
}
You have to think of this classes in runtime, so for example you have an object a from class A called a, this object is represented by both classes since class A extends class B.
In this case I would do a diagram with the constructor of the super class B, so I can link this diagram to the diagram in which I represent the constructor of the class A.
Since the call to the super class constructor refers to the same object a not another object the message arrow should be a self message in which it calls to the constructor of the super class B.
Additionally to make things more clear I would add the code of the super call.
Something more graphical should be this.
And for class B
PD. I Use Enterprise Architect software to do the diagrams.

Can Groovy Mixins Satisfying Abstract Class Requirements?

I have three Groovy classes: M, A, & B. B exists as a mixin of M and an extension of the abstract class A:
class M {
def foo = 11
def bar = 12
}
abstract class A {
abstract foo
}
#Mixin(M)
class B extends A {
}
def b = new B()
print "${b.foo}\n"
print "${b.bar}\n"
Attempting to run this causes Groovy to complain with:
Can't have an abstract method in a non-abstract class. The class 'B' must be declared abstract or the method 'void setFoo(java.lang.Object)' must be implemented.
However, the method is implemented by the mixin M.
Furthermore, if I change B to be:
#Mixin(M)
class B extends A {
def foo = 13
}
Then I get the printout:
11
12
And not:
13
12
Which is what I expect and seems to prove that M provides an acceptable implementation of the abstract methods of A.
So, why isn't groovy happy with using the mixin M to satisfy the abstract class A, what am I doing wrong?
You're doing nothing wrong. It's the problem of the compiler performing this check before actually applying the AST transformations. You better post this on their issue tracker at http://jira.codehaus.org/secure/BrowseProject.jspa?id=10242.
Since #Mixin transformation was actually created by the author of Groovy++ AFAIK, and since Groovy++ has much more extended support for categories, mixins and traits you could expect this to be a valid code there. You should try it.

About casting and objects

it's simple, i just want a explanation about this:
internal class B { // Base class
}
internal class D : B { // Derived class
}
in other class I wrote:
B b3 = new Object(); //compilation time error!
why??? We suposse that all classes inherit from "object"
B is more specialized than Object, therefore you cannot assign an Object instance to a B reference. This is because not every Object is actually a B - only the opposite is true.
Let's assume that you have a field x in the class B. When you instantiate an Object, no memory is reserved for this field, and if you could assign it to a reference of type B, it would therefore try to read or write to unallocated memory, which is not allowed (or useful).
All classes are objects, but not all objects are {someclass}.
In a similar way, all buses are vehicles, but not all vehicles are buses.

Resources