Currently I am working on a part of a bigger project, but I am not quite sure how to approach this part of the system.
Each individual can be married multiple times, each marriage needs to have an officiant, partner1, partner2 and witnesses. Individuals can represent these roles in multiple marriages.
I am wondering if there is a way to represent all of the necessary individuals with less associations, since the diagram quickly turns into a mess when looking at the whole system.
Updated class diagram
Replace partner1 and partner2 by partner with multiplicity 2, and of course same for partnerWitness
individualId and marriageId are wrong because written underlined that mean they are static. Probably they are primary-key, but they are instance-member, not class-member. You can also name them id, useless to have a prefix
What is statusPartner ? is that can be supported by a class-association ?
The separated relation Individual -> Marriage is wrong because like that it can be for a marriage which not the same as the marriage the individual participate whatever its role, and this is not what you want. So remove it and use bidirectional relations
From your remark
statusPartner is simply status of the partner before marriage (divorced, widow and so on)
that enforce to manage it through a class-association :
With only partner you cannot know for who is statusPartner1 and statusPartner2, of course you do not have that problem in case of a class-association.
You can also move that attribute in Individual but in that case it exist not only for the partner and that has no lot of sense to have it
So for instance :
Note it is also possible to use only one relation for both the officiant and witness using a class-association :
with a constraint saying there are two Individuals with the role witness and one with the role officiant
The role can also be an enumeration or replaced by the isWitness being a boolean etc.
It is also possible to use only one class-association :
with a first constraint saying the role of a Partner is partner and a second saying at a marriage there are two Individuals with the role witness and one with the role officiant and two with the role partner
Perfectly! But notice that in the beginning there were partner1Witness and partner2Witness, that is, each partner has his own witness.
first constraint saying the role of a Partner is partner and a second saying at a marriage there are two Individuals with the role witness and one with the role officiant and two with the role partner
may be diagramming
Possible scheme in the picture
Related
I am modeling a course management system with the following requirements:
2 roles: Student can choose course; Administrator can make courses and then make groups for course, based on list of students who chose that course and based on list of tutors for that course.
In one course students can go only in one group, and teacher can teach more groups in one course. But student can go in 1 or more courses.
This diagram is a sketch of a class diagram. There is too much redundancy and I don't know how to solve it. Please help me to model my domain and ignore the mistakes in UML syntax or multiplicitycardinality.
More precisely, how can I make association between students and groups, and tutors and groups without redundancy, because I already have associations with courses?
Let's focus indeed on the domain model:
The direct association between Student and Course corresponds to the student's choice. The choice may or may not be fulfilled. And if it is fulfilled, it's only when the groups are made.
The indirect association between Student and Course via Group corresponds not only to fulfilled choices, but also to practical organisation of courses.
The two paths that exist are not redundant, but the representation of two different realities.
For the tutor, it's similar: the direct association tells what the tutor is able to do, and the indirect one tells what he/she has to do. So the model looks fine in this regard.
In some cases you could simplify (hint: not here)
In some situation a choice/plan can be combined with a fulfilled choice/implementation, by merging associations. For example, if there wasn't your group requirement, you could have only one association class between Student and Course and use a state of your association class to make the difference. But this will not work here, given your requirements.
You could also trick with the requirements. For example, you could have for every course a dummy group that corresponds to students that chose the course and are not assigned to a group. But shortcuts in the design can (and often will) backfire. Here for example, it would add complexity (need to create a dummy group for every course, make a difference between the dummy group and the real groups in almost every activity). Moreover, this trick would constrain your solution. For instance, not having an association class for the choice will prevent from enabling the students to prioritise their courses or providr other elements that facilitate the creation of groups that do not yet exist (e.g. pre-existing skill level).
In summary: your model should primarily aim at addressing the requirements. Premature optimisation is the root of all evil, in modelling as well.
We're tasked to make a system that will record students daily in and out of the institution premises via student ID, to ensure student safety, and The instructor can also use this system as the student attendance.
Can you help me by checking if this is correct or any improvement is required?
In short
There are some syntactic issues with the associations in your diagram.
Moreover, associations correspond to a structural relationship. Do not create associations, simply because one class uses another at some point in time: for a simple use, a «use» dependency is the most you can do.
More details
Syntactically, this diagram seems correct, except for the label on the association:
Since it's in the middle of the line, we assume it's the association name. But the association name has no visibility.
Since there is a - (private) visibility, we understand that it could be the role of an association end. But It should then be located on the end and not in the middle.
Semantically, from an UML point of view there are some suspicious relationships:
The double composition of Login is probably wrong: composition indicates an exclusive ownership. Your diagram says that a Login occurence is owned either by an Admin or by a Teacher but if it's owned by one, the other cannot be related to it.
Moreover, composition suggest a part-whole relationship and I don't see a login to "be a part of" a teacher or an admin.
The aggregation is not well defined in UML and therfore does not really add value. Some people see it suggesting a part§whole relation with non-exclusive ownership: in this case it would be wrong. Better get rid of it.
The name of the Validates association is confusing as it corresponds to a Login's operation. It might lead to think that the line corresponds to the dynamic invocation of the operation, whereas in reality an association is structural.
But it's difficult to say more in absence of any requirement or analysis context. Based on my domain knowledge:
The 1 to 1 association between Admin and Student must be wrong, since an Admin may enrol 0 users (new admin), or many users
There's a login which is probably used to monitor the in's of the students, but nothing seems to monitor the outs.
Do each student have only one single teacher ?
It's not clear to me if all these associations are a structural relation. For example, we can understand that at a point in time, in a transaction, a teacher validates a login. But should a trace of this validation be kept (i.e. do you expect to be able to later find out all the logins that a teacher has validated? or to find for a given login which teacher did validate it?).
Is it allowed in UML to generate arrow as follows between Administrator and Member ?
On one hand, Admin is a secondary actor because he will react according members actions.
On the other hand, he amends the website's content and can do everything a member can.
I have a doubt on the style of the arrow because it is not properly straight showing the heritage, is that an issue ?
What does UML say?
The difference between primary and secondary actors is not UML. The UML specification (see UML 2.5.1 page 638) does not even define the semantics when several actors are associated with the same use-case:
Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. (...)
The manner in which multiple Actors participate in the UseCase depends on the specific situation on hand and is not defined in this specification. For instance, a particular UseCase might require simultaneous action by two separate Actors or it might require complementary and successive actions by the Actors. (...)
An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases.
In UML, actors are classifiers, and classifiers may be specializations of other classifiers of the same kind. So, yes, from an UML perspective, an actor can be a generalization of another actor regardless of primary or secondary.
By the way, the notation of a generalization is a big non-filled triangle shape. The small arrow head whether open or plain is not correct; it's even misleading.
Is it about roles or is it about users?
According to your narrative:
Admin is a secondary actor because he will react according members actions. On the other hand, (...) he can do everything a Member can.
The main question here, is to know if you speak of the users (i.e. the persons who interact with the system) or if you speak about the user's role. To help you determining that, let's reason with an extreme case: suppose you'd have an intelligent bot or an external system that would replace the Admin (e.g. using some kind of interface); would this automated Admin still have to be a Member?
If yes, the role of Admin seems to automatically imply the role of Member. Generalization is ok.
If no, the role of Admin in reality independent of the role of Member and it just occurs that human users that have the admin role also have the Member role. In this case you should not use the generalization.
Use-case value and primary vs. secondary actors
UML is neutral about that, but use-cases should in principle be of value to a user, and help the user to achieve his/her goals. Without this principle of value, there is no primary and no secondary users. Here for example Spence & Bittner's definitions:
Primary actors: (...) The primary actors are those for whom the system is built; they are those to whom the system provides sufficient economic value to warrant its construction.
Secondary actors: These are the actors that support the use cases provided by the system and those that support the system itself.
I suspect that if an Admin generates quotes ("devis" in French in your diagram) and invoices ("Facture" in French), there are chances that it's not a secondary actor, but a primary actor.
Last but not the least, verify your usage of include and extend. This seems to correspond to a navigation flow or a functional decomposition (or both) of your system and not really use-cases. But I'll not develop more: for that you'd need to translate your use-cases.
Is a Generalization between primary & secondary Actor allowed?
primary and secondary actors do not exist in UML standard, so there is nothing in the standard saying this is not allowed.
In your case you can have that generalization because you it does not create a circularity.
Is it allowed in UML to generate arrow as follows between Administrator and Member ?
I don't know what is the relation drawn between Membre and Admin in your diagram, so I prefer to say no
I have a doubt on the style of the arrow because it is not properly straight showing the heritage, is that an issue ?
yes it is an issue because one does not know what that relation is / means
If you want a generalization the arrow head is different :
There are other problems in your diagram :
I do not see why Admin is a secondary actor, in your diagram Admin is always a primary actor. But see remark 5 below
by definition a Membre cannot register nor login, so Membre cannot activate the UC s'inscrire nor se connecter. An actor like guest can login or subscribe
when an UC includes an other than means the included UC is always done each time the including UC is activated. You certainly do no want Member login each time he/she want to edit his/her profile, same for Admin each time an account is deleted etc, and as I said by definition of the actors Member and Admin the login cannot be activated by them.
For a lot of people "se connecter" (login) does not have enough plus value to be an UC
how a Membre can "consulter l'historique de ses demandes / devis / facture" while Membre cannot ask the system to create them (with Admin as a secondary actor) ? Visibly some UCs a Member can activate are missing
Regarding Use-Case Diagram:
Consider 2 kinds of actors: Customer & User. Customer is a User (generalization)
I want to model the use case of a Search option for items ('search items') which is allowed for all users without the need for a login : but only a customer (because he is registered) could take part in the use case add items. note that this means that the customer will also need to be logged in for this to happen.
I can't seem to make it work without messing up the whole diagram.
Thanks!
Simply add a constraint to the use case. You can make that visible in a diagram by using a constraint element which looks like a note but has the text enclosed in curly brackets.
As is noted in the specs:
NOTE. An Actor does not necessarily represent a specific physical entity but instead a particular role of some entity that is
relevant to the specification of its associated UseCases. Thus, a single physical instance may play the role of several different
Actors and, conversely, a given Actor may be played by multiple different instances.
Thus there is no reason to try to mash multiple use cases into single Actor; User and Customer represents two different roles and thus it is often better to represent it by two actors; the fact that Customer is derivation of User can represented by a generalization.
And finally you can add a note to the use-case association to specify that the Customer has to be logged in - but at least for me this seems unnecessary, because the User already had to log in in order to take on the "Customer" role.
Generally in UML, you model roles as opposed to people however if there is a use case to model people (along with their names, contact details, etc), is there a known way of depicting this?
For example do I create a superclass called "Person" and generalize the roles followed by a specialization of a real person?
I took a look at some of your other questions and now I realise I completely misunderstood and you're probably trying to model an organization and the people in it.
ArchiMate is a semantic layer on top of UML that is intended for architecture modelling. Real people get described in the business layer, as actors.
A business actor is defined as an organizational entity capable of (actively) performing behavior.
A business actor performs the behavior assigned to (one or more) business roles. Examples of business actors are humans, departments, and business units. A business actor may be assigned to one or more business roles. The name of a business actor should preferably be a noun.
Now generally the person fills a spot in the organization that in a couple years could be filled by another person. The structure / architecture of the organization would not change and as such the actor can be described by the name of their position, say, "Head of department" rather than by their name and phone number.
Still, I understand that it may be handy to have this sort of information available when you want to contact them.
UML-model-wise, I'd think that the actor Head of Department is a class, realizing a business role that's also a class, and that Joe with phonenumber 12345 is an object of that class.
But practically, I'd think this is too much detail for the level at which you're describing the organization. I'd suggest you stick a UML note on those few actors of key contacts whose names you think are worth mentioning in the diagram. But administrate the rest of them in a system that's more fit for this, like your company's ADS or Contacts in Microsoft Outlook.