Language
Concepts

Group

The concept of a "group" in Brahms is similar to the concept of a template or class in object-oriented programming. A group represents a collection of 'agents' that can perform similar work and have similar beliefs. A group defines the work activities (activity frames and thought frames), the initial-beliefs of members in the group and the initial-facts in the world. The difference with classes in object-oriented programming is that the relationship between a group and its members is not an IS-A relationship, but a MEMBER-OF relationship. This is why we speak of "a member of a group" instead of "an instance of a group."

Functional Roles

In terms of organizations the concept is similar to that of functional roles in an organization. A group in Brahms could represent a typical role in an organization; The work activities that someone performs when he or she plays that role. For example, we could represent the role of Maintenance Technician or Central Office Engineer as a "group".

Structural Groupings

A group in Brahms can also depict an organizational group. For example, we can define a group as "Members of the Work System Design group at S&T." We could now describe the work-activities, and initial-beliefs of members of the WSD group at S&T.

Conceptual Groupings

We can also create informal groups related to conceptual definitions that make sense in the modeling activity. For instance, in modeling the people at S&T we could create a group "People at 400 Westchester Avenue." We can now describe the activities and initial-beliefs that people at 400 Westchester Avenue have in common. This might not be that interesting, but in modeling people's interactions with legacy systems in NYNEX we could define a conceptual group of "LMOS users." In this group we could now describe how people interact with LMOS, and what initial-beliefs LMOS users have (for instance, the initial-belief that LMOS has data about today's trouble tickets).

Syntax

group::=

group group-name { group-membership }
{ display: ID.literal-string; } { cost: ID.number; } { time_unit: ID.number; } { icon: ID.literal-string; } { attributes } { relations } { initial-beliefs } { initial-facts } { activities } { workframes } { thoughtframes }

group-name::=ID.name
group-membership::=memberof group-name, group-name ]*
attributes::=attributes: [ ATT.attribute ]*
relations::=relations: [ REL.relation ]*
initial-beliefs::=initial_beliefs: [ BEL.initial-belief ]*
initial-facts::=initial_facts: [ FCT.initial-fact ]*
activities::=activities: [ activity ]*
activity::=

[ CAC.composite-activity |
PAC.primitive-activity |
MOV.move-activity |
CAA.create-agent-activity |
COA.create-object-activity |
COM.communicate-activity |
BCT.broadcast-activity |
JAC.java-activity |
GET.get-activity |
PUT.put-activity ]

workframes::=workframes: [ WFR.workframe ]*
thoughtframes::=thoughtframes: [ TFR.thoughtframe ]*

Semantics

Group membership

In a model a hierarchy of groups can be built by defining the group-membership. A group can be a member of more then one group. When a group is a member of a group the member-group will 'inherit' the attributes, relations, initial-beliefs, initial-facts, activities, workframes and thoughtframes from its parent groups. Private attributes and relations are not inherited, only public and protected attributes and relations are inherited. In case the same constructs are encountered in the inheritance path always the most specific construct will be used, meaning that a workframe defined for a group lowest in the hierarchy tree has precedence over a workframe with the same name higher in the hierarchy.

Cost and time-unit

The cost and time-unit are used for statistical purposes and define the cost/time-unit (in seconds) for work done by members of the group. The members of the group can override the cost and time-unit figures.

Example

group Student memberof SystemGroup

Defaults

Every group in a model is by definition a member of 'BaseGroup' defined in the 'BaseModel' library which is imported by definition for every model. The 'BaseGroup' defines built-in attributes, relations, initial-beliefs, initial-facts, workframes and thoughtframes as defaults for groups. The 'BaseGroup' membership does not have to be defined explicitly. Other defaults are:

Constraints

  1. The name of a group must be unique amongst all concepts in a model
  2. The time_unit defines the time in seconds

Agent

An agent in Brahms is the most central construct in a Brahms model. An agent represents an interactive system, a subject with behavior interacting with the world. An agent can for example represent a person in an organization, but could also represent an animal in a forest. A Brahms model is always about the activities of agents in a work process. In Brahms it is also possible to implement the behavior of an agent in Java instead of in the Brahms language. This is done by defining an external agent. An external agent can interact with the Brahms agents and Brahms agents can interact with external agents. External agents do not have any reasoning capabilities unless these capabilities are built-in by the implementer of the external agent.

Syntax

agent::=

agent group-name { GRP.group-membership }
{
{ display: ID.literal-string; }
{ cost: ID.number; }
{ time_unit: ID.number; }
{ location: ARE.area-name; }
{ icon: ID.literal-string; }
{ GRP.attributes }
{ GRP.relations }
{ GRP.initial-beliefs }
{ GRP.initial-facts }
{ GRP.activities }
{ GRP.workframes }
{ GRP.thoughtframes }
}

externalagent::=external agent: agent-name
agent-name::=ID.name

Semantics

Group membership

An agent can be a member of one or more groups. When an agent is a member of a group the agent will 'inherit' attributes, relations, initial-beliefs, initial-facts, activities, workframes and thoughtframes from the group(s) it is a member of. All attributes and relations are inherited including private ones (an agent can be seen as an instance of a group in terms of object oriented practices). In case the same constructs are encountered in the inheritance path always the most specific construct will be used, meaning that a workframe defined for the agent has precedence over a workframe with the same name defined in one of the groups of which the agent is a member.

Defaults

Every agent in a model is by definition a member of 'BaseGroup' defined in the 'BaseModel' library which is imported by definition for every model. The 'BaseGroup' defines built-in attributes, relations, initial-beliefs, initial-facts, activities, workframes and thoughtframes as defaults for agents and groups. The 'BaseGroup' membership does not have to be defined explicitly. Other defaults are:

  • display = <agent-name>
  • cost = 0
  • time_unit = 0
  • location = none

Example

  agent Alex_Agent memberof Student
  external agent SimulationManagerAgent

Constraints

  1. The name of an agent must be unique amongst all concepts in a model
  2. The time_unit defines the time in seconds
  3. The Java class name of an external agent must be identical to Brahms external agent's name as defined in the Brahms model. Both Java class and Brahms external agent must also be defined with the same package name.

Class

The concept of a 'class' in Brahms is similar to the concept of a template or class in object-oriented programming. It defines the activities (workframes), initial-facts and initial-beliefs for instances of that class (i.e. 'objects'). Classes are used to define inanimate artifacts, such as phones, faxes, computer systems, pieces of paper, etc.

Syntax

class::=

class class-name { class-inheritance }
{ { display: ID.literal-string; } { cost: ID.number; } { time_unit: ID.number; } { resource: ID.truth-value; } { icon: ID.literal-string; } { GRP.attributes } { GRP.relations } { GRP.initial-beliefs } { GRP.initial-facts } { GRP.activities } { GRP.workframes } { GRP.thoughtframes } }

class-name::=ID.name
class-inheritance::=extends class-name [, class-name ]*

Semantics

Class inheritance

In a model a hierarchy of classes can be built by defining the class inheritance. A class can inherit from more then one class, so multiple inheritance is supported. When a class is a subclass of a class the subclass will inherit the attributes, relations, initial-beliefs, initial-facts, activities, workframes and thoughtframes from its parent classes. Private attributes and relations are not inherited, only public and protected attributes and relations are inherited. In case the same constructs are encountered in the inheritance path always the most specific construct will be used, meaning that for example a workframe defined for a class lowest in the hierarchy tree has precedence over a workframe with the same name higher in the hierarchy.

Cost and time-unit

The cost and time-unit are used for statistical purposes and define the cost/time-unit (in seconds) for work done by instances of the class. The instances of the class can override the cost and time-unit figures.

Resource

The resource attribute defines whether or not instances of the class are considered to be a resource when used in an activity (resource attribute is set to true) or whether the instances of the class are considered something that is worked on (resource attribute is set to false). The resource attribute is used in relation with the touched-objects definition for activities (see the semantical description of touched-objects in the definition of the primitive-activity).

Example

class MyClock extends CalendarUtilClass

Defaults

Every class in a model is by definition a member of 'BaseClass' defined in the 'BaseModel' library which is imported by definition for every model. The 'BaseClass' defines built-in attributes, relations, initial-beliefs, initial-facts, activities, workframes and thoughtframes as defaults for classes. The 'BaseClass' membership does not have to be defined explicitly. Other defaults are:

  • display = <class-name>
  • cost = 0
  • time_unit = 0
  • resource = false

Constraints

  1. The name of a class must be unique amongst all concepts in a model
  2. The time_unit defines the time in seconds

Object

An 'object' in Brahms is the second most central element in a Brahms model. An object represents a specific artifact in the world. It is possible to model the activities of an artifact in an organization. For example the data processing activities of a computer system can be modeled. The activities can be defined in the object's class (which will be inherited by the object) and/or can be defined for the object itself.

Syntax

object::=

object object-name
instanceof CLS.class-name
{ COB.conceptual-object-membership }
{
{ display: ID.literal-string; } { cost: ID.number; } { time_unit: ID.number; } { resource: ID.truth-value; } { location: ARE.area-name; } { icon: ID.literal-string; } { GRP.attributes } { GRP.relations } { GRP.initial-beliefs } { GRP.initial-facts } { GRP.activities } { GRP.workframes } { GRP.thoughtframes } }

object-name::=ID.name

Semantics

Conceptual object membership

An object can be part of one or more conceptual objects by defining the conceptual-object-membership for the object. This allows for later grouping of statistical results for the object with other objects in one conceptual object.

Resource

The resource attribute defines whether or not the object is considered to be a resource when used in an activity (resource attribute is set to true) or whether the object is considered something that is worked on (resource attribute is set to false). The resource attribute is used in relation with the resources definition for activities (see the semantical description of resources in the definition of the primitive-activity).

Example

object Campanile_Clock instanceof MyClock

Defaults

  • display = <object-name>
  • cost = 0
  • time_unit = 0
  • resource = false
  • location = none

Constraints

  1. The name of an object must be unique amongst all concepts in a model. It is possible to give an object the same name as an object defined in a library.
  2. The time_unit defines the time in seconds

Conceptual Class

A conceptual class defines a type of conceptual objects used in a model. For the definition and usage of conceptual objects see the section on conceptual objects.

Syntax

conceptual-class::=

conceptual class conceptual-class-name { conceptual-class-inheritance } {
{ display: ID.literal-string; } { icon: ID.literal-string; } { GRP.attributes } { GRP.relations } }

conceptual-class-name::=ID.name
conceptual-class-inheritance::=extends conceptual-class-name [, conceptual-class-name ]*

Semantics

Conceptual class inheritance

In a model a hierarchy of conceptual classes can be built by defining the conceptual class inheritance. A conceptual class can inherit from more then one conceptual class, so multiple inheritance is supported. When a conceptual class is a subclass of a conceptual class the subclass will inherit the attributes and relations from its parent conceptual classes. Private attributes and relations are not inherited, only public and protected attributes and relations are inherited. In case the same constructs are encountered in the inheritance path always the most specific construct will be used, meaning that for example an attribute defined for a class lowest in the hierarchy tree has precedence over an attribute with the same name higher in the hierarchy.

Example

conceptual_class Order extends BaseConceptualClass

Defaults

Constraints

  1. The name of an object must be unique amongst all concepts in a model.

Conceptual Object

Syntax

conceptual-object::=

conceptual-object conceptual-object-name
instanceof COC.conceptual-class-name
{ conceptual-object-membership } {
{ display: ID.literal-string; } { icon: ID.literal-string; } { GRP.attributes } { GRP.relations } }

conceptual-object-name::=ID.name
conceptual-object-membership::=partof conceptual-object-name [, conceptual-object-name ]*

Semantics

Conceptual object membership

A conceptual-object can in itself be a member of other conceptual object forming a hierarchy of concepts for grouping statistical results.

Example

conceptual_object Diner_Order instanceof Order
conceptual_object Lunch_Order instanceof Order partof Diner_Order

Defaults

Constraints

  1. The name of a conceptual-object must be unique amongst all concepts in a model.

Area Definition

An area definition is used for defining area constructs used for representing geographical information in a model. Area definitions are similar to classes in their use. Examples of area definitions are 'World', 'Building', and 'Floor'.

Syntax

areadef::=

areadef areadef-name { areadef-inheritance }
{
{ display: ID.literal-string; } { icon: ID.literal-string; } { GRP.attributes } { GRP.relations } { GRP.initial-facts } }

areadef-name::=ID.name
areadef-inheritance::=extends areadef-name [, areadef-name ]*

Semantics

Area definition inheritance

In a model a hierarchy of area definitions can be built by defining the area definitions inheritance. An area definition can inherit from more then one area definition, so multiple inheritance is supported. When an area definition is a subclass of another area definition the subclass will 'inherit' the attributes, relations, and initial-facts from its parent area definitions. Private attributes and relations are not inherited, only public and protected attributes and relations are inherited. In case the same constructs are encountered in the inheritance path always the most specific construct will be used, meaning that for example an attribute defined for an area definition lowest in the hierarchy tree has precedence over an attribute with the same name higher in the hierarchy.

Example

areadef University extends BaseAreaDef

Defaults

  • display = <area-def-name>

Constraints

  1. The name of an object must be unique amongst all concepts in a model.

Area

An area represents a geographical location and is used to create a geographical representation for use in the model. Examples are 'NewYorkCity', 'SandTBuilding', etc. Areas are instances of area definitions.

Syntax

area::=

area area-name
instanceof ADF.areadef-name
{ partof area-name } {
{ display: ID.literal-string; }
{ icon: ID.literal-string; }
{ GRP.attributes }
{ GRP.relations }
{ GRP.initial-facts }
}

area-name::=ID.name

Semantics

Area decomposition

Areas can be decomposed into sub-areas. For example a building can consist of one or more floors. The decomposition can be modeled using the part-of relationship. Model builders have indicated that they frequently want to reason about the area decomposition in their models. The virtual machine therefore generates a set of initial facts about the decomposition of the areas in a model. The virtual machine generates initial facts using the built-in relations 'isSubAreaOf' and 'hasSubArea' defined in the BaseAreaDef area definition. For each area an initial fact is generated about its aggregate area using the 'isSubAreaOf' relation, only one initial fact can be generated since an area can only be part of one other area. For each area we also generate an initial fact for every sub area of the area using the 'hasSubArea' relation. Agents can detect any of these facts as needed by these agents. Note that the virtual machine only generates the initial facts for the direct relation between areas and sub-areas and not the indirect relations. If area A1 has a sub-area B1 and B1 has a sub-area C1 then we only generate the initial facts relating A1 to B1 and B1 to C1 but we do not generate the initial facts relating A1 to C1. This relationship would have to be deduced by modeling preconditions and asserting beliefs of Brahms agents by model builders.

Example

  area Berkeley instanceof City
  area UCB instanceof University partof Berkeley

Defaults

Constraints

  1. The name of a conceptual-object must be unique amongst all concepts in a model. -->

Path

A path connects two areas together and represents a route that can be taken by an agent or object to travel from one area to another. For the path is specified how long it takes to travel from one area to the other.

Syntax

path::=

path path-name
{
{ display: ID.literal-string; }
area1 : ARE.area-name
area2 : ARE.area-name
{ distance : ID.unsigned }
}

path-name::=ID.name

Semantics

Distance

The distance represents the time it takes to move from area1 to area2 and vice versa. In future versions of the language the distance will represent the actual distance and based on the transportation used to travel over the path the duration will be calculated.

Example

path SpH_to_from_BOA {
    area1: SproulHall;
    area2: Telegraph_Av_113;
    distance: 240;
  }

Defaults

Constraints

  1. The name of a path must be unique amongst all concepts in a model.
  2. The distance represents the travel duration in seconds -->
LanguageAttributes, Relations, Variables