Pseudocode:
Object A is a parent of Object B
Object B is a parent of Object C
Object C is a parent of Object A
Why is this usually not allowed in most programs (I've never seen it)?
Couldn't a program recognize when it's made a loop and stop performing a task?
For Instance:
Let's say these objects are 3d meshes and we want to translate Object A on the x axis 2 units.
Generally, a parent-child relationship would move any children of A. So it goes through the tree of children, and translates each child 2 units on the x axis with A. Then it reaches Object A in the tree, instead of moving it, why not just have it check for identity and if identity returns true, then stop moving things?
Is this just laziness on the part of software developers?
I'll suggest that it is equivalent and generally considered easier to have an Object D that is a parent of Object A, Object B, and Object C. Whatever the three have in common can be defined in D. Whatever they don't have in common can be defined in each.
No cycle detection is needed. Cycle detection may seem a small matter, but it would introduce an overhead for every object all the time.
Related
Object B contains a bunch of public events.
Object A subscribes to these events.
What is the UML relationship between these?
Currently I have a directed association from Object A to Object B. Is that correct? Or should the direction go the other way?
It depends on what you want to express.
Logically, the subscriber A must know the publisher B, and the other way round, so you have a bidirectional relationship.
Technically, often the subscriptions are not managed by the publisher B but by some dispatcher D. The subscriber A knows the dispatcher D and the other way round. But the publisher B doesn't know A and, depending on the platform offering the broadcasting mechanism, maybe not even the dispatcher D. So, if you have a particular platform in mind, find out which types of objects need instance variables to reference other objects, and model the relationships according to that.
There should be a dependency relationship from A to B (a dashed arrow pointing from A to B). Chapter 7.8.4.1 of the UML spec version 2.5 reads:
A Dependency is a Relationship that signifies that a single model Element or a set of model Elements requires other model Elements for their specification or implementation.
In your case, A requires B to exist, but B does not require A to exist. Maybe B requires A to implement a particular interface. In that case, B depends on the interface, but not on A itself.
You propose to have an association from A to B. An association is stronger than a dependency. It means that A has a property of type B (well, the definition is a bit more complex, see chapter 11.5.3.1 of the UML spec). This implies that A depends on B, like a dependency, but a dependency does not require A to have a property of type B.
To summarize:
The arrow should point from A to B, not from B to A (unless your particular implementation of B depends on the existence of a class called A, which is unlikely).
A dependency is enough, but if you want A to have a property of type B, then you may draw an association (solid line) instead of a dependency (dashed line).
Both A and B probably maintain references to one another. A may want to unsubscribe, and B certainly has to be able to notify A of events. Thus, I would model it as a bidirectional relationship. You might even want B to compose all the subscribing instances. Check out the well known Observer Pattern.
A few days ago a friend pointed out to me that I had a wrong idea of composition in UML. She was completely right, so I decided to find out what more I could have been wrong about. Right now, there is one more thing that I have doubts about: I have a circular dependency in my codebase that I would like to present in UML form. But how.
In my case the following is true:
Both A and B have a list of C
C has a reference to both A and B to get information from.
C cannot exist if either A or B stops to exist
Both A and B remain to exist after C is deleted from A and/or B
To model this, I've come up with the following UML (I've ommited multiplicities for now, to not crowd the diagram.)
My question is, is this the right way to model such relations?
Problems
Some facts to keep in mind:
Default multiplicity makes your model invalid. A class may only be composed in one other class. When you don't specify multiplicity, you get [1..1]. That default is sad, but true.
The UML spec doesn't define what open-diamond aggregation means.
Your model has many duplicate properties. There is no need for any of the properties in the attribute compartments, as there are already unnamed properties at the ends of every association.
Corrections
Here is a reworking of your model to make it more correct:
Notice the following:
The exclusive-or constraint between the associations means only one of them can exist at a time.
Unfortunately, the multiplicities allow an instance of C to exist without being composed by A or B. (See the reworked model below.)
The property names at the ends of all associations explicitly name what were unnamed in your model. (I also attempted to indicate purpose in the property names.)
The navigability arrows prevent multiple unwanted properties without resorting to duplicative attributes.
Suggested Design
If I correctly understand what your model means, here is how I would probably reverse the implementation into design:
Notice the following:
Class D is abstract (the class name is in italics), meaning it can have no direct instances.
The generalization set says:
An instance cannot be multiply classified by A and B. (I.e., A and B are {disjoint}.)
An instance of D must be an instance of one of the subclasses. (I.e., A and B are {complete}, which is known as a covering axiom.)
The subclasses inherit the ownedC property from class D.
The composing class can now have a multiplicity of [1..1], which no longer allows an instance of C to exist without being composed by an A or a B.
Leave away the open diamonds and make them normal associations. These are no shared aggregations but simple associations. The composite aggregations are ok.
In general there is not much added value in showing aggregations at all. The semantic added value is very low. In the past this was a good hint to help the garbage collection dealing with unneeded objects. But nowadays almost all target languages have built-in efficient garbage collectors. Only in cases where you want an explicit deletion of the aggregated objects you should use the composite aggregation.
I have a composite relationship between two objects (A & B) (A is composed of many Bs). Now another class (C) has a one-to-many association relationship to class 'B'. I would like to be able to retrieve all instances of class (A) from class (C).
How do I do this without creating redundant associations? Since 'C' has basically a list of 'Bs' I can't just iterate over all of them asking what's your 'A' and eventually returning a list of 'A' to 'C'.
I really hope someone out there understands this and doesn't find it completely confusing!
Thanks
Update:
Dataset has a list of defined variables. An activity can select a subset of variables from each dataset and give some attributes to them, hence an association class is used. Now if I want to be able to retrieve from an Activity instance the datasets it is registered with, how do I achieve this in UML and in object implementation?
According to your task, it is IMPOSSIBLE to take all B's from all C's. Because there is no sentence that states that any B belong to some C.
On the contrary, as A have compositions of B (notice, A IS NOT composition, A HAS composition of B, for A can have heaps of other things, too), and any B MUST belong to some A object, you can easily get all B's from all A's. Only create the list of B as a set for not to have multiply values.
But even if the association B-A includes B->A connection, you cannot get all A's from B's. Because some A's can be EMPTY. You'll never reach them. from B's.
So, you cannot take all A from C's for TWO important reasons. And NO redundant association will help.
As for the question set after "Update",
For getting All from variables, use
Dataset <---- Variable ---> Activity // This variant is the easiest for adding associations.
For getting connected datasets from an activity,
Dataset <--- Variable <----- Activity
But please, notice, it is not updated, it is DIFFERENT question.
I assume your diagram would look something like this :
If C has a reference to B, and B has a reference to A, then it should be no problem navigating to A from C. There is no need for any additional redundant relationships.
the job of the layout is to place vertexes at given locations. if the layout is iterative, then the layout's job is to iterate through an algo, moving the vertexes with each step, until the final layout configuration is achieved.
I have a multi-level graph - say 100 objects of type A; each A object has 10 objects as children; call the children type B objects.
I would like the layout location placement algos to operate on objects of type A only (let's say) - and ignore the B objects.
The cleanest way to achieve this objective might be to define a transform to expose those elements that should participate in the 'algo' placement operation via the step method.
Currently, the step methods, assuming they respect the lock flag at all, do their calculations including the locked vertexes first - so lock/unlock won't work in this case.
Is it possible to do this somehow without resorting to multiple graph objects?
If you want to ignore the B objects entirely, then the simplest option is to create a graph consisting only of the A objects, lay it out, and use the locations from that layout.
That said, it's not clear how you intend to assign locations to the B objects. And if the A objects aren't connected to each other at all, then this approach won't make much sense. (OTOH, if they aren't connected to each other then you're really just laying out a bunch of trees.)
Say you had two classes A and B. If the relationship between is has-a
i.e. A has-a B
how can you pass information from B into A? Say for example in B you work out a calculation and need the answer in A.
Is there any other way of doing this besides passing a pointer to class A into class B and calling a function which takes the answer as a parameter.
Hope this makes sense,
MD.
Sorry I should have been more specific
quote from my comment below.
"well I gave a simple example. I am programming this in java and my class B runs a new thread and and will calculate the answer. Therefore I cannot just call the function from class A as I don't know when the calculation will be completed."
The method in A that needs the result of the computation should call into the method in B that does the computation.
This answer is so obvious that there may be something you're not telling us (?)
Ok, so the question is really about threading. Yes, then passing a reference to owner object and calling back into it may be a good idea. A better idea might be to return a future object that encapsulates the result of the computation.
If I understand correctly, you have this kind of relationship:
class Car {
Engine engine;
int test() {
int fuelLevel = engine.getFuelLevel();
// do sth with fuel level, store it, use it etc.
}
}
This example shows how can you pass information between the two classes: for instance as a result of function. Car object (your class A) calls a method on Engine object (class B) and int this way he obtains desired information. This can be easily translated to any kind of work that class B does.
There are basically two ways to manage "asynchronous" calls.
The first is having a callback and the other polling.
Having a callback is what , you describe. When B has finished, it needs to call A somehow that it has finished. That can been done by "giving" the adress of A to B, so it knows what to call, or by using a intermediate object C, which calls B synchronously and send the result back to A. C then needs to know about A.
Polling is when A check regularly if B has finished. This solution is usually less satisfying intellectually and more CPU consuming. You are also not notified exactly when B finished. (When B finish, nothing happend, you'll have to wait for the next poll to be aware of it). However, that way , B doesn't need no know anything about A.
I would use the first pattern with an intermediate object (and special class C). So that your model is still clean (B doesn't need to know about A or C). I suggest also you have a look at the Observer pattern.