I am working on a vending machine project and trying to build a state machine, as I saw from other examples. The machine that I am trying to build holds up to 100 dollars. And it takes nickel, dime and quarter. So, I should define about 2000 states one by one. How can I build an FSM in an easier way? I just want a suggestion to proceed.
Thanks :)
Why do you feel that every possible value of the machine's cash balance needs a separate state? That sounds like a poor use of a FSM.
Just use an integer register which holds the total balance of the machine, or separate registers which hold the number of various coins and bills and calculate the total from that.
States might be things like process payment, dispense item, or refund change. Not the balance of the machine.
Just because you have 2000 "states" doesn't mean you have to enumerate every single one of them in a case statement.
As others have mentioned, you need to store some of your state in counters.
Related
I'm trying to draw UML state diagram for vending machine, maybe its basic but im a beginner and havent found the appropriate solution on internet
Task: - the vending machine receives 1,2 and 5 $, the price of drink is 2 $
- it dispenses the drink if enough money is entered and refunds change
- machine has power on and power off)
I marked each state and transitions the numbers (STATES = s1,2 ..., TRANSITIONS = p1,2 ...), to make it easier to answer without drawing
(e.g. "p1 is wrong, there should be written this" etc)
Here is my diagram:
Questions:
Does it eventually return to IDLE - which seems to me more logical -
or it must go to the final state (rounded black point) as power off?
Or can there be two final states, so the S5 goes to another final state?
should it be after P3 or P4 maybe two branches?
maybe a new branch where the exact price amount is inserted (so there is no need for refund )
if so, where to put it?
If I understand the principle, on the arrows there should be written in this form - correct?
trigger event
[condition if it exists] /
action
Is there any basic errors I made?
Thanks in advance, I appreciate any feedback.
You can have as many finals as you need.
I'd make Dispensing an optional state after Waiting (for the > case) while the = case will directly go to selection. Just from a logical perspective. Of course you can make machines do dispense and change in parallel. In that case you need to fork to Dispense and Refund.
Correct
You should model Power off as Signal which can be triggered at any time. The power can be disconnected at any time during the machine is running, not just when it's idle.
I have a dataset consisting of calls going to agents (atually 10 of them) per day. These agents can either answer calls or transfer them to a call center. What we are interested in is whether each of these agents answers more calls than he transfers. In order to answer this, I have created a variable for each of these agents:
Answered/Transferred
I am using line graph to depict these variables per agent over time.
Now if this variable is less than 1 then this agent transferred more calls than he received. The problem now is that this is not a safe way to measure the overall impact of transferred calls. This is because the traffic pertaining to agents 1,2,3 is far greater than the one pertaining to agents 5,6,7 and so on. Therefore, I am trying to come up with a way to "weight" the variables I have created before. That is, somehow include the total number of calls reaching each agent (irrespectively of whether they are getting transferred or answered) in my calculations. That means that if an agent is getting 5 calls per day while another guy is getting 5.000 per day then I should find a way to depict this in my graphs.
Do you guys have any ideas?
Easiest would be to drag weight measure to colors and choose something like temperature diverging. Depending on your viz you can also drag weight measure to size, and for example, make bars or lines thicker to show there are more records there.
Say there is 5 bags of potatoes, when it hits two bags, an order is sent to the supplier automatically. Who/What is the actor?
Clearly you have an actor to watch the queue like this:
Even if the Potato Watcher is something implemented inside the SUC, it would be an actor on its own. You may drag it inside the SUC boundary. In a final implementation it might be a system task to poll a queue or a subscriber to the queue. But from the added value viewpoint it's just a simple actor to watch a queue and do something with it.
Since "an order is sent... automatically" the system is the actor. Assuming you are automating using software system.
However in real life it all goes wrong and businesses are far away from sending orders automatically.
Badgerbadger, you need to be carefull about statement "sent an order".
It is easy to overlook actual business process and previous subfunction-level answers are giving a nudge.
More realistic scenario is that the system is the actor who just initiates the check of stocks, maybe orchestrates. And then there is a complicated process of getting approval, finding budget, checking if goods are really required to be ordered and so on. In theory all of those can be automated, but usually in practice there is a work for human actor as well. Of course you may be lucky and avoid all of this.
Example of pessimistic scenario to consider:
It was eight bags, but now hits three. John just bought five bags from us, hooray!
System automatically places an order and pays for 10 more bags.
In ten minutes someone ordered one more.
System automatically places an order again and pays for 10 more bags.
We don't have enough money on account so we are facing overdraft.
At the same time regular inspection found that one bag is rotten.
System: 10 more bags please!
Our colleague just told us that we've missed 20% discount from supplier on simultaneous orders of 25+ bags which can be obtained only by calling a company manager.
John cancels his order in an hour after placing it.
Now we have 36 bags and a hole in our budget.
And our marketing manager just told us that the green bags system ordered are actually now selling with a discount, we are getting rid of them in favour of new line of blue bags.
You have to possibilities here:
Each time the stock is used the system checks if the condition to order is met and if yes then order it. As ordering will probably involve another actor (e.g. supplier's system), you might need to model it as a separate UC and use extend relationship. In this case you will not have any additional actor initiating the order, only the actor initiating stock usage.
The system checks on a regular basis what stocks reached the automated order level and make a single mass order. In this case you'll have to model Scheduler as an actor (in reality it's another system running on the server so it's fine to call it an actor). Some people prefer modelling such actor as "time" but it's discouraged.
In my event sourced application developed using DDD, there are saving accounts that should accumulate interest every day. At the end of every year the accumulated interest should be capitalized. My question is: Should every daily calculation really be treated as a domain event?
An alternative could be to calculate the accumulated interest at a given point in time on the read side by traversing the transactions that has happened on the account up until that day (withdrawals, deposits etc), and sum the accumulated interest for each day.
The amount of events in the event store would quickly grow to millions, given that there could be hundreds of thousands saving accounts in the system calculating their accumulated interest each day. But at the same time it seems like a drawback to have to calculate the accumulated interest "on the fly" on the read side instead of raising an event every day.
I'm no banking expert, but InterestCredited looks like the event you really want to store since it will change the state of the system.
Accumulated interest is a virtual concept if I understand correctly - modelling it as an event of its own adds no value. You would be able to calculate the capitalized interest at the end of the year anyways regardless of daily InterestAccumulated events being present. Instead, a simple read-side value recalculated each day seems to match the need pretty well.
Interest accumulation is only a domain event when it gets credited/debited to an account. Until that occurs it doesn't mutate aggregate state. Consider corrective events, posting errors (e.g an NSF credit reversal). You would need to correct for every daily incorrect interest calculation between the original and correction.
The read side can take care of rolling up accrued interest at whatever intervals desired.
Should every daily calculation really be treated as a domain event?
What do your domain experts say?
You might also want to review chapter 11 of the blue book, which includes "Example: Earning Interest with Accounts". That may not directly answer your question about the domain events, but it should provide you with some extra context for framing your own analysis.
I'm not a domain expert, but my expectation would be that accrued interest has implications, either legal, or in the model, and that you would expect to have a consistent record of the accrual and its consequences on your model.
From your initial description, the impact on the model is annual, so I would expect to see the InterestCapitalized event only once per year per account. But I find it difficult to believe that daily accrued interest doesn't matter, especially in the face of changing balances and compounding interest, so I'm suspicious that the described requirement actually matches the needs of the business.
I wouldn't expect "millions" of events to be that big a problem; using the CQRS pattern, most of your reads are going to come out of rolled up results anyway, so that's not a big deal. The real hurt will be in trying to re-hydrate an aggregate with millions of events; but if you are facing performance problems there, you can look into loading the aggregate from snapshots.
And of course, if each account is calculating its own accrued interest, then you are only looking at 365 (ish) extra events per year, which is no sweat at all.
I'm pretty new to Maximo and I have a question about how things should be handled. We have a project of integrating our ERP with Maximo using MIF interfaces. I'd like to know how you performed this in your company as I'm sure we're not the only one facing this challenges.
Let's go pretty simple about the Inventory. Receiving will be performed in our ERP and sent to Maximo. "Consumption" and inventory movements will be performed in Maximo and interfaced back to our ERP. so far so good, standard process.
However, there's a difference in the real inventory vs the inventory from a Financial perspective. As an example, we have let's say 3 cutters (same part number, different serial number). We have 2 in the internal storage and 1 in the machine where its being used. Once it is in the machine, it's known as "consumed" by finance. So from a finance point of view, there's only 2 in stock. From the tooling guy however, there's 3! The one in the machine can be taken out and replaced by one of the two others.
How are things like that handled in maximo? Any help, advices would be appreciated.
Regards
M.
It depends on how you plan to track on the individual level (track cutters by individual asset tags or serial numbers) or on the group level (3 cutters with the same item number)
If the cutter is treated as inventory and not as an asset, once it is issued then it is considered used. You can opt to use "Condition Code" and give each item a value from 0 to 100. Think of this value as depreciation. If a cutter is swapped out, then the new cutter (100%) is issued, and the replaced cutter is disposed of or returned to the shelf with a diminished value (e.g. 25%).