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.
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.
I am trying to make a use case diagram with the help of my class diagram but the problem is i am here confused that what should i take as actors and what will come and what attributes shall i take and where to use <<extend>> ?
Kindly help. Thank you in advance.
As Thomas pointed out, there is no algorithmic way to go from a class design to a use case. In fact, for a given class diagram, it's not even granted that there is a use case at all (for example, if the classes represent only the relation between business objects and no actors).
However, by analyzing your specific diagram from a human point of view, you can very well infer a class diagram:
1) Identify candidate actors
An actor specifies a role played by a user or any other system that interacts with the subject. Candidates in your diagram are: visitor, admin, and registered user
The classes Movie, Book tickets, Make payment are obviously not representing roles of a user.
2) Identify candidate use cases
A use case defines the interactions of a system and an actor in order to achieve some goal. So let's brainstorm a little bit to find everything that looks like an interaction:
Very explicit candidate use cases: Book tickets (class and method of Registered user), Make payment (class and method of Registered user)
Less explicit candidate use cases or interactions: View movie (relation and method of Registered user), update movie (relation), Add movie record (method of admin), Update movie record (method of admin), delete movie record (method of admin), Confirm registration of visitor (inferred from relation), 'Get registered(method of a user),cancel ticket(and method ofRegistered user),Login(method ofRegistered user),Logout(method ofRegistered user),Update Seats available(method ofBook tickets), confirm transaction (method), refund money of cancelled ticket (method)
Implicit/inferred use cases or interactions : create and maintain admin , create a visitor, register and maintain a registered user account, anything else ?
3) Sort out the use cases
Among all the potential use cases and interaction identified, not all should get the use case status. You have then to find which are use cases and which are just interactions part of the same use case. For example:
update movie catalog would be composed of update movie, Add movie record, Update movie record, delete movie record.
Get registered and Confirm registration of visitor are obviously part of the same use case, because the goal is the same: registering a user.
...
I let you as an execise sort out the rest.
4) Review the actors
After having identified meaningful use cases you may want to review your candidate actors:
Some candidate actors might appear to be in fact only objects that are unrelated to users (it's not the case here, but it could be, for example, if you'd have a Movie producer, which is just an info related to a movie but not a user of the system).
Identify obviously missing actors for important use case that you have identified. Here for example, I first thought it was an internet movie business. But the method Update Seats makes obvious that we are talking of a real theater. So who would get the payment from the user, hand out the ticket, reimburse money in relation with the system ? If it's just the online booking system, we are fine. If the cahs desk operator shall use the system as well, then we should add this actor.
Find out relationship between candidate actors. A registered user was first a visitor. Shall we represent both of them in the diagram or not ?
5) Draw your use case diagram
Now you have all the elements, you can make your use case diagram. But you still have to decide on the level of detail you want to represent. Here a proposal:
You can not create a use case from a class design. Only the other way around. Form follows function, not vice versa.
Your class diagram indicates that you are not yet familiar with class modeling. Your classes Book Ticket and Make Payment sound like use cases rather than proper classes. A class is a container of data and functionality working on those data, whereas a use case is a piece of work that an actor performs with the help of the system.
Giving you the help you need might be too broad for this platform. Study introductory texts on UML modeling to get a feeling for what can be expressed by which type of model. And don't feel obliged to use all elements the language offers. There are plenty of use case models that don't need include and extend relations.
I've been working on putting together a rough conceptual model of an E-commerce website that basically allows users to resell concert tickets. It's purely conceptual and not something i'm actually making!
Anyway I've put together a domain model and I was hoping for some feedback. I've made class model before and modelled databases but found it quite difficult differentiating between them.
I've seen the words rich and anaemic thrown around a lot and I believe my model is anaemic. Would simply notating more behaviour make it rich?
Are my relationships correct? Have I correctly used my aggregations and compositions?
I would love any suggestions on improvements.
Thanks in advance.
You have the right idea, but some of the UML is incorrect and a (business) domain model shouldn't have a User.
Some examples of problems I see:
A User is probably not a Bidder and a Seller; rather, a User can play a Role of Bidder or Seller.
Generalizations do not have multiplicities.
It makes no sense to me for a Ticket to HAVE an Artist. A Ticket generally allows a Person to be admitted into a Show, and an Artist performs at a Show.
Compositions can have at most one composing class.
I would remove compositions and aggregations from a conceptual model. Otherwise, I don't think it's anemic as a conceptual model. The next step would be to add behavior to it as an OOA model and generate some code from it. Please see Leon Starr's How to Build Articulate UML Models article for more help.
As Jim says, you're not entirely clear on how composition and aggregation work. This example might be helpful. Tom Pender (author of "The UML Bible") uses it in his classes.
Suppose you have a car factory and you make cars. A car has an engine. In order to be a car, it has to have one; if you haven't put it in it isn't a car yet. But also, the engine is part of a car. The only reason to have the engine is to put it in the car. So, the engine has no identity or lifetime independently of the car. That's composition.
Now, suppose you have a junkyard. Same car, many years later. You can sell any items off the car and it will still be that car. If you sell the engine, the car will be the car without an engine. That's aggregation.
So, in a manufacturing context, a car is a composition of parts, and in a junkyard context, a car is an aggregation of parts. The point is that in composition, the lifetime of the parts is tied to the lifetime of the car, and in aggregation, it isn't.
Looking at your Ticket object, I would say that Venue and Artist are in a composition association with it. While the Venue and Artist certainly are not dependent on the ticket for their existence, you have to keep in mind the context. You're doing e-commerce. Your artist and your venue interact with the e-commerce system via tickets, and not in any other way. So composition. On the other hand, tickets are most certainly NOT composed of Orders. If that were so, there would be no such thing as an unordered ticket! So, tickets and orders have a simple association, not aggregation or composition.
As for your bidder and seller, they are users. So you have your inheritance arrows backwards. If Bidder and Seller have specialized user behavior that is independent of one another (e. g. "OfferBid" and "AcceptBid"), then they need to be modeled as specializations of the User class. If they do not, then they are just two users that are acting in different roles, and can be modeled as such.
I have an assignment for school, where I have to create a domain model of a specific e-commerce site that delivers complete grocery bags to people's homes. (http://www.linasmatkasse.se/)
It's quite basic. Chose a bag, create account (with info), pay.
My question is, what exactly should be included in the model (in general)? In other words, where does the lines of the domain end? For instance, should delivery and suppliers be included? They aren't technically part of the website itself, by still play a role.
Thanks in advance!
What is domain
Let us take some theme/subject. It could be grocery delivery, satellites, swallows observations, anything. Let us name this theme "AAA"
domain model for AAA is a "profi IT" word for model for AAA. That's all.
All elements specific to AAA that you'll set in your model, belong to domain. I don't know, why the old good word theme is not used. It is a pity. But the term is already accepted.
So, delivery and suppliers are in your domain. And also much more specific words belonging to grocery. And to bags. And to people's homes - addresses, drive ways in and out - everything that is relevant to your theme.
The domain sets your vocabulary. And that one is really important - you should use the vocabulary used by your clients and not to invent new words, such as "domain" for "theme" :-)
And first you should define your Use case diagram, later- State machine diagram, Deployment diagram, Component diagram, Communication diagram, Sequence/Activity/Time/Interaction Overview diagrams, and at last - class, object and composite structure diagrams. You needn't make all of them, but SOME are necessary.
Every entity that models an entity in reality is a part of the domain. In your example, delivery and suppliers should be a part of the domain model. Basically any entity that has a defined behavior should be modeled as a part of the domain. Many times it seems like the domain model components aren't a part of the website and this is actually normal, the front-end is a way of viewing the domain model, it doesn't need to expose everything within the domain.
I usually find it easy to think about what entities are logical components of the business model in the real world and I only remove one if I find that it is redundant, unnecessary or can be encapsulated within another entity.
About the entities that are not the part of IT system
Do not ignore the pure human operations. On the contrary. Put them here, only their use cases will connect not actor-(sub)system, but actor-actor. And seeing them is very good for better planning the system as a whole. When ignoring them it is impossible to create a system good for user. The IT system is an integral component of the larger system, and we are creating the larger one really, with planning the support, processes, exchange of info, divisions and dependencies.
Too often had I problems with programmers who are blind to anything out of IT system border. And often it is impossible to make them think out of these borders. As a result, the system is blind to the real needs of the user, too. So we have that sad picture of user-hating software.
It is very useful to start to study the problem/domain/theme from entities that are out of the IT system, and to create firstly the diagram, that considers IT system as merely one of many blocks.
I am trying to draw a conceptual class diagram. In my system, I have one person who can be performing 2 roles. One being "teacher" and other being "student". The same person could be a teacher in one instance and the same person could be a student in another instance. In such a situation, is it good to depict them as 2 separate classes (in my conceptual diagram)?
Please advise.
Thanks
Unless the person is teaching themself, don't get caught up in trying to show relationships that cross a use-case boundary. Validate the links for each scenario separately; just realize that not all connections will be used for every scenario.
People fill roles. Try
Person associated with EducationRole
EducationRole has subclasses of 'Student' and 'Teacher'
Here is a diagram.
They can change the role they play depending on the situation. If you need to show a person teaching themself then create a subclass of EducationRole named 'Autodiadact' which just means self-teacher.
A commenter asked about changing the role using a method and I'd like to include the answer here.
So, yes you could code the ability to change the role in a method but back up and ask the bigger question, why are we changing the role? A teacher is becoming a student or a student is becoming a teacher, either way the model as shown allows a Person to have many EducationRoles (which is what the asterisk denotes) at the same time so there isn't really a need to change the role but support a person with multiple possible roles.
In the conceptual model you are attempting to illustrate relationships between any valid state of the system, not necessarily how the change might be executed (using a method).