I’m trying to prepare UML model for my project. It’s quite complex however I focus on one of use-case. In short term, use case name is “Edit patient results” and actor “Doctor” uses it. In fact, entering results triggers always the set of following actions:
List item
Normal Ranges calculation
Related Expression calculation
Interpretation merging
Assuming that I have my use-case diagram prepared as follows:
My questions are:
How shall I draw actions that are triggered automatically? As extended use-cases like this?
How shall I draw “Edit patient results” use-case realization? Each edit operation involves several software components interactions, shall I use collaboration diagrams? (how to join my main use-case with them), maybe something else?
How to draw sequence diagrams to show actions sequence and parameters passed? How to join these diagrams with my use-case.
What is the best way to show use-case realization
I'm using Enterprice Architect.
Thank You !!!
No. These are just activities which are part of scenarios inside the use case. Trying to make the use cases is functional analysis the wrong way. A use case synthesizes a number of steps under a common goal/added value.
A use case realization is a collaboration (bubble with dashed line border; along with the UC in the toolbox). The collaboration contains diagrams which show how the single classes communicate/collaborate to realize (parts of) the use case. Use a Realization from Collaboration to Use Case.
Put the SDs inside the collaboration and group/name them reasonably.
see above
As to your comments:
Edited 2.
I never found a good use for Collaboration Use and I've done a lot of successful UC modeling. So you can probably live without it as well.
Put Actions inside an Activity representing a scenario and connect them as desired. You might look into BPMN as well.
Related
Little background
I'm new to writing use cases and representing their scenarios.
I'm dealing with a complex system. In the first step of analyzing the system, I created a use case diagram where each use case represents a distinct goal or value for the system. I have tried my best to keep the use cases independent. All these use cases require the initialization and activation of the system, so I decided to take out this common part and link it to the main use cases using include relationship.
I understand that include and extend relationships need to be used only when necessary.
Now I'm lookin into defining scenarios for each use case and then developing user stories and requirements based on scenarios.
Main issue
The use cases are very complex and the easiest way to analyze it seems to be mapping it into a sequence of steps/activities where each activity contains several scenarios and each scenario is represented using a sequence diagram.
I understand that an activity cannot be a use case which is related to the main use case using include relationship; but having sequence diagrams for activities seem wrong too.
What is the best way to represent a use case where each step of the main flow is complex and can have several interactions between actors and systems as well as having error scenarios which can result in termination of the sequence at that step or possibility of the user cancelling/aborting the sequence?
I have attached a simplified version of the activity diagram for "Initialize" use case.
As I mentioned, each activity can have many scenarios. For example
"Perform Self check" has many steps and each step might result in a failure that can terminate the sequence and alert the user (via a HMI). The user then can either terminate the initialization or retry.
"Validate system configuration" include steps for obtaining the reference config versions and comparing that to the system config, then download the new config files if necessary and then update the system configs. Each step might have a failure resulting in some sort of message to user and termination of the sequence. In some cases user should be able to skip the failed steps and proceed without doing that activity.
Same goes for every other activity in the diagram; many steps with exception or alternative paths.
Can I map these on one sequence diagram for the "Initialize" Use case?
My attempt to put all these on one sequence diagram failed.
I tried putting all these interactions on an activity diagram with swimlanes but things got so complex that stakeholders have a hard time understanding what is going on.
Maybe I'm trying to put too much details at the system level. Should I leave all these interim steps and interaction for the lower level of design? Should I create a hierarchy of use cases and roll down the complexity? I'm confused. :(
What is the best way to deal with such level of complexity? Could you provide some good examples.
The only way to represent a complex use case, where every step of the main flow can have multiple scenarios, is fortunately very simple:
The complexity of the scenarios does not change anything to the simplicity of the actor's goals. And if the goals are not sufficiently simple, you'd probably looking at too much details. Or the things are not as clear as they should.
The scenarios are often represented with a set of sequence diagrams. But if it gets really complex you'd better show the flow with an activity diagram.
By the way, you do not need to create an artificial extending or included use-case for the sake of modelling common steps. You may just create a separate activity diagram for the common part. Then, in each of your use-case activity diagram, you'd insert a call action of the common activity. This also avoids to misleadingly include the common part in the description of one UC and forget it for the others.
Last but not least, you also want to develop user-stories based on the use-case scenario. This is a mixed approach that requires some more thoughts:
user-stories are generally used without use-cases. Complex erquirements are described as an epic. The epic would then successfully be refine it into user-stories, that fit in an iteration;
it is possible to structure such user-stories according to stakeholder goals and tasks. THis approach is called user-story mapping. This is closer to the use-case, but there is no term to describe the higher-level goals.
use-case driven development is generally used without user-stories: the scenarios and activity directly lead to development without intermeriate user-stories.
Fortunately, the Use-Case 2.0 approach allows to combine both ways. Read the linked whitebook: it's short, it's free, it's written by the inventor of use-cases together with leading authors of use-case methodology; it offers a reegineered appraoch that allows agile developments, using use-case for the big picture and using use-case slices to break it down dynamically into units that can be developped in one iteration.
A complex use case can remain a single use case, but it may need multiple diagrams to specify its flows.
Your activity diagram (although not 100% UML compliant) gives a good overview of the flow of the use case. Keep this as the main diagram. I would decompose the complex steps in separate diagrams. To indicate that a step is decomposed in a separate diagram, you can display a rake symbol, as follows:
See UML 2.5.1 specification, section 16.3.4.1 for more information.
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 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.
I came across a situation where a use case has two options to choose from.
Example: Use case "Process data" has options like "Approve" and "Decline"
If approve, update the inventory.
If decline, file the information.
I know how to represent this in an Activity Diagram but I have no idea of showing it in Use case diagrams.
There are two choices here.
A) You make two use cases instead of one. Approve Data and Decline Data
B) You make one use case Process data. In the main scenario you describe the steps for Approve Data and in the exception or alternate scenario you describe the steps for Decline Data. In this case the difference is not visible on the use case diagram, but that is OK. Use case diagrams are meant to give you an overview of the big chunks of behavior in your application, not of the details.
The choice for alternate or exception scenario depends on your post-condition(s). If the Declinescenario meets the post-condition then it is an alternate, else it is an exception scenario.
The term Data is not very specific. I would prefer something more meaningful then data like Order, Application,...
I can't know for sure without knowing all the details, but option B) is probably the best.
A usecase has a specific goal for a specific actor.
Identify the Actor for the usecase(s).
Identify the Goal of the Actor.
Define the usecase with a strong specific verb, process is weak unspecific verb.
I find the requirements ambiguous, it seems you may be conflating two separate Actors.
See the Uml Style Guide : Usecase
You create two views of the same usecase. In the first view you create Process data with Approve and a second one with Decline. Each view is a different usecase diagram but using the same usecase.
It is important to make a clear differentiation between graphical views and model view. I mean that graphical usecase diagrams should be a view which is extracted from the UML model.
if not then use this link http://msdn.microsoft.com/en-us/library/dd409427.aspx