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.
Related
Let's imagine we have a User class, this is a generalization of two other classes: Admin and noAdmin
There is a another class to which only an Admin can interact with, let's call it only_admin
My question is, to what class should only_admin be related to? User or Admin?
If User is associated with Something, then, all specializations of User (i.e. Admin and NoAdmin) would be associated with Something as well.
Therefore, if Something makes only sense with Admin, then make the association with Admin only and not with User. The diagram would be crystal clear and self-explaining.
Additional remarks:
If NoAdmin has nothing specific compared to User, you do not need to have an own class for it.
If things get more tricky, and User would have many more specializations, most of them being associated with Something, except a few, or if you'd have SomethingForAdminOnly which would be a specialization of SomethingForAllUsers you could have a look at this other SO question.
For the UML point of view as your class diagram
to what class should only_admin be related to? User or Admin?
The simpler and clearer the better, so Admin, else you have to add a constraint oclIsKindOf(Admin) or oclIsTypeOf(Admin) (see below)
Anyway if this is allowed only for instances of Admin and not for instances of possible classes inheriting Admin the constraint is required typically using oclIsTypeOf(Admin) even the relation is attached to Admin rather than User.
From Object Constraint Language / formal/2014-02-03 page 153:
oclIsTypeOf(type : Classifier) : Boolean
Evaluates to true if self is of the type t but not a subtype of t.
post: self.oclType() = type
oclIsKindOf(type : Classifier) : Boolean
Evaluates to true if the type of self conforms to t. That is, self is of type t or a subtype of t.
post: self.oclType().conformsTo(type)
I have a child class which wants to add more functionality to a base class function, how can I represent that it also does the base class function not just the newly added functionality?
Interesting question. I tried that with Enterprise Architect. It did let me select the parent's operation but the display in the diagram did not change. It seems like you need to use notes for that:
As you can see Class2 inherits from Class1. The SD shows a call to Class2's operation a(). The call to the super-class's Class1.a() as internal call shows the same signature. A note clarifies the situation.
Maybe there's something else possible with this. But that's what I came up with immediately.
P.S. I've looked up the specs. P. 575 of UML 2.5 says
The message-name appearing in a request-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation or Signal referenced by the signature. Otherwise the name is unconstrained.
That would put in the option to specify the operation in question as Class1:a() or the like. Actually Enterprise Architect shows it that way in the properties of the message but shortens it to just the basic name. Just a border case, I'd guess.
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.
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.
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.