I have a task to make a simple information system for the functioning of a guest house. I need to make a USE CASE diagram, but I don't know if what I've done is correct, or if I need to add something, I don't know where to include the maid.
As users of the system I have put - client, receptionist, manager
As objects of the system I have put client, room, occupied rooms, employees (maids, receptionist, manager), tour agency, payment
Can you give me a hand?
Well, you are at the verge of functional decomposition. And that's not what UCs are about. They are about added value. So the bubbles contain headers describing those added values. For a hotel the basic UC would be Reserve room. (A real hotel would of course offer more added values, but for your example that's it.)
Now, the reservation is usually going along with payment. But would you consider that added value? I would not. So rather than making these UCs they are constraints (from requirements defined elsewhere). There's a lot one could talk about representing requirements and business rules, but that is far too much for a discussion here. I recommend reading Bittner/Spence about UC sythesis. It takes that book and a lot of experience to get familiar with this area.
Note that UCs are described with subject/predicate(/object) to be meaningful. Room is no UC. If you intend to show an object, use a rectangle (with object notation). That however, is in most times more confusing than helpful. Stay with actors and (real!) use cases.
Another note: the downward association from Hotel manager should rather be a generalization (open triangle instead of an arrow). And the actors usually are also shown with arms ;-)
Related
Craig Larman states that creating an Actor[/User]-Goal list in form of some table/grid is a good technique for finding Use Cases during Requirements Analysis. (Applying UML and Patterns - P. 69 ff)
Some simple two-column table should be enough to provide a good Overview for this example; imagine following Actor-Goal List:
Actor Goal
Admin Create User
" Read User
" .. (full CRUD)
" CRUD Entry
" Assign Entry (to User)
" ..
User Create Entry
" .. (full CRUD)
" CRUD himself?
" ..
Admin can do what User can + more like managing the Users of the System under Development or assigning Entries to them.
Admin and User clearly are sharing some Goals(Can we use the term Use Case yet?).
Im not really sure where to go from here in terms of refining this Actor-Goal list.
My brain tells me that i can spare time and effort by reusing/abstraction here, so I will most likely end up with one common superclass implementing the CRUD Entry behaviour, where Admin is extending the functionality by the Manage Goals(CRUD User, assign, etc.).
But I know that this is rather a question of Design than Analysis.
I also know that I can write the Use Case for this in isolation: I dont have to state who exactly uses it, I just need to know that it's some entity which is adhering to the given contract[/interface].
When is the time to start thinking about abstraction?
Am I overcomplicating things by doing so right now?
Should We leave the Actor-Goal list like above and check it off as a "complete" Artifact?
Since the classical purpose of an Actor-Goal list is to provide some quick overview for our next Artifact - the Use Case Diagram - could we begin the transition right here?:
The Use Case Diagram makes the whole reusing part much more visible (at least to me). Would it be advisable to adopt the redundancy right now and take care of it during later stages (e.g. design)?
Appreciate your input!
EDIT: Also I'm not quite sure about the User CRUDing himself.. But lets keep things simple and stick to the main question.
It's an excellent idea to identify the candidate use cases in an actor-goal list, as you have described.
The issues when identifying use cases
In the real life, you'll quickly encounter consistency issues when elaborating the list during requirement elicitation :
some interviewed users/business experts will describe very detailed step by step goals (corresponding to system functions), whereas other will describe rather high level goals user goals. So you'll need a third column to identify the goal level of each use case.
terminology and user goals will not always be expressed in an homogeneous way. So cross checking, and renaming of use cases might be required. For example, I had a system where:
an admin claimed to manage authorizations, and a business user claimed to manage authorization. Was it the same use case ? No: it appeared that the first maintained assignment of authorizations in the system and the second was empowered to decide on authorizations assignment and request them from the admin.
a purchaser explained that for a purchase order someone has to register a good receipt before the invoice is paid. The warehouse clerk explained that at warehouse they manage stock movement. Latter, though, it appeared, that those movements where good receipts, good issues, and stock transfers.
So a fourth column for comments about main variants could help to keep the overview, and to spot hidden sharing potential.
There is generally a great deal of cross checking and harmonization to be done before sharing/reusing use cases. Reusing too quickly might end up loosing more time than expected.
The use case diagramming
I will now be very provocative: once you have the nice and consistent table with all the actors and use cases, what will be the benefit that you expect from a use case diagram ?
It is generally recommended not to abuse use case diagrams for functional decomposition (see also here). So the use case diagram will add little more to what you already have in the list.
In addition, <<Include>> , <<Extend>> and generalization relations should be used scarcely because they tend to quickly make the diagram difficult to understand.
Finally, does abstraction and reuse really happen at the level of the use case ? Is this relevant to the actors outside of the system ? If not, it's more about design and implementation details. So I'd suggest to consider these more in the class model that you will create (or derive) to implement the use cases.
I'm taking a UML class at my school, and my teacher wants us to do the basic, bare-minimum of the assignment, and will not answer any questions. That being said, the requirements of the system had use-cases of Registration, Student Record, Log-In, Course Record, and Class Record. All it really needs to do is the following:
A student will log into the system and the only thing they can do is
register. In the register page, it would list courses available, a
student would select one or many and then they would list the classes
available for each course. The student's records have to be checked
to verify that they meet the prerequisites.
A registrar can log into the system and they can not only register a student but also view and modify course records, class records, and student records.
Also, the classes can be either online or on-site and I'm wondering if that should be defined...
I can provide more detail if it's needed to understand.
Well, I think I took it too far, and I supposed I wanted opinions on how to go about determining the basic requirements.
I also have a couple questions:
Is a Log-In object required in an SRS? Or should it simply be assumed that the users have logged in?
Regarding cardinality and multiplicity, is it the same concept?
Looking at what I've made my multiplicities, did I make any remarkably obvious errors?
As far as making it less complex, would it make sense to only have: class-type, course, class, registration, student, and registrar?
A systems requirements specification is by far more complex than a simple diagram. There are many ways to accomplish a SRS, so your question is a candidate for being flagged off-topic as being too broad. Anyhow, here is what I did.
In a first step you need to group the requirements themselves. The first broad division is by separating functional and non-functional requirements. Non-functional are those requirements which can not be pinned to a single function. Eg. performance, legal, safety, security, you name it. Those are the categories you build first and eventually you have a set of them in the course of the SRS creation.
Grouping the functional requirements is a bit more tricky. You do that by synthesizing use cases. Each functional requirement needs to be realized by a single use case. You don't need to put in details for the use cases, but only a rough story. But once you have connected all functional requirements to use cases your SRS will be ready.
Note that the non-functional requirements are not yet related. This is because they have impact on a lot of functions and the system design in later phases. It's only necessary to have them clearly structured.
Another thing to note is, that requirements themselves should be traceable to their origin. That means you need a reference to the paper, meeting, phone call, personal talk, etc. from where you got it.
There are many, many details which make creation and maintenance of a SRS a science of it's own, but the above is your staring point.
A class diagram is not necessarily part of a SRS. It's part of a later design specification.
Now for your additional questions.
Log-in is no business object in no case. It is a constraint derived from a requirement "user must be logged in to..."
see cardinality vs multiplicity
I would simply leave away the .. notation. If left away it means just the same (unspecified). I'd remove the 'Log-in' word from credential manager since it will also handle log-out and much more. So the emphasis is not right. Else the class design is, as said, not really part of a SRS.
Suppose there is a scenario of Users having Tasks. Each User can either be a Watcher or Worker of a Task.
Furthermore, a Worker can file the hours he has worked on a given Task.
Would the following diagram be correct? I have looked around at domain models and I have not seen one with the two associations (works on, watches). Is it acceptable?
EDIT: What about this scenario? An User can make an Offer to another user. A possible way of modelling it is shown on the following diagram.
However, in that diagram it would seem possible for a user to make the offer to himself. Is it possible to model some constraints in, or is this handled further down the development line?
It is in principle correct, this is how you model multiple relationships between two classes.
As for the constraints, UML makes use of OCL (Object Constraint Language), so you can say that the associations are exclusive (xor - exclusive or).
Also note that it is generally a good idea to name the end roles of the associations.
Regarding one of the comments saying
There are no UML police to flag you down for being "unacceptable".
It is like saying: there's no code police to flag you down for writing shitty code.
You create diagrams to convey information (for school project anyway), if you diverge from standards or best practices you make it harder for other people to understand your diagrams.
And just like there are linters (jslint, ...) that check your code for common problems, for models there are model validations that do the same thing.
Also models, just like code, aren't set in stone so don't be afraid to modify them when you find a better way to express your domain.
Update
As Jim aptly pointed out, you usually do stuff not as a User (or Person), but as a Role. E.g. when you are student and you are filling a form, nobody cares that you are human, but that you are a Student. Typically a Person will also have several different roles (you could be a Student and a TA, a Professor, etc.)
Separating it in this way makes the domain much clearer as you are concerned only with the Roles, and not the people implementing them.
On the first model, there's not much to add after Peter's excellent and very interesting answer.
However your second diagram (in the edit section) does seem to give a true and fair view of the narative. From the strict 1 to 1 relationships, I'd understand that every user makes exactly one offer to one other user, and every user receives exactly one offer from another user:
"A user can make an offer to another user" implies a cardinality of 0..1 or *, not 1.
From this we understand implicitly that not all users need to receive an offer, i.e. also a cardinality of 0..1 or *
This can be debated, but "an offer" doesn't in my opinion mean at "at most one offer", so the upper bounds of cardinality shouldn't be * and not 1 to show that every user may make several offers and receive several offers.
As you can see, you can add constraints to the schema to increase expressivity. This is done in an annotation between { } . But you can choose the most suitable syntax. Here an example with the full expressivity of natural language (as suggested by Martin Fowler in his "UML distilled") but you can of course use the more formal OCL, making it {self.offerer<>self.offeree}.
I see #Peter updated his answer before I could post this answer, but I will post this anyway to show you some other tricks.
In general, it is perfectly valid to have multiple associations between the same two classes. However, I don't think it's a good idea here.
You say you want to build a [problem] domain model. I'm glad to hear that! A problem domain model is very important, as I explain in the last paragraph here. One thing to point out is that you want to build a durable model that transcends a system you can conceive. In the problem domain, there is no "User". There are, however, Roles that People play. For example, you mentioned Watcher and Worker. Hopefully these are concepts your customer already has in the "meat world".
In the model you posted, you have no place to hang the hours worked or progress made. You might try an exercise. If you had no computer, how would your customer track these things? They often have (or had) a way, and it was probably pretty optimal for a manual system.
Here is how I would model my understanding of your problem domain:
Some things to note:
A Person plays any number of Roles.
A Role is with respect to exactly one Task and one Person. A Watcher watches exactly one Task, a Worker is assigned to exactly one Task, and any kind of Role is played by exactly one Person.
A Role is abstract, and its subclasses are {complete}, meaning there can be no valid instance of a Role without also being an instance of a subclass.
A Task is watched by any number of Watchers and may be assigned to one Worker at a time. There is a constraint saying {person is not a watcher}. (You can show the OCL for that, but few people will understand it.)
I have added a Progress concept as a way of logging progress on a Task. A Worker makes Progress on one Task. Each bit of Progress has a Description and a Duration. Note that I have not committed to any computational way of representing a Description or a Duration. The designer of a system for this will be free to derive a Duration from start and end times, or ask the user to self-report.
I have heard conflicting things about this and just wanted to clarify.
I have always thought that when constructing a Use Case Diagram, I only include the activities that will be carried out by the system. For example, if it were a bank atm, "User depositing money" would be included, as it involved the user interacting with the atm. However, "User is paid cash in hand from job" is not included in the diagram, even though it may bear relevance to a scenario or situation.
Thanks all
The fact that the user is paid in cash is in any way related to the information system which is a system involving people. The payment transaction has to be integrated with your project, at least on a conceptual point of view. In other words it should have a relationship of an unspecified kind with a use case, depending on the context.
I recognize my answer is quite messy: if you're already getting bored, jump directly to the solution section...
The use cases diagram
According to The UML User Guide:
A use case is a description of sequences of actions that a system performs that yield observable results to a particular actor.
The point is about modeling what is related to the system: your main problem is to consider the scope of your project.
Depending on the scope you identify, the use case you should consider would be something like Cash withdrawal: consider the observable results from the point of view of the actor. This part is highly subjective whether you consider the operation part of the system or not. I personally disagree with the other answers here.
A few words about being paid cash in hand. On a pure development process point of view, would it be normal to have a sharp idea how a user is being paid while modeling ? Still the scope question here: perhaps is it a strong constraint in your context.
Even when reverse-engineering, a use case is user-oriented, it has nothing to do with how things are done, but what is done: I think nothing to do with especially automating things, even when talking about a system. There is a subtle idea here: I consider an information system, a system involving people in the first place, not a completely automated system. Of course, purely automated systems can be modeled with UML, but most systems involve users.
The relationship between the use case itself and the information how the payment is done has not to be represented on the diagram figure. However, even if this is not in the use cases spirit, the way it is done could be written in a note if it is an important constraint the diagram reader should be informed of.
The solution
In my point of view, the right place to put that information in the use cases is not the diagram figure itself but in a use case description. Martin Fowler gives a few hints about this in UML distilled. You have a simple use case description example here. This is related to the way you are using UML and the way you wish to describe use cases (I personally share Martin Fowler's perception).
Perhaps you would prefer to represent this with a formalism specific to your modeling software, but I think this would not be a traditional way of using UML (appropriate for an Executable UML, not appropriate with blueprint or sketch).
It is not included because the "User is paid cash in hand from job" is outside the scope of a project and would not be needed for what you are trying to create.
Most often use cases are used at the functional/logical level of your model (MDA's PIM level). This means that it only describes those parts of the process that will be automated.
So unless your system has a feature that somehow records the fact that the user is paid in cash, that isn't part of the system under construction.
At the business/conceptual (MDA's CIM level) level however you model the whole processes, regardless of automation. So at this level it "User is paid in cash from job" would certainly be at its place.
I have a scenario where a customer calls and gets an appointment at a garage. When drawing a UML Use Case Diagram, is the actor who is connected to placing this appointment inside the system (a) the customer, or (b) the employee?
The person that has their fingers on the keyboard and mouse is the actor. The person calling in is important from a business perspective, but not as important as the customer service rep that is interacting with the system.
Knowing that the actor is a CSR helps the screen designer and even the developer, because they will work from that perspective, ask for requirements or design clarifications from that perspective, and the system will be better as a result.
The reason the conflict exisits is because of the point of the project when you start drawing these use cases.
In your example, you already know that there is a CSR using 'a system' to make the booking.
However the design could have started from scractch. If this had happened the initial broad use case would have been 'a customer wishes to make a booking'. This could have lead to a number of differenc cases i.e. a customer will call a telephone number and an automated service will make the booking, a customer arrives at the garage and uses a terminal to make a booking or (as in your case) talks to a CSR (however that is i.e. phone or face2face) and they make the booking.
In many examples the customer would be the main actor in the system. However in your design the CSR is the one holding the mouse/keyboard/phone/pen or whatever and you don't need to design the iteraction between the customer and the CSR! Most societies did that years ago :)
It can be both. It depends. There is no single good way to model this. I would personally opt for the customer.
It is btw perfectly alright to include the phone as part of your system. So the boundary of a system does not have to be a defined by screen, mouse, keyboard. A printer might be included too as part of the system. I have written use case where it was quite essential that users printed some information and file that.
Who is the important actor here? The customer right? It is interesting to note here that Alistair Cockburn extended the actor and goals model of Ivar Jacobson with the actors and 'interests' model. His advice is to also think about who cares (or gets hurt) if user goal fails.
Is it important to get the actor just right? It is useful to brainstorm actors to find all user goals against the system. When you are confident you have found all goals, the actor is not so important anymore. Would you 'write' a completely different use case depending on this decision? Would a different system be build based on the outcome of this decision?
Who initiates the interaction? What is the event initiates it? This event is the decision of customer to call to make an appointment.
You could model customer as primary and employee as secondary actor helping customer to reach user goal. Both use phone and system to reach the goal, customer helped by employee. How they do that exactly is design?
Another consideration is that the 'actor' is a role. So you could use a role Appointment Maker. Some people care a lot about keeping job titles separate from roles as there typically some flexibility in roles that job titles perform.
There are also people who are of opinion that use of 'system' in describing use case is undesirable. They feel that it is a design/implementation decision and so they prefer more neutral 'Performer'. The Performer could be a system but also a human. In use case texts they use 'Initiator' and 'Performer' and in introduction of the use case text they explain that the 'Initiator' is in use case the Appointment Maker.
I personally think it would be fine and better if the use case was described as if customer was the one operating the system. The employee is just passing along information from system to customer and vice versa.
The book by Alistair Cockburn is a recommended read. His insights really helped me with questions like this one. It also helps to make sense of UML in relation to use case