I just wanted to ask if my comment class has a list of comments then how is this shown in a class diagram?
I am developing a blog in MVC and I'm getting confused between aggregation and composition. A post is made by only a staff, a comment is made on either a comment or post and made by only a customer. Is this aggregation or composition. Please help.
if my comment class has a list of comments then how is this shown in a class diagram?
With a link to itself like this (shows composition but see comment below):
It's technically probably composition because a comment belong to exactly one other comment or no comment in the case of a top level comment, but you can use aggregation, composition, or just an association with multiplicity explicitly listed (aggregation and composition are just types of associations). Using an association is probably best to avoid confusion and arguments about the difference between composition and aggregation.
Related
I was going over some of the docs here.
I was curious why Grakn opts to indicate relations using noun semantics rather than verb semantics? In most of the other graph work and research I’ve covered, it usually makes sense to think that two entities (nouns) are linked by a verb e.g. person worked at company. Indeed, for a few entities that I am dealing with, it is a bit difficult to reason about the relationships as nouns for example if artist remixed track.
I’m inclined to use verbs as relations but I wonder if that is not how I should be thinking about it in a Grakn setup. Are there eventual difficulties I can expect to face if I decide to use verb semantics?
Typically, graph databases use directed edges to represent binary relations. Under those circumstances it makes sense to use a verb to describe a relation, since verbs often indicate a directional action between a subject and an object.
Grakn is a knowledge graph, which works differently. This is because relations in Grakn act as hyperedges. This means that there can be more than two participants (called roleplayers) in a relation. This is great for flexible modelling, but it can break the verb naming convention.
To work from your example, rather than artist remixed track, we could (very conveniently in this case) use the noun remix as the relation. Taking a guess at the domain model, an artist remixes a track, and as a result they have created a new track. That’s a great opportunity for a ternary (3-way) relation in grakn. The model for that would be as follows:
define
remix sub relation,
relates original-track,
relates remixed-track,
relates remixing-artist;
track sub entity,
plays original-track,
plays remixed-track;
artist sub entity,
plays remixing-artist;
Once the schema above has been defined in Grakn, we can add a remix instance connecting two new tracks and a new artist like so:
insert
$o isa track, has name "Brimful of Asha";
$rt isa track, has name "Brimful of Asha (Norman Cook Remix)";
$a isa artist, has name "Norman Cook";
$r(original-track: $o, remixed-track: $rt, remixing-artist: $a) isa remix;
It has then proved useful to use a noun for the relation because it doesn’t connect any of the 3 roleplayers it can have in a binary way. Instead we have named the concept that sits in-between the two tracks and the artist.
In this way we see that the relation nicely describes the (undirected) link between any pair of the roles:
original-track <-remix-> remixed-track
original-track <-remix-> remixing-artist
remixed-track <-remix-> remixing-artist
We can see that using remixed in place of remix wouldn't work so well, it would try to add direction to these links where there is none.
Grakn's data model can be extended on-the-fly. Therefore even if you start with a binary relation, should you later add more roles, making it ternary or N-ary, verb naming will no longer make sense.
It’s not always easy to name relations with nouns.
My suggestions are:
first try using a past or present participle of a verb (used as an adjective) with a noun. For example the role remixing-artist uses this.
resort to verbs when using nouns is really awkward, and/or if you’re dealing with a relation that you expect always to be binary.
If you must use verbs as relation names, then use the gerund form (which for all practical effects, acts like a noun). e.g.
faceting sub relation,
relates facet-assignment,
relates assigned-facet.
listing sub relation,
relates list-assignment,
relates assigned-list.
I'm a little confused on what the relationship would be for the scenario below. When examples of composition are used they always tend to use simple ones such as rooms and a building.
This scenario is that doctor patient visits are recorded. Would it be an association, composition or a mix of both? I've included a picture below of the two different relationships I am stuck between. I am thinking composition because the visit belongs to each party?
Derived association
In general my rule of thumb is that when in doubt, always use association rather than composition/aggregation. My reasons for this are:
(1) In Object-oriented analysis and design for information systems Wazlawick notes that the real advantage of composition and aggregation
is that the attributes of the parts are often used to derive attributes of the whole. As an example he mentions that the total value of an order (whole) is derived of the value of each of its items (parts). However, this to him is a design concern rather than a conceptual modelling
concern. From a conceptual modelling perspective, he believes that modellers often apply aggregation and composition inappropriately (that is, where whole-part relations are not present) and that their use seldom have real benefit. Hence he suggests avoiding or even abolishing their use.
(2) UML aims to provide a semi-formalization of part-whole relations through composition/aggregation. However, formalization of part-whole relations is a non-trivial task, which the UML specification does not do justice. Indeed, a number of researchers have pointed out various aspects with regards to aggregation and composition in which the UML specification is under specified. All have proposed means for addressing the shortcomings of the UML specification, but to date these changes have not been incorporated into the UML specification. See for instance Introduction to part-whole relations.
When being in doubt, which kind of associoation to use, use the more generic one. Especially, in your case there is no real "consists of" relation. Further in your EX2, you would have an instance of visit, which is an existance bound instance to an Doctor instance and to Patient instance. This is problem when applying the composition rules, as it also introduces an existence relation between Doctor and Patien implicitely. Thus, this shall not be done.
I guess the concept you are loooking for is an association class. This is a class, which instances give the association between an Doctor instance and Patient instance some further information.
I'm coding an application to create surveys with Symfony3 and Doctrine. I would like to understand which is the best way to model the relation between the survey, items, and answers. A survey is composed by multiple items that have peculiar typologies of answer. For instance I could have the following typologies:
AnswerChoice
AnswerText
AnswerRange
etc..
Which is the best way to model this scenario with Doctrine?
I thought 2 possible solutions:
I create a single Answer object including every possible feature of the answers. The Item object should have a one-to-one relationship with this objects.
Pros: I have just one answer object
Cons: Confusing and against the single responsibility principle
I create a generic Item object containing a specific Answer object (AnswerChoice, AnswerText...) in a predefined class property. The Survey object should have a one-to-many relationship with Item that in turn will have a one-to-one relationship with a specific Answer object;
Pros: Nice solution but...
Cons: I need a property for each type of answer!
Could you please help me to choice the best solution? I have the feeling that I'm not facing well this problem. Thanks
It's inheritance. Actually Doctrine handles inheritance pretty well.
There are a few ways of implementing inheritance in Doctrine but I think, that in your case Single Table Inheritance is what you're looking for.
That way you will be able to get a repository for parent (abstract) answer,but you'll get instances of actual child types in return.
I have a class diagram which has a dictionary (in python terms) as an attribute. This is the basic structure:
serverEntry = { creditCardObj1 : accountBalance1, creditCardobj2 : accountBalance2, ...}
To clarify, creditCardObj1 is an instance of a class CreditCard while accountBalance1 is an integer value and similarly for the other entries in the dictionary.
I read that in Java, it is called HashMap. In any case, I would like to implement it in my UML class diagram. Any tips on how to do that. I am using Visio 2007 so it would even more helpful if someone can explain in terms of that.
I won't put much effort into this, as another answer has been chosen already. That answer does not cover the closest thing in UML to a HashMap: the qualifier. It is drawn as a rectangle between a class and an association. Inside the rectangle is a name and a type. What it means is that given an instance of that type, the association will yield some number of instances of things on the other end of the association. That number of instances is specified with a multiplicity.
For your purposes, you would put creditCard: CreditCard inside the qualifier rectangle, and Integer on the other end of the association, with a multiplicity of 1.
I believe that this question is more about UML than about the programming language. Thus, please allow me to use the language I feel more comfortable in.
C# calls it Dictionary too, Dictionary<string, T> for example with a string for the HashKey. The UML Class Diagram in Visual Studio (I am using the Community Edition of VS 2015 here) is fortunately close enough to code so that the UML Model basically is the language's meta-model and the diagram is just a different view to the real code.
This comes in handy because real programming problems - like the one you asked for - can be addressed directly in the diagram. (Also: no extra code generation or additional parsing necessary to get or maintain the diagram).
I like the way Visual Studio solved this. They offer two options, one that is focussed more on the technicalities (show as Association)
and one that is focussed more on the domain (show as Collection Association).
I am usually using the first one only if I need the diagram to emphasize that the Dictionary class is involved, in every other case the second option is my preferred option.
In my semester exams I got a question:
Draw class diagram and association diagram for the online booking of movie tickets.
I know how to draw class diagrams so I drew it, but I was confused regarding association diagrams.I took a chance and drew a diagram with my vague understanding.I only drew class boxes and showed associations between them while drawing association diagram,while in class diagram I showed all the relationships like aggregation,composition,inheritance etc.I don't know whether i was right or wrong because when I googled it I found nothing but the examples of class diagrams only.
I would appreciate deeply if anyone alleviate my confusion.thank you!
So, again after a long wait , I am going to answer my question and since it was me only who asked this, suggestions are welcome from the deep bottom of my heart.
Now , so far what I have concluded is that ( obviously after searching many a times on net ) there is nothing specific like Association diagram as such (I am darned of my university for asking question in this way) . If there is anything after all its the association relationships among classifiers which can be otherwise shown as a "association diagram*. So, here is the minute difference which I could make out :
CLASS DIAGRAMS:- Class diagram is basically a detailed one showing classes, their interfaces , attributes and also their relationships. As for example :
While in "association diagrams" ( I am considering for now it as association diagram), classes' attributes and their internal implementation is not given much importance ,all that is shown, is the type of relationships among them.As for example :-
NOTE-- Any kind person who finds any more relevant information regarding this topic, please put suggestions in the comments so that I can edit my answer, for better. Any one is also free to edit my post if he or she feels its right.