I have state diagram for an application, and one of the states should be duplicate.
can i duplicate the state in state diagram?
since it is necessary to be.
Related
Can you tell me please,what types of relationship are there present in state diagrams and how they are represented? There is a lot described about class diagrams, but relationships in state diagrams I can't find anywhere.
Thank you.
The basic relation is a Transition (p. 357 of UML 2.5)
A Transition represents an arc between exactly one source Vertex and exactly one Target vertex (the source and targets may be the same Vertex). It may form part of a compound transition, which takes the StateMachine from one steady State configuration to another, representing the full response of the StateMachine to an occurrence of an Event that triggered it.
Of course you can have Dependency and sometimes ObjectFlow. Others depending on context. UML allows to place anything in any diagram. So you could put in classes with associations and any other stuff as well (if it makes sense to the reader).
I'm starting to wonder what is the point of django-fsm?
I am working on a production management system. As an example, a transition from state INCEPTED (details being entered) to states IN_PRODUCTION (being manufactured) or RESOURCE_WAIT (some necessary input entity is not yet available). Establishing the details involves querying a considerable number of different models, and might come to involve asking questions of the user.
It seems unnatural to attempt to put querysets on other models into the model containing the state field. (It's causing me a circular import problem as well, which I don't know how to resolve).
So, I have written this transaction as a view instead, which also means that I can display a list of checks which were made, and their success/fail status. The issue of making sure that the transition is fully committed or not committed is easily handled via with transaction.atomic() so if anything goes wrong, nothing is committed to the DB.
Which leaves me wondering what I am missing. Why does django-fsm exist? It doesn't seem to fit into what I am trying to accomplish. Too low-level, or ....
There is a lot of talk about changing state especially in web development. I hear parts of a page connected to something in the back end that need to change state when new information is available. What does it mean when a part of the code changes its state? Is it becoming something else or are granular parts of it, attributes only, changing?
If you are familiar with Trello, would storing an entire Trello board as an actor (with akka persistence) be a good use case?
A trello board consists of:
lists
tasks in a list
each task can have comments and other properties
What are the general best practices or considerations when deciding if akka persistance is a good use case for a given problem set?
Any context where event sourcing is a good fit is a good fit for Akka Persistence.
Event sourcing, in turn, is generally applicable (note that nearly any DB you're using is event sourcing (with exceptionally frequent snapshotting, truncation of the event log, and purging of old snapshots)).
Event sourcing works really well when you want to explicitly model how entities in your domain change over time: you're effectively defining an algebra of changes. The richer (i.e. the further from just create/update) this model of change is, the more it's a fit for event sourcing. This modeling of change in turn facilitates letting other components of a system only update their state when needed.
Akka Persistence, especially when used with cluster sharding, lets you handle commands/requests without having to read from a DB on every command/request (basically, you'll read from the DB when bringing back an already persisted actor, but subsequent commands/requests (until such time as the actor passivates or dies) don't require such reads). The model of parent and child actors in Akka also tends to lead to a natural encoding of many-to-one relationships.
In the example of a trello board, I would probably have
each board be a persistent actor, which is parent to
lists, which are persistent actors and are each parents to
list items, which are also persistent actors
Depending on how much was under a list item, they might in turn have child persistent actors (for comments, etc.).
It's probably worth reading up on domain-driven design. While DDD doesn't require the actor model (nor vice versa), and neither of them requires event sourcing (nor vice versa), I and many others have found that they reinforce each other.
It mostly depends on how much write the app wants to perform.
Akka persistence is an approach to achieve very high write throughput while ensuring the persistence of the data, i.e., if the actor dies and data in memory is lost, it is fine because the write logs are persisted to disk.
If the persistence of the data is necessary, while very high write throughput is not required (imagine the app updates the Trello board 1 time per second), then it is totally fine to simply writing the data to external storage.
would storing an entire Trello board as an actor (with akka
persistence) be a good use case
I would say the size of the actor should match the size of an Aggregate Root. Making an entire board an Aggregate Root seems like a very bad choice. It means that all actions on that board are now serialized and none can happen concurrently. Why should changing description of card #1 conflicts with moving car #2 to a different category? Why should creating a new board category conflict with assigning card #3 to someone?
I mean, you could make an entire system a single actor and you wouldn't ever have to care about race conditions, but you'd also kill your scalability...
So I'm attempting to make a game using C++, and I've read a ton of articles on Finite State Machines (FSM), and Hierarchical State Machines (HSM). However I will admit most of the stuff I've read is a bit dense and hard to understand, so I was hoping someone can simplify it for me. Is this answer an FSM or an HSM?
From what I would like to clear up:
How is an HSM different from a normal FSM, and why is it better for games?
Regarding C++, How do you implement a basic HSM following the state pattern? (I might be incorrect on this/using the wrong words.)
How exactly do you handle transitions? What is the on_exit and on_enter method I keep hearing a lot about?
Do I need one HSM for my entire game? (e.g. Handling all enemies, player actions, game menus) or do I use multiple HSMs?
When implementing player entities, would they all be a subset of an Entity state?
Lastly if someone could give some pseudo-code to help visualize these questions, I would appreciate it.
It's just about nesting. An HSM is basically an FSM, but where each state in turn can be a separate FSM.
For an example in a game, consider an NPC. It has multiple states:
Walk to point A
Wait a minute
Walk to point B
Wait a minute
Continue from 1
Fighting with PC
This FSM is simple, but all states needs to have a transition to state 6 (Fighting with PC) for when the NPC is attacked by a PC. This makes the FSM kind of ugly. So instead lets have this much more simple FSM:
Walking about
Fighting with PC
This FSM is very simple, there's only two transitions, and it's easy to understand. The major parts of state 1 is then a secondary FSM:
Walk to point A
Wait a minute
Walk to point B
Wait a minute
If there's an event which doesn't match the secondary FSM transitions, like a PC attacking, you go up a level to the top-level FSM to match the event and find a suitable transition.
You could in a way think about it as a stack, each state in a higher level could push a new lower-level FSM. If there's an event that doesn't match any possible transitions, pop the stack and go back up a level. Continue until there's a matching transition.
In short, it's a way to simplify an FSM.