When designing flowchart models for my programing, I sometimes ask myself if I am drawing email communication between swim lanes the best way. Perhaps there are some who has better suggestions to describe the following process?
A wants a specific customer list from B. To do that, A has to send a request to B - it could be an email. B creates the list and sends it back to A.
UPDATE
My initial illustration wasn't UML so I try with this instead - ready for your comments:
Actually this is a perfect and overall used approach. Rather than using swim lanes, which are just graphical elements on the diagram, you should use ActivityPartitions (which are real UML elements) which you can classify with the actors in question.
Further you should use ActivityInitial (full circle) and ActivityFinal (hollow circle with large dot in center) to mark the start and end of your flow.
For more examples see here.
N.B. Just noticing this is tagged with Visio. Since Visio is a pure drawing tool you should consider using a real UML modeling tool instead.
P.S. I see that Geert removed the UML tag. So I may have been deceived by the question and thinking of this as being an UML activity diagram. So that's what my answer refers to. Anyhow, since flow charts are ancestors of activity diagrams this might help as well.
Related
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.
Could you please let me know whether flow chart can be consider for use case modelling? As far as I know it just represents a flow of events and do not have any actors, so cannot be considered for modelling.
Can some some experts confirm this?
Flow charts are the ancestors of activity diagrams and as such very rudimentary. You can use flow charts along with use case modeling, but it is not a good idea. First you will limit yourself in the language (think of a native speaker vs. a foreigner that knows only a little vocabulary). Second is that activity diagrams are matured to a standard within UML. So you can expect more people to be able to read and understand them correctly. And last: activity diagrams are the basis for BPMN which is going to be the next step after use cases (it brings a whole set of new standardized language elements which allows expression of what is in and behind a use case).
And yes, your basic assumption is correct: no relation to actors. So you'd need to find ways to express that outside the flow chart.
See also Wikipedia.
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'm creating a use case diagram for a checkers game that I programmed. How in-depth are you really supposed to go when making these? I read that they are supposed to be simple, but that is kind of vague. Do I need to create more arrows, for example between "move regular" (which means move a regular piece, as oppose to a king) and "jump"? Or is it fine not having a connection there? I just don't want to make too many arrows because it will begin to look pretty messy. Any input will be appreciated.
1) ..UML..diagram..how in-depth are you..supposed to..do I need..more arrows..don't want..it..look..messy..?
How in-depth and how simple depends on many factors, basically on an answer to "why you need it" and "who will read it".
Actually the set of questions and guides and other practices that can help you decide can be quite long. Especially useful one is listed in the chapter Agine Modeling: Agile/Lean Documentation: Strategies for Agile Software Development in Scott W. Ambler's online book.
One thing that you should get absolutely clear is what kinds of UML diagrams you need/want
2) UML..use case diagram..more arrows..or..no..connection..too many arrows..?
The arrows in use case diagrams are not an arbitrary connection lines but instead they have precise meaning, especially the <<include>> and <<extend>> relationship, see http://www.uml-diagrams.org/use-case-reference.html for their definition and examples
Besides being graphical bubbles the use case represent how an actor interacts with the System Under Design. Content of the bubbles is then described in more/less formalized text form, see Wikipedia: Use case and especially Alistair Cockburn's use case pages as he basically defined meaning of the term (later adopted by UML) his opinion matters.
3) I'm creating a..UML..diagram for a checkers game that I programmed..
In your case the King Piece bubble does not seem to be included-in or extending the Start Game bubble initiated by the Player and I don't see what sequence of steps might be hidden inside its textual representation (or in your code).
The things you began to draw look much more like UML Activity Diagram, an example
and some explaining links:
overview Debenedetti Emanuele, Activity diagrams in UML 2.0
background by Conrad Bock (one of UML authors), UML 2 Activity and Action Models, The Journal of Object Technology
UML 2 Activity and Action Models
UML 2 Activity and Action Models, Part 2: Actions
UML 2 Activity and Action Models, Part 3: Control Nodes
UML 2 Activity and Action Models, Part 4: Object Nodes
UML 2 Activity and Action Models, Part 5: Partitions
UML 2 Activity and Action Models, Part 6: Structured Activities
tool manuals
PaceStar UML Diagrammer, UML Diagramming Guide - http://www.pacestar.com/uml/udg60.pdf
Sparx Enterprise Architect, Using UML Part Two – Behavioral Modeling Diagram - http://www.sparxsystems.com.au/downloads/whitepapers/UML_Tutorial_Part_2_Introduction.pdf
Microsoft Visual Studio, UML Activity Diagrams - http://msdn.microsoft.com/en-us/library/vstudio/dd409360.aspx
There are much less use cases here. Pls refer to the following diagram drawn by myself:
The other requirements can be written in use case specification, specially the business rules.
Use case name: Move piece
Actors: Player (Primary)
Pre-conditions: ******
Post-conditions: ******
Stakeholders and Interests: ******
Basic Path:
Player selects one piece and the destination square, and submit a move request.
System validates destination square.
System moves the piece and calculates the moving.
System displays the moving result.
Exception Path:
2a. destination square is not valid:
2a1. System ****
Business Rule:
valid destination square : ……
calculating rule, such as king piece, win game……
What is the practical difference between using flowchart diagrams and UML activity diagrams?
I have some thoughts, but maybe I'm missing an elephant in the room?
Flowchart diagram:
Widely used;
Easily understood by non-programmers;
Old?
UML Activity diagram:
Standardized;
Supports concurrency;
Less known syntax, but still simple enough.
For my case of ad-hoc documenting a particular block of application logic, I decided to go with the flowchart diagrams. More people in the company will be able to understand them.
It might seem as a preference, but if we have a standardized language for describing software systems, Why do we use something else? This can lead to bad habit of overusing flowcharts. Activity diagrams are really simple. But if you decide to describe a more complicated aspect of the system or try to change the part you are describing, you might have to switch anyway. So just use UML and prevent confusion in the future.
As you note, Activity diagrams inherently can include concurrency and timing. If you look at this example cribbed from Wikipedia, shown below, you can observe the section with two heavy horizontal bars, and two parallel activities of "present idea" and "record idea". That is read as "start these activities in parallel, and continue only when both are complete." Flowcharts can't express this within the notation.
Practically, using activity diagrams lets you think clearly about concurrent processes. I think you'll find that anyone who can read a flowchart will quickly adapt.
Activity diagram by spanish Wikipedia user Gwaur CC BY-SA 3.0, via Wikimedia Commons:
According to the Agile Modeling site:
In many ways UML activity diagrams are the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development.
From IBM:
However, flow charts do not include And states, and flow charts for operations cannot receive events.
Probably this is why flow charts are easier to understand because activity diagrams have the notion of object-oriented development and concurrency.
You can generate source code from UML, and vice versa; hence the "standardized" characteristic you talked about.
UML in itself is used to share your understanding. Share the understanding in a standardized way. Since your case is ad hoc and the primary usage of an UML diagram is to provide an informal sketch, activity diagram can be used here. But so can flow charts as there are no parellism involved here. I have always found the following argument to be helpful. The artifct that i am producing is going to benefit whom? And can i express the flow in a self explanatory way using a flow chart. And if yes, then you should go ahead and use flow chart. But if your class diagrams, sequence etc are in UML format, it would make sense to have your activity diagrams in UML as well for consistency sake(The argument here would be, if people can understand class,sequence UML semantics, then y not activity diagrams.).