1. Overview
AUML features mainly include three components:
- AUML Text editing & checking;
- Sequence diagram & interaction table build-up;
- Model construction;
2. AUML Textual Notation Check:
2.1 Syntax Check
The syntax check logic is mainly inherited from standalone PDT tool. Here I summarize what kinds of error considered. An error will be alerted, if:
1) Any end of a message interaction is not an agent (a message should only associate with two agents.);
2) A percept/action interaction is not between agent/role and actor/environment;
3) The adjusting commands' argument is not a valid integer. For example, the command "agwidth+" must be followed by an integer parameter. If the parameter can not be parsed as an integer, an error will rise up. This is also true for other adjusting commands, such as "tagwidth+", "backup", "skip", "boxskip+", "offset+", etc.;
4) A line does not start with an eligible command, such as "agent", "actor", "message", "backup", etc.;
5) A short name is already used in former definition;
6) There is missing parameters, such as a declaration "agent shortname" without long name;
7) The "box" command has an illegal parameter (currently only support "par", "alt", "opt", "break" and "loop" 5 types);
8) The protocol name in AUML text does not match the name in Graphical Editor;
9) There is redundant parameter, such as "finish protocol" where the parameter "protocol" is redundant;
10) There is a short name which does not have a corresponding long name declared in this protocol;
11) The same reference is used by different crossing messages or "goto"/"label" commands;
12) The references of crossing message's start and end do not match each other;
*13) Commands "goto" and "label" do not appear in pairs;
*14) Commands "timestart" and "timeend" do not appear in pair;
*15) The cross message declaration "mes-" and "-sage" do not appear in pair;
*16) The "box" keeps open;
*17) There are no actors, agents, or environment defined in the protocol;
*18) There are no interactions defined in the protocol;
*#19) The agent/actor/environment is defined but never used in any interaction;
#20) The time constraint commands "timestart" "timeend"are nested;
#21) The long name is duplicated, which means user defines different short names for the same long name;
NOTE:
* From 13) to 19) above, the error can only be detected after parsing the whole AUML text. Therefore, they can not be used for real-time syntax check. Real-time syntax check means that every time user finishes a line, PDT performs the syntax check and gives error feedback if there is any.
# The rule is new-created in plug-in version PDT.
2.2 Design Consistency Check
Besides syntax, we need the following rule to perform further check to ensure the protocol is consistent with the other parts of the design:
22) If the entity name mismatches the entity type, for example, user declaration "agent shortname MessageA" where "MessageA" is actually a message existed in the design;
2.3 Commands Defined Differently from the Paper:
PDT implementation is slightly different from what is noted in the paper (Michael Winikoff. Defining syntax and providing tool support for agent uml using a textual notation. IJAOSE, 1(2):123-144, 2007..pdf)
2.3.1 backup line number
In PDT, user must indicate how many lines an interaction should be backed up.
2.3.2 skip line number
Similar to backup, user must indicate how many lines an interaction should be skipped.
2.3.3 boxskip+, interboxgap+, offset+
These 3 commands are not mentioned in the paper but implemented in the PDT plug-in.
The picture below shows their meaning:
2.3.4 Do not support inittagwidth+, but support tagwidth+
2.3.5 Do not support invis, but support environment/actor/percept/action
environment shortname longname is a declaration similar to actor declaration. PDT will draw a dashed-line box for actors and environment, but a solid-line box for agent and role.
To make the environment invisible, the long name must starts with "invis".
2.3.6 Percept & Action have bracket "<>" or "><". Messages have no bracket.
3. Sequence Diagram
Only if the AUML text passed all the checks above, the sequence diagram is constructed. Again, this is done with the standalone PDT source code.
4. Model Construction
Since PDT plug-in is re-modeled, so this part must be overwritten.
After the sequence diagram is done, the following changes in model will happen due to user-defined AUML text:
4.1 Create new entities (agent/actor/role/message/percept/action);
4.2 Create new relations (not included 3-tuple relation):
- Message->Agent;
- Agent -> Message;
- Agent -> Action;
- Role -> Action;
- Percept -> Agent;
- Percept -> Role;
- Protocol - Agent;
4.3 Propagate relations:
- Role's Agents -> Action: if an action is associated with a role in the AUML declaration, the action should be related to the role's agents;
- Percept -> Role's Agents: similar as above;
4.4 Propagate cells: create percept/message/action cells on agent's diagram;
4.5 On protocol property tab, refresh interaction table to show the updates (3-tuple relations inside a protocol are shown in this table);
* If the AUML text is modified, all the processes above should be updated to reflect the changes. But the relations between Action/Percept and Agent/Role must be modified manually since they may effect other roles or agents.
