The reason to have the meta model is that IDL is not expressive enough to
express everything we want to express, such as preconditions and effects of
methods.
Ideally, if someone writes an IDL file, we should be able to read it in as a
model. People can the extend it to add the additional information, and then
we can save the whole thing as a mastermind application model. One drawback
with the current scheme is that we cannot just save the extensions the IDL
part as an IDL file, and the extensions as a separate file.
A possible scheme is that for the Application model we use the IDL syntax, and
we encode all the extensions as comments. So, things could look like this:
interface phone {
attribute line_attributes line;
boolean ok_to_switch (in line_mode switch_to);
boolean switch_to (in line_mode switch_to);
//% switch_to.precondition: self.ok_to_switch(switch_to);
//% switch_to.effects: self.line.status = switch_to;
}
So, if people load in the IDL, and extend it, we can save it as an IDL file
with comments. THis allows people to continue editing their IDL file in the
way they are used to. We can also save it as a mtf file.
Obviously, the mtf file is much easier to parse, and a LOT more verbose. But,
with a modified IDL parser we could do the above trick.
I think we can consider the modified IDL as an option. However, it seems to
me easier to work with mtf files initially. Yikes! this is a messy business.
Anyway, here is a modified mtf file for the phone example. I added
preconditions and effects (and lots of comments to explain what the additions
mean).
// Translation of JK phone.idl to Mastermind MTF syntax.
//
// Pedro Szekely, 1/6/95
//
{module
name pbx
{interface
name phone
exceptions
{exception
name invalid_number
fields
{field
name number
type string
}
}
{exception
name error
fields
{field
name number
type string
}
{field
name message_string
type string
}
}
{exception
name busy
fields
{field
name number
type string
}
{field
name caller_id
type string
}
}
{exception
name call_in_progress
fields
{field
name number
type string
}
{field
name caller_id
type string
}
{field
name outgoing
type boolean
}
}
{exception
name call_connected
fields
{field
name number
type string
}
{field
name caller_id
type string
}
}
{exception
name incoming_call
fields
{field
name number
type string
}
{field
name caller_id
type string
}
}
{exception
name call_forwarded
fields
{field
name from_number
type string
}
{field
name from_caller_id
type string
}
{field
name to_number
type string
}
{field
name to_caller_id
type string
}
}
enumerations
{enumeration
name line_mode
enum_ids "local" "long_distance" "internal"
}
{enumeration
name line_status
enum_ids "free" "to_be_used" "dialing" "in_use"
}
structures
{structure
name line_attributes
fields
{field
name mode
type @line_mode
}
{field
name status
type @line_status
}
}
attributes
{attribute
name line
type @line_attributes
}
methods
{method
name ok_to_switch
type boolean
parameters
{parameter
name switch_to
mode mode_in
type @line_mode
}
}
{method
name switch_to
type boolean
parameters
{parameter
tag p_switch_to
name switch_to
mode mode_in
type @line_mode
}
exceptions @error
// Here is an example of an extension to CORBA IDL.
// We model the preconditions to invoke a method.
preconditions
// It is ok to use invoke as a predicate provided that the
// method to be invoked returns a boolean. Otherwise it woul
// be necessary to use an equality or membership predicate to
// test the result of the method against another parameter.
{invoke
method @ok_to_switch
// self means the same object on which the switch_to method
// will be invoked.
object self
// We invoke the ok_to_switch method with the same argument
// that is about to be passed to the switch_to method.
//
// Note: Maybe the parser can be smart enough so that @switch_to
// would work, because even though the @switch_to reference is
// ambiguous, here we need a parameter and not a method.
parameters @p_switch_to
}
// Here is an example of an extension to CORBA IDL.
// We model the effects of a method.
effects
{assignment
// Here is an extra bit of syntax. The dot is used to refer to
the
// status field of line. We need to start with self to identify
the
// object that is to be changed. In general, the effect could
be on
// an object passed as a parameter, in which case the syntax
woould be
// @param_tag.attr.field
description "The line will be switched to the @p_switch_to mode."
left self.line.status
right @p_switch_to
}
}
{method
name dial_digit
type boolean
parameters
{parameter
name digit
mode mode_in
type string
}
exceptions @invalid_number @call_in_progress @error @busy
}
{method
name get_status
type boolean
exceptions @invalid_number @busy @call_in_progress @error
@call_connected @incoming_call
}
{method
name lift_handset
type boolean
exceptions @call_connected
}
{method
name hangup
type boolean
exceptions @call_connected @call_forwarded
}
}
Pedro Szekely
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292
Phone: 310/822-1511, Fax: 310/823-6714
URL: http://www.isi.edu/isd/HUMANOID-HOME.html