How do I determine what should I add to my use case diagrams? 1 for each button/form? Should things like sort and search be included? Or are they under "list items" for example? Though, a list of items seems understood?
The Use Case diagram is intended to help define the high-level business tasks that are important, not a list of functions of the system. For example, a system for use in customer service might involve a research task of looking up information to help someone on a support call.
Most of the literature describes Use Cases as a starting point for defining what the system needs to accomplish. The temptation has always been to be as complete as possible; adding ever more details to define the use case down to a functional (code-wise) level. While it is useful to have a comprehensive understanding of the requirements, the Use Case diagram is not intended to provide that level of documentation.
One thing that makes the issue worse is the syntax which I've never seen used in a working project. It isn't that the terms aren't useful, it's due to the lack of consensus over when to use either term for a given use case. The UML artifacts expect a process that is more focused on the business language instead of the implementation language - and by that I do not mean a computer language. The tendency by some has been to approach the diagrams with a legalistic bent and worry about things like when to use for related use cases or how to express error-handling as exceptions to a defined list of process tasks.
If you have ever tried to work through the Automated Teller Machine (ATM) example, you'll know what I mean. In the solar system of UML learning, the ATM example is a black hole that will suck you into the details. Avoid using it to understand UML or the Object Oriented Analysis and Design. It has many of the problems, typical of real-world domains, that distract from getting an overall understanding even though it would make for a good advanced study.
Yes, code will eventually be produced from the UML artifacts, but that does not mean they have to be debated like a treaty in the Senate.
The OMG UML spec says:
Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The subject is the system under consideration to which the use cases apply. The users and any other systems
that may interact with the subject are represented as actors. Actors always model entities that are outside the system.
The required behavior of the subject is specified by one or more use cases, which are defined according to the needs of actors. Strictly speaking, the term “use case” refers to a use case type. An instance of a use case refers to an occurrence of the
emergent behavior that conforms to the corresponding use case type. Such instances are often described by interaction specifications.
An actor specifies a role played by a user or any other system that interacts with the subject. (The term “role” is used
informally here and does not necessarily imply the technical definition of that term found elsewhere in this specification.)
Now most people would agree that business and user level interactions are the sweet spot, but there is no limitation. Think about the actors/roles being outside of the main system/systems you are focusing on. But in one view a system could be an actor, but in another the implementer of other use cases.
Related
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'm wondering if System Sequence Diagram (SSD) belongs to design part or analysis part?
A System Sequence Diagram (SSD) is be a special type of UML sequence diagram that intends to document for one specific use case the the sequence of exchanges between the system under consideration and the outside actors.
It is not a standard UML diagram, but build upon such diagrams. The book "System analysis and design in a changing world" seem to have popularized this approach, but I could find articles dating back to the early 2000' (like this or this).
The above mentioned book places the SSD in the analysis activities. The reason is that analysis is about understanding the requirements, which often start with use-case. The SSD is then a fine-tuning of this analysis.
However, one could argue that it's part of the design activities, since the use case are the requirements, but how these requirements are addressed through a sequence of exchanges is already the start of the design of a solution, exactly as when you start to sketch an UI: more than one SSD could satisfy the needs and you have the choice.
So the answer depends on the purpose for which you're using the model.
My own point of view is that you're already drafting a solution, so it should be design, unless you do some reverse engineering of an existing application, or your client has very detailed requirements
Elaborating a little on Christophe's answer:
I would add that analysis and design are two highly intertwined activities, so you would probably see these SSDs in both contexts and it would be perfectly fine and acceptable. Use Cases, those that involve a system, are necessarily a design artefact (they are a design of what the system does in relation to external actors) although you can of course see that same thing as a pure analysis output (telling you what the system is required to do). These things are very hard to separate. The point may seem philosophical (it is somewhat), but it is useful to think in these terms.
When you see people creating "Login" Use Cases you can bet they already stepped into pure design, in other words: functional decomposition. In analytical terms the state of a User being logged in is a constraint on a Use Case, not a Use Case itself. Having a Use Case called Login therefore represents only a design choice (incidentally, if you see this in contexts where there is a division of responsibilities between the people performing analysis and design, then you'd do well to consider it an analysis fail: the analyst is essentially designing the system and that's not their role). Analysts sometimes use Use Cases to model layers of requirements that relate only to business processes, usually referred to as "Business Use Cases", that don't involve any system per se. But the origins of Use Cases from 20-odd years ago was in the system space.
Is use case narrative part of the UML?
A textual description of the business event and how the user will interact with the system to accomplish the task.
First of all, UML means Unified Modelling Language. It is a language which helps in designing and modelling software systems. So use case is not a part of UML. UML is a tool that helps to represent Use Cases (Among other things). And Use Case Modelling is an approach in requirement engineering for understanding and describing the functional requirements of a System.
It can be both narrative and graphical. Textual representation part is called use case specification while the graphical representation part is called Use case diagram.
So what is a use case? A use case is a summary of scenarios for a single task or a goal like "pay bill" in the above image. And a Use case model typically consists of several use cases. It helps to provide a clear picture about the external actors (both users and external systems),the functional requirements of the system and the relationships among them which in turn leads to a better design.
I'm going to assume that you mean "use case narrative." That given, the short answer to your question is "no."
A "use case narrative" is a document that describes the entire behavior of a use case. The UML doesn't define documentation methodologies specifically, so this isn't part of the UML specification.
The UML community has yet to build any sort of consensus on a term for this document (and, indeed, exactly what it ought to contain). Nipun Sampath, in his answer, calls it a "use case specification," for example, and muszeo calls it a "textual description," which, of course, it is.
The behavior of a use case would be modeled in UML as an activity diagram. So, an activity diagram is a diagram of a use case narrative.
For more information on use case narratives, see this post.
I believe you mean Use Case, rather than User Case. The description you give (textual description of steps to accomplish a business task using a system) is broadly what Use Cases are about.
To be clear, a Use Case is a kind of functional requirement; namely a description of a process that a person and/or system (role(s)) performs with information to accomplish an objective that has business value. With Use Cases this specification generally starts with a model ('blobs on a page') which illustrates the process, system and actor (role) context, with a textual description and/or supporting models (e.g. Activity Diagrams) to express the steps of the process. There are other ways to express functional requirements -- User Stories and BPMN process charts are two other examples that achieve the same thing but in different ways. You may be confusing Use Cases and User Stories, perhaps.
I have a question about uml and extend notation of use-case.
How I can extend all use case.
For example if I created a connection down use case that extend almost all use case, but I don't want to connect all with the notation on the use case diagram cause is very orrible to see. How can I do?
First of all: the importance of Use Cases
Modeling Use Case Diagrams (Use Case Modeling) is SO important step in Software Analysis and Use Case Modeling should be performed by professional Analysts:
All estimations (Time, Budget, Resources and etc.) are performed based an Use Cases.
In some Use Case Driven Methodologies, all subsequent steps are based on Use Cases.
and etc.
Secondly: Knowing Use Case Modeling Traps.
In Use Case Modeling there are some traps that we need to conside related to your question:
(Trap #1: Use cases that users don't understand.) (see reference 1)
Use cases are a way to represent user requirements, which describe
what the user needs to be able to do with the product. Use cases
should focus on tasks a user needs to accomplish with the help of the
system, so they should relate to the user's business processes.
Your users should be able to read and review use cases to find
possible problems, such as missing alternative flows or incorrectly
handled exceptions. If users cannot relate to use cases, there's a
problem. Perhaps they're written too much from a technical, rather
than business, perspective.
(Trap #4: Describing specific user interface elements and actions) (see reference 1)
Write "essential" use cases that describe the interactions between the
user and the system at an abstract level, without incorporating
user interface specifics. The use case description should not include
a screen design, although simple user interface prototypes can be
valuable to facilitate the use case exploration.
(2. Not having clear business goals for every use case) (see reference 2)
(6. Specifying use cases in too much detail) (see reference 2)
Thirdly: Use Case Modeling is in the Requirement phage of methodologies.
We should not put common implementation methods in Use Cases. Common methods in implementation handled by other diagrams in next steps of methodology. (maybe in Design Model) So, if we put all common methods in Use Case Model, the number of use cases increases a lot. (and our estimation as mentioned in first part goes wrong)
You can't - and it's nonsense. A use case shows added value for an actor. Extensions to use cases are very rare. In most cases people try to apply functional decomposition and mistake a step of actions recurring in multiple use cases as "partial" use cases. They aren't! If you are trying to do what you describe you went the wrong path. You should instead think why and where your use case synthesis broke.
I strongly recommend reading Bittner/Spence to get the right idea what use cases are all about.
You can use use inheritance.
Something like this, use cases B and C are extended since this is inherited.
But as #Kilian said, it would be interesting that you explain why you need a such model.
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.