All Classes and Enumerations
The document is organized into the following major sections:
Derived from: Task
Inherited attributes: task_id, task_label, user_label, readable_description, goal_description, goal, task_parameters, pre_conditions, effects, is_optional, is_resumable, is_interruptible, possible_error_flags
An abstract task is a task which can be decomposed into subtasks.
A subtask can be one of the 4 task types: abstract, application,
interaction technique, or presentation task.
The abstract task class is a subclass of the Task class. The additional
information stored here has to do with subtasks.
- tasks
- type: Task
- multi valued: Yes
- inheritance: Prototype/Instance
A list of all subtasks by their labels.
- sequencing_order
- type: Task_Order
- inheritance: Prototype/Instance
The sequencing order in which the subtasks must be performed.
- loop_condition
- type: Expression
- inheritance: Prototype/Instance
Is this set of subtasks repeatable. If so, what are the
conditions which will terminate the loop.
Derived from: Task
Inherited attributes: task_id, task_label, user_label, readable_description, goal_description, goal, task_parameters, pre_conditions, effects, is_optional, is_resumable, is_interruptible, possible_error_flags
An application task stores information which MASTERMIND needs to invoke
a routine when it is appropriate. Basically, this is declarative
information about a routine and where it can be invoked (in which
application) by MASTERMIND.
- application_title
- type: String
- inheritance: Prototype/Instance
The application which has the routine as part of its code.
- routine_name
- type: String
- inheritance: Prototype/Instance
The name of the method which MASTERMIND will invoke
- routine_parameters
- type: Task_Parameter
- multi valued: Yes
- inheritance: Prototype/Instance
A list of parameters for this routine.
- designated_object
- type: String
- inheritance: Prototype/Instance
The label of a task parameter which will hold the pointer
to the object instance of which method must be invoked.
- server_name
- type: String
- inheritance: Prototype/Instance
I (Noi) think this field might be needed for a CORBA application.
Sub-classes: RGB_Color, HSV_Color, Named_Color
Color models colors of graphical objects. All colors must be
modeled as sub-classes of Color: RGB_Color, HSV_Color
and Named_Color.
Derived from: Visual_Parameter
Inherited attributes: label, documentation
- value
- type: Color
- inheritance: Prototype/Instance
conditionals allow the definition of presentations whose
appearance depends on the characteristics of the data to be displayed
(e.g., Email messages and voice messages in a messaging application),
on the characteristics of the platform (e.g., color display vs. black
and white), or on the characteristics of the interface at any given
moment (e.g., given a row of buttons, if the window is narrowed,
rather than truncating the row, some buttons become pull-down menus,
so that all commands remain accessible without scrolling).
A presentation can have several sequences of conditionals. Each
sequence act as a case statement, consisting of several conditional
clauses. MASTERMIND evaluates each conditional independently: it
evaluates the condition expression of each conditional in the
sequence until one returns true, and then uses the skeleton
associated with the specifications of the successful clause.
- condition
- type: Expression
- inheritance: Prototype/Instance
The condition is an expression that
depends on presentation or task parameters, guides and grids of the
containing presentation and its ancestors. When it is true, the
features of the Presentation specified in the skeleton of
each element of the specifications attribute are applied to the
presentation being constructed.
When MASTERMIND evaluates conditionals, it records the dependencies of
all the condition expressions it evaluates, so that if any of the
application data, guides or grids on which the predicates depend changes
value, MASTERMIND will re-evaluate the appropriate predicates,
re-apply the appropriate specifications, and update the display.
- specifications
- type: Specification
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
A conditional may affect several
components of the display, other than the presentation itself where
the conditional is stored. Each specification contains a
skeleton to be applied and a pointer to the presentation
where the specification has to be applied.
A point specifies a point to two dimensions.
- x
- type: Magnitude
The coordinate along the X axis.
- y
- type: Magnitude
The coordinate along the Y axis.
Derived from: Parameter
Inherited attributes: label, documentation
- value
- type: Data_Wrapper
- inheritance: Prototype/Instance
Derived from: Primitive_Parameter
Inherited attributes: label, documentation
- value
- type: Double
- inheritance: Prototype/Instance
Derived from: Task
Inherited attributes: task_id, task_label, user_label, readable_description, goal_description, goal, task_parameters, pre_conditions, effects, is_optional, is_resumable, is_interruptible, possible_error_flags
Error handling task contains a sequence of steps which altogether forms
a procedure to handle a particular error.
- error_flag
- type: String
- inheritance: Prototype/Instance
The error type which this procedure responds to.
- tasks
- type: Task
- multi valued: Yes
- inheritance: Prototype/Instance
A list of error handling subtasks.
- sequencing_order
- type: Task_Order
- inheritance: Prototype/Instance
The sequencing order in which the error handling subtasks
must be performed.
Fill_Style specifies the style for drawing the insides of filled
areas, such as rectangles and circles. The fill style supports the
specifications of simple parameters such as color, and an array of
very technical parameters, which most users will not need to specify.
- color
- type: Color
- inheritance: Prototype/Instance
The color of the fill.
- solid_style
- type: Fill_Solid_Style
- inheritance: Prototype/Instance
The fill can be solid, or defined using
a pattern in several different ways.
- poly_style
- type: Fill_Poly_Style
- inheritance: Prototype/Instance
Not documented yet.
- stipple
- type: String
- inheritance: Prototype/Instance
The name of a file that contains a bitmap
to be used to fill an area.
Derived from: Visual_Parameter
Inherited attributes: label, documentation
- value
- type: Fill_Style
- inheritance: Prototype/Instance
A Font is used to represent fonts for text objects.
- font
- type: String
- inheritance: Prototype/Instance
The name of the font, e.g., Helvetica.
- available_styles
- type: Font_Style
- multi valued: Yes
- inheritance: Prototype/Instance
The set of styles available for
this font. The value of this attribute must be a subset of all the
elements of the Font_Style enumeration.
- style
- type: Font_Style
- inheritance: Prototype/Instance
The particular style of this font (e.g., italic).
- size
- type: Magnitude
- inheritance: Prototype/Instance
The size of the font in points. Note: if on a
given platform the requested size is not available, and the system
will substitute another font.
- color
- type: Color
- inheritance: Prototype/Instance
The color of the font.
- underline
- type: Underline_Style
- inheritance: Prototype/Instance
Whether the text should be underlined.
Derived from: Visual_Parameter
Inherited attributes: label, documentation
- value
- type: Font
- inheritance: Prototype/Instance
A Grid is a set of parallel lines that span an area of the
display. Parts of a presentation can be snapped to grid lines to
define the layout. Grid lines in a parent presentation are visible in
the children of the presentation and their children and so on. This
allows deeply nested parts to be aligned with less nested parts.
- direction
- type: Direction
- inheritance: Prototype/Instance
Specified whether the grid is vertical of
horizontal.
- distance
- type: Magnitude
- inheritance: Prototype/Instance
The distance between gridlines. The
distance between two particular gridlines can be overriden explicitly
by specifying exceptions.
If the grid is stretchable, the distance specified here refers to
the distance when the grid is not stretched. The actual distance of
stretchable grids can vary at run-time depending on how much the grid
is stretched.
- num_lines
- type: Long
- inheritance: Prototype/Instance
The number of lines in the grid.
If the grid is not stretchable, then this attribute can be
ommitted, and the number of grid lines is computed based on the
start and end of the grid: as many gridlines are defined as
necessary to span the distance between start and end.
- start
- type: Magnitude
- inheritance: Prototype/Instance
The location of the first grid line. This
location can be a constant, or a Magnitude expression that
depends on a guide or application data of a presentation. Typically, the
expression is just a reference to a guide, which causes the grid to
start at the location of the guide.
If the grid is not stretchable, then this attribute can be
ommitted, and it will be computed based on the num_lines and
end attributes.
- end
- type: Magnitude
- inheritance: Prototype/Instance
The location of the last grid line.
If the grid is not stretchable, then this attribute can be
ommitted, and it will be computed based on the num_lines and
start attributes.
- stretchable
- type: Boolean
- inheritance: Prototype/Instance
A stretchable grid is one where the
distance between the gridlines will be adjusted so that the number of
grid lines specified in num_lines can be placed between
start and end. Space is proportionally divided between grid
spaces, taking into account the excpetions.
If the grid is not stretchable, the number of lines is adjusted.
- exceptions
- type: Grid_Exception
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
The exceptions allow the
specification of irregular grids, where the distance between
particular gridlines is different from the distance specified in the
distance attribute.
Grid_Exceptions are used to specify irregular grids. In
general, a grid is specified by defining the distance between any two
lines in the grid. With Grid_Exceptions it is possible to specify a
different distance for a particular pair of lines.
- index
- type: Long
- inheritance: Prototype/Instance
The index of the grid space for
which the exception is being defined. The first space has index 1.
- distance
- type: Magnitude
- inheritance: Prototype/Instance
The distance between the two
lines that define the gridspace.
Derived from: Layout_Parameter
Inherited attributes: label, documentation
- value
- type: Grid
- part/whole: Yes
- inheritance: Prototype/Instance
A guide is an invisible line used for aligning the parts of a
presentation. By default, all presentation have four guides
corresponding to their left, right, top and bottom. In addition, a
presentation can define as many additional guides as appropriate for
the type of presentation being defined. Layouts are often defined by
snapping guides to other guides or to grids.
Grids and guides are design time elements, i.e., they are used by
developers to define the layout of the display, but they don�t
appear in the final interface that the end-user sees. However, it is
possible to define tasks that manipulate the guide position, thus
giving the end-user a way to adjust the layout of the display.
The positions and margins of a guide can be defined using
Expressions that depend on other guides, on Grids, and on
Application_Data. These expressions allow the definition of layouts
that are dynamically updated when the values of the elements that the
expressions depend on change.
- direction
- type: Direction
- inheritance: Prototype/Instance
The direction of a guide specifies
whether the guide is horizontalor vertical. Currently oblique
directions are not supported.
- position
- type: Magnitude
- inheritance: Prototype/Instance
The position of a guide specifies the
offset from the left or top of the presentation where the guide is
defined.
- margin1
- type: Magnitude
- inheritance: Prototype/Instance
The margin1 specifies the left margin
for vertical guides, or the top margin for horizontal guides. The
margins are useful for defining gaps between objects.
- margin2
- type: Magnitude
- inheritance: Prototype/Instance
The margin2 specifies the right margin
for vertical guides, or the bottom margin for horizontal guides.
Derived from: Layout_Parameter
Inherited attributes: label, documentation
- value
- type: Guide
- part/whole: Yes
- inheritance: Prototype/Instance
Derived from: Color
HSV_Color models colors in the Hue/Saturation/Value format.
- hue
- type: Double
- inheritance: Prototype/Instance
A real number between 0 and 1.
- saturation
- type: Double
- inheritance: Prototype/Instance
A real number between 0 and 1.
- value
- type: Double
- inheritance: Prototype/Instance
A real number between 0 and 1.
An interaction sequence represents a graph structure of the
sequence in which terminal tasks must be performed by users.
This sequence contains not only interaction techniques, but also
system activities which occur in between user interactions,
for example, invocation of application methods or requests for
presentation tasks.
Designers can manipulate the interaction sequence separately
from the task tree with which it is associated. Designers specify a
sequence of terminal tasks which fits a particular desired interface style.
However, violations of the original sequence specified in the
task trees will be flagged (and prevented???).
- begin_node
- type: Task_Node
The beginning of the graph.
- end_node
- type: Task_Node
- multi valued: Yes
The tail(s) of the graph.
Derived from: Task
Inherited attributes: task_id, task_label, user_label, readable_description, goal_description, goal, task_parameters, pre_conditions, effects, is_optional, is_resumable, is_interruptible, possible_error_flags
Interaction techniques will contain parameters which are necessary to
pass information on to the actual executable primitives in the underlying
toolkits. In this case, it is Amulet. This object will be furnished
in the next version.
Derived from: Parameter
Inherited attributes: label, documentation
Sub-classes: Guide_Parameter, Grid_Parameter
Line_Style specifies the style for drawing lines, such as color,
thickness, and an array of very technical parameters, which most users
will not need to specify.
- thickness
- type: Magnitude
- inheritance: Prototype/Instance
An integer that specifies the thickness
of the line.
- color
- type: Color
- inheritance: Prototype/Instance
The color of the line.
- cap_style
- type: Line_Cap_Style
- inheritance: Prototype/Instance
How the end-points of the line look. This
parameter is relevent for thick lines.
- join_style
- type: Line_Join_Style
- inheritance: Prototype/Instance
How the elbows of polylines look.
- solid_style
- type: Line_Solid_Style
- inheritance: Prototype/Instance
Whether the line is solid, dashed,
dotted, etc.
- dash_specification
- type: Long
- multi valued: Yes
- inheritance: Prototype/Instance
Allows the specification of new
dash patterns, by specifying the lengths of the line segments and the
gaps as a sequence of numbers.
Derived from: Visual_Parameter
Inherited attributes: label, documentation
- value
- type: Line_Style
- inheritance: Prototype/Instance
Derived from: Primitive_Parameter
Inherited attributes: label, documentation
- value
- type: Long
- inheritance: Prototype/Instance
Not documented yet.
A magnitude is used to represent things like the width, height and
other magnitudes used in modeling presentations.
Currently a magnitude is simply a real number, but we expect to extend this
concept to include additional information, such as stretchability. This
information will be used to define the behavior of layouts the during
negotiations that can take place for dividing up screen space between
multiple parts.
- value
- type: Double
The value is a real number.
- units
- type: Magnitude_Unit
Derived from: Visual_Parameter
Inherited attributes: label, documentation
- value
- type: Magnitude
- part/whole: Yes
- inheritance: Prototype/Instance
Derived from: Color
Named_Color models colors by giving their name. Note: this
method of modeling colors might be machine dependent.
- name
- type: String
- inheritance: Prototype/Instance
Sub-classes: Visual_Parameter, Layout_Parameter, Primitive_Parameter, Data_Parameter, Task_Parameter
Parameters are used to specify information to control the
appearance of presentations and the behavior of tasks. See definition
of the sub-classes of Parameter for more information.
- label
- type: String
- inheritance: Prototype/Instance
The label is the string that is used to show
the parameter name in the development environment.
- documentation
- type: String
- inheritance: Prototype/Instance
The documentation is a string that
specifies what the parameter is used for.
A presentation defines a component of a display. Presentations
can be composed hierarchically through the parts attribute.
A presentation has a name, and a prototype presentation from which the
newly defined presentation inherits information (defined via the
is_like link).
In addition, a presentation has parameters to define its visual
appearance (visual_parameters), its layout
(layout_parameters), options (primitive_parameters) and
parameters that define the application data to be presented
(data_parameters).
The replications are used to specify whether a presentation that
is used as a part of another presentation should be replicated many
times, in order to present variable amounts of data. The
conditionals specify alternative ways of adjusting a presentation
depending on the current context.
- visual_parameters
- type: Visual_Parameter
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
The visual parameters are used to
specify the visual appearance of a presentation. The values of these
parameters can be fonts, colors, etc. (see definition of
Visual_Parameter).
- layout_parameters
- type: Layout_Parameter
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
The layout parameters are used to
specify the layout of a presentation. The values of these parameters
can be Guides and Grids.
- primitive_parameters
- type: Primitive_Parameter
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
The primitive parameters are
used to specify various options of a presentation whose values are
primtive values such as integers, strings, booleans, etc. (see
definition of Primitive_Parameter).
- data_parameters
- type: Data_Parameter
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
The data parameters are used to
specify the data to be displayed in a presentation.
- point_list
- type: Coordinate
- multi valued: Yes
- inheritance: Prototype/Instance
- parts
- type: Presentation
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
The parts of a presentation are other
presentations, so that presentations are defined as a hierarchy of
presentations.
- replications
- type: Replication
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
A sequence of replications, each
(if any) corresponding to a different part of the presentation,
defining a replication for these parts (see documentation on
Replication).
- conditionals
- type: Collection
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
The conditionals support the
specification of alternative presentations depending on
characteristics of the data being displayed, or on characteristics of
the display, such as the amount of space available. Conditionals can
override any element of the specification where they appear (e.g., the
position of grids, the prototype for a part), and can also add and
remove parts.
Derived from: Task
Inherited attributes: task_id, task_label, user_label, readable_description, goal_description, goal, task_parameters, pre_conditions, effects, is_optional, is_resumable, is_interruptible, possible_error_flags
A presentation task is a task (or group of tasks) which makes
something happen in an interface to an application. What this task will
represent will be the kind of expression which will trigger changes
in an interface. Currently, this expression has not been determined
yet. This task will be refined in a later version.
Derived from: Parameter
Inherited attributes: label, documentation
Sub-classes: Long_Parameter, Double_Parameter, String_Parameter
Derived from: Color
RGB_Color models colors in the Red/Green/Blue format.
- red
- type: Double
- inheritance: Prototype/Instance
A real number between 0 and 1.
- green
- type: Double
- inheritance: Prototype/Instance
A real number between 0 and 1.
- blue
- type: Double
- inheritance: Prototype/Instance
A real number between 0 and 1.
References provide a convenient way for specifying the layout
for replicated parts by specifying that the replications should fill a
grid, or by specifying that the replications should be laid out
according to some other replication which is already laid out (e.g.,
specifying that an icon should be placed to the right of every other
element of a list).
It is possible to specify multiple references in a replication
object. A common case is to use two references, containing a vertical
and a horizontal grid. The effect is that elements are laid out in
rows according to the vertical grid. When the columns in the vertical
grid are exhausted, the next row in the horizontal grid is used. In
general, the use of multiple references supports the specification of
a large variety of layouts.
- grid_reference
- type: Grid
- inheritance: Prototype/Instance
Specifies the grid on which the
layout is based. The set of parts will be placed on the grid lines
according to end_condition and init_procedure attributes.
- replication_reference
- type: Replication
- inheritance: Prototype/Instance
Specifies that the set of
parts should be laid out according to the parts of another replication
(e.g., to the right of each part in the other replication).
- init_index
- type: Long
- inheritance: Prototype/Instance
The init_index specifies which grid
line or replication element should be used to place the first element
in this reference, which by default is the first one.
- end_condition
- type: Expression
- inheritance: Prototype/Instance
The end_condition specifies when
to stop using this reference for placing objects (e.g., when reaching
the last column in a vertical grid).
- init_procedure
- type: Expression
- inheritance: Prototype/Instance
The init_procedure is an
advanced feature that provides more flexibility for specifying the
init_index by allowing a procedure to be called, rather than
always using the same init_index.
Replications are used to model presentations of
collections. When combined with the conditional construct,
replications can be used to specify the presentation of heterogeneous
collections of information.
- replicated_part
- type: Presentation
- inheritance: Prototype/Instance
Part to which the replication
applies. The part belongs to the same presentation that contains the
replication.
- data_sequence
- type: Data_Parameter
- part/whole: Yes
- inheritance: Prototype/Instance
The data_sequence is a parameter
whose value is the collection of elements to be displayed. Typically
this value is computed with an expression that invokes an application
routine (e.g., a routine that extracts from a mailbox object the
collection of messages it contains).
- references
- type: Reference
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
The references specify how to lay
out the multiple replicas of the part using grids or using other parts
as a reference.
- anchor
- type: Presentation
- part/whole: Yes
- inheritance: Prototype/Instance
The anchor and generic provide an
alternative to references for specifying the layout of replicated
parts. This mechanism is used for layouts that cannot be defined
appropriately in terms of grids or other replications. The basic idea
is to define the layout by defining the position of the first element
(anchor), and then defining the position of the nth element (generic)
based in the position of the nth minus one element (generic). The
anchor is a presentation skeleton that defines how the first replica
should be laid out. Typically the skeleton presentation only contains
definitions for two guides (e.g., left and top), in terms of guides
and grids of the parents. The generic is a list of presentation
skeletons that defines how all the other elements are laid
out. Typically two generic presentations are defined, corresponding to
the nth (n) and nth minus one (n-1) replicas. Expressions for guides
in the nth presentation define the layout with respect to the guides
for the n-1 presentation. More than two generic presentations can be
defined to define layouts that depend on the n-1, n-2,
etc. replications.
- generics
- type: Presentation
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
See documentation on anchor.
- on_demand
- type: Boolean
- inheritance: Prototype/Instance
The on_demand attribute specifies
whether all replicas of the part should be generated in advance, or
only as needed. This attribute gives developers the flexibility to
define presentations where all elements of a collection are displayed
at once (e.g., in a scrollable window), or presentations where the
display of the elements is constructed incrementally (e.g., a display
composed of multiple pages, where pages are added only as needed).
- conditionals
- type: Collection
- multi valued: Yes
- part/whole: Yes
- inheritance: Prototype/Instance
This attribute is used to specify that
each element of the replication is a conditional part (the elements of
the replication can use different presentations), as opposed to first
define a conditional for a part, and then replicate the part (all
elements of the replication use the same presentation). To get the
latter effect, place the conditional in the containing presentation of
the conditional part
- where
- type: Presentation
- inheritance: Prototype/Instance
Where specifies the part of the display to
which the Specification is to be applied.
- skeleton
- type: Presentation
- inheritance: Prototype/Instance
The skeleton is a partially
filled in presentation. When the corresponding conditional is
true, all the attributes filled in in the skeleton are
applied to the presentation beign constructed.
Derived from: Primitive_Parameter
Inherited attributes: label, documentation
- value
- type: String
- inheritance: Prototype/Instance
Sub-classes: Abstract_Task, Error_Handling_Task, Application_Task, Presentation_Task, Interaction_Technique
A task holds a definition and conditions of a step which must be performed
(by the user, by the application, or by the user interface). There are 5
different kinds of tasks MASTERMIND recognizes. Those in italic are
terminal task types.
- Abstract Task
- Error Handling Task
- Application Task
- Presentation Task
- Interaction Technique
The Task object as defined
here captures common attributes shared among different kind of tasks.
Instances of this class should never be created. (The Task object is
similar to a pure virtual class in C++ and instances cannot be instantiated
from a pure virtual class.)
Below are groups of task parameters
ID, labels and descriptions: task_id, task_label, user_label
Goal : goal_description, goal
Conditions and Effects : pre_conditions, effects
Flags for runtime behavior : is_optional, is_interruptible, is_resumable
(The behavior descriptions apply only when the flags are set.)
Error handling : possible_error_flags
- task_id
- type: String
- inheritance: Prototype/Instance
A unique task identification generated by MASTERMIND
- task_label
- type: String
- inheritance: Prototype/Instance
The label of the task as defined by designer
- user_label
- type: String
- inheritance: Prototype/Instance
The label of this task which is used mainly
when it appears to users in the user interface.
Note that this name is not used internally so
it can have spaces in the name.
- readable_description
- type: String
- inheritance: Prototype/Instance
A verbal description of what this task means,
what it's for, etc. This is for documentation
purposes only. No reasoning is done on this
attribute. This description eventually might
be used for help purposes.
- goal_description
- type: String
- inheritance: Prototype/Instance
A verbal description of the goal statement of this task
- goal
- type: Expression
- inheritance: Prototype/Instance
A systematic description of the goal if the system needs
to check and make sure that the goal is satisfied.
- task_parameters
- type: Task_Parameter
- multi valued: Yes
- inheritance: Prototype/Instance
A set of parameters of this task.
- pre_conditions
- type: Expression
- inheritance: Prototype/Instance
Conditions which must be satisfied before this
task can be performed.
- effects
- type: Expression
- inheritance: Prototype/Instance
Conditions which will be true after the task is performed
- is_optional
- type: Boolean
- inheritance: Prototype/Instance
This task is only optional and does not have to be
performed in the seqeunce in which it is defined.
- is_resumable
- type: Boolean
- inheritance: Prototype/Instance
Once this task is interrupted, it can be resumed.
- is_interruptible
- type: Boolean
- inheritance: Prototype/Instance
This task can be interrupted
- possible_error_flags
- type: String
- multi valued: Yes
- inheritance: Prototype/Instance
Labels of error types which can be generated by thi task.
These flag labels are used by error handling tasks.
An edge links two nodes together. It also has pointers to tasks
in the sequence in which their pre-conditions must be evaluated and
satisfied before interaction can proceed to the next task.
- before_node
- type: Task_Node
The node leading to this edge.
- after_node
- type: Task_Node
The node this edge leads to.
- check_conditions_with
- type: Task
- multi valued: Yes
This is the place where this edge points to
one or more tasks. The pre-conditions of these
tasks must be satisfied before the system can assume
proceedings to the next task. Pre-conditions of these
tasks must be evaluated in the order in which they
are specified in this sequence.
A task node is a node in the interaction graph structure which points
to an instance of a task it represents.
- in_nodes
- type: Task_Edge
- multi valued: Yes
Connections from all edges coming in to this node.
- out_nodes
- type: Task_Edge
- multi valued: Yes
Connections to all edges going out of this node.
- task_id
- type: Task
The task this node is pointing to.
Derived from: Parameter
Inherited attributes: label, documentation
A task may be defined with parameters. The parameter object holds the definition
of a parameter.
- type
- type: String
The type of the parameter
- mode
- type: Task_Parameter_Mode
One of the values defined in Task_Parameter_Mode
Derived from: Parameter
Inherited attributes: label, documentation
Sub-classes: Color_Parameter, Line_Style_Parameter, Fill_Style_Parameter, Font_Parameter, Magnitude_Parameter
This object models arrays in IDL. Arrays have a type specification
and a dimension specification. Dimensions are specified as a
sequence of short's.
- element_type
- type: idl_type
The type of the array. Once again we just use an object
of type idl_type to model the type.
- dimensions
- type: Short
- multi valued: Yes
A sequence of short values, which specify the various
dimensions of the array. A dimension with a value of -1
indicates the dimension is not being used.
Derived from: idl_field
Inherited attributes: name, type
Models attributes in IDL. Attributes in IDL have a name, a type
specification, and an optional attribute specifying if the
attribute is readonly or read-write.
- is_readonly
- type: Boolean
Is this attribute readonly or read-write.
Constants in IDL have names, types, and values. A constant in IDL
can only be of a primitive type.
- name
- type: String
The name of the constant.
- type
- type: idl_type_enum
The type of the constant. Since the type can only be a
primitive type, it is enough to just have an enumeration
here. Hence we use an object of type idl_type_enum.
- value
- type: idl_value_or_type
The value is being stored in an object of type
value_or_type
Models enumerations in IDL. An enumeration has a name and a
sequence of enum_value objects.
- name
- type: String
The name of the enumeration.
- enum_ids
- type: idl_enum_value
- multi valued: Yes
Sequence of enum_value objects. Each object represents
an enumeration.
This object models a single value in an enumeration. A sequence
of such objects is used to model enumerations in IDL.
- name
- type: String
The name of the enumeration.
- value
- type: Short
The value of the enumeration.
Models exceptions in IDL. Exceptions in IDL can have data members
too. Hence we have a name and a sequence of idl_field objects.
- name
- type: String
The name of the exception.
- fields
- type: idl_field
- multi valued: Yes
Sequence of idl_field objects which comprise the
data members of an exception.
Sub-classes: idl_attribute
A field has a name and a type. The type of the field is modelled
using the object idl_type defined above. The name of a field
is just a string.
- name
- type: String
The name of the field.
- type
- type: idl_type
The type of the field.
This object models interfaces in IDL. Interfaces in IDL are similar
to class definitions in C++ without definitions for methods.
Although, interfaces in IDL can define attributes, the IDL
compiler does not generate any storage for them. Both attribute
and method declarations are used to define the interface that
can be used to manipulate instances of the interfaces. Instances
in IDL can also contain definitions of constants, typedefs,
enumerations, structs, and exceptions. This object just contains
sequences of objects of the respective types.
- name
- type: String
The name of the interface.
- typedefs
- type: idl_typedef
- multi valued: Yes
The types defined in the interface. Sequence of
idl_typedef objects.
- constants
- type: idl_constant
- multi valued: Yes
The constants defined in the interface. Sequence of
idl_constant objects.
- enums
- type: idl_enum
- multi valued: Yes
The enumerations defined in the interface. Sequence of
idl_enum objects.
- structs
- type: idl_struct
- multi valued: Yes
The structs defined in the interface. Sequence of
idl_struct objects.
- attributes
- type: idl_attribute
- multi valued: Yes
The attributes defined in the interface. Sequence of
idl_attribute objects.
- exceptions
- type: idl_exception
- multi valued: Yes
The exceptions defined in the interface. Sequence of
idl_exception objects.
- methods
- type: idl_method
- multi valued: Yes
The methods defined in the interface. Sequence of
idl_method objects.
Methods in IDL have a name, a return type, an ordered sequence
of parameters, and a sequence of exceptions. The mastermind
extension to IDL methods adds preconditions, and effects to methods.
- name
- type: String
The name of the method.
- return_value
- type: idl_type
The type of the return value. An object of type
idl_type.
- parameters
- type: idl_parameter
- multi valued: Yes
An ordered sequence of objects of type idl_parameter.
- exceptions
- type: idl_exception
- multi valued: Yes
A sequence of objects of type idl_exception. These
define the exceptions that a method can raise.
- pre_condition
- type: mastermind_precondition
A expression which defines the pre condition for a method.
It is still not clear what the structure for this will be
like.
- effects
- type: mastermind_effect
- multi valued: Yes
Another expression which defines the effects of a method
invocation. Again the structure of this is not clear.
This object models modules in IDL. An IDL module defines a namespace.
Modules can consist of typedefs, constants, enumerations, structs,
interfaces, exceptions and other modules. This object just contains
sequences of objects of the respective type.
- name
- type: String
The name of the module.
- typedefs
- type: idl_typedef
- multi valued: Yes
The types defined in the module. Sequence of
idl_typedef objects.
- constants
- type: idl_constant
- multi valued: Yes
The constants defined in the module. Sequence of
idl_constant objects.
- enums
- type: idl_enum
- multi valued: Yes
The enumerations defined in the module. Sequence of
idl_enum objects.
- structs
- type: idl_struct
- multi valued: Yes
The structs defined in the module. Sequence of
idl_struct objects.
- interfaces
- type: idl_interface
- multi valued: Yes
The interfaces defined in the module. Sequence of
idl_interface objects.
- exceptions
- type: idl_exception
- multi valued: Yes
The exceptions defined in the module. Sequence of
idl_exception objects.
- modules
- type: idl_module
- multi valued: Yes
The modules defined in the module. Sequence of
idl_module objects.
This object models, parameters in IDL. Parameters have name, type
and mode.
- name
- type: String
The name of the parameter.
- type
- type: idl_type
The type of the parameter.
- mode
- type: idl_mode
The mode of the parameter.
Models sequences in IDL. Sequences in IDL have a type, and a size.
The size determines the bound of the sequence. The sequence is
unbounded if the size is -1.
- element_type
- type: idl_type
The type of the sequence. This is an object of type
idl_type. Since, idl_type contains the object
idl_value_or_type, which in turn contains references
to objects of type idl_sequence, modelling
recursive sequences is not a problem.
- number_of_elements
- type: Short
The maximum size of this sequence. The sequence is
unbounded, if the size is -1.
Models structures in IDL. Structures have a name and a sequence
of idl_field objects.
- name
- type: String
The name of the structure.
- fields
- type: idl_field
- multi valued: Yes
Sequence of idl_field objects. Each object represents
a field in a structure.
This object models a single member of a IDL union. Since IDL unions
represent the discriminator explicitly, each member of the union
has a variable, a type specification for the variable, and a value
for the discriminator when this variable is to be used.
- discriminator_ids
- type: idl_value_or_type
- multi valued: Yes
A sequence of values representing the values that the
discriminator may take on to select this union member.
- element_name
- type: String
The name of the variable for this union member.
- element_type
- type: idl_type
Type specification for the variable of this union member
The objects defined above are brought together in this object. This
object can model any type that can be defined in the IDL language.
- type
- type: idl_type_enum
The IDL type we are dealing with. This variable will contain
a value from the enumeration.
- value
- type: idl_value_or_type
More information about the type, if we need it. The name
value is partly incorrect.
Models type defines in IDL. A type define has a type, and a name.
- name
- type: String
The name of the typedef.
- type
- type: idl_type
The type that is being defined.
This object models unions in IDL. Unions in IDL have a name, a
discriminator, and a sequence of objects of type idl_triple.
- name
- type: String
The name of the IDL union.
- discriminator_type
- type: String
The type of the discriminator for this union. Once again
we use names instead of an object if type idl_type so
that the definition of the discriminator can be changed
independently.
- cases
- type: idl_triple
- multi valued: Yes
Sequence of objects of type idl_triple.
This structure is used to store the value in the case of primitive
types, and more information about the type itself in the case of
non-primitive types. For example, in the case of a structure,
the name of the structure is stored, and in the case of sequences
information about the type of the sequence is stored. This together
with the enumeration above can be used to model any IDL type. See
the object idl_type for more information. Since the attribute
of primitive types is straight forward, only non-primitive types
are described below.
- value_short
- type: Short
- value_long
- type: Long
- value_ushort
- type: Unsigned_Short
- value_ulong
- type: Unsigned_Long
- value_float
- type: Double
- value_double
- type: Double
- value_boolean
- type: Boolean
- value_char
- type: Char
- value_octet
- type: Octet
- value_any
- type: Long
- value_string
- type: String
- info_enum
- type: String
Contains the name of the enumeration. Names are used so that
any changes to the definition of the enumeration can take
place without any knowledge of the places it is being
used.
- info_union
- type: String
The name of the union is stored.
- info_struct
- type: String
The name of the structure is stored.
- info_sequence
- type: idl_sequence
In this case, just storing the name will not help, since
the sequence can be nested. But, since sequences are
always anonymous, the update problem discussed above is
not a problem here. This variable is of type
idl_sequence.
The object idl_sequence (discussed below) can model
nested sequences to any depth.
- info_array
- type: idl_array
Once again, just storing names will not help. And once again
since arrays are anonymous, we don't have any update problems.
The type of this variable is idl_array. The object
idl_array is discussed below.
- assignment
- type: String
- predicate
- type: String
A Direction is used to specify the direction of Guides and Grids.
Values
- Horizontal
- Vertical
Values
- Even_Odd
- Winding
Values
- Solid_Fill
- Tiled
- Stippled
- Opaque_Stippled
Font_Style specifies styles of a font used to display text.
Values
- Regular
- Font without any styles applied to it.
- Bold
- Boldface style.
- Italic
- Italic style.
- Bold_Italic
- Bold and italic style.
Guide_Type specifies the constraints that can be defined on a
Guide and the operations that can be performed on it accordingly.
Values
- Input
- Used to declare that a guide can only be constrained to guides
outside the containing part of the guide. In reusable components the input
guides are used to position the component in a display.
- Fixed
- Indicates that a guide is already constrained to inner guides
of the containing part.
- Adjustable
- Non-constrained, non-input guide.
Values
- Not_Last
- Butt
- Cap_Round
- Projecting
Values
- Miter
- Join_Round
- Bevel
Values
- Solid_Line
- On_Off_Dash
- Double_Dash
Magnitudes can be specified in a variety of units.
Mastermind will make the best effort to make the sizes of
the elements on the screen match the measurements specified.
Values
- Pixel
- Screen pixels
- Pica
- A pica is equal to ??? inches
- Point
- A point is equal to ??? inches
- Cm
- A centimeter is equal to ??? inches
- Inch
- An inch is equal to 2.54 cm, ??? points
The sequencing order of the subtasks. When subtasks are specified for
a task, their sequencing order needs to be specified.
Values
- sequential
- The subtasks must be done one at a time in the order specified.
- alternatives
- Each subtask is an alternative of the other tasks.
- unrestricted_one_a_time
- The order in which subtasks are performed is not important,
but each subtask must be performed one at a time.
- unrestricted_parallel
- The order in which subtasks are performed is not important
and subtasks must occure simultaneously.
- unrestricted_can_be_parallel
- The order in which subtasks are performed is not important
and subtasks may bne performed in parallel.
A task can have parameters. When a parameter is specified for a task,
its mode has to be specified. Parameters can be one of these 3 modes:
Values
- produced
- The parameter is an output of the task
- consumed
- The parameter is an input to the task
- both
- The parameter is both input to & output of the task
Underline_Style specifies whether text should be underlined, and how.
Values
- None
- No underlining.
- Single
- Underlining with a single thin line.
- Dotted
- Underlining with a dotted line.
Enumeration of parameter modes. A parameter of a method can either
be input only, input-output, or output only.
Values
- in
- Parameter mode in input only.
- out
- Parameter mode in output only.
- inout
- Parameter mode is input-output.
Enumeration of all types in IDL. This forms the basis for modelling
IDL types in the application model. IDL supports primitive types
like short, long, unsigned short, unsigned long, float, double,
char, octet, and boolean. The type octet is basically a byte.
IDL however, doesn't support the types int or unsigned int. Apart
from these primitive types, IDL also supports other types including
structured types. These are explained below.
Values
- t_void
- t_short
- t_long
- t_ushort
- t_ulong
- t_float
- t_double
- t_boolean
- t_char
- t_octet
- t_object
- The type object can be used to represent any CORBA object.
Since, user defined interfaces are eventually translated
into CORBA objects, the type object can be used to
represent user defined interfaces too.
- t_struct
- A structured type in IDL that provides an aggregation
mechanism. Structures in IDL are very similar to structures
in C and are quite different from structures in C++. Unlike
C++, structures in IDL cannot participate in inheritance.
Structures in IDL are also different from interfaces in
IDL. An interface in IDL defines only the API. It doesn't
define any storage. Structures in IDL on the other hand
only define storage.
- t_any
- This is the equivalent of 'void *' in C++. A variable
of type any can hold values that can be held by any type
in IDL.
- t_union
- Unions in IDL are different from unions in C or C++. Unions
in IDL have a discriminator. The value of the discriminator
defines the value the union contains. Discriminators exist
in C or C++ too, but are external to the union. In IDL
however, discriminators are part of the union definition.
The reason for this is that, different values in the
union need to be encoded different ways, when values are
distributed. CORBA uses the value of the discriminator to
determine the type of encoding to use for the value.
- t_enum
- An enumeration in IDL is very similar to an enumeration in
C. Enumerations in IDL are also tied very closely to unions.
The discriminator of a union should be an IDL enumeration.
- t_string
- Strings in IDL, can be used to contain arbitrarily
long sequences of characters. Strings in IDL may be
defined to have a maximum bound, or no bound at all.
- t_sequence
- Sequences in IDL can be used to construct sequences of
objects. The objects can be primitive types, or constructed
types or user defined types. Sequences in IDL can be bounded
or unbounded.
- t_array
- Arrays in IDL are similar to arrays in C or C++. The type
of an array can be primitive, structured or user defined.
- Direction {Horizontal, Vertical}
- Fill_Poly_Style {Even_Odd, Winding}
- Fill_Solid_Style {Solid_Fill, Tiled, Stippled, Opaque_Stippled}
- Font_Style {Regular, Bold, Italic, Bold_Italic}
- Guide_Type {Input, Fixed, Adjustable}
- Line_Cap_Style {Not_Last, Butt, Cap_Round, Projecting}
- Line_Join_Style {Miter, Join_Round, Bevel}
- Line_Solid_Style {Solid_Line, On_Off_Dash, Double_Dash}
- Magnitude_Unit {Pixel, Pica, Point, Cm, Inch}
- Task_Order {sequential, alternatives, unrestricted_one_a_time, unrestricted_parallel, unrestricted_can_be_parallel}
- Task_Parameter_Mode {produced, consumed, both}
- Underline_Style {None, Single, Dotted}
- idl_mode {in, out, inout}
- idl_type_enum {t_void, t_short, t_long, t_ushort, t_ulong, t_float, t_double, t_boolean, t_char, t_octet, t_object, t_struct, t_any, t_union, t_enum, t_string, t_sequence, t_array}
Mastermind
Home |
Documentation Top Level