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.
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.
Firstly, I'm still quite new to UML; but, highly interested and am attempting to learn as much about it as I can.
With that said, I’m in a situation where I’m directed to assemble a ‘Context Diagram’. I feel as though I understand the concept of what a context diagram is and how to create one, so I think I’m ok there. Basically it is identifying the system and the components or actors it will interact with. It applies the focus on the system, and not the actors. Kind of like a Use case diagram, but not focusing on the actors. If I’m wrong, please tell me.
I read somewhere that Context Diagrams are not actually part of UML. I also read, somewhere, that, if you use a Context Diagram, it falls into the Component side of things. When I read about Domain models, it seems like it should be there.
For my current situation, I know a simple answer is to simply create the diagram and move on, as that is all that is required. But, for my interest to better understand and leverage UML, I know there is a right way and a wrong way. If I were in a case of a bigger project, what would be the right way?
Now here is where my question begins. I’m using Enterprise Architect, create my project, and start to create a model. Does it belong in a Domain Model or Component Model? What is the difference between these two? Or even more. As it is an aide to help identify requirements, should it go there? Or does is just simply depend on what and how I want to convey it?
The Domain Model is where you standardize the vocabulary that everyone on the project will use to communicate in a consistent manner. The development team are experts at software development, but they may not have any experience in the domain (e.g. banking, air traffic control, healthcare) in which they are being asked to work. So you get domain experts and modelling experts together to build a model that describes the domain, answering important questions like "how are account fees calculated?" and "how does a pilot know what route to follow?" and then this model is then passed to the development team to provide them with the important domain knowledge that they will need. I would use UML class diagrams to create a domain model.
A Context Diagram shows the system being modeled in relationship to external systems. It could show data flowing in from and out to external systems, modeled by a data flow diagram (not part of UML). It could show behavioral interactions between the system and external "actors", modeled by a UML use case diagram. It could show the system's physical connections to other systems, modeled by a SysML block diagram. Whichever you choose, it will be on page 1 of your design document, so choose wisely!
You (can) create context diagram by making any element composite. Then drag the element itself onto that diagram as link (not instance!) and highlight it by making the border a bit thicker. Finally insert related elements from the context menu (differs from EA version to version). Layout the diagram and now you have your element in the context.
A domain model is usually a class diagram showing the (business) domain on a higher abstraction level.
As you have said, Context Diagrams per se are not part of the UML spec. There are plenty of ways to do a context diagram, but the UML way is to use a Use Case diagram, with or without supporting narratives and scenarios. Start with this, which is a broad overview of different types of Context Diagrams. Then, investigate use case diagrams, use case narratives, and activity diagrams. If you need to go into more detail than a use case narrative can easily do, get into use case scenarios and sequence diagrams. Here is a pretty good use case narrative template (feel free to leave out sections such as "scope and level" if they are more than you need, and consider adding information about what triggers the use case and where you go when you finish it--these two are required for scenarios if you go that far).
Keep in mind that use case narratives and use case scenarios are often confused. (Some people will say that I am the confused one; I will invite you to judge the matter for yourself.) A narrative is an explanation of an entire (single) use case, and may be supported with an activity diagram. A scenario is an explanation of a single path through a single use case, and may be supported with a sequence diagram.
For example, a use case will generally have a basic flow of events, along with a number of alternate flows. The narrative describes the entire process. The basic flow and each alternate flow would each be a separate use case scenario.
I suspect that it's unlikely that you will have to get down to the level of use case scenarios. You will probably want to put a use case diagram together, and possibly prepare narratives and activity diagrams for each of the use cases in the diagram.
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.
BPMN (Business Process Modeling Notations) is used for modeling business process by visualization, thus making intangible ideas become physically concrete through the expression of BPMN diagrams. The question is, how do I organize the BPMN with the UML.
Initially, I thought of two ways to organize use cases and business process diagram:
1 to one/many: By mapping each step (step here means each node in the BPMN digram) in the business process diagram with one or several use cases. Each use case is mapped with relevant several class diagrams/component diagrams (I prefer this one, since you can encapsulate a set of classes into one component which has input and output), several sequence diagrams (optional). After you have class diagrams/sequence diagrams, code is written/generated based on the model.
Many to one: By mapping several steps into one use case. The subsequence steps are the same.
Many to many: For example, one step in the business process can be mapped with two or more use cases, and the same two or more use cases can be mapped with other steps.
The above methods can be done by the modeling tool, and in my case, I use Enterprise Architect from Sparx System. I discover it recently and I am using its trial, but I will buy it in the future. I can organize many use case diagrams with one step of the BPMN diagram, and can click to view the necessary use cases. However, I don't if it supports many to many cases.
After thinking my own method for organizing BPMN and Use Cases, I searched the Internet, and found two other papers, each suggest the following method:
Turn each use case into each step of BPMN diagrams: To visualize how refined use cases fit into the business process. I like this approach, since the business process with steps can be modeled, and later each step is turned into a use case. One step is one use case. This is the same with my one to one mapping above. Original presentation is here: Visualizing Use Case Sets as BPMN Processes
Each use case is exactly a business process: Each step in the use case is each step of the business process. Original paper is here: Describing Business Processes with Use Cases
It seems to me that there's not standardized way of gluing these artifacts (BPMN and Use Cases and other digrams) together. Maybe it's a management problem and rely more on creative usage rather than follow a formal steps. What are your opinions/experience on the usage of these diagrams in software engineering process?
I know methodology like XP which specifies its own practice in software development process. However, unlike Scrum where it focuses more on management aspects (which means you can still apply the BPMN/UML modeling into your work process), XP specifies software practices and requires you to follow, and eliminate the modeling process like BPMN/UML, and its practices if not apply properly will lead to issues like under documentation, incorporates insufficient software design....
I prefer the model driven way than XP. I guess it's up to the preference of companies and people. One of Agile goal is to "free developers from document works". Methodology like XP seems to easily lead to under documentation. I think to achieve that goal, the solution is to implement the tool to help developer reduce the workload on writing document, not by writing less documents, by gathering information from existing diagrams and automatically generate reports (in RTF, PDF, HTML in the case of Enterprise Architect of Sparx System). Another example is, people often complain about drawing diagrams consume their time. In my opinion, the solution is not to draw diagram, but the using the tool. Modeling tools today support round-trip engineering, where you can synchronize between your code and your diagrams, thus eliminates the extra effort to manually correct the diagrams if the code base changes (specifically, class diagram). What's your opinions/experience on this issue?
Usecase should be goal oriented tasks they are not single steps. The first example is a definite variation of the standard way to utilise usecases. I suggest map each usecase onto a single business process. This Sparx EA example maps usecase onto activities diagrams but does reveal the approach to use.
My 2 cents
My suggestion is to use these tools to understand the business processes. I follow the below
End user point of view: user stories
Business Analyst perspective: use cases (with main and alternate flows) and specification by example
BPMN: Executable business process
When you start looking out for the perfect marriage of all these, you will be lost in details. ;-)
I suggest this approach: https://www.academia.edu/6750935/From_Business_Process_Models_to_Use_Case_Models_A_systematic_approach
Generally speaking, one process maps to more than one use case, only in particular cases the relationship goes one-to-one.
What are the steps to be followed when we start UML diagrams for new features or requirements?
I need the entire steps like
Identify the actor,
Identify the use cases,
like this etc....
What you need is some sort of methodology.UML doesn't come with any, because it is ment to be methodology independent. However, the authors of UML have created some methodologies, which heavily use UML. One of the methodologies, which is free, is Unified Process or UP for short. Try to look at that, there are plenty of books, which discuss UML and UP at the same time.
Create a simple model of the existing system, and a detailed model of the area you plan on working in. There are a number of different types of diagrams (activity, sequence, class, etc), you should use the ones most appropriate for the complexity of your system and its interactions with other components, systems, and people.
This is a very board expression. In general, I would start with Use Case diagrams and go from there. As Gabriel pointed out, there are entire books written on this and there is no one right answer. My personal favorites for Use Cases are:
Advanced Use Case Modelling
and
Writing Effective Use Cases
Take a look at Craig Larman's book "Applying UML and Patterns". That describes very accessibly how to use UML to tackle a problem (Use Cases, Class Diagrams, ...).