I must describe the operation of a pump that delivers a certain volume provided that the liquid is at the correct temperature. the cycle is started by a push of a button.
I wish to describe this operation by the diagram below
button when (Q = 40ml)
-------------> | do [T> Tmini] / pump () | ------------------------>
do I have the right to use this notation?
the question can be summed up
Can we have a conditional action in a "do" of a state machine diagram
You have to specify the tool you are trying to do this in, I would think. And after you do, I would recommend reading the SysML spec to better understand that you may be asking for a state machine diagram, or a sequence diagram, or a constraints specification on a constraints block within a parametric diagram.
I don't know, but this "answer" should illuminate enough for you to either figure it out yourself, or refine your questions :) Good luck!
Related
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.
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.
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……
i am currently doing an dynamic model for my ojt project. but i am stuck on a particular problem, my idea of a solution just seems overly complex.
to explain it in a different context, lets say i have 2 classes: customer and salesperson. the customer is buying something from the customer. but before everything is settled, they have to undergo a series of activities. after each activity, both the customer AND the salesperson have to chance to back out of the transaction. put in a diagram it looks like this:
is this correct? how about when i have like 50 possible activities? then that diagram will become very unreadable. what is a good way to solve this?
If you look at InterruptibleActivityRegion in the UML spec (section 12.3.33 of UML 2.4.1 superstructure ), it gives a similar example of cancelling an order at any point before the transaction is agreed. Within the interruptible region, which is notated as a dashed rounded rectangle with a Z shaped arrow coming out of it, all the activities may be interrupted by the event associated with the arrow - in your case backing out - and end up in the interruption handling activities.
You should use interruptible activity region. For a quick reference, see this sample diagram:
Has anyone ever seen a sequence diagram used as a use case? I never have and it really twists my head. At my current company, in all the documentation and discussions, the term "use case" is used to label a sequence diagram. I've asked a couple of times about this practice and get funny looks like it is a normal thing to do. - I've been a software engineer for a long time and used UML since the late 1990's when it was first (fairly) widely talked about. I don't expect to change the company culture. I'm just asking if this practice is used anywhere else and associated comments. - Thanks.
In my university, we learned that a use case diagram and a sequence diagram are both different diagrams with different meanings. In my experience, I have never heard anyone calling a sequence diagram a use case diagram or vice versa so I guess it's just the company culture...
Sequence Diagrams are typically used to describe an example of an action flow with communication. Thus Sequence Diagrams are very well suited to display an example for a use case. For this reason it is normal to refer to such a diagram as "a use case".
In consequence you would draw multiple Sequence Diagrams for each Use Case