How can I graphically represent within Statechart Diagrams that a state never gets executed more than a certain amount of times? So that it doesn't end in an infinite loop. Something like
assert enterPIN(int p) <= 3
and then branch to another state, if condition violated. Should I include it somehow in the guard? Or in the state activities?
EDIT:
(CheckPIN)--[invalid]-->(counter| + inc.)--[counter>3]-->(retainCard)
^ |
|-----[counter<=3]-----|
Something in this direction?
Legend: (StateName | (+-)activity), Transition: -->, [Guard]
I think your question is way too far down in the weeds. While you can model to infinitesimal detail, you should aim to create a much more durable model that will not require as much change over time.
H. S. Lahman makes an excellent case for using Moore state machines in his book, Model-Based Development: Applications. Moore state machines are where actions happen on entry to states, as opposed to where actions happen on transitions between states. His most compelling reason for using Moore state machines is that transitions do not degenerate into a sequence of function calls, they are instead announcements of things that have completed.
Here is an example of how to avoid all the detail and create a more durable model:
You'll notice that how things happen is completely encapsulated. For example, challenging the user might involve a PIN number, retina scan, or subdermal chip. The maximum failures allowed for each of those authentication modes might be completely different. That policy can be represented elsewhere.
To give a graphical answer:
This is how I would model it.
The counter object is usually not needed, since it's a simple counter and it's rather obvious that the rest/increment would refer to a common counter. Also there is no real <<flow>> to that counter. A not stereotyped dependency would also suffice.
Related
I want to write a simulation of a multi-entity system. I believe such systems motivated creation of Simula and OOP where each object would maintain its own state and the runtime would manage the the entire system (e.g. stop threads, serialize data).
On the other hand, I would like to have ability to rewind, change the simulation parameters and compare the results. Thus, immutability sounds great (at least up to almost certain garbage collection issues caused by keeping track of possibly redundant data).
However I don't know how to model this. Does this mean that I must put every interacting entity into a single, huge structure where each object update would require locating it first?
I'm worried that such approach would affect performance badly because of GC overhead and constant structure traversals as opposed to keeping one fixed address of entity in memory.
UPDATE
To clarify, this question asks if there is any other design option available other than creating a single structure that contains all possibly interacting entities as a root. Intuitively, such a structure would imply logarithmic single update penalty unless updates are "clustered" somehow to amortize.
Is there a known system where interactions could be modelled differently? For example, like in cold/hot data storage optimization?
After some research, there seems to be a connection with N-body simulation where systems can be clustered but I'm not familiar with it yet. Even so, would that also mean I need to have a single structure of clusters?
While I agree with the people commenting that this is a vague question, I'll still try to address some of the issues put forth.
It's true that there's some performance overhead from immutability, because when you use mutable state, you can update some values in-place, whereas with immutable state, some copying has to take place.
It is, however, a common misconception that this is causes problems with big 'object' graphs. It doesn't have to.
Consider a Haskell data structure:
data BigDataStructure = BigDataStructure {
bigChild1 :: AnotherBigDataStructure
, bigChild2 :: YetAnotherBigDataStructure
-- more elements go here...
, bigChildN :: Whatever }
deriving (Show, Eq)
Imagine that each of these child elements are big and complex themselves. If you want to change, say, bigChild2, you could write something like:
updatedValue = myValue { bigChild2 = updatedChild }
When you do that, some data copying takes place, but it's often less that most people think. This expression does create a new BigDataStructure record, but it doesn't 'deep copy' any of its values. It just reuses bigChild1, updatedChild, bigChildN, and all the other values, because they're immutable.
In theory (but we'll get back to that in a minute), the flatter your data structures are, the more data sharing should be enabled. If, on the other hand, you have some deeply nested data structures, and you need to update the leafs, you'll need to create a copy of the immediate parents of those leafs, plus the parents of those parents, and their parents as well, all the way to the root. That might be expensive.
That's the theory, though, but we've known for decades that it's impractical to try predict how software will perform. Instead, try to measure it.
While the OP suggest that significant data is involved, it doesn't state how much, and neither does it state the hardware specs of the system that's going to run the simulation. So, as Eric Lippert explains so well, the person who can best answer questions about performance is you.
P.S. It's my experience that when I start to encounter performance problems, I need to get creative with how I design my system. Efficient data structures can address many performance issues. This is just as much the case in OOP as it is in FP.
I am working on an RTS game and I want to be able to build structures, which means that a builder will walk to target location and, once there, start building.
I want to implement a statemachine in every unit where states can be added as the user gives input because this might come in handy later, when units guard position and stuff.
My question is: is it useful to create a statemachine for every individual, user-owned unit or is this a pitfall?
State machines are common in games.
A state machine is the usual approach for behavior of objects, NPCs, etc in games.
They are so commonly used that they are often supported by game engines: e.g.: Unity
A state machine pitfall might be resource consumption by a naive implementation, e.g. one employing a State Pattern, which is ok only if don't have relatively few state machines running at the same time, otherwise resource consumption of a State Pattern would be prohibitively high for thousand of concurrent state machines.
If you indeed intend to have thousands of individual state machines running at the same time, or need extreme efficiency, you will have to implement them with a simpler approaches: eg: nested switch statements or table based implementations examples in C.
Reasons for using State Machines, in general, not only in games.
The main reason for using state machines is modeling your problem with clarity: You can think about edge conditions visually, by drawing out the state machine, e.g. by using tools such as GraphViz or by hand.
It easier to see what would happen in which scenario, precisely.
Sometimes your problem "just calls" for a State Machine representation: it has "states", and complex behaviors, which depend on past events.
State machines have decades of computer science research behind them, and algorithms about analyzing them, simplifying them, etc are known.
If you try to model a state machine "by adding and removing IF statements", by hand, you will end up with messier code, which you won't be able to transform, model, etc.
On the "cons" side, if you use table based state machines, debugging them would be somewhat hard.
What happens in an UML state machine if the transition selection algorithm (TSA) finds two transitions that should both fire and the following holds true:
transition #1 ends directly in a state
transition #2 ends (intermediately) in a choice pseudostate
As both the transitions fire, they cannot be in conflict. Else they would not have been chosen by the TSA in the first place.
Now the following occurs:
As the choice is evaluated (after transition #2), it takes a path (transition) that would lead to the exit of an ancestor state of the source state of transition #2. Due to this exit of an ancestor state, a conflict with transition #1 occurs.
UML diagram showing such a situation
(improved according to the discussion with Thomas Kilian in comments to his (now deleted) answer)
... if Event_1 occurs and x < 0.
Questions
Is the state machine ill-formed or what is supposed to happen now?
Is it illegal for a transtions after a choice to exit a state? At least it doesn't play together well with the "transition execution sequence" (exit(s), transition behavior(s), enter(s)). As it would be exit, behavior, exit, behavior, enter(s) in that case. I could not find anything about that in the UML Superstructure Specification (chapter 15). But then everything about orthogonal regions is very vaguely described in that document...
Motivation
I am asking the question out of the perspective of a library implementer. So my focus is not on how to design this situation in a nicer manner. I need to figure out how to deal with this situation correctly (or I need to know that it is an illegal situation).
This is one reason why there is a "Precise Semantics of UML State Machine" at the OMG...
First, it is legal for most transitions to exit a state. There are a few restrictions in the UML spec, but none that would concern your design.
You should always have a single state that is potentially active within any state machine region. As it stand, you have an implicit region in your "StateMachine1" that contains both the "X" and"Y" states. This would mean that your state machine could be in both "StateMachine1::X" and "StateMachine1::Y" states at the same time! As you probalby already know, orthogonal states are there do deal with such a situation. Perhaps you need to bring "X" and "Y" within state StateMachine1::S' regions?
Also a warning that by default in UML, states have shallow history. This means that, as it stands, the initial transitons within StateMachine1::S' regions will only be taken once. If you try to get back into "S" (I know, you don't have a transition for that - just speculating), it will go back to the last states (one per region) before if left the state, which, after event1, would be "A" and "E".
It would be difficult to comment more without knowing what you are trying to model, but I hope this helps.
What is the interpretation of the following quoted sentences from UML Reference Manual?
When an orthogonal state is entered, the number of control threads
increases as a direct substate in each orthogonal region becomes
active.
When the orthogonal state is exited, the number of control
threads decreases.
This is a complex part of the UML spec. In the simplest case, when you enter a state containing orthogonal regions, the initial psuedo state in each orthogonal region essentially starts a separate thread of control. There are lots of complicated rules about how events are consumed by these threads and how the threads join back together.
But, according to a methodologist I highly recommend (H. S. Lahman), you really shouldn't use more than plain old Moore state machines. For more information on why one should use Moore state machines (which you can model perfectly well in UML) instead of Mealy or Harel state machines, please see this excerpt from Lahman's book. For more information on the difference between a Moore and a Mealy state machine, please see
this StackExchange question.
I need to know this differences in order to undestand how to use them right.
Which are the differences of DFD and Activity diagram?
Actually, it's reasonably logical. You only have to look at the names.
In data flow diagrams, the lines between "boxes" represent data that flows between components of a system. Because these only show the flow of data, they do not give an indication of sequencing.
In activity diagrams, those lines are simply transitions between activities and do not represent data flow at all. They more represent the sequencing of activities and decisions. You can tell from these what order things happen in.
That's a simplistic explanation but should be a good starting point. Further information can be garnered from Wikipedia for DFDs and activity diagrams.
Explicit bias: I'm a DFDs proponent.
#John is correct that Activity diagrams can be used to represent object flow. #pax equally correct they seldom are.
Two big DFD advantages for me:
Link to object model. Data stores on a DFD provide a really nice way to link the data produced / consumed to the object model. Very useful for consistency and ensuring your thinking is joined up.
They de-emphasise control flow. Far too often designs over-constrain sequencing. Activity diagrams do support concurrency - but it requires the user to (a) remember and (b) use it. So the default is over-serialisation. DFDs don't. They lay bare the real sequence dependencies without any extra effort on the part of the user. Consequently they also make it easier to see causal relationships. If processes a and b both require data input D then it's obvious on the diagram. And hence parallel activity is obvious.
Don't get me wrong - I'm not against Activity diags. Where control flow is the primary consideration I'll use an AD over a DFD. But empirically I'd say I find DFDs a more useful tool in ~70-80% of cases.
Of course, YMMV.
Just a humble opinion from someone who has had to explain processes, both computer and manual, to upper management and CIOs. I have found simple is better and pound-for-pound, DFDs get the message across when I am actually "asked" about details. That being said, the better approach is to always practice the story line and answer in simple answers.
One final comment regarding the age of tools and products. Remember that in most cases these are running the business and work pretty darn good. The adage "you break it (or replace it) and you own it" can make you a hero or make you into a clown.
We have a CIO who wants to replace all mainframe application for the simple reason that they are old technology. One must weigh the consequences and understand if the replacement can handle workload. Have you ever wondered why JPMC, Credit Swiss, Walmart, and Bank of America to name a few still run mainframes?
My apologies for taking it in that direction. Just make sure, whatever analysis tool is used, that all aspects of the replacement are documented including workload, I/O, concurrent users, adoption curve, and scalability.
Data Flow represents flow within one module or one independent code. However Sequence Diagram represents sequence of activity in between different modules.
Yes at some points they may pass the same messages.
I basically use Sequence diagram in interface documents which will be shared with other modules/elements, however DFD will be used in Low level design documents which will be used to develop the code within one module or network element.
If we look closer to a dataflow diagram, we can notice that when a node collects data from all its edges, it starts to process them. And to process, it needs an activity token, which represents access to a processor. Usually the process of obtaining that token is omitted, but it has to exist. Typically, the whole node as a token is put in a double-ended queue, where on the other end of that queue free activities (processors or threads) are stored. A thread pool is a perfect example of such a queue, and the nodes ready to work are represented as tasks. As soon as a node meets activity, they both are taken from the queue and actual processing starts. When processing finishes, activity is returned to the queue. This way we can think of activity as a special kind of token.
So both dataflow and activity diagrams are just simplified variants of a general active-data-flow diagram, with either activities or data tokens omitted. But generally, both kinds of tokens can be represented in a diagram simultaneously.
Programmers used to think about threads as activities, but if we look at them closer, we notice that when a thread is ready to execute, it gets in a line to processors, and real execution starts only when a free processor switch to that thread. This is absolute analogy as tasks are executed on a thread pool. So from simplified point of view, a thread is an activity, and from more rigorous point of view a thread is a data token and the only real activity is a physical processor. This shows that activity tokens are not different from data tokens. And indeed, we can omit the route of node chasing an activity and consider a dataflow node as an activity itself, which starts to work immediately when all its edges (inputs) contain data.