Backround to the problem: I have connected two classes to each other in UML, both of them being regular classes and one of them is named "League".
In the "miscellaneous" menu in MDriven, I found that the following “EffectiveName": "League_children” as well as "OtherEnd": "League_parent".
This was confusing in three ways:
There is not a class named "League" in "OtherEnd"
The terms "League_children” and "League_parent" were created automatically
It says "League_children" not "LeagueChildren" with the latter one I thought was more correct becuase of how you write in code, and also everywere else in the diagrams and menus in MDriven's workspace.
I read about the terms "children" and "parent" in the official book (https://www.capableobjects.com/xdownloads/MDrivenTheBook/MDrivenTheBook-Part2-Design.pdf ) and obviously these are used when you have superclasses and subclasses to those. However, neither "League" or any other class in my diagrams as of now are superclasses", so why are these names created then?
Furthermore, "OtherEnd" is not called "League" and therefore shouldn't have be called "League_parent".
I searched through my different classes and found no hidden associations that I had acidentally/falsely deleted.
I recognize the _Parent _Children pattern as what MDriven does when adding an association from a class back to the same class.
If you check the Class in the tree I bet you will find an association pointing back to self. If this was added by mistake - delete it.
Normally MDriven leaves the name of association ends blank - then the effective name will be the name of the Class in the end. Name - if set - overrides this.
When creating associations back to self - MDriven sets the names of the ends appending _Parent and _Children.
Related
I am making a class diagram for Class/Course Registration where students have to first register their course then select their class schedules (timetable)
I am unsure if I can have CourseRegistration and ClassRegistration table like that. The reason why I made it like that is, a student can register for a course but doesnt register to a class directly. so they can wait few days and then only register. So I have to make sure the course registration is saved in the database.
Thank you for all the help
PS: pls don't mind my attributes, they're just a draft.
Your business logic for the registration process (register both for a course and a corresponding class) is too complicated. Normally, one would only register for a class, which would then imply taking the corresponding course.
Also, what does "ClassSchedule" stand for? Is an instance of a "ClassSchedule" a class meeting?
Since your model is supposed to define a design (of database tables and of, e.g., Java classes), each entity class should have an ID attribute defined, which is expressed in UML with the keyword "id" in curly braces appended to the attribute declaration. Having "ID" in the attribute names is not a formal declaration. Also, an ID attribute seems to be missing for ClassSchedule.
Yes, that's fine this way. You could alternatively use the association class notation like this:
Some side notes:
labeling associations is not that helpful except you are on a business level analysis. Rather use role names on either end where appropriate.
Edit I somehow overlooked that you're designing tables. So my previous comment
remove all the id attributes. Each object will have its unique id assigned by the runtime system. Use such an id only if it's of public meaning (e.g. a passport id or a student's registration number). And then use that specific name (e.g. passportId) rather than a <class>id.
goes just for basic class design. If you already have a (derived) table design you can just go with those ids.
In the example I made every object of the type "Folder" have an array of type "File" with the name "content" a size of "n" as a private attribute (just saying my understanding of it to make sure that I am not already wrong there). That's how I see it in most examples but I never understand what "n" now is. Is it another attribute of the "Folder" object or is it something that we specify in another part of an UML diagram or something else completely?
What I am trying to achieve is that every object of the type "Folder" has an additional attribute that specifies the size of the "content" array.
Of course, you can not only write 0..*, but use any concrete number, too. If that number has some external definition, you can use there n, as you have it.
The external definition means "not defined by class diagram elements, except notes". Everything that you need to be said on a class diagram page, but can't because of the UML limitations, should be put in a note.
So, n can be defined in appropriate note on the page or in some different document or both.
As #Kilian had mentioned, in the case of some more complicated dependencies of such variables you can use constraints. This way seems to me the most powerful.
But if n has no objective definition or dependency, but is a simple variable that can have any meaning, then it will be correct to use a rule, such as 0..*, or 1..*, or maybe 3..5, according to the reality you are working with.
Using this tool the classes corresponding to my code were created.
Each class has attributes with its getter and setter methods.
The attributes are created in the diagram but with the label << Property >> Without the corresponding methods, as you can see from the image.
Moreover, lists are not attributed to the type List , even if I change the association into aggregation.
The label << Property >> tells you precisely an attribute which correspond getter and setter?
I could not find anything about this label in the UML documentation
What you call label is a stereotype. Attributes with a <<Property>> stereotype are usually marked this way to tell a code generator that appropriate getter and setter methods shall be created if the target language supports (or requires) that.
Lists do not depend on the composition symbol but on the multiplicity which is barely readable, but I guess the dots near the associations are asterisks (for any multiplicity). The dots at the end of the associations are isOwned attributes (saying the the dot-marked class owns the association).
I'm working on a class diagram of a simple project.
Here's a basic description of it:
"usuario" is the 'user class'. From it, i can have "membro_coral, "Membro_comissao" and "Administrador". "membro_coral" can post some news on the web site, but it goes through an avaliation to see if it can be posted or not. "Membro_coral" has a "perfil" associated with it.
There's the "evento" class. It's a class for mapping events. Users can give their disponibilities to attend to some events. And "escalacoes_disponibilidades" is the junction table.
I've added Three classes corresponding to the "Perfil" values. Some people are "membro_comissao", some people are "membro_coral" and actualy, only one is the "Administrador".
Is this class diagram right? Any modifications i should do?
EDIT: i've update my class diagram. I've added the "Status_Noticia" class. It's associated with noticia. I've done this in order to improve the statemachine diagram of "Noticia" (there's an use case which an user can send news to de displayed, but it goes through an avaliation process).
It's mostly correct. There are some minor observations however:
Membro_comissao, Membro_coral and Administrator are kind of users, right? If so, you should do one of the following: a) derive all 3 classes form user, or b) create a new class (enumerator) TipoUsuario, with those 3 values. Which option to implement depends on if there are some special features that make the 3 different one from another (some different attributes, methods or maybe associations (see the next point)
You said: " "Membro_coral" has a "perfil" associated with it.". Than this class should be associated with PErfil and not otherwise. This could be a reason to apply the option a) from before. This association should be a normal assoc. and not a composition
So, the main decision you must take is how to model user types.
In ArgoUML, I have the ability to put a class Type to any property of a class. For example, I can declare a customer property with a Customer type in the Order class.
I can also easily draw a relationship from class to class:
But I can't figure out how to "draw" the link from the customer property to the Customer class. The link is never really connected to the property, but rather to the entire Order class.
I can move the position of the link manually:
But it's never really "locked" to the customer property, and can be moved automatically by the software at any moment.
Is there a way to do this?
You can not have an association in UML which is not connecting the entire two classes. It is not possible to touch the property inside the class.
Workarounds are:
add a note linked to the property
add an icon to the property which would be designed like an association.
I don't know if this advanced icons customization is available in this free tool but it is in other tools.
I found a flash demo which shows the association attribute with an icon. Look at : http://www.download-omondo.com/show_association_member.swf
If you need to understand what mean an association in UML and code generation in Java then have a look at this demo: http://www.download-omondo.com/association.swf
Hope this help.
ArgoUML follows the UML specification. Associations are drawn from one class to another. Attributes are drawn inside the 2nd compartment of a class.
The association type closest in meaning to an attribute is composition, but they are not equivalent.
You should never portray something AND as an attribute of a class, AND as a separate class associated to it.
E.g. 1. an Order may have a Number, that may be used by the customer to identify his Order. The Number is best portrayed as an attribute (in the 2nd compartment of the class).
E.g. 2. an Order may be associated to the Customer who placed the order. The Customer is best portrayed as a separate class, since it has its own lifespan (behavior), associated with the Order. This allows to show multiplicities and roles at both ends of the association line.