Attribute
Attributes represent a property of a group, agent, object class or object. Attributes have values. Attributes of a class or value type are single-valued attributes, attributes of a collection type are multi-valued. The value of an attribute is defined through facts and/or beliefs.
Syntax
attribute | ::= | { private | protected | public } attribute-type-def attribute-name { attrib-body } ; |
attribute-name | ::= | location | ID.name |
attribute-type-def | ::= | [ type-def | collection-type-def | relation-type-def ] |
type-def | ::= | [ class-type-def | value-type-def | java-type-def ] |
class-type-def | ::= | [ Agent | Group | Class | Object | ActiveClass | ActiveInstance | ActiveConcept | ConceptualClass | ConceptualObject | ConceptualConcept | AreaDef | Area | GeographyConcept | Concept | GRP.group-name | CLS.class-name | COC.conceptual-class-name | ADF.areadef-name ] |
value-type-def | ::= | [ int | long | double | symbol | string | boolean ] |
collection-type-def | ::= | [ map ] |
relation-type-def | ::= | relation ( type-def ) |
java-type-def | ::= | java ( java-ref-type-def ) |
java-ref-type-def | ::= | java-class-or-interface-type-def [ [ ] ]* |
java-class-or-interface-type-def | ::= | java-type-decl-specifier { java-type-arguments } |
java-type-decl-specifier | ::= | [ ID.name [ . ID.name ]* | java-class-or-interface-type-def . ID.name ] |
java-type-arguments | ::= | java-type-argument [ . java-type-argument ]* > |
java-type-argument | ::= | [ java-ref-type-def | ? { java-wildcard-bounds } ] |
java-wildcard-bounds | ::= | [ extends java-ref-type-def | super java-ref-type-def ] |
attrib-body | ::= | { {display : ID.literal-string ; } } |
Semantics
Attribute scope
Attributes are always defined within a group, agent, area-definition, area, conceptual-class, conceptual-object, class or object definition and cannot be defined outside any of these concepts or inside of any other concepts. Attributes can have different scopes within the specified concepts defined by one of the keywords private, protected or public.
Private attributes
Private attributes are scoped down to only the concept for which it is defined. The private attribute is not inherited by sub groups or sub classes (agents /objects that are members/instances of the group/class will inherit the attribute) and the private attribute can only be referenced by initial beliefs, initial facts, workframes and thoughtframes for that specific concept.
Protected attributes
Protected attributes are inherited by sub groups and sub classes. Protected attributes can only be referenced by initial beliefs, initial facts, workframes and thoughtframes of the concept for which the attribute is specified or any of the sub groups/sub classes and of agents/objects that are members/instances of the sub group(s)/class(es).
Public attributes
Public attributes are similar to protected attributes, the only difference is that they can be referenced by initial beliefs, initial facts, workframes and thoughtframes in any group, agent, class or object.
Value assignment
Value assignment of attributes differs from value assignments in third and fourth generation computer languages (which usually use an assignment operator like '=' or ':='. Assignment of a value for an attribute is done through beliefs and facts.
Meta types
The meta types allow for binding of concepts that are considered to be a subtype of the meta types. The following concepts can be bound to the specified meta types:
Group | any group |
Agent | any agent regardless of the group it is a member of |
Class | any class |
Object | any object regardless of the class it is an instance of |
ActiveClass | any group and class |
ActiveInstance | any agent and object |
ActiveConcept | any active class and active instance |
ConceptualClass | any conceptual class |
ConceptualObject | any conceptual object |
ConceptualConcept | any conceptual class and conceptual object |
AreaDef | any area definition |
Area | any area |
GeographyConcept | any area definition and area |
Concept | any active concept, conceptual concept and geography concept |
Collection Types
The collection types allow for attributes to have multiple values assigned to them. Only collections of type map are currently supported. A map is a collection for which values are accessible via a unique index or key being either an integer or string.
Relation types
The relation type is a new way to declare relations in the language in the attributes section as an alternative to declaring the relations in the relations section. This is in preparation for eliminating all section headers and would still allow for the notion of relations since they require a different notation and different handling in conditions compared to regular attributes.
Java types
Attributes, variables and parameters can now also be declared to be of any Java reference type allowing for the modeler to directly reference Java objects. Note that the Brahms language assumes at a minimum Java 5.0, the Brahms language supports the generics notations. For more information on Java reference types see the Java Language Specification. (opens in a new tab)
Defaults
The default scope of an attribute is public.
- display = <attribute-name>
Constraints
- The name of an attribute must be unique within the definition of a group, agent, class or object. In case of a name conflict in multiple inheritance (two different concepts from which is inherited define an attribute with the same name) the following conflict resolution strategy is chosen. If both attributes are of the same type just one definition will remain with the same name and same type. If the types of the attributes differ an error will be generated.
- If the name of the attribute is location, its type must be the name of an area definition or the meta-type Area.
- If a Java type is used as the type of the attribute the Java type must reference a Java type that is either referenced by its simple name or by its fully qualified name(s). If the simple name is used the simple name must be resolvable to a fully qualified name using the Java import statements (jimport). The compiler must be able to load the Java Class for the type, the compiler uses this method to ensure that the Java type is valid. The Java Classes for the types used in the Brahms language must therefore be in the Java classpath.
Relation
Relations represent a relation between two concepts. The first (left hand side) concept is always the concept for which the relation is defined, the second concept (right hand side) can be any concept.
NOTE: The syntax for the declaration of the relation will be replaced by the preferred syntax of declaring an attribute to be of a relation type. See the attributes for details.
Syntax
relation | ::= | { private | protected | public } ATT.class-type-def relation-name { ATT.attrib-body } ; |
relation-name | ::= | ID.name |
Semantics
Relation scope
Relations are always defined within a group, agent, area-definition, area, conceptual-class, conceptual-object, class or object definition and cannot be defined outside any of these concepts or inside of any other concepts. Relations can have different scopes within the specified concepts defined by one of the keywords private, protected or public.
Private relations
Private relations are scoped down to only the concept for which it is defined. The private relation is not inherited by sub groups or sub classes (agents /objects that are members/instances of the group/class will inherit the relation) and the private relation can only be referenced by initial beliefs, initial facts, workframes and thoughtframes for that specific concept.
Protected relations
Protected relations are inherited by sub groups and sub classes. Protected relations can only be referenced by initial beliefs, initial facts, workframes and thoughtframes of the concept for which the relation is specified or any of the sub groups / sub classes and of agents/objects that are members/instances of the sub group(s)/class(es).
Public relations
Public relations are similar to protected relations, the only difference is that they can be referenced by initial beliefs, initial facts, workframes and thoughtframes in any group, agent, class or object.
Defaults
The default scope of a relation is public.
- display = <relation-name>
Constraints
- The name of a relation must be unique within the definition of a group, agent, class or object. In case of a name conflict in multiple inheritance (two different concepts from which is inherited define a relation with the same name) the following conflict resolution strategy is chosen. If both relations are of the same type just one definition will remain with the same name and same type. If the types of the relations differ an error will be generated.
Variable
Variables can be used in a workframe or thoughtframe to write more generic work- and thoughtframes. Before a variable can be used it has to be declared. The scope of the variable is bound to the frame it is declared in. A variable that is not declared within the workframe it is used in, must be declared higher up in the activity-tree the workframe is part of. (The activity tree is created through composite activities.)
Syntax
variable | ::= | { collectall | foreach | forone } ( ATT.type-def ) variable-name { ATT.variable-body } ; |
variable-name | ::= | ID.name |
variable-body | ::= | { { display : ID.literal-string } } |
Semantics
Quantification
Variables are of one of three quantification types: collect-all, for-each and for-one. The difference between the three quantification types is the way variables are bound to a specific context of a defined type (agent, object, or other value). The difference in binding is as follows:
for-each variable
A for-each variable is bound to only one context. For each context that can be bound to the variable a separate instance is created for the workframe in which the variable is bound. For example in the following frame:
workframe DoSomething {
variables:
foreach(Order) order;
when (
(order is-assigned-to current) )
do {
workOnOrder();
}
}
There are three Order instances in the model (order1, order2, and order3) satisfying the precondition. For this workframe three instances will be created in which the for-each variable is bound to one of the orders in each frame instantiation. This means that the agent for which the workframe is defined can only work on one order at a time and will work on them in consecutive order if no interruptions take place.
collect-all variable
A collect-all variable can be bound to more than one context. The variable will be bound to all contexts satisfying the condition in which it is defined. Only one frame instantiation will be created as a result of the binding with the collect-all variable. If we consider the same example as for for-each variables changing the quantification of the variable to collect-all.
workframe DoSomething {
variables:
collectall(Order) order;
when (
(order is-assigned-to current) )
do {
workOnOrder();
}
}
Also assume that again three orders match with the precondition based on the beliefs of the agent, then all three orders are bound to the variable and one frame instantiation will be created for the agent to work on. This means that the agent for which this workframe is defined will work on all orders at the same time.
for-one variable
A for-one variable can be bound to only one context. Only one frame-instantiation will be created as a result of the binding with the for-one variable. A for-one variable binds to the first context satisfying the condition in which it is defined. If we consider the same example as for for-each variables changing the quantification of the variable to for-one.
workframe DoSomething {
variables:
forone(Order) order;
when (
(order is-assigned-to current) )
do {
workOnOrder();
}
}
Also assume that again three orders match with the precondition based on the beliefs of the agent, then one of the orders will be bound to the variable and one frame instantiation will be created for the agent to work on. This means that the agent only works on one order and it doesn't matter on which order. The other two orders will not be worked on.
Defaults
The default scope of a relation is public.
- display = < variable-name >
Constraints
- The name of the variable must be unique within the definition of a workframe or thoughtframe.