Company X wants a web-based system that serves as a market place of ideas. Users should be able to login and post new ideas. Other users can comment on them and “upvote” them. The Administrators can login and mark that ideas have been implemented, and can reward the employee who posted it.
Following are the requirements:
Users should be able to login.
Users should be able to post a new idea.
Users should be able to search for and view other ideas
Users should be able to comment on ideas
Users should be able to upvote ideas
Administrators should be able to mark ideas as implemented
Administrators should be able to delete unwanted comments
Do you guys think my diagram is correct? I am new to UML so you guys can make fun!
http://imgur.com/TGKhweh
It is a not so bad start. Only:
Administrators are also users. They descend from them. So, they should have a generalization connection - empty triangle head arrow from Admin to User. Or to OtherUser (look below).
it is more natural to have a picture and name of an exemplar of agent. So, user, administrator - in singular.
you can divide Users from Other Users only if they have different definition and that difference is seen from the documentation, too. It is not. I would use only Users.
Of course, if some users really have different rights, it is OK, but:
the name is not good, IMHO.
They have all options of users, don't they? So they have to descend from Users
You should continue by adding the parts of your future system, that will collaborate with human agents on these use cases. Now you have only the first half of work done.
Edit:
Still your admin hasn't the generalization error from Admin to User. Admin can do ALL activities that user can, cannot he?
Still you have no subsystems on the diagram.
Search through older ideas should be the use case directly connected to user. And it does not extends nothing on the diagram.
Remember - use Include and Extends only on the last stage of UC diagram creation. When you already have the main picture and are refining it. And very often they should be used only on further, more thorough diagrams. Using Include and Extend from the start means that you haven't found the main concepts yet.
Related
I am incredibly new to Domain Models and I am trying to build up my understanding. I have created this domain model around a scenario which I will provide. I feel this model is simple and as a result, feels incorrect and might be missing elements I might not have thought of although, I cannot think of what else might need to be included in a domain model given the scenario. The idea is to demonstrate the relationship between real world class entities which I feel I have managed to achieve.
Scenario: Management Application that allows you to create users, projects, companies and issue tickets. The projects are assigned to companies, the users are assigned to projects and the issue tickets are assigned to the users. Tickets have a status which can be changed.
Changes
Implementing proposed changes. I think this is a better way to represent the idea based on the feedback returned, especially in regards to the use of composition. I have also updated the multiplicities to better represent the scenario.
Further changes
The diagram should stay as simple as possible, but not more.
In this specific case:
The two specializations of User might be too complex for the need: a User stays a User, isn’t it? If you really need to take into account differences between categories of users, and especially if the category changes over time, you'd better consider (object) composition over inheritance (or better worded for UML: prefer association over inheritance).
The associations might be too simple or incomplete. For example, before an Issue ticket gets assigned to a User, isn’t it also associated to a Project or a Company? It is not clear either if User is also associated to Company (e.g. multi-tenant cloud scenario) or if there is no such association (e.g service provider scenario, where the company is in fact a customer company).
Some associations may hide association classes, e.g. do you expect to monitor how many time a user worked on a ticket?
It entirely depends on the purpose of your model.
Some models might be created to stimulate discussion and further discovery. Some might be required for the senior stakeholders to approve. Some might be for developers to work from. Others might be for marketing material.
Your model is ok for stimulating discussion and further discovery.
Let's say that i have started making an use case diagram for tourist agency web application. So what bothering me is the thing that i am not sure should i make administrator role and connect him with other actors with the generalization because they share common behaviors.
For example, i have web-site visitor as a role, then i have registered one who can book hotels... Now i was thinking of putting the administrator role who would have permissions to do what ever he wants to do. So all i need is your advice and what you would do if you will ever have the similar problem.
Yes, you can do that. And it's a common pattern. An actor represents (plays) a role within the system under consideration. And if you find people acting with different roles you can apply a generalization. Especially if you generalize Administrator from User this says that the admin can do anything the user can do.
I have created a use case diagram for site similar to oDesk.
Site description: the place, where freelancers can find suitable jobs accordingly to their skills and pricing demands and where employers/clients can find suitable freelancers for their job postings with necessary skills and for stated price.
The goal of the site owner is: get income, by means of taking 10% fee from every payment made from employer/client to freelancer.
Have a look at the link below. Will be happy to hear any comments and advices!
I'm new here, but this question looks suitable for Business Analysts. This diagram does make sense. From my point of view, i would have added a "user" role (generalization of "employer" and "freelancer)". And aligned functions similar to "freelancer" and "employer" with "user" role.
From use full functionality point of view (it is what UseCase defines) your diagram is almost perfect. BUT, remove login usecase (it is not service..no body use system to login. Login is precondition for accessing security website functionality). Separate profile manage, block profile and other administration services (usecase) from the rest and build new diagram for them. There are mix of incompatible use cases at the same place.
Your "Make Payment" use case is off. You have it so that only the Employer doesn't make payments to anyone except possibly himself. Consider making the two types of payment into specializations of Make Payment (remove all the extends and includes except from the Make Payment to the Process Transaction), associating the Employer with the main use case, and associating the Site Owner and Freelancer each with the appropriate specialized use case.
Also, as Vladimir says, you might consider splitting this up into multiple diagrams.
I'm creating an application to track publications and grants for a university. Professors will need to put they CV into the system when it is up and running. Yeah, right.
The person in charge is planning on hiring someone to input all of the information, but my questions is how?
The strategy I'm thinking of is to install a backdoor. The lucky undergrad can log in as any professor using the backdoor. Once all the data is removed, the backdoor can be removed.
Doing so would probably be as simple as editing out a comment in the config file. The IT guys would still have access, but since they control the machines, they would have access anyway. Are there any flaws to this strategy?
Instead of installing a backdoor, why not create a priviledged user role. Users with this role can view and modify data for any other users (or a select group of users if you want to be fancy - and more secure - with it). So, the undergrad could use an account with this role to input the necessary data. When he is done, an admin can remove the role from his account, effectively closing the "back door".
You risk the undergrad dealing some other damage. What you should do is have them create a new user, give that user a small partition, and have the user enter the data on to that. Then just copy it over when he's done. Bad idea to give a student actual access, and even worse to have him log on as the guy - he should have his own user.
Don't underestimate the ongoing need for staff, students, or temps to enter and maintain the data. As simple as upkeep may be after the initial loading (typing) period, some professors simply will not do it, and will delegate it to staff.
In an eerily similar application (ours tracks publications and grants, among other things, as part of a career review for raises and promotions) our decision was to use a "proxy" system, where certain users can "switch to" other users. It's not really a switch because we store who was doing the input/editing along with who the data applies to.
Contrary to what Justin Ethier said about privileged roles, these people are the least privileged in the system, allowed only to switch to another account and do data entry.
IS it best to configure permissions within a website for Administration access, separate webPages, or a completely separate application to administer changes on the site?
I usually configure permissions within the same website and have separate web pages for administration.
In some cases, having the same page with more controls can be useful as well, for instance, if you want a page to Approve/Reject comments, or something like that, instead of creating a separate interface you just add a few buttons depending on the role of the logged in user.
I often find that with questions starting "Is it best to" that there's usually a someone and a sometime involved (a kind of pragmatics type thinking - whome and in what context)
Different contexts will offer up different pro's and con's for each of the scenarios you've presented here and depending on who requires what functionality may also sway your choice.
With regard to the "who" part there may be other questions you'll be asking yourself about the process you're going through. Is it my users that require admin access, is it my development team, is it the managing director with little I.T. experience etc etc.
Questions about the medium used may also play a role in the decision you make. Are the "admin" people going to be on a PC, sales reps on-the-road using a palmtop which might suit it's own software application etc.