I have a small UML assignment due Monday; it doesn't seem too complicated, and I'm not asking this site to solve it for me -- I'm just asking for clarification over a couple doubts of mine.
I'm just telling parts of the assignment because its content is probably not so relevant.
We're provided a basic use case where the actors "officer" (e.g. police officer) communicates with the actor "correspondent" in order to report an emergency. The use case is expressed in the form:
Use case name: Report emergency
Participating actors: Officer, correspondent
Flow of events: ...
Preconditions: ...
Postconditions: ...
Then we're given three scenarios that "refine" the use case. I say "refine" because they turn it upside-down: they involve team leaders, respondents, incident handling -- nothing that was even mentioned in the flow of events described by the very basic use case given.
On top of these scenarios we're given ten "events" (i.e. they basically chunk the three scenarios into ten easily recognizable sentences). The assignment asks us to make one collaboration diagram for each of these events.
I know that collaboration diagrams describe the behaviour of the system, i.e. how the different parts of the systems interact with each other. So I thought that, even with these "creative" scenarios given, I could make something out of them. But then this part comes:
"Collaboration diagrams should make use of controller, boundary, domain objects and other new fabricated software objects (e.g. data structure components) necessary to completely handle each event."
And then:
"Your assignment will be evaluated in terms of the quality of your design (i.e. modularity: low coupling, high cohesion)"
My questions are:
1) Are scenarios supposed to present so much new information compared to the basic use case?
2) Do I just have to draw ten simple collaboration diagrams? Using which classes?
3) Why are things like low coupling, high cohesion, domain objects, mentioned? What do they have to do with all of this?
1) A scenario is a detailed description of a use case. There can be several scenarios based on constraints. The use case itself just describes the sunny day scenario in a condensed format. The meat is in the scenarios.
2) Classes related to the UC can be extracted when going through the scenario. You will find text parts that tell certain functions need to be performed. Take these classes and place them in the collaboration diagram and connect them with the right message.
3) These are general design rules. Low coupling/high cohesion means good design (and vice versa). The domain objects are those which are in the center of the system and the sum of all use cases will deal with the sum of all domain objects.
Related
I'm trying to create a Use Case Diagram of Order System. But I'm curious if the 'send notification' and 'add order' is connected since before ordering, the inventory will check for the stock. I'm thinking of connecting the two using 'extend'. What do you think?
Whenever you wonder if use-cases are related because of some sequential or causal relationship, you are no longer in use-case analysis, but in one of the following situations:
Functional analysis: you’re doing functional decomposition, i.e. breaking down a functionality in more elementary functions (e.g. the includes for Ship order): this is not forbidden but leads to very complex diagrams that are difficult to read and use in practice due to unnecessary details and mixed levels of abstraction.Solution: don’t! Simplify your diagram and focus on user’s goals.
Designing a flow of activities: this is wrong, since there shall be no order/sequential relationship between use-cases, and use-cases shall not be confused with events or preconditions(e.g. item is not out of stock) Solution: go for an activity diagrams, which are meant for exactly this kind of modelling.
misusing use-cases for user-interface design (suspicion that all the generate xxx corresponds to windows to show data to the actor): this usually leads to bad user-interfaces and incomplete analysis of the user’s goals.
I think your (impressive and comprehensive) diagram corresponds to the first two situations. I recommend to simplify, focus on the user goals, and for each use case that is more complex, make an activity diagram for the flow.
I am very concerned when I see in the table “use-case(process)”, and it appears that this is an exercise you are trying to do. This is plain wrong: a use case is an actor’s goal and not a process. Processes are typically modelled with activity diagrams. If this comes from an UML tutorial, then immediately change tutorial!
Imagine that we are building a Library system. Our use cases might be
Borrow book
Look up book
Manage membership
Imagine that we can fulfill these use cases by a librarian person or a machine. We need to realize these use cases.
Should we draw different use case realizations for different flows?
If not, it is very different to borrow a book from a machine and a person. How can we handle it?
Moreover, what if we have updated version of library machines some day? (e.g. one with keyboard and the other is with touch screen) What should we do then? The flow stays the same, however the hardware and the software eventually be different.
What would you use to realize use cases and why?
It might be a basic question, but I failed to find concrete examples on the subject to understand what is right. Thank you all in advance.
There is no single truth or one way you "should" do it. I will give you my approach, based on the Unified Process.
The use case technique is primarily used to describe a dialog between a human user (actor) and an application. It is modeled as an ellipse and further specified as an activity diagram or just a list of steps: 1 The actor does A, 2 The system does B, 3 The actor does C etc. In this approach, the application is regarded as a black box.
A "use case realization" describes how the system performs its steps (white box), e.g. in terms of collaborating components, transparent to the user.
It is possible, but much less common, to have so-called business use cases. In that case, the "system" represents an enterprise or a business unit. In your case, it would be the library. The "actor" represents an external person or organization, e.g. a client or a supplier. In your case, it would be a client. With business use cases, the library is regarded as a black box. The steps are still in format "actor does A; system does B", but here, it is not specified which of the library's actions are performed by humans and which by applications. The system is the organization, interfacing with external actors, regardless of whether this is implemented by employees or by applications.
A "business use case realization" specifies how the system performs its steps (white box) and specifies which parts are done by employees and which parts by machines.
Now, let me answer you questions one by one.
Question 1.
If you have described your use case as a business use case, and it is at such a high level of abstraction that the steps for client-librarian interaction are the same as for client-machine interaction, then you will have one business use case "Borrow book" and two business use case realizations for this business use case.
However, it is more common practice to have only use cases for user-application interaction. If the client interacts with the system in the same way as a librarian would do on behalf of the client, then you will have only one use case "Borrow book", with actor "Person". This actor has two specializations: "Client" and "Librarian". There will be only one use case realization per use case.
Otherwise, you would have one use case "Borrow book online" describing the flow of events when a client interacts directly with the application, connected to actor "Client" and another use case "Borrow book for client" describing the flow of events when a librarian interacts with the application while talking to the client. The latter use case has "Librarian" as its actor. Again, there will be only one use case realization per use case.
You may choose to model the Client-Librarian interaction separately, or not at all, depending on the purpose of your model.
Question 2.
Let's take use case "Borrow book online". You may have two use case realizations for this use case: one for the keyboard machine and one for the touch screen machine. If these use case realizations are very similar, then I would just make only one use case realization and describe the fact that there are two possible input devices inside that single realization.
Question 3.
For a business use case realization, I would use BPMN 2.0 or a UML activity diagram. These are well suited for business workflow specification.
For a normal use case realization, I usually make a sequence diagram, where the lifelines in those diagrams refer to components defined in a common component diagram. In the left margin of the sequence diagrams, I usually write the steps of the use case in UML note symbols. The sequence diagram focuses on the interaction between components, using their interfaces. This gives a nice overview of the collaboration between components in the context of a particular use case.
For more information, please refer to my white paper Which UML models should we make?. The use case realization is described on page 19.
UML is method-agnostic. Even when there are no choices to make, there are different approaches to modeling, fo example:
Have one model and refine it succesfully getting it through the stages requirements, analysis (domain model of the problem), design (abstraction to be implemented), implementation (classes that are really in the code).
Have different models for different stage and keep them all up to date
Have successive models, without updating the previous stages.
keep only a high level design model to get the big picture, but without implementation details that could be found in the code.
Likewise, for your question, you could consider having different alternative models, or one model with different alternatives grouped in different packages (to avoid naming conflicts). Personally, I’d go for the latter, because the different alternatives should NOT be detailed too much. But ultimately, it’s a question of cost and benefits in your context.
By the way, Ivar Jacobson’s book, the Object advantage applies OO modeling techniques to business process design. So UML is perfectly suitable for a human solution. It’s just that the system under consideration is no longer an IT system, but a broader organisational system, in which IT represents some components among others.
UML has collaboration elements to show different implementations. The use cases are anchors since the added value for the actors does not change. However, you can realize these use cases in different ways. And that is where the collaborations come into play. A collaboration looks like a use case but has a dashed border. And you draw a realize relation from one or many collaborations towards a use case. Inside the collaborations you show how the different implementation's classes collaborate (hence the name).
P.213 of UML 2.5 in paragraph 11.7 Collaborations:
The primary purpose of Collaborations is to explain how a system of communicating elements collectively accomplish a specific task or set of tasks without necessarily having to incorporate detail that is irrelevant to the explanation. Collaborations are one way that UML may be used to capture design patterns.
A CollaborationUse represents the application of the pattern described by a Collaboration to a specific situation involving specific elements playing its collaborationRoles.
I have this kind of situation where I have multiple actors which share the same use case.
I cannot figure out from which point of view I should write the flow of events and describe the sequence diagram of this specific use case, having more than one single actor.
You: I have multiple actors which share the same use case.
... from which point of view I should write the flow of events
Use-cases are goal-oriented. They are not supposed to be a functional decomposition nor a sequence of actions. It's not me, but Ivar Jacobson, the inventor of use-cases, in Use-Case 2.0:
A use case is all the ways of using a system to achieve a particular goal for a particular user. (Page 4)
So use-cases are meant to provide the big picture. Your use-case diagram should identify these independent goals. Of course, behind each use case, you have some narrative that describe the interaction between the actors and the use-case:
The purpose of a use-case narrative is to tell the story of how the system and its actors work together to achieve a particular goal. (...)
Use-case narratives can be developed at different levels of detail ranging from a simple outline, identifying the basic flow and the most important variants, through to a comprehensive, highly detailed specification(Page 47)
One way of describing this flow, is how Geert Bellekens explained in the comments: describing the scenario telling who does what in which order. A variant of this presentation is a tabular form: a column for the actor actions and a column for the actor actions.
Now, if you're at the beginning of the design, and especially if you have several actors, this kind of UC description forces you to make a decision about the way you design the interactions. A more creative variant is to describe essential use-cases: instead of describing the flow of event, you make a table describing mapping more in detail the intents (i.e. intentions) of the actors (in one or n columns) to the corresponding responsibilities of the system (in a separate column).
You can then start to think about possible sequences, but also about alternative sequences that could provide a better user experience or a more optimal flow of information. The flexibility is so high that you could even design voice-driven or NLP driven interfaces in which the sequence is not predetermined but could be different for each use-case execution.
For my homework, I have to write functional requirement of a game called downfall (see Wikipedia).
We have to make this game, but with not two sides but n (any number of) sides.
In an example solution (another game), the teacher writes the functional requirements, then writes what use case they belong to.
I have created a use case diagram in which I have the player as an actor, and ChooseDial, RotateDial and EndTurn as use cases:
What I dont understand are the following:
Is the number of players functional requirement?
Is the table having two sides a functional requirement?
Is the goal of the game (getting coins from top to bottom) a functional requirement?
Is a rule like coins must reach bottom in order a functional requirement?
If they are, what use case could they belong to? Is my use case diagram wrong?
I have no idea where to put these functional requirements, because I feel like they arent part of any of my use cases.
About requirements
First, let's handle the requirement question:
A functional requirement tells something about what a software shall do. Everything related to goal, the gameplay or the rules of the game, is a functional requirement.
A non functional requirement tells something about how the software shall be, for example how accurate, how performant, how easy to use, how easy to maintain. Your narrative shows no such requirements.
About use-cases
Use case driven software development methods start with the high-level user's goals that are captured in use-cases. Personally, I see only one such goal:
Very rare usage: a multiplicity on the actor side of the use case. This says that 2 or more instances of players are involved in an instance of the use case. Of course, this makes sense only for the game as a whole, not for individual actions (like you have in your diagram).
In your diagram, you have shown 3 use cases:
is EndTurn an independent goal that the user may freely decide to chose ? No ! It's what always follows a player action. So this is definitely not a use case.
you say that RotateDials extends ChooseDials. This means that a player could ChooseDials but not rorate it. Is this a valid scenario ?
if on the other hand you'd say that ChooseDials includes RotateDials, the latter would always happen. But then, wouldn't ChooseDial not be more than just choosing a dial ? Shouldn't it then be called PlayTurn ?
I could understand that for learning purpose, you'd want to decompose the Play game in more detailed use-cases. Typically, once the players try to reach their goal Play game, this might include sub-goals of Play turn. As long as it is goal-oriented, and not too detailed, this is ok. But do avoid simple functional decomposition (it doesn't help for being more user-driven, and use-cases are not functions ). And, above all, do not misuse a use-case diagram for trying to show a sequence of activities.
Requirement traceability
The use cases do not capture the full requirements. It captures the most enssential thing: the purpose of the system and the user goals.
When writing down the requirements, it's then useful to get guided by the use-cases and their narrative, and to trace-back every use-case specific requirement.
But of course, there are some general requirements as well. These are not specific to a particular use-case. Some are even common to all use case. Mark these as general requirements (e.g. use case *).
Requirements management (RM) can be tricky indeed. A requirement like The board must have two sides seems to be more involved in the design, rather than the use case. In such cases you could relate that to the boundary rather than a single use case. That will indicate it's some "global" requirement (similar to a non-functional requirement). Usually in a project you start with a more or less strange mix of requirements mixed in user stories. The business analyst (BA) has to comb that information and come up with decent use cases (synthesize the added values). The system architect (with the BA) will then go through requirements and use cases to come up with a (business) class model.
There are tons of books and procedures describing RM. Lots of seminars too. I think if you grasp the condensed idea above you're ready to start. It's a marathon to start...
I'm learning UML by trying to simulate how a car service garage works with diagrams and documentation. One problem I have is with postcondition (or rather, GOTO) statements.
Is the dashed line << include >> relationship only for preconditions? Can Use-case bubbles connect to eachother and follow a logic path?
So this is what I have so far..
1) Is the 'Settle Payment' bubble in the wrong place? Should it have been << include >>ed to the other bubbles?
2) Should I associate the 'request service' bubbles to the technician too as he will be the one fixing the car?
Image
Use Cases are like classes. They have inheritance (extends) and relationships like includes and uses.
Preconditions are common relationship constraints. Some of us write the preconditions and postconditions in the text of the use case. You can draw it, but it isn't required.
Do not try to sequence the use case bubbles. That's what activity diagrams and sequence diagrams are for. That's what narrative text is for. That's something the users already know.
Also, don't waste a lot of time treating the use cases as a super-high-level programming language. Remember, the actors already know what they're doing; they don't need help sequencing things.
You need to focus on capturing the actors, the use cases, and basic "extends", "uses", "includes" among the use cases. Use Case models are not programming. The use case diagram is knowledge capture of "who" and "what".
Think of it as more like a security model that defines what the actors can do. Order, sequence, and other details don't matter as much as what the actors do.
When you have Actor associated with actor (like Technician and Front Desk), you're saying that the actors interact outside the system. You're saying that the tech never logs in to the system to do get their work or log their time.
If the technician actually will log in to get work and record time, then the technician participates in some use cases.
Use cases aren't programming. They're things actors do. Use cases are connected by virtue of being built in a big, common piece of software. You don't need to draw data flow or logic arrows among the use cases. They can all be largely independent.
When you design the system, you'll implement UI features and database features that connect the use cases in some sequence.