Curerntly, I am documenting all the client's requirements using usecase diagrams and ofcourse I am new in design paradigm. I have a highlevel usecase diagram that contain overall system requirements. And then I have detail level usecase diagram for each usecase define in high level usecase diagram. Now, In detail level diagram, I have included usecases that system trigger itself as well.
e.g. High level usecase - Upload Report file
Detail level usecase for Upload Report file:
Here, in the figure above, the usecase 1.3, 1.4 and 1.5 are trigger from system and this usecases are not directly interacted with user.
So, my question is that should I include these type of system level usecase in the details usecase diagram or should I just include those usecase that only interact with user?
P.S. if what I'm doing above is not valid(the way I am producing usecase diagram as in diagram displayed) then please I would like to have your recommendations.
Well, not really an answer, but an advise. The problem here is that I'd need to dump your design so far and start from scratch. And that's of course not possible. So as a guidance:
Look for added value, not functionality.
Do not use (!) include/extend and just draw simple associations between actor and use case.
For each use case ask yourself: is that added value? Only if the answer is yes, then add the bubble.
Name each use case with verb/subject (and eventually an object)
Use only the main actor and leave away any secondary actors in your diagrams.
If your UC diagrams start resembling spider webs your design is likely broken.
There is no absolute number, but you end usually with a handful of actors and a few dozen of UCs.
Related
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 discuss with my friend our project and we are in a way to draw the sequence diagram ( UML 2).
He told me that the sequence diagram is drawn by the use case. It means that for each use case we should draw a Sequence Diagram.
Is it correct ?
Thank you for any suggestion.
Well, taken as dogma it is not correct. A sequence diagram (SD) shows the behavior of objects in the way they interchange messages (and also if needed their lifetime and some minor additional information). You "can" also use a sequence diagram to describe scenarios in use cases. But simply speaking, a SD is more technically oriented (class design/programmers) rather than business (business design/stakeholders). To visualize a use case scenario you're better off using activity diagrams (AD). And even better if you dive into BPMN (which brings ADs to a new level).
It is possible though, to convert ADs to SDs and vice versa without information loss (if you forget about the afore mentioned bits and pieces).
Now another point: you will not necessarily need a diagram for each use case. I found that often use cases are more easily (and even clearly) described in a textual way (see Cockburn or Bittner/Spence) rather than diagrammatically. Especially if you have UC scenarios that are very linear in their single actions. So you can leave out the AD for those and just fall back to simple text. You should further avoid describing UC scenarios in both ways (i.e. text and diagram) as this introduces unwanted redundancy (means you would need to maintain always both when changes happen; and they happen often; and people are lazy -> so which one holds the truth: text or diagram?).
Generally, as Thomas points out, use case detail is set forth in an activity diagram. As he also mentions, a use case scenario would use a sequence diagram, when necessary. A use case scenario is a single path through a use case.
Sequence diagrams aren't good at diagramming multiple simultaneous behaviors and multiple decision points, and use cases generally have both of these features in their behavior. Activity diagrams do these things very well. A single path through a use case, by definition, doesn't have simultaneous behaviors and decision points, so a sequence diagram is more appropriate.
Googling "use case scenario sequence diagram" gives a number of links that explain the use of sequence diagrams for use case scenarios in detail, of which this is an example.
UseCase is declaration of behavior (service or usefull behavior) of system which is executed by system with collaboration (interaction) with system's actors.
Any type of diagram defined in UML could by used to describe behavior on any level of abstraction. All of diagrams could be also used to describe both business or technical aspects of system.
UseCase is declaration of behavior, it means that UseCase does not define behavior at all. UML does not define scenarios of UseCase ,scenarios are usually defined in methodology not in UML.
If you need to describe behavior of system in context of UseCase you can use some of behavior diagrams defined in UML for each UseCase.
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.
According to UML context diagram context diagram doesn't exists.
So my question is which one of UML diagrams is good to show something like this and how to paint this?
I've just found the following definition: http://en.wikipedia.org/wiki/System_context_diagram
That's probably what you need. :)
A context diagram defines a boundary between the system, or part of a system, and its
environment, showing the entities that interact with it.
There is no single diagram in UML that would map to this definition, but I have some good news - there are several diagrams (out of total of 14) that can show the frontier between the system and its surrounding world from different perspectives. This is much more flexible than only a context diagram.
First of all, I would mention a special UML element - a boundary. It can be used in any diagram type to show some kind of delimitation. You might want to optionally use it to visually delimit between the system and its environment, especially in situations when this is not explicit.
The following diagrams can show the boundary between the system and its environment:
Use case diagram (your example) support the context explicitly on the functional level. Use cases are elements of the system under development, while the actors are extern entities (systems or human users). Before mentioned boundary is often used to visually delimit between the system and its environment.
Component diagram is used to model some kind of software modules (applications, DBs, external systems, libraries, etc). You can use it to show both internal and external components and the way they interact. A boundary can be used to clearly draw the separation line.
Activity diagram can show your system/business/usage processes. Some activities can be performed internally, others externally. Here you don't need the boundary, but the so called swimlanes to depict who does what.
Sequence/collaboration diagrams are another option. They show the communication sequences between several objects. If you split those objects in internal and external ones and wrap them up with the boundaries, there is another context diagram. :)
UML is flexible, there are probably further options, but I think this is enough to get the idea.
Names of your association are services. UseCase in center of diagram is context of services definition. See usecase diagram:
It could be done with a use case
http://en.wikipedia.org/wiki/Use_case
EDIT:
Reconsidering it, use case diagram should be the next step once the operations are defined so first you shouls make a system sequence diagram.
http://en.wikipedia.org/wiki/System_sequence_diagram
If you're happy with going into the not complete superset of UML that is SysML, you can have proper Context diagrams there.
However, context diagrams in SysML are simply Block Diagrams showing system context… and Block Diagrams happen to be the same as UML2 Class diagram, where the classes are of stereotype «SysML::Block».
So you can define your context diagram in terms of aggregation of blocks to your system, with the relevant stereotypes, basing it on UML2 Class diagrams.
I tend to use collaboration diagrams for this. So for each major scenario of each use case, draw a collaboration diagram showing the actors, with the application as a single entity in the middle, and messages travelling around that show how the application interacts with the actors in order to fulfil the scenario.
(I don't put too much detail in the messages -- I only want to show that there is a delegation of responsibility and some kind of interaction, but I don't care about details of actual messages, views, data etc.)
I find the context diagram does have a particular appeal. It sits well with business users, showing them the scope & parties of a system in a very easy way. So, I tend to create a context diagram, even in contexts where UML is prevalent.
I'm currently architecting a design for an application that communicates with an inventory system. I don't need to design a class in my class diagram for this inventory system, but a class has to communicate with that inventory system in a sequence diagram. Can I simply model a lifeline for that inventory system without having modeled it in my class diagram?
My short answer is yes, you can include something in a sequence diagram which doesn't appear in any class diagrams.
My long answer is: making UML diagrams is not modeling, it's a way of illustrating how you plan to model; it's a tool for communicating ideas. A comprehensive, complete set of UML diagrams probably won't translate into a working system which meets your customer's needs, because while the system is being built your customer is very likely to change their mind about what they want, and you're very likely to discover things you didn't know up front which force some of your carefully-diagrammed plans to change.
With this in mind, I use UML only as a tool to get an idea across to a particular audience at a particular time. As such, I consider everything which isn't vital to illuminating a particular concept or part of the system I'm looking at at the time as irrelevant. This includes whether my UML diagram covers every part of the system, whether every entity in a sequence diagram has a corresponding symbol in a class diagram, etc. I'd say the only measure of whether a UML diagram is 'correct' is if it helps illustrate the part of the model you intend - if it does don't spend any time worrying about the details.