Starting Rose
After completing a Use Case specification for Agent-01, start Rational Rose. You can control toolbar contents with preference changes. You can also control font, diagram layout, component color, and window defaults with preference changes.
Use Case Diagram
In this class, all of your specification activities will take place in the “Use Case View.” While I encourage you to express aspects of your agents’ behaviors in other diagram types, the version of the framework we’re using ignores everything not in the Use Case View.
To begin working in the Use Case View, click on the + in the
Browser on the left and double-click “
Add an Actor
To begin specifying your agent’s behaviors, you’re going to have to add it to the model. To do this, simply click the Actor tool in the Toolbox and click somewhere in the Diagram Window. Name the actor “*Agent-01*”.
After adding and naming the actor that will correspond to Agent-01, you should see something like this…
Add New Use Cases
To complete the top-level Use Case Diagram, you must include the use cases required by the agent. To add Use Cases, simply click on the Use Case tool in the Toolbox and click somewhere in the Diagram Window.
Since we want to represent the main Use Case defined in our specification, we’ll re-name the 1st Use Case “Rotate to Follow Agent.” To make the agent’s behaviors as explicit as possible, we’ll also include a Use Case the represents the “Turnto Location” action primitive…
Add the 1st
Association
Use cases and actors must be associated with each other if the UML is going to represent actor/action relationships. To specify the associations that exist between components of the top-level Use Case Diagram, select the “Unidirectional Association” tool in the Toolbox, click the origin of the association, and drag to the destination of the association…
Add 2nd
Association
To specify the association between our main Use Case and the representation of the action primitive select the “Dependency or Instantiates” tool in the Toolbox, click the origin of the association, and drag to the destination of the association. This association indicates that our main Use Case depends on the “Turnto Location” primitive action.
Adjust Layout
After adding associations to the Use Case Diagram, you can ask Rose to “tidy up” the layout…
Drilling Down
While the main Use Case Diagram succinctly represents the agent’s behavior, code cannot be automatically generated from such a high-level description. More detailed information about the agent’s behavior is added to the UML model by developing a set of nested Statechart Diagrams within the agent. To begin specifying the main decision/action framework used by Agent-01, right-click on the actor and select the “New Statechart Diagram” sub-menu…
Add Start & Stop
States
This Statechart Diagram is simple; remember, all the agents developed in the class will be reactive. To specify Agent-01’s top-level control structure add:
1 Start State
1 State
1 End State
The Top Level Control
Structure
Add 2 State Transitions and change the State’s name to something like “Choose Action.” Your Diagram Window should look something like this…
Nested Control
Structures
While the top-level control structure shows that the agent will repeatedly transition from it’s start state to it’s end state by choosing an action, we still need to specify the agent at a greater level of detail if we want to automatically generate code. To add this additional detail to the UML diagram, we’re simply going to “drill down” into the “Choose Action” state and describe the just how Agent-01 will choose actions. To begin specifying the details of Choose Action, right-click on the state and select the “New Statechart Diagram” sub-menu…
Actual Behavioral Control
Structure
This Statechart Diagram is going to actually define Agent-01’s control structure. Agent-01 has only one behavior in it’s repertoire so the diagram is going to be simple. To specify Agent-01’s behavioral control structure add:
1 Start State
2 States
1 End State
The names you give to the 2 states should be meaningful and contain no spaces (they will be used during code generation and must therefore be legal Lisp symbols). Use names similar to the ones below…
Sensors
At this point, we’re going to start extending the UML via stereotypes. We want some of our states to represent percept assessments and others to represent action requests. To do this, we’re going to use 2 stereotypes; sensor and effector. Sensors will represent states in which percepts are assessed. Effectors will represent states in which actions are requested.
To change the stereotype of a state, double-click it in the Diagram Window and type or select the required stereotype. Here is a screenshot of the 1-rotate/follow state being assigned the sensor stereotype…
And here is a screenshot of the 1-turnto-location state being assigned the effector stereotype…
Specify 1st
Rule
Again, we’ve added more detail to Agent-01’s UML description. Again, we’ve not included enough detail to allow for code generation. To allow for code generation, we’re going to have to specify the details of Agent-01’s sensor and effector state. To begin specifying the details of 1-rotate/follow, right-click on the state and select the “New Statechart Diagram” sub-menu…
1st Rule
Details
This Statechart Diagram is going to actually define how 1-rotate/follow will allow Agent-01 to assess its percepts. To specify 1-rotate/follow add:
1 Start State
3 States
1 End State
4 State Transitions
Create a State Chart something similar to this…
Transition Guards
Remember, patterns of inference will be represented as Statechart Diagrams in our framework. In this case, we’re going to represent how Agent-01 transitions from a start state, to a state where it has acquired a target, to a state where it has determined the target’s location, to a state where it asserts the intention to turn-to the location of the target.
We’re going to use a statechart to represent one of our L3 behaviors…
Rotate
to Follow Inference
IF a target is found in FOV,
AND IF the
target's location can be determined,
THEN turn to the target's location.
To represent this behavior we’re going to add:
2 Transition Guards
1 State Enter Action
To add the 1st transition guard, double-click the
State Transition between the
Add the Guard Condition “(location ?target
?x ?y ?z)” to the State Transition between “Target Acquired” and “Location
Determined.”
Setting Up an Entry
Action
Since percepts can only be expanded through assertion, a guard is not going to be able to help us represent Agent-01’s intention to turn to the target’s location. To express this assertion, we’re going to insert an Enter Action into the “Turnto Requested” state. To do this, double-click on the “Turnto Requested” state, select the Actions tab, right-click in the Action List area of the window, and select the “Insert” menu…
The action being added defaults to the correct “Enter” type so don’t change anything.
To actually specify the action (in our case assertion), double-click the action and enter the assertion pattern in the Name field…
If & Then Stereotypes
To make the purpose of the sensor state explicit to the agent support software (to allow for code generation), we must assign stereotypes to the components of the sensor states internal statechart.
The 2 guarded states are if stereotyped…
while the state with the entry action is then stereotyped…
Specifying an Effector
The effector state is specified in greater detail just as the sensor state was…
Effector Details
Effector States are much simpler than sensor states. They essentially look through percepts for indications of desired actions and then make arrangements for commands to be uploaded to the agent in the testbed.
Create the following statechart…
Explicit Details of Effector
Next, change the stereotypes of the 2 states and insert an entry action into “Action Scheduled” so your statechart looks like this…
Since one of the states is if stereotyped, a guard must be provided. The specifics of this guard are left as an exercise. Remember, the L3 behavior we’re attempting to specify is:
Action
Execution Inference
IF agent has in it's percepts a predicate expressing
an intention
to turnto a location,
THEN upload the command "turnto-location"
Re-naming Things
& Additional Specification Information
While enough behavioral detail is present in Agent-01’s UML diagram at this point, automated code generation requires some additional information. This information makes explicit the roles of various components in the control structure and sensor/effector statecharts.
Do the following:
- Give sensor/effector state meaningful names (Rule1 & Rule2 for example).
- Assign a topology stereotype to the behavioral control structure.
- Assign a rule stereotype to sensor/effector states.
- Give Statemachine Specification meaningful names (1-rotate/follow & 1-turnto-location for example)
- Add documentation to sensor and effector Statemachine Specifications.
Code Generation
Once you’ve specified Agent-01 in Rose, save the .mdl file somewhere safe. From within Allegro Common Lisp, convert the Rose file into Lisp with the function r->t…
> (r->l “*Agent-01*”)
This will produce a Lisp file that can then be loaded into Lisp. Load it in now if you’ve not seen any code generation errors.
The Agent Inspector
When an agent is communicating with UT, it’s possible on Windows to use graphical agent inspectors. To graphically inspect an agent use the function inspect-agent…
> (inspect-agent “*Agent-01*”)
All of this information is available on Linux through the listener.
Working within the
Framework
This is how your final desktop might look. You can see the agent in the UT testbed. You can see the agent’s percepts in ACL. You can see a graphical representation of the agent’s control structure in ACL. You can interact with the agent, inspect its decision/action cycle and decide if you’ve achieved your desired behaviors…
