This generic behavior modeling exercise was brought to you by Chat bot.
So you are about to design the next hit .com like Google, Yahoo, Hexbot, Ebay. One of the keys to implementing a robust multi-user application is to fully understand it from a behavior modeling perspective. Moreover, you must decide how the system should behave.
What is behavior modeling?
Behavior modeling is when you think of your ideas in terms of states and transitions. This requires both identifying all of the interesting states of being that your software or its components are likely to be in. And also, at a high level, abstracting what events are likely to cause your software or its components to change between states of being. Confused yet? After you do a few examples you will quickly get the hang of this mental exercise.
Behavior modeling is also referred to as State modeling, State machines and State transition matrix.
Why model behavior?
"Behavior modeling is the minimal form of logical abstraction that fits nicely into how the human mind thinks and allows for one to understand complex systems and essentially increasing one’s own ability to solve difficult puzzles"
– Daniel Stephen Rule
Mentally modeling the behavior of your idea helps you to better understand how your system or its components will react to events.
Here are some reasons to master behavior modeling
- Prevent race conditions in your software.
- Avoid nebulous areas in your software development.
- Help you ask the right questions to your clients.
- It is a critical skill designing large-scale multi-user solutions.
Drawing behavior models
Although you should generally just do behavior modeling or any software design in your head, some times while learning how to behavior model, it helps to draw out the models in a diagram.
Components of drawn behavior models
For the state you simply draw a box with the name of the state inside of it. The name of the state should remind you of what state action occurs when that state is encountered.
Represent a transition by drawing an arrow from the start state to the destination state and note what event causes the state to change.
Here are some examples that demonstrate how to draw your behavior model. The objective here is to master behavior modeling in your head, but drawing them out first will help you get there.
Once the bullet is created it is out of the rifle. If the bullet has not been fired it can be put into the rifle. Once in the rifle it can be either taken back out by hand or fired.
Once the rifle is created its safety is off and it is unloaded. As long as the rifle is not being fired the safety can be pushed on and off freely. The rifle can also be loaded and unloaded freely as long as it is not firing. The rifle can only be fired when the safety is off and it is loaded. Once the rifle is fired it looses its bullet and becomes unloaded and the safety remains off until it is pushed on.
Scenario to try modeling yourself
Here is a simple scenario to try modeling yourself. First roughly identify the states and transitions. Then reread it and check your behavior model for correctness:
Jack wants you to design him a chat bot. He wants the chat bot to ignore people unless they either say “hello” or “what is this”, if they say “hello” the chat bot should say “hi I am a bot” back to them and then wait to see if they say “hello” again or if they say “what is this”. If they say “what is this” then the chat bot should say “I am a chat bot, do you know what that is?” and then after that ignore everything they say unless they say “yes” or “no”. If they say “yes” at that point then the chat bot should say “good I am glad you know” and then go back to waiting to see if they say “hello” or “what is this”, if they say “no” at that point then the chat bot should say “that is too bad” and go back to waiting for the chat bot to say “hello” or “what is this”.
Practice behavior modeling
You can practice behavior modeling on a chatbot at create hexbot and then adding states and transitions at train hexbot. Once you create your chat bot you can test out the state model with Chatbot! by chatting with your state model at chat hexbot.
Mastering behavior modeling
One exercise to master behavior modeling is to read your favorite novel and constantly break the information up into states and transitions in your head as you read.
How does behavior-modeling compare to OOP?
Behavior modeling is a way to think more clearly about problems. OOP is a collection of constructs commonly found in computer programming languages that are considered to be useful and called OOP. There are various formalized software analysis diagrams, which are considered to be useful when coding OOP; these include UML, xUML and Shlaer Mellor. Mastering behavior modeling is a prerequisite to using any of these methodologies. However, having behavior modeling under your belt alone is often sufficient to engineer most large-scale projects.
How do design patterns compare to behavior modeling?
Design patterns are commonly used data models with intended behavior. Often, design patterns will share very similar behavior models but have much different usage. Like behavior modeling, design patterns help computer programmers communicate architecture at a higher level. In contrast, behavior-modeling focuses on generically breaking up the software design into states and transitions whereas design patterns are data models that are reused across many different applications within the same manor. Hence the “pattern” in “design pattern". If you were to look at behavior modeling from a design patterns perspective you would have a fairly simple data model and some rules about state transitions. Here is what a coding implementation of behavior modeling would look like from a design patterns perspective:
State machine design pattern
The state machine design pattern consists of an object that maintains both a state transition matrix and a current state pointer. The state transition matrix is dimensioned with all possible events by all possible states. The state transition matrix holds a pointer to the next state for each possible state and event pair. When the object gets an event, it determines what the next state is given its current state and the logic imposed by the state transition matrix. It then re-points the current state pointer to the new state in the state transition matrix hence completing a transition.
This is one implementation. You could opt to not use a state transition matrix and just use if-then logic in your code to maintain the state machine. The behavior modeling and how you code it are two very different things. Behavior modeling is when you mentally break your problem up into states and transitions, how you code your state logic is entirely up to you. There were a number of tools in the 90’s and early 2000’s that converted high-level behavior model diagrams into the coded design patterns and generated code. There is now a state transition mechanism that you can use to design state machines concurrently while they are being tested with events, without any sort of boot time configuration or code generation (patent pending: Daniel Stephen Rule). It works a lot like an RDBMS however, instead of creating tables while users send SQL against them, it lets you create states and transitions concurrently while users send events against your behavior models causing transitions. An example of this technology is Hexbot.com. Thousands of users are creating behavior models for Hexbot.com’s mind data concurrently while users are sending events (chatting) to Hexbot.com invoking state transitions.