I have a question as the topic suggests. In my web application i got 4 classes which are related to each other so a "class 1" object has many "class 2" objects inside, a "class 2" object has many "class 3" objects inside and so on.
How to make Store for this type of Structure.
Related
I want to understand the difference between connecting classes together with a shared line or by having classes only "connect" through other classes. Is there a significant difference here? If classes share a line are you specifically trying to convey that information is being accessed from each of the other classes on the shared line?
For "Three Objects in a Row" I mean a layout that would appear as follows (sorry my diagram is:
For "Sharing Lines" I mean a layout that would appear as follows:
difference about access
In the first case instances of Flat and instance(s) of Tenant know each other, and independently of that instances of Tenant and instances of LeaseAgreement know each other. Instances of Flat do not have direct access to instances of LeaseAgreement and instances of LeaseAgreement do not have direct access to instances of Flat, they can only access the other instances if Tenant offers these accesses whatever the way (method or public attribute).
In the second case there is an association-class, instances of Flat and Tenant know each other more the corresponding instance of LeasingContract indicating how they are associated.
difference about knowledge
In the first case supposing the hidden multiplicity are not 1 a tenant having two rents is associated with two instances of Flat and two instances of LeaseAgreement but there is nothing in the given model allowing to link the right instance of LeaseAgreement with the right instance of Flat, that means the model as it is do not say for which flat a lease agreement was written.
In the second case there is no ambiguity, each couple of instances Flat and Tenant is associated with (in fact throw) the right instance of LeasingContract
The notation in your lower picture is called Association Class (see this wiki). Bascically it's a shortcut for a 1-* AC *-1 relation where AC is connecting two classes so you can add attributes and operations. In your example the AC is Leasing contract and it would add information about duration, payment, etc. And the two * were taken from the * left and right on the AC's association's far ends. So this would be an equivalent of your lower diagram:
I'm trying to make a UML class diagram for a very simple scenario. Consider the following code: List<Food> foods = {new Tomato(), new Pizza()}; as a field to class A. Clearly, class A has associations between Tomato and Pizza, but should it also have an association between Food?
Of course, Tomato and Pizza extend from Food :)
The use of generics such as List<Food> is always a challenge in UML, since the semantics of generics are not the same across the programming languages.
Here, the field foods of class A means that there is a navigable association from A to Food. And Tomato and Pizza are specializations of Food (based on your use of the term "extend"):
Additional remarks:
The association is with Food, because the type is List<Food> and there is no direct coupling between A and Tomato or Pizza.
Keep in mind that a class diagram shows the general picture and not a specific scenario with individual objects (that was the purpose of the former object diagram).
The use of a list tells that the association can be with be 0 or more Food. But we don't know if one Food object could be used by several A or not (several is theoretically possible if Food would be a reference type): therefore the multiplicity is unspecified on the A side.
Based on the semantics, you may consider making the association a composition or an aggregation. But a simple association is correct in any case.
Based on the what you want to highlight about your design in the A-to-Food association:
you may prefer the dot notation on the Food end, if you want to underline that the association (aka the list) is owned by A
you may just use navigability notation as in my diagram, if care less for the current implementation and just want to express that accessing Food from an A should be easy.
you may show none of the above, if you want to keep these topics open.
I would say your ClassA has a structural relation (association) to Food.
Because it also calls the constructors of Tomato and Pizza it has a dependency to those classes.
Without seeing more details it's difficult.
Your food is a 0..n multiplicity association.
Both Tomato and Pizza do not have an explicit assocation in that code. So that's just a dependency.
An association is a stronger form of a dependency (sloppy definition that is). Actually you can create an association. It depends on the yet unknown details. If your focus is on the list and you want any subclassed food in it, you would not draw associations to each of these subclasses but only to the parent class Food.
As said: it all depends and as a design template the details from the template need to be more beefy.
Documentation on using multiple objects describes creation of certain objects as "categories" while using custom properties to assign them.
It also says that:
Note: Facebook only reads object relationships three deep, so there’s no need to map out more than 3 relationships for each object.
If an object has more than 3 custom properties which are references to other objects, how are these relationships determined?
Is it the first 3 in the list?
Thanks!
It only reads 3 deep not wide. You can (and should) have as many properties on an object that it needs.
When creating references between ECore entities there is the possibility to mark a reference as "containment".
Can somebody explain me in easy words what's the difference between a plain reference and a containment? The definitions and explainations I found so far didn't do the trick for me.
Reference: A reference is a plain "A knows B" relation. Separate references do not influence each other. A can know B and B can know C. Hence, if you have A, you can go to C over B. If you remove the reference, A, B and C will still exist, they just don't know each other any more.
Containment: A containment is the "A has B" kind of relation. Usually used for lists, e.g. "A has multiple B". ECore/EMF can then perform atomic commands on such collections, such as move all objects from one containment to another. It can also enforce constraints, such as a minimum amount of contained objects or a maximum amount of contained objects, or ensuring that the contained object is not contained in any other containment.
Example:
Assume you have an object called ShoppingCart with a reference called Customer and a containment called OrderedProducts. The OrderedProducts has a reference to a Product.
What does this model tell you?
You can assign a Customer to the ShoppingCart. If you remove the Customer from the ShoppingCart, the Customer object itself will still exist (e.g. in the database)
The OrderedProduct objects need a ShoppingCart to exist. If you remove one from the ShoppingCart, it will cease to exist.
Each OrderedProduct has a reference to an existing Product in the database. If you remove one of the OrderedProducts from the ShoppingCart, the Product in the database will still be there - just the order of that product for that specific customer is gone
Reference : can be like association in UML
Containment : is the composition relation from UML
Also this can be seen in the EMF diagram, if you set the containment to true, then the line will have a filled side, showing the containment/composition. This is what I have observed.
Let's take 2 UML class model entities: One represents an actual Order and another represents an Orede Type. Any Order corresponds to one Type. A 2-way-naviglabe many Orders to one Type relation is meant. Order Type instances are, for example, "Request availability", "Request price", "Preorder", "Buy", "Cancel", "Request support", etc. Order Types are to be addable and editable in the resulting application. Should I model Order Type as Class or as Enumeration? From the data perspective I can't see the difference actually.
I would prefer an enumeration. Classes should define properties and behaviour. In this case the type represents only a value with no need of methods.
Conclusion:
The usage of a class would surely possible but not necessary if you only want to represent values. Also, it would create a lot of extra coding work. You would have to write and maintain a bunch of classes that only represent one value when you could use an enumeration, which is surely the best and shortes way to represent typed values.