O-MaSE is an agent-oriented analysis & design (AOAD) methodology.  I have found it to be a particularly powerful tool, in the development of project work, due to its flexibility of use and ability to handle single and multi-agent domains equally well.  For example, unlike many other methodologies (which I’ll leave nameless to avoid stoking any fires), O-MaSE is very adaptable to be easily slimmed down for smaller projects while having requirements and analysis support for quite complicated, multi-agent domains (e.g., RoboCup teams).  Additionally, O-MaSE’s initial requirement phases focus more on system goals, rather than agent goals.  In doing so, it is easier to model multi-agent domains without becoming prematurely bogged down in the details of which responsibilities belong to which agent.

As I’ve discussed this methodology, and resources for learning more about it, in a previous post, I’d like to instead share an example of how I’ve used it for a  proof-of-concept project I’m putting together as a stepping stone towards higher aspirations.  This first step in O-MaSE is goal modeling.  The methodology defines a goal as an overall function of the organization; a goal could be seen as a desirable situation or the objective of a computational process.  The “Model Goal” task focuses on transforming system requirements into goals and sub-goals represented as an AND/OR decomposition/goal tree.

An AND/OR goal tree is simply a class diagram where each class is stereotyped as “<< goal >>” and sub-goals are shown hierarchically.  It is an AND/OR tree because while some goals may require all of its sub-goals to be completed in order to be satisfied, other goals may only require one of its subgoals to be completed to be satisfied.  The UML relationship aggregation notation is used to note that all sub-goals must be satisfied to consider the parent goal satisfied, while the UML generalization (inheritance) notations is used to note that only one sub-goal must be satisfied.

It’s certainly easier to understand by looking at an example.  The proof-of-concept project that I’m working is an assisted capture the flag game.  The idea is that a mobile robot must follow a person to a particular room and search the room for a flag, then returning to its initial location to report the results.  Below is the AND/OR goal tree that I put together to represent the goals of the system, using Enterprise Architect.  (Click the image to see it full-size.)

As indicated, the overall system goal is “Find Flag.”  To achieve this, the goal is broken down again and again into sub-goals.  The level of granularity to which you take the decomposition is certainly subjective, but it should continue to be done until the decomposition process is no longer resulting in new information, or is beginning to express how goals are to be achieved.  Once you cross the threshhold of defining how the goals are to be achieved, rather then simply defining the goals themselves, you’re switching gears from goal-modeling to plan-modeling.  In fact, even in this example, the line between goals and plans becomes gray after the third tier; e.g., “Identify Person to Follow,” “Follow Person,” and “SLAM Path Taken” could be argued as being closer to plans than goals.  That was a clear indication to me that I had gone “far enough” and should now turn attentions towards analyzing plans for achieving the goals presented.

Billy McCafferty