I'm making a class diagram for user authentication ( register / log in ) i have some problem i'm facing:
is this how i indicate that a parameter is optional (phone number and username are optional)
should i make the log in / register a class or as i made it here a method?
Looks ok to me.
Some ideas:
The optional phone number and username are only optional as attributes. In your login operation they are mandatory. You should also specify a multiplicity [0..1] here. This is also possible for parameters of an operation.
Depending on your system Login could of course also be a class. It really depends on what your requirements are. Maybe you allow a login independent of a User.
To specify that an attribute or a method parameter is optional, you can add [0..1]. In your diagram, you use three dots. It shall be two dots.
To specify that an attribute or a method parameter is mandatory, you don't have to add anything. You may remove [1..1] from your diagram.
Login is a verb, so I would expect it to be a method, not a class. But as far as UML is concerned, it allows you to have a class called Login.
By the way, standard primitive types in UML are not string and int, but String and Integer. If you prefer to use int and string, it would be good to define them as UML data 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.
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.