Library attributes

The dynamic and static libraries have library attributes. These library attributes serve two purposes: They describe the library and they are needed for layout, analysis, simulation, evaluation and more.

The library attributes are filled with values in the ADOxx Notebook. The notebook is structured as described below:

• Description
  • Keywords
  • Description
  • Comment
  • Service *
  • Author
  • Creation date
  • Last user
  • Date last changed
• Add-ons
  • Modi
  • Versioning format *
  • External coupling
• Modelling
  • Default settings
  • Page layouts
  • Connector marks - Numbering
  • Connector marks - Graphical representation
  • Object arrangement *
• Analysis
  • Relation analysis
• Simulation
  • Simulation definition - Simtext *
  • Simulation definition - Simmapping *
  • Simulation definition - Sim result mapping
  • Simulation definition - Variable check *
  • Agent definition *
  • Enterprise time - Days per year *
  • Enterprise time - Hours per day *
• Evaluation
  • Activity based costing - CCC mapping *
  • Activity based costing - CCC default setting *
  • Dynamic evaluation modules *
• Documentation
  • Configuration of documentation *

Hint

The attributes marked by an asterisk ("*") can only be edited in the dynamic library's notebook. The attributes "Service", "User defined", "Library icons" and "Agent definition" refer to the application library. All other attributes marked are only used in the modelling of dynamic models.

Attention

An application library, which attributes are edited, is locked for other users. It means, that other ADOxx administrators cannot change its attributes (parallel) from a dibeing fferent place.

After you have selected the library to be edited in the window "Library management - library configuration" and clicked on the button "Library attributes" the notebook "<Library Name> - Library attributes" will appear.

After completing your changes, close the ADOxx library notebook by clicking on the button "Assign". Any changed attributes will be stored in the ADOxx database after a confirmation query.

Attention

We recommend that you check the library attributes after editing. This allows you to ensure that the library attributes are correct and prevent possible runtime errors during the work with the ADOxx Modelling Toolkit.

Hint

We also recommend that you talk to your ADOxx consultant prior to making any changes of library attributes.

Keywords (Description)

Enter keywords or a short description of the library here. For documentation purposes.

Description (Description)

Enter a description of the library here. For documentation purposes.

Comment (Description)

Enter a comment on the library here. For documentation purposes.

Service (Description)

An attribute where you can name a person (e.g. the ADOxx administrator), or give an address of the institution to contact in case of help needed (by the user).

The text entered here will be displayed in the Option "Service" from the "Help" menu of the Modelling Toolkit.

Hint

The attribute "Service" is only defined in the dynamic library. It refers, however, to the application library to which this BP library is assigned.

Author (Description)

A system attribute which is automatically filled with the name of the user who performed the library import into the database.

Creation date (Description)

A system attribute which is automatically filled with date and time of the library import into the database.

Last user (Description)

A system attribute which is automatically filled with the name of the last user editing the library attributes.

Date last changed (Description)

A system attribute which is automatically filled with the date and the time of the last changes to the library.

Modi (Add-ons)

In the library attribute "Modi" model types and (view) modes for model types can be defined.

A model type specifies a subset of all instantiable classes and relations. Every model is of a certain model type which cannot be changed once the model has been created.

Model type groups should be defined, in case an application library contains many model types. Thanks to this, relative model types can be put together and clarity will be improved.

A mode is a further restriction to a model type. It defines a subset of all the instantiable modelling classes, allowing the user to have different views on one model. In contrast to the model type a model's mode can be changed at any time so that a mode can serve to temporarily make certain modelling classes invisible.

The language for defining model types and (view) modes is based on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal	Definition
ModelTypes :	[ GeneralSettings ] [ Method ] { ModelTypeDef } [DisplayedModelAttr] .
GeneralSettings :	GENERAL [ order-of-classes: OrderOfClasses ] .
OrderOfClasses :	default | custom .
Method :	METHOD [ graphrep: strAattrName ] { {ModelTypeGroupDef} } .
ModelTypeGroupDef :	GROUP strGroupName [ default ] { { ModelTypeOfGroup } } .
ModelTypeOfGroup :	MODELTYPE strModelTypeName .
ModelTypeDef :	MODELTYPE strModelTypeName [ plural: strModelTypePluralName ] [ pos: nIndex ] [ from: MTSource ] [ bitmap: strFileName ] [ auto-connect: AutoConnectCriterion ] [ modeling-modi-accessible: boolVal ] [ not-simulateable ] [ just-tabular ] [ abstract ] [ default-access: AccessMode ] [ BGBitmap ] [ attrrep: strAttrName ] [ graphrep: strAttrName ] { Access } { MTClasses } { VariantDef } { ModeDef } .
MTSource :	all | none | strModelTypeName .
AutoConnectCriterion :	pos | part | full .
BGBitmap :	bg-bitmap: strFileName bg-bitmap-w: width bg-bitmap-h: height [ bg-bitmap-repeat: BGBitmapRepeatMode ] .
BgBitmapRepeatMode :	none | x | y | xy .
Access :	ACCESS usergroup: strUserGroupName mode: AccessMode .
AccessMode :	blocked | protected | full .
VariantDef :	VARIANT strVariantName {VariantExclClass} VariantExclClass: EXCL strClassOrRelnClassNameOfMT .
MTClasses :	INCL strClassOrRelnClassName | EXCL strClassOrRelnClassName | OR_ASSIGN strModelTypeName
ModeDef :	MODE strModeName [ from: ModeSource ] [ abstract ] [ no-modeling ] [ no-documentation ] { ModeClasses } .
ModeSource :	all | none | strModeName .
ModeClasses :	INCL strClassOrRelnClassNameOfMT | EXCL strClassOrRelnClassNameOfMT | OR_ASSIGN strModeName | AND_ASSIGN strModeName .
DisplayedModelAttr :	DISPLAYED_MODELATTR strModelAttrName [default-hidden] {enum-value1: strAttrValue bitmap1: strBMPath enum-value2: strAttrValue bitmap2: strBMPath ...} .

Hint

GENERAL [ order-of-classes: OrderOfClasses ] applies to the whole library, not only a part!

Model types:

A model type is marked by a unique name (modelTypeName). The plural form of the model name (modelTypePlural) should also be specified.

With pos, the order of model types in the dialogue "Create new model" can be changed. By default, the modeltypes are shown in the same order as in the model type definition. Using pos moves the respective modeltype upwards. Consequently, if you want do move a modeltype down, you have to move the following modeltypes upwards.

If the attribute abstract is specified, the model type can only be used as basis for creating other model types. It means that the user cannot create any other models of this type.

The auto-connect criterion specifies when auto-connectors are created. pos means creation for objects where the position is inside the container object. part means that the auto-connector is created for objects which overlap the container object (i.e. the object is partly or completely inside the container object). full means creation exactly if the object lies completely inside the container object. If no criterion is specified, pos is assumed.

With attrrep, you can add customised model attributes. Enter the name of an attribute containing the NOTEBOOK definition for the new model attributes.

Hint

The attribute ( attributeName ), which contains a notebook definition for the model attribute is contained, must be defined in a class "__ModelTypeMetaData__". Please contact your ADOxx consultant, to properly extend the library definitions.

With DISPLAYED_MODELATTR an additional displayed modelattribute can be defined for model selection lists.

If a model type is defined as not-simulateable, models of this type will not be listed in model selection boxes, as they show models which can only be simulated.

If just-tabular is set for a model type, just the tabular (not the graphical) model editor can be used for models of that type.

Instantiable class:

The attribute from specifies a basis - which will then be further modified - for the instantiable classes of the model type:

• from:all includes all instantiable classes to be included.

• from:none specifies that we start with an empty set.

• Specifying an already existing model type determines that classes instantiable in that model will be the basis for the current model type.

In addition, the following set operations can be carried out:

• INCL adds a class (or relation class) to the current set of classes.

• EXCL removes a class (or relation class) from the current set of classes.

• OR_ASSIGN unites the current set of classes with the class set of the model type specified and assigns this merged set to the current set of classes.

• AND_ASSIGN causes the intersection of the current set of classes and the class set of the model type specified and assigns this intersection to the current set of classes.

As a final result the user assigns the classes available for modelling within this model type.

Graphics:

Every model type can get a bitmap graphic (fileName) as a symbol via the attribute bitmap. This graphic will be used in all model and model type selection lists. The BMP file will be loaded from a file system over the file name fileName whereas the quotation of the path and the file name must be under quotation marks .

Hint

The graphic file must have the file format *.bmp and a size of 16*16 Pixel with the 16 colours of the standard palette. Afterwards it has to be copied into the ADOxx installation directory. If no bitmap file is specified, the symbol for Dynamic models () is used for the model types of the D library and the symbol for Static models () is used for the model types of the S library.

"General Settings":

With help of the GENERAL Element you can influence the order of the classes and relations in the modelling bar (Modelling Component in the Modelling Toolkit) . The order of the classes (resp. relation classes) in the modeling toolbox depends by default on the sequence in which the classes have been defined in the library (i.e. on the class IDs). If order-of-classes is set to custom in the GENERAL element, the order depends on the sequence in which the classes have been included to the model type or modeling mode.

Modi:

When the instantiable classes of a model type have been defined, the modes for the current model type may be defined. This happens in a similar way to the model type definition. Basis for quantity of links are only modes, which have already been defined for the same type of model.

With modeling-modi-accessible, the direct access to the menu entry "Mode" can be removed. This is useful, if the mode shall only be changed via AdoScript mechanisms.

As in case of model types, the user can set the starting point with from:all or from:none. The classes with INCL, EXCL, OR_ASSIGN and AND_ASSIGN will be assigned or removed.

If no-modeling is specified, the mode concerned cannot be applied for modelling and will thus not be shown in the option "Modes" in the Modelling Component.

By adding no-documentation a mode is specified that cannot be used for documentation generation.

Access for user groups:

Both model types and modes can by using ACCESS usergroup: userGroupName mode: accessMode be locked for certain user groups. In principle it is true, that a user group has a default access rights, provided no other (special) access rights has been defined for it. It is also a standard situation, that default access rights means (full) access rights, provided no other access rights have been defined as default rights in a model type or mode definition (element default-access). Read-only access rights to model types (protected) mean, that models of this type cannot be created, changed or deleted. Locked access rights to model types (blocked) mean, that models of that type are invisible and cannot be opened.

Model type groups / Method diagram:

For modelling methods, which are either complex or use model types which can be categorised into groups ("levels", "application scenarios"), it is suitable to use a method diagram. There, the model types are divided into as many sub groups as needed. On the user interface, a method diagram is shown as a method box in dialogues. The syntax is as follows:

MethodBox :	METHOD [ graphrep: attrName ] { {ModelTypeGroupDef} } .
ModelTypeGroupDef :	GROUP groupName [ default ] { { ModelType } } .
ModelType :	MODELTYPE modelTypeName .

The graphical representation of the modeling method is defined using the GraphRep language. The attribute where the GraphRep code is stored in belongs to the class "__ModelTypeMetaData__". You can use the attribute "GraphRep" or a custom (LONG)STRING class attribute (not instance attribute!). The name of the attribute for the graphical representation of the modeling method is specified in the library attribute "Modi" at the METHOD element's graphrep attribute, where "GraphRep" is the default.

Within the method's GraphRep code a preset variable mtgroup is accessible that holds the current model type group name. This makes it possible to mark GraphRep elements that correspond with the current model type group.

You can define click regions in the method's GraphRep using HOTSPOT elements. The name of a hotspot is a model type group name that can be selected by clicking into the region.

Each group of model types is introduced by a GROUP element with a group name. A group consists of a list of model types. Each model type of a group is specified by a MODELTYPE element with a model type name.

If default is specified at a GROUP element, this group will be selected by default in dialogues.

Example:

METHOD graphRep:"Method GraphRep" { GROUP "Group 1" { MODELTYPE "Model type 1" MODELTYPE "Model type 2" } GROUP "Group 2" { MODELTYPE "Model type 3" MODELTYPE "Model type 4" } }

Variants: For a model type a set of variants can be defined. By default, no variant is defined for a model type. No defined variant means something like implititely one nameless variant exists. For each model type where variants are going to be defined all included classes and relation classes must have a string attribute "__Variants__". For classes this can easily be done by defining that attribute in the library's root class ("__BP-construct__" or "__WE-construct__"). If a needed "__Variants__" attribute is not existing for a class it is created automatically. However, it is recommended to create the "__Variants__" attributes for the two root classes. The "__Variants__" attribute value of an object contains the position information for all variants. It is recommended to use LONGSTRING as type for the variants attribute. Variants are defined with VARIANT elements after the model type definition in the "Modi" library attribute. For each variant a name has to be specified which is unique for the model type. For each variant optionally some classes can be excluded. This can be done by writing EXCL statements after the related VARIANT element -- the same way as excluding classes for a model types and a mode. The set of variants always contains a general, nameless variant which is shown at the UI as <No Variant>. It contains all classes of the model type and has no related layout algorithm. As that variant is always the first one, it is used automatically when a model contains no variant information, e.g. when a model has been imported from a library without variants.

Versioning format (Add-ons)

ADOxx supports various types of model (and attribute profile) versioning:

• Model-based versioning
• Time-based versioning

The library attribute "Versioning format" is defined in the D library for the whole application library and is valid for all model types and attribute profiles.

Model-related versioning:

The version number can contain any user-defined text (20 characters maximum).

Hint

In model-related versioning, only models have version numbers, while attribute profiles have none.

Time-related versioning:

On creation of a model/attribute profile under time-related versioning it receives a validity date. This validity ends with the beginning of the validity of the next version. The valid version is always the most recent one.

The language for the definition of the versioning is based on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal	Definition
VersioningFormat :	VERSIONING start_date fields .
start_date :	START_DATE [ day: start_day ] [month: startMonth ] [ year: start_year ] .
fields :	[ text_field ] [ day_field ] [ text_field ] [ month_field ] [ text_field ] [ year_field ] [ text_field ] .
text_field :	TEXT_FIELD " text " .
day_field :	DAY_FIELD [ default: def ] [ minimum: min ] [ maximum: max ] .
month_field :	MONTH_FIELD [ default: def ][ minimum: min ] [ maximum: max ] [full] .
year_field :	YEAR_FIELD [ default: def ] [ minimum: min ] [ maximum: max ] .

The definition of versioning format begins with the key word VERSIONING. In the element START_DATE a start value (Day, Month and/or_Year_) can be quoted, which will be set when creating the new ADOxx-model.

The format for the display of the version date will consist of the following elements:

• DAY_FIELD for the day,
• MONTH_FIELD for the month,
• YEAR_FIELD for the year,
• TEXT_FIELD for a text for and between the date values.

Hint

If in the value text quotation marks (") are contained they must be marked i.e. instead of ' " ' must ' \" ' be quoted.

Additionally to every date value (DAY_FIELD,MONTH_FIELD and/or YEAR_FIELD) a standard value (default:) as well as a minimum value (min:) or a maximum value (max:) must be quoted.

Through the quotation of the attribute full in the MONTH_FIELD the value of the month will be displayed as text.

Hint

The parameter "default" is used only when the corresponding START_DATE does not exist.

Example:

VERSIONING
START_DATE month:1 year:2002
TEXT_FIELD "<"
MONTH_FIELD full
TEXT_FIELD " "
YEAR_FIELD default:2002 minimum:1950 maximum:2100
TEXT_FIELD ">"

Through the above definition the version date will be displayed in the form of <month yeas> where as the month will be fully written and the year is in the area between 1950 and 2100 . When creating a new ADOxx-model the value "January 2001" will be suggested.

External coupling (Add-ons)

With the library attribute "External coupling" functions in the Modelling Toolkit can be added, extended, modified or removed. For each component it is possible to define library-specific menus calling AdoScripts. These changes are possible either for all users or only for certain user groups.

To define new functions, AdoScript is used. This e.g. enables the design of:

• interfaces to objectiF and case 4/0 (manufacturer: microtool)
• new menu items and smart icons (actions)
• EventHandlers

Hint

Please refer to the appropriate chapters of the documentation for details.

The language for the external coupling is based on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal	Definition
ExternalTools :	[ Case40Classes ] [ ObjectifClasses ] { SetAccess | ToolsItem | EventHandler
Case40Classes :	CASE { CLASS className } .
ObjectifClasses :	OBJECTIF { CLASS className } .
SetAccess :	SET_ACCESS usergroup: UserGroupSpec mode: AccessMode .
UserGroupSpec :	strValue | all .
AccessMode :	blocked | protected| full .
ToolsItem :	ITEM [ itemText | separator ] { name_ langCode : itemText } { Component } [ sub-of: strValue ] { sub-of_ langCode : strValue } [ pos1: intValue ] [ pos2: intValue ] [ pos3: intValue ] AdoScript .
Component :	ComponentName [ : itemName ] { ComponentName _ langCode : itemName } .
ComponentName :	[ acquisition ] [ modeling ] [ analysis ] [ simulation ] [ evaluation ] [ importexport ] .
EventHandler :	ON_EVENT eventName { AdoScript } .
CheckCC:	CHECK_CC_AT_COMPILE_TIME [ off ] .

Attention

An_AdoScript_ belonging to the AdoScript will never be put into brackets. An_AdoScript_ belonging to the ON_EVENT must always be put into brackets.

Hint

langCode are two lower case letters defining a language according to ISO-639. As an example, german itemText can be specified with name_de.

Menu extensions:

With the ITEM constructs a new menu item can be defined. It will be inserted into the quoted component (or the quoted components) in the menu. The name of the menu item (itemText) will be quoted directly behind the keyword ITEM. Behind the component quotation the name of the insertion in the menu bar (itemName) will be quoted. If this quotation is left out the name of the "tool" will be set as name. It can be a new or an already existing insertion in the menu bar. If there is no insertion in the menu bar with the quoted name it will be inserted automatically. New menu items can not only be inserted into the menus which belong to the insertions of the menu bar but also to the sub menus. In this case the insertion has to be specified with sub-of which is connected with the submenu.

With pos1 the position of the insertion can be determined in the menu bar. With no quotation it will be inserted prior to the "Extras" menu. With pos2 or pos3 the position in the menu or the sub menu can be determined. With no quotation it will be added on the end.

An accelerator can be defined through a tilde ~ prior to the accelerator of the desired letter. If there is no tilde in the name the accelerator will be generated automatically.

If the so defined menu item is called in the Modelling Toolkit the ITEM belonging to AdoScript will be executed.

As it is possible to select a language during login, do-it-yourself **ITEM **s have to be multilingual too, if this option is active. If only one language is available, a definition may look like: ITEM "Test" modeling:"Extras" sub-of:"Submenu" This adds a menu entry "Extras - Submenu - Test" to the menu bar of the Modelling Component. If more than one language is available, all further text items have to be specified with name_<language> and sub-of_<language>. If German (default) and English are available, a definition could look like: ITEM "Kaese" name_en:"Cheese" modeling:"Brot" modeling_en:"Bread" sub-of:"Ei" sub-of_en:"Egg" In this case the German menu entry is "Brot - Ei - Kaese" while the English one is "Bread - Egg - Cheese".

EventHandler:

EventHandler are Ado Scripts, which are executed when determined events happen. The available events are described in the chapter "Event Handler" .

Access rights for user groups:

With SET_ACCESS the following ITEM s can be determined user group specific. As standard all insertions are accessible for all user groups i.e. all defined extensions are available for all users. If the following insertions should be invisible to a user group the user group must be set mode:blocked. To make insertions visible but not selectable set the mode to mode:protected. With mode:full you set the access right for a user group to full access.

If a user belongs to more user groups he will get the maximum access right for this user group.

In order to define the access rights for all user groups at the same time, usergroup:all should be used. It would be particularly useful, when access to one particular function should be limited and e.g. be allowed only for administrators.

case/4/0 and objectiF interface:

For every class listed (classname), the context menu (right mouse button) of the object of this class contains a menu entry "case/4/0" or "objectiF".

Default settings (Modelling)

The library attribute Default settings is a place for storing different patterns of behaviour for new models:

• Snap-grid settings
• Move references on "Save as" and "Paste"
• Cardinality checks
• Switch to US time format
• SVG options
• Password restrictions
• Gradient printing
• Increase model change counter
• Layout algorithms
• Layers

The general language for Default settings is based on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal	Definition
DefaultSettings :	[ Grid ] [ MoveRefsOnSaveAs ] [ CheckCardinalities ] [ FormatSettings ] [ SVGOptions ] [ PasswordRule ] [ ChangeCounterDef ] [ GradientPrinting ] { LayoutAlgorithm } {LayoutAlgOfVariant} [ Layers ] {Action} .
Grid :	GRID [ snap: SwitchModifier ] [ visible: SwitchModifier ] [ x: measureVal ] [ y: measureVal ] [ w: measureVal ] [ h: measureVal ] .
SwitchModifier :	on | off .
MoveRefsOnSaveAs :	MOVE_REFS_ON_SAVEAS mode: MoveRefsMode .
MoveRefsMode :	all | if-all-writeable | none .
CheckCardinalities :	CHECK_CARDINALITIES before-save: boolVal after-modeling-action: boolVal .
FormatSettings :	FORMAT time:locale:"US" .
SVGOptions :	SVG_GENERATION [ generateOnClick: boolVal ] [ generateOnMouseDown: boolVal ] [ generateOnMouseUp: boolVal ] [ generateOnMouseOver: boolVal ] [ generateOnMouseMove: boolVal ] [ generateOnMouseOut: boolVal ] [ clickRegionCursorHand: boolVal ] [ generateConnectorClickRegion: boolVal ] [ SVGClassesOptions ] .
SVGClassesOptions :	{ { ClassDef } } .
ClassDef :	CLASS className [ generateOnClick: boolVal ] [ generateOnMouseDown: boolVal ] [ generateOnMouseUp: boolVal ] [ generateOnMouseOver: boolVal ] [ generateOnMouseMove: boolVal ] [ generateOnMouseOut: boolVal ] [ clickRegionCursorHand: boolVal ] [ generateConnectorClickRegion: boolVal ] .
PasswordRule :	PASSWORD_RULE regExpr errMsg: strVal .
ChangeCounterDef :	INCR_CHANGE_COUNTER_OF_SOURCE_MODELS enable: boolVal .
GradientPrinting :	GRADIENT_PRINTING mode: GradientPrMode .
GradientPrMode :	default | first-color | avg-color .
LayoutAlgorithm :	{ WithoutSwimlanes | WithSwimlanes } .
WithoutSwimlanes :	LAYOUT_ALGORITHM "Without swimlanes" [ name: strValue ] { name_<langcode>: strValue } [ orientation: Orientation] [ raster-width: measureValue] [raster-height: measureValue ] .
WithSwimlanes :	LAYOUT_ALGORITHM "With swimlanes" [ name: strValue ] { name_<langcode>: strValue } swimlane-creation-attr: strValue swimlane-classname: strValue [ raster-width: measureValue] [raster-height: measureValue] .
Orientation :	horizontal | vertical .
LayoutAlgOfVariant :	LAYOUT_ALGORITHM_OF_VARIANT modeltype: strModelTypeName variant: strVariantName algname: strLayoutAlgorithmName .
Layers :	LAYERS [ swimlanes: SwimlanesLayer ] [ grid: GridLayer ] .
SwimlanesLayer :	first | layer .
GridLayer :	first | intValue .
Action:	ACTION actionName [ visible: boolValue ] .

boolVal is an integer value, where 0 means false, any other value means true and a specification without a value means also true.

regExpr is a string which is interpreted as regular expression.

Hint

ClassesDef (from SVGClassesOptions) always has to be put in curly braces.

Snap grid settings:

The language for the snap grid settings is based on the following syntax:

Non-terminal	Definition
Grid :	GRID [ snap: SwitchModifier ] [ visible: SwitchModifier ] [ x: measureVal ] [ y: measureVal ] w: measureVal h: measureVal .
SwitchModifier :	on | off .

The snap-grid can be activated (snap:on) or deactivated (snap:off) and faded in (visible:on) or faded out (visible:off). The horizontal (w) and vertical (h) distance between the grid-coordinates as well as the right (x) and the upper (y) offset of the snap-grid in cm can also be defined.

Example:

GRID snap:on visible:off w:0.5cm h:0.5cm x:0cm y:0cm

The snap grid is activated but faded out, the distance between the grid-coordinates both horizontally and vertically is 1/2 cm without offset.

Move references on "Save as" and "Paste":

The language for the references settings is based on the following syntax:

Non-terminal	Definition
MoveRefsOnSaveAs :	MOVE_REFS mode: MoveRefsMode .
MoveRefsMode :	all | from-writeable-models | none .

When saving models in the ADOxx Modelling Toolkit via "Save as" option or when pasting model content it is possible to move ingoing references in the active model from the old instances to the new ones - even if some of the superordinated models have read-only access rights. As this can lead to confusion, it is possible to limit this behaviour:

• The mode all means that references from any source model can be moved on "Save as" or "Paste" - even if the source model is write-protected.

• The mode from-writeable-models means that just references from writeable models can be moved. In case of having some changeable and some write-protected source models here, the user can decide whether just the changeable or no references shall be moved.

• The mode none means that the moving of references on "save as" is disabled completely. All incoming references are always left unchanged.

Cardinality checks:

The language for cardinality checks is based on the following syntax:

Non-terminal	Definition
CheckCardinalities :	CHECK_CARDINALITIES before-save: boolVal after-modeling-action: boolVal .
boolVal :	0 | 1 .

boolVal is an integer value either 0 = false, or 1 = true. In the basic settings both checks are deactivated (0). If the before-save check is active, flawed models are not saved.

Switch to US time format:

The language for the time format switch is based on the following syntax:

Non-terminal	Definition
FormatSettings :	FORMAT time:locale:"US" .

By default, clock times in ADOxx are displayed in the European 24-hour format. With this command, the time format is switched to the US AM/PM format.

Hint

At the moment, no other time formats are available. Therefore, every other specification means "European 24-hour format".

SVG options:

The language for the SVG options is based on the following syntax:

Non-terminal	Definition
SVGOptions:	SVG_GENERATION [ generateOnClick: boolVal ] [ generateOnMouseDown: boolVal ] [ generateOnMouseUp: boolVal ] [ generateOnMouseOver: boolVal ] [ generateOnMouseMove: boolVal ] [ generateOnMouseOut: boolVal ] [ clickRegionCursorHand: boolVal ] [ generateConnectorClickRegion: boolVal ] [ SVGClassesOptions ] .
SVGClassesOptions :	{ ClassesDef } .
ClassesDef :	CLASS ClassName [ generateOnClick: boolVal ] [ generateOnMouseDown: boolVal ] [ generateOnMouseUp: boolVal ] [ generateOnMouseOver: boolVal ] [ generateOnMouseMove: boolVal ] [ generateOnMouseOut: boolVal ] [ clickRegionCursorHand: boolVal ] [ generateConnectorClickRegion: boolVal ] .

Hint

ClassesDef (from SVGClassesOptions) always has to be put in curly braces.

The attributes, their default values and meaning:

generateOnClick

1: The event "onclick" is available in the SVG file (default). 0: The event "onclick" is not available in the SVG file.

generateOnMouseDown

1: The event "onmousedown" is available in the SVG file. 0: The event "onmousedown" is not available in the SVG file (default).

generateOnMouseUp

1: The Event "onmouseup" is available in the SVG file. 0: The event "onmouseup" is not available in the SVG file (default).

generateOnMouseOver

1: The event "onmouseover" is available in the SVG file. 0: The event "onmouseover" is not available in the SVG file (default).

generateOnMouseMove

1: The event "onmousemove" is available in the SVG file. 0: The event "onmousemove" is not available in the SVG file (default).

generateOnMouseOut

1: The event "onmouseout" is available in the SVG file. 0: The event "onmouseout" is not available in the SVG file (default).

clickRegionCursorHand

1: The mouse pointer changes into a hand symbol upon reaching the click region. 0: The mouse pointer does not change upon reaching the click region (default).

generateConnectorClickRegion

1: For the connector, its AttrSpots and HotSpots click regions are generated. 0: No click regions are generated for the connector (default).

Password restrictions:

With this option, users changing their password in the ADOxx Modelling Toolkit can be forced to enter only passwords of a given type. The language for the password restriction is based on the following syntax:

Non-terminal	Definition
PasswordRule :	PASSWORD_RULE regExpr errMsg: strVal .

The rule has to be defined as a regular expression. Additionally, an error message has to be specified which is displayed when a user tries to set a new password which does not match the defined password restriction rule. The rule is just effective for the password changing dialogue.

Example:At least six characters

PASSWORD_RULE ".{6,}" errMsg:"The password must have a length of at least six characters!"

Gradient printing:

Some printer device drivers have problems with printing colour gradients. Sometimes whole gradients or parts of them are missing. If no error-free printer is available, another filling method can be specified using GRADIENT_PRINTING. These variants are available:

• default: The normal gradient filling is printed.
• first-color: Instead of a gradient, a solid filling is printed using the first colour of the gradient.
• avg-color: Instead of a gradient, a solid filling is printed using the average colour of the gradient.

Increase model change counter:

When changing a name of a model or of an object, INTERREF attributes referencing this model or object are updated implicitly. Actually this is not a modification of the source models - the references themselves keep unchanged. However, from the perspective of a user, the referencing models do change - the displayed INTERREF attribute values are not the same as before the renaming action. This is especially of importance at the "delta generation" (cf. ADOxx user manual). The language for the model change counter is based on the following syntax:

Non-terminal	Definition
ChangeCounterDef :	INCR_CHANGE_COUNTER_OF_SOURCE_MODELS enable: boolVal .

This function should always be activated, except the computer/network has low capacity and large pool models are renamed on a regular basis:

INCR_CHANGE_COUNTER_OF_SOURCE_MODELS enable:1

Layout algorithms:

Two layout algorithm classes are currently available: "Without swimlanes" and "With swimlanes". Each layout algorithm class can be instantiated multiply. This makes sense if the parameters of two instances of the same layout algorithm class are different. For example, multiple "With swimlanes" layout algorithm instances could be created, each parameterized with another swimlane class.

DefaultSettings :

...{ LayoutAlgorithm}{ LayoutAlgOfVariant}...

LayoutAlgorithm :

{ WithoutSwimlanes | WithSwimlanes } .

WithoutSwimlanes :

LAYOUT_ALGORITHM "Without swimlanes" [ name: strValue ] { name_<langcode>:strValue } [orientation: Orientation] [raster-width: measureValue] [raster-height: measureValue] .

WithSwimlanes :

LAYOUT_ALGORITHM "With swimlanes" [ name: strValue ] { name_<langcode>:strValue } swimlane-creation-attr: strValue swimlane-classname: strValue [ swimlane-objref-attr: strValue ] [raster-width: measureValue] [raster-height: measureValue] [minimize-bp-count: boolValue]

Orientation :

horizontal | vertical .

LayoutAlgOfVariant :

LAYOUT_ALGORITHM_OF_VARIANT modeltype: strModelTypeNamevariant: strVariantName algname: strLayoutAlgorithmName

The parameter name of a layout algorithm instance is used as text for the menu entry related to the execution of that layout algorithm. If no name is specified, the (localized) layout algorithm class name is used. A language-specific name can be specified with lang_<langcode> , where langcode is an ISO-638 language code. For example, a name for the English UI would be specified with name_en.

WithoutSwimlanes:

The algorithm "Without swimlanes" can be applied on Dynamic models containing "BP_Event" instances and "subsequent" relation instances. The algorithm deletes all swimlanes (if any existing) and arranges the flow objects in flow direction from left to right (orientation:horizontal) or from top to bottom (orientation:vertical). The minimum horizontal and vertical distances between modelling objects are specified with raster-width and raster-height, where the default values are raster-width:6cm and raster-height:4cm.

WithSwimlanes:

The algorithm "Without swimlanes" can be applied on Dynamic models containing "BP_Event" instances and "subsequent" relation instances. The algorithm creates swimlanes of the swimlane class specified with swimlane-classname. With the optional parameter swimlane-objref-attr an attribute name of the swimlane class can be specified. That attribute must be of same type as the swimlane-creation-attr attribute. For all modeling objects the value of the attribute specified with swimlane-creation-attr is examined and for each different value a swimlane is created. The modelling objects are then placed in the related swimlanes. For objects without the swimlane creation attribute the related swimlane is the same as for the previous object (or for the next object if no previous object with a swimlane creation attribute is exising). If a swimlane creation attribute is empty, the space below (resp. right of) the last swimlane is used.

With the optional parameter swimlane-objref-attr an attribute name of the swimlane class can be specified. That attribute must be of same type as the swimlane-creation-attr attribute.

The names of the created swimlanes are the same as the values of the related swimlane creation attributes. If the swimlane creation attribute is of type INTERREF, the name of the referenced object is used as attribute value. The minimum horizontal and vertical distances between modelling objects are specified with raster-width and raster-height, where the default values are raster-width:6cm and raster-height:4cm.

Layers:

Layers :

LAYERS [ swimlanes: SwimlanesLayer ] [ grid: GridLayer ] .

SwimlanesLayer :

first | layer .

GridLayer :

first | intValue .

By default, swimlanes and grids are drawn before any other graphical objects ("at the bottom"). If swimlanes shall be drawn in other layers defined in each GraphRep, swimlanes:layer has to be specified. If grids shall be drawn in a certain layer, the layer index has to be specified with grid.

Actions:

Action :

ACTION actionName [ visible: boolValue ]

If all customized variants are related with layout algorithms, usually the variants related actions "Settings" and "Excluded objects" should not be used.

Page layouts (Modelling)

The library attribute "Page layouts" exists in both types of library (D library and S library). The page layouts defined here are available for all models of a type defined in the particular library. Usually, the attribute "Page layouts" in an application library has the same value in both the D and the S library.

Using the page layout the formats for printing models are defined. One of the layouts defined can be assigned at any time to any model. It will be used when printing the model. The layout can be selected via the "Page layout" option on the printing screen. Among other things, a layout defines the size of the printed page available for the model. The margin resulting from this can be made visible as broken lines on the drawing area so that the ADOxx user can already see the measurements of his model during a modelling session.

Via page layouts, model printing formats are defines. Every model can be assigned one of the defined layouts at any time which is then used for printing. The desired page layout can be selected via the menu entry "Page layout". A layout definition contains e.g. the definition of the printable area on one page. The resulting page borders can be shown as a dashed line in the graphical modelling editor, telling the user if an object would be printed on two pages.

There is no limit for the number of page layouts (except the 3700 characters max length of the STRING attribute type). A new model automatically gets the first defined layout. Three layouts are defined internally and neither can be deleted nor hidden: The "ADOxx standard page layout", the "ADOxx standard page layout for tables" and "Posters with adhesive tabs". These are always last in the list.

The language for defining page layouts is based on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal	Definition
PageLayouts :	{ PageLayout } .
PageLayout :	LAYOUT layoutName [ for-models ] [ for-reports ] [ orientation: Orientation ] [ graphrep: AttrName ] { Pen | Fill | HeadArea | BitmapArea | PageArea | FootArea } . Hint: HeadArea,BitmapArea and FootArea may appear at most once, PageArea must appear exactly once per layout.
Orientation :	portrait | landscape .
Pen :	PEN [ w: width ] [ style: PenStyle ] [ color: colorSpec ] .
PenStyle :	solid | dot | dash | dashdot
Fill :	FILL [ style: BrushStyle ] [ color: colorSpec ] [ fcolor: colorSpec ] [ transparent ] .
BrushStyle :	solid | horz | vert | cross | diagcross | updiag | downdiag | mix25 | mix50 | mix75 | null .
HeadArea :	HEAD PosSize { FixedText | ModelAttribute | Font } .
BitmapArea :	BITMAP [ bmpFileName ] PosSize { FixedText | ModelAttribute | Font } .
PageArea :	PAGE PosSize [ with-flaps ] [ left-margin: width ] [ top-margin: height ] { FixedText | ModelAttribute | Font } .
FootArea :	FOOT PosSize { FixedText | ModelAttribute | Font } .
FixedText :	TEXT text PosSize [ line-break: LineBreakMode ] .
ModelAttribute :	ATTR modelAttrName PosSize [ line-break: LineBreakMode ].
PosSize :	[ XCoord ] [ YCoord ] [ Width ] [ Height ] .
XCoord :	x: xpos | x: XCoordFlags [: xpos] .
XCoordFlags :	l | c | r .
YCoord :	y: ypos | y: YCoordFlags [: ypos] .
YCoordFlags :	t | c | b .
Width :	w: width | w: WidthFlags[: width] .
WidthFlags :	[ p ] [ l | c | r ] .
Height :	h: height | h: heightFlags[: height] .
HeightFlags :	[ p ] [ t | c | b ] .
LineBreakMode :	off | words | rigorous .
Font :	FONT [ fontName ] [ h: fontHeight ] [ bold ] [ underline ] [ italic ] [ color: ColorSpec ] .

A layout definition starts with the keyword LAYOUT, followed by a name in quotation marks. Since you select the page layout by the name assigned here, the name should somehow characterise the layout.

Two page layouts for two scenarios are distinguished: for-reports: this parameter defines that the layout is only used for printing tables (browser). for-models: this parameter defines that the layout is only used for printing model graphics. If neither for-reports nor for-models is defined, then the layout can be used for both purposes.

There are four sections in the layout definition which start with the following keywords:

	Description
PAGE	Definition of an area on the printed page (model area), available for printing the model. From this, you can also derive the size of the page which may be displayed in the model editor.
HEAD	Definition of position and size of the header. The header can contain texts, model attributes and print attributes such as the printing date.
FOOT	Definition of position and size of the footing. The footing can contain texts, model attributes and print attributes such as the printing date.
BMP	Definition of an area into which a bitmap is inserted.

These sections can have any arbitrary order you wish.

Hint

In any case, PAGE must occur once per layout definition, HEAD, FOOT and BMP are optional.

The following elements may be used within the PAGE, HEAD, FOOT and BMP sections:

	Description
TEXT	Specify text to be displayed in a defined position in the current section. This will usually be the header or the footer. The text may contain tokens which are replaced by print attributes during the printing. %D is replaced by the printing date, %P by the current page number, %N by the total number of pages and %# by a reference to adjacent pages. In the case of %# a directing arrow with the respective page's number is set for each one of the (at most) four adjacent pages. Please take care that a font which contains arrows as special symbols is specified for this purpose (such as "Symbol" under NT or "Symbol Set" under OS/2).
ATTR	Specify a model attribute to be displayed in the current section at the position specified.
FONT	Change the current font (font type, font height and font style). This effects the following TEXT and ATTR output. Using the FONT element you can define the font type (fontName) by the name following the keyword and the font height (fontHeight) by the attribute h. You may also combine the styles bold,underline and italic.

The_XCoordFlags_ have the following meaning:

	Description
l	Default setting; in the cases of PAGE,HEAD, FOOT and BMP the coordinate refers to the left margin of the printed page, in the cases of TEXT and ATTR to the left margin of the current area.
c	The coordinate refers to the horizontal centre.
r	The coordinate refers to the right margin.

The_YCoordFlags_ have the following meaning:

	Description
t	Default setting; in the cases of PAGE,HEAD, FOOT and BMP the coordinate refers to the upper margin of the printed page, in the cases of TEXT and ATTR to the upper margin of the current area.
c	The coordinate refers to the vertical centre.
r	The coordinate refers to the bottom margin.

The_WidthFlags_ have the following meaning:

	Description
p	The printed page's width is added to the width value, i.e. only a width value <= 0 is sensible here. This flag is only effective in the cases of PAGE, HEAD,FOOT and BMP. The current page size is taken from the printer's settings.
l	Alignment to the left with regard to the x-coordinate. Default setting for PAGE, HEAD,FOOT and BMP.
c	Horizontal centring with regard to the x-coordinate. Default setting for TEXT and ATTR.
r	Alignment to the right with regard to the x-coordinate.

The_HeightFlags_ have the following meaning:

	Description
p	The printed page's height is added to the height value, i.e. only a height value <= 0 is sensible here. This flag is only effective in the cases of PAGE,HEAD, FOOT and BMP. The current page size is taken from the printer's settings.
t	Alignment to the top with regard to the y-coordinate. Default setting for PAGE, HEAD,FOOT and BMP.
c	Vertical centring with regard to the y-coordinate. Default setting for TEXT and ATTR.
b	Alignment to the bottom with regard to the x-coordinate.

For BMP a bitmap file ( bmpFileName ) will be loaded and adjusted in a rectangle through some given coordinates. The BMP file will be loaded from a file system with a name fileName . Please remember to enter a path and a file name of the BMP file in inverted commas.

Hint

The backslashes (\) in the path specification of the bitmap file must be masked by '\' as in c:\\bitmaps\\logo.bmp for the file "logo.bmp" in the directory "bitmaps" on the partition "C:").

Hint

For the including of bitmap files which are saved as external files in theADOxx-databasequote as path 'db:\' (e.g. "db:\\logo.bmp" for the in the database saved file "logo.bmp").

Hint

If no bitmap is specified or if the file specified does not exist, the BOC logo will be used.

Hint

The ratio of the sides of the rectangle defined in BMP should match the one of the bitmap, otherwise the diagram will be printed in a distorted way.

At the FONT element, the font size (font height) will be determined which overrules the assigned name of the font and the attribute h.
Furthermore the following styles can be combined as you like:

• bold - bold letters.
• underline - underlined.
• italic - cursive font.

Over PEN and FILL analog to the GraphRep - the squaring and filling of the parts PAGE, HEAD, and **FOOT **can be determined. Default at HEAD and FOOT is PEN color:black FILL color:$f0f0f0 # hellgrau, $f0=240 but the PAGE-square with PEN color:black FILL style:null .

GraphRep for complex layouts:

It is possible to use GraphRep-Syntax for defining page layouts. This enables integrating more than one graphic file, using colour gradients and more.

Hint

Complex layouts are only available after a special modification of the application library . Please contact your ADOxx consultant for details.

Connector marks - Numbering / Graphical representation (Modelling)

The connector mark definition in a library is based on two attributes:

• Numbering

• Graphical representation

"Numbering" is of type ENUMERATION and describes, how the connector marks are numbered in the models. Two options are available:

	Description
numerical	Arabic numerals (1, 2, 3 ...)
alphabetically	letters (A, B, C ..., AA, AB, ...)

The graphical representation of the connector marks is defined in the library attribute "Graphical representation". The syntax for it is based on the GraphRep grammar (graphical representation of classes and relations). A special variable, called isoutgoing, is available. With a value of 1, the connector is outgoing, if the value is 0 it is ingoing. This enables a different look for the two connector marks of a pair. Another predefined variable is cindex, which holds the connector number (as string). Internally, to the connector mark's GraphRep always a TEXT element is appended, which shows the connector number by outputting the value of cindex at the connector mark's origin. The connector number is shown anyway, but cindex could be used to determine the needed width for the connector number. The font of the connector number can be changed by adding a FONT element at the end of the connector mark's GraphRep.

Examples of connector marks:

	Description
Circle:	The attribute value GRAPHREP ELLIPSE rx:.3cm ry:.3cm creates a circle (e.g. ).
Triangle:	The attribute value GRAPHREP POLYGON 3 x1:-.3cm y1:.25cm y2:-.35cm x3:.3cm y3:.25cm creates a triangle (e.g. ).
Square:	The attribute value GRAPHREP RECTANGLE x:-.3cm y:-.3cm w:.6cm h:.6cm creates a square (e.g. ).
Pentagon:	The attribute value GRAPHREP FILL color:aliceblue PEN w:0.03cm IF (isoutgoing) { POLYGON 5 x1:-0.3cm y1:-0.3cm x2:0.3cm y2:-0.3cm x3:0.3cm y3:0.25cm x4:0cm y4:0.35cm x5:-0.3cm y5:0.25cm } ELSE { POLYGON 5 x1:-0.3cm y1:-0.25cm x2:0cm y2:-0.35cm x3:0.3cm y3:-0.25cm x4:0.3cm y4:0.3cm x5:-0.3cm y5:0.3cm } creates a pentagon in the shape of a house with different in- and outgoing parts.

Hint

The numbering of the connector marks is exactly nine pixels high. The breadth depends on the letter(s) or the number displayed.

Object arrangement (Modelling)

The attribute "Object arrangement" allows you to define the characteristics of one or more object arrangement functions of the process hierarchy function and of the numbering function.

Hint

The way the three function types mentioned above work is documented in the ADOxx user manual.

The language for defining the object arrangement function is based on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal	Definition
TotalConfiguration :	[ ArrangeConfiguration ][ EnumConfiguration ][ MenuConfiguration ] .
ArrangeConfiguration :	[ Parameterset ][ Hierarchyset ] .
Parameterset :	PROFILE " Functionname " [ type:Profiletype ] DefinedModeltypes Parameters [ BibParameterset ] .
Profiletype :	std | cust .
DefinedModeltypes :	DEFMODELTYPE " Modeltypename " [ DefinedModeltypes ] .
Parameters :	[ BendPointParameters ][ MinCrossingParameters ][ PendulumParameters ][ FlipflyParameters ][ DoubleBendPointParameters ][ ChangesizeParameters ] .
BendPointParameters :	BEND [ points | edges ] .
MinCrossingParameters :	MINCROSS [ upon ][ upcount: countVal ][ dwnon ][ dwncount: countVal ][ pairwise ][ paircount: countVal ] .
PendulumParameters :	PENDULUM [ upon ][ upcount: countVal ][ dwnon ][ dwncount: countVal ][ rubband ][ rubcount: countVal ] .
FlipflyParameters :	FLIPFLY [ mirrhor ][ mirrvert ]FlipflyWay .
FlipflyWay :	dwn | up | toright | toleft .
DoubleBendPointParameters :	DOUBLEBP dist: countVal .
ChangesizeParameters :	CHNGSIZE vertdist: countVal hordist: countVal .
BibParameterset :	{ ClassParameters }{ ClassPairParameters } .
ClassParameters :	CLASSMODELTYPE " Modeltypename " { ClassParameterLine } .
ClassParameterLine :	CLASSPAR " Classname " turn: boolVal space: countVal priority: countVal .
ClassPairParameter :	CLASSPAIRMODELTYPE " Modeltypename " { ClassPairParameterLine } .
ClassPairParameterLine :	CLASSPAIRPAR first:" FirstClassname " second:" SecondClassname " xdist: countVal ydist: countVal .
Hierarchyset :	HIERPROFILE [ " HierFunctionname " ] use:" Functionname " { HierParameters } .
HierParameters :	HIERMODELTYPE " Modeltypename " usetype:" UseModeltypename " { HIERCLASS " Classname " } HIERATTRIB " Attributename " HIERUSECLASS " UseClassname " HIERUSEREL " UseRelname " [ relturn ] .
EnumConfiguration :	ENUMPROFILE [ " EnumFunctionname " ] { Modtypeenumset } .
Modtypeenumset :	ENUMMODELTYPE " Modeltypename " { EnumRel | EnumClass } .
EnumRel :	ENUMREL " Relname " [ enumturn ] .
EnumClass :	ENUMCLASS " Classname " [ attrib:" UseAttributename " ][ inflow ] .
MenuConfiguration :	DISABLE [ arrange ][ edit ] [ enum ][ hier ] .

ArrangeConfiguration defines both the Object arrangement Function and the Hierarchy function. The settings of the Numbering Function are specified in EnumConfiguration.

Hint

An object arrangement function defined in the application library can be copied in the Modelling Toolkit, and can be changed as well as saved as a user-defined object arrangement function in the ADOxx database.

MenuConfiguration provides the possibility to DISABLE the menu options for the object arrangement, the model hierarchy and the numbering function in the modelling component of the Modelling Toolkit with the following definitions:

	Description
arrange	The menu option "Arrange" (menu "Edit") is disabled, i.e. the ADOxx user can neither use the object arrangement functions defined in the application library nor create user-defined object arrangement functions.
edit	The sub-menu option "Arrangement Assistant" (option**"Arrange"** - menu "Edit") is disabled, i.e. the ADOxx user can use the object arrangement functions defined in the application library but not create any.
enum	The option "Number Objects" (menu "Edit") is disabled, i.e. the ADOxx user can not use the numbering functions defined in the application library.
here	The sub-menu option "Process Hierarchy (graphical)" (option "Search Models" - menu "Model" is disabled, i.e. the ADOxx user can not use the model hierarchy functions defined in the application library.

Relation analysis (Analysis)

With the help of relation analysis you can create relation tables which show for a model of a given type the existing connectors of one class of relations between two object classes. The term "relation" has a wide meaning in this context. The relation tables are based on AQL, i.e., to determine which relations exist AQL is being used. The relation tables can be selected in the Analysis Component of the Modelling Toolkit via the menu "Relation tables".

The language for the definition of relation tables is based on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal	Definition
Tabledefinition :	{ Table } .

| Table : | RELATIONTABLE " Tablename " [ modeltype:" Modeltype-name " ] fromclass:" FromClass-name " fromattribute:" FromAttribute-name " [ tomodeltype:" ToModeltype-name " ] toclass:" ToClass-name " toattribute:" ToAttribute-name " Aql | Rel . | | Rel : | relation:" Relation-name " [ attribute:" Relationattribute-name " ] . | | Aql : | { EXPR " Aql expression part " | FOREACHFROM } . |

There are two possible definitions for relation tables:

• The relation between two classes (the "Rel" case)
• Via AQL expression (the "Aql" case)

The relation between two classes (the "Rel" case)

Its semantics are as follows:

A relation table presents all existing connectors of the given relation between objects from two different classes. However, it can be done for only one model (due to the defined fromclass and toclass, which defines in this case a starting and a target class).

RELATIONTABLE element defines the name of the relation table (Tablename), which is then shown in menu "Relation tables".

Hint

Names of relation tables must be clearly defined in an application library!

If desired, the system can also display the model type (Modeltypename).

Hint

If the model type is not displayed, it means that the standard model type (= on the first place of library attribute "Modus", belonging to the defined modeltype) was not accepted in the particular library.

The value of the objects which are shown in the ADOxx browser are defined via fromattribute or toattribute. It allows you to visualise other attributes as object names. The existence of a connector between two objects is represented with an 'x'. If there is an attribute, the system will show the value of this attribute.

Example:

RELATIONTABLE "Activity-Resource table"
fromclass:"Activity"
fromattribute:"Name"
toclass:"Ressource"
toattribute:"Name"
relation:"uses"

This definition shows each connector and the relation "uses", which exists between activities and resources.

Via AQL expression (the "Aql" case)

An AQL expression can be used here in order to present one (possibly transitive and model predominant) relation between any two classes. In this case these two classes can come from two different model types. The AQL expression is dynamically built up from FOREACHFROM and EXPR and evaluated for each object of the starting class. The part FOREACHFROM presents reference to an object of the starting class and is filed with the current object name. EXPR elements show those parts of the AQL expression, which are fixed and independent from the changing object names.

The name of the relation table (Tablename) is defined in the RELATIONTABLE element. This name is shown in Menu "Relation tables".

Hint

Relation table names must be clear in the application library!

If desired, the system can also display the model type (Modeltypename).

Hint

If the model type is not defined, it means that the standard model type (= on the first place of library attribute "Mode", belonging to the defined modeltype) is taken over to the current library.

Similarly to the Rel - case the target class defines the max number of objects of which relations will be shown. If the class is not in the same model type as the starting class,tomodeltype must be given. Due to this, the target class should be clearly identified via its name. It is also possible to visualise any attribute of the objects, by using_fromattribute_ or toattribute.

Ways of defining relation tables via FOREACHFROM and EXPR

In order to define relation tables with FOREACHFROM and EXPR the user has to define the AQL expression, which will display desired results for the concrete object of the starting class. In order to show e. g., which resources are used by the activity-4711, you need to use the following AQL expression:

{"Activity-4711"} -> "uses"

or alternatively

{"Activity-4711" : "Activity"} -> "uses"

.

Each part of the above AQL expression which contains names (eventually with the class) of the objects should be replaced with FOREACHFROM construction, because the final relation table should display all objects of the starting class. It will allow the dynamic use of the names of all instances.

Consequently, the AQL expression must be divided: {"Activity-4711"} or {"Activity-4711":"Activity"} will be replaced with FOREACHFROM and the rest with EXPR. As the other LEO elements (in the opposite to the above example) remain unchanged, the following LEO syntax is used:

RELATIONTABLE "Activities-Resource tables"
fromclass:"Activity"
fromattribute:"Name"
toclass:"Resource"
toattribute:"Name"
FOREACHFROM
EXPR "-> \"used\""

If a table showing who is the manager of whom should be created (for working environment), it should be started with a concrete performer:

{"Performer-1"} -> "is manager" \<- "belongs to"

The above expression displays all performers of an organisational unit, where performer-1 is the manager. If we presume that the organisational unit is modelled in such a way that the manager of the unit (additionally) belongs to it, it is reasonable to remove this particular performer from the list with results, as nobody is manager of himself:

{"Performer-1"} -> "is manager" \<- "belongs to" DIFF {"Performer-1"}

The dynamic parts must be replaced (i.e. the names of the concrete instances) - here are two examples of such a case. The rest is a part of EXPR:

RELATIONTABLE "Manager table"
fromclass:"Performer"
fromattribute:"Name"
toclass:"Performer"
toattribute:"Name"
FOREACHFROM
EXPR "-> \"is manager\" <- \"belongs to\" DIFF "
FOREACHFROM

Other examples:

To define a relation table between variables and activities you can use the following LEO syntax:

RELATIONTABLE "Variables-Table with activities"
fromclass:"Variable"
fromattribute:"Name"
toclass:"Activity"
toattribute:"Name"
FOREACHFROM
EXPR "<- \"create variable\" -> \"create\""

If the user reduces the relation table to the variables, which are used as objects occupying variables, and which are divided according to the discrete distribution, he can use the following LEOgram:

RELATIONTABLE "Variables-Activities table"
fromclass:"Variable"
fromattribute:"Name"
toclass:"Activity"
toattribute:"Name"
FOREACHFROM
EXPR "<- \"created variable\" [?\"Value\" like \"Discrete*\"] -> \"created\""

RELATIONTABLE "Activity-Organisational table"
fromclass:"Activity"
fromattribute:"Name"
tomodeltype:"Staticsmodel"
toclass:"Organisational unit"
toattribute:"Name"
FOREACHFROM
EXPR " --> \"Organisational unit\""

Simulation definition - Simtext (Simulation)

The attribute Simtext contains some user-specific expressions. These are used by ADOxx to label simulation results . The Simtext is used ...

• ... in the Path Analysis: in the result text

• ... in the Capacity Analysis, the Workload Analysis and the Analytical Evaluation: for labelling the table columns

Hint

The attribute "Simtext" is only defined for D libraries.

The language describing the definition of the Simtext is based on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal	Definition
Simtext :	SIMTEXT undefined | Settings .
Settings :	bp: " term for <business process> " cycletime: " term for <cycle time> " activity: " term for <activity> " number: " term for <number (count)> " actor: " term for <person> " perscost: " term for <personnel costs> " resource: " term for <resource> " rescost: " term for <resource costs> " .

Hint

The term "undefined" is automatically assigned, if an invalid simtext is detected during the conversion of an application library from ADOxx Version 1.3 or earlier to ADOxx Version 1.5. This expression causes ADOxx to ignore the complete simtext. In this case, you can neither execute a simulation nor an analytical evaluation unless the simtext is corrected and the expression "undefined" removed.

Attention

The Library check returns an error, if Simtext contains neither a definition nor "undefined"!

Simulation definition - Simmapping (Simulation)

"Simmapping" is an attribute of the D library. In this attribute, input sets for the Simulation and the Analytical Evaluation are defined. Furthermore, a group of classes can be defined which are then used in simulation-related Actions.

The language for the definition of the SimMapping is based on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal	Definition
SimMapping :	{ SimOption } [ SimClasses ] .
SimOption :	SIMOPTION [ invalid ] name: " option name " [ { name_ <iso639code> : " option name in ISO639 language " } ] activity: " name of activity-class " [ helptext: " info/help text for option " ] [ { helptext_ <iso639code> : " info/help text for option in ISO639 language " } ] [ executiontime: " attribute name of execution time " ] [ waitingtime: " attribute name of waiting time " ] [ restingtime: " attribute name of resting time " ] [ transporttime: " attribute name of transport time " ] [ userattribute-1: " additional attribute name 1 " ] [ userattribute-2: " additional attribute name 2 " ] ... [ userattribute-n: " additional attribute name n " ] [ PerformerAssignment (for Subprocesses) ] { SimActions } .
PerformerAssignment (for Subprocesses) :	processcall: " class name of subprocess call " subperformerattr: " attribute name of the default performer assignment for subprocesses " .
SimActions :	ACTION class: " class name " attribute: " attribute name " [ event: start | interrupt | continue | finish .
SimClasses :	SIMCLASSES bp-all | bp-none | [ bp-1: " bp class name " bp-2: " bp class name " ... bp-n: " bp class name " ] we-all | we-none | [ we-1: " we class name " we-2: " we class name " ... we-n: " we class name " ] .

Hint

The attribute defined with subperformerattr must be of type "Text" (STRING) or "Expression" (EXPRESSION).

ACTION Following this key word you can get process class ("class") and attribute of the type "Program call" ("attribute"). During simulation each object of the process class, which is processed, will automatically execute the proper program call. Optionally, the event: use can indicate when during simulation the process call should be used. However, the following events can be evaluated:

• start, when the process object that your dealing with was started,

• interrupt, when the process object that your dealing with is cancelled,

• continue, when the process object that was cancelled is continued,

• finish, when the process object that was cancelled was ended.

"event:start" is the standard value.

bp class name Name of a class from your ADOxx D library. With the expression bp- nr : " bp class name " you may specify as many classes as you wish, where nr is a serial number. This means that the additional class has to be specified by bp-1, the second class by bp-2 and so on. The classes specified in this manner are of importance for the ADOxx evaluation agents: only instances of the classes specified can be assigned as reference objects to the agents (in the ADOxx BPMS Application Library these classes are "Activity" and "Subprocess"). The specification of bp-all instead of bp- nr is equivalent to specifying all classes from your ADOxx D library. When an ADOxx D library is migrated from ADOxx Version 1.3 or earlier to ADOxx Version 1.5 the expression bp-all is automatically generated. We recommend that you replace this expression with a sensible selection of classes and do not use it when customising manually.

we class name Name of a class from your ADOxx S library. Using the expression we- nr : " WEClassName " you can specify as many classes as you wish, where nr is a serial number. That means, the first class has to be specified by we-1, the second class by we-2 and so on. Classes specified in this manner affect the assignment of agents and the result output of the simulation and the agents in the ADOxx Modelling Toolkit: No classes are available for agent assignment which have not been specified in this way. The result windows of the simulation and of the agents allow the aggregated representation of results which refer to the Static. No class which has not been specified before as described above is available as aggregation criterion.

Hint

Neither in the assignment of agents nor in the respective result windows are necessarily all classes specified available for selection.

The specification of we-all instead of we- nr is equivalent to the specification of all classes from your ADOxx S Library. When an ADOxx S library is migrated from ADOxx Version 1.3 or earlier to ADOxx Version 1.5 the expression we-all is automatically generated. We recommend that you replace this expression with a sensible selection of classes and do not use it when customising manually.

Multilinguality:

It is possible to assign values in different languages to name and helptext. The suffix "_<iso639code>" (e.g.helptext_en for English) must then be set. Upon starting ADOxx, the corresponding name/help text is used.

Leaving Simmapping undefined:

To formally correct leaving Simmapping undefined, the attribute must have the value: SIMPOTION invalid SIMCLASSES bp-none we-none

Hint

The expression "invalid" is automatically assigned, when an incorrect combination of input parameters is detected while an application library is migrated from ADOxx Version 1.3 or earlier to ADOxx Version 1.5. The expression causes ADOxx to ignore the SimOption specified this way.

Simulation definition - Sim result mapping (Simulation)

The attribute "Sim result mapping" defines which simulation results are written back into which attributes of a model when you click on the "Evaluation" button.

The language which defines the Sim result mapping for the dynamic library is based on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal

Definition

Simresultmapping :

[ PROCESSSTART " Name_of_processtart_class " [ fixedinfo:" Name_of_info_attribute " ][ fixedcycletime:" Name_of_cycletime_attribute " ][ fixedpersonalcosts:" Name_of_personalcosts_attribute " ]{ FROMCLASS " Name_of_fromclass " fromattribute:" Name_of_fromattribute " toattribute:" Name_of_toattribute " } ] [ ACTIVITY " Name_of_activity_class " [ fixedinfo:" Name_of_info_attribute " ][ fixednumber:" Name_of_number_attribute " ][ Fixedpersonalcosts:" Name_of_personalcosts_attribute " ]{ FROMCLASS " Name_of_fromclass " fromattribute:" Name_of_fromattribute " toattribute:" Name_of_toattribute " } ] .

The simulation results can only be transferred into the process start class (ProcessStartClassName) defined in PROCESSSTART or in the activity class (ActivityClassName) defined in ACTIVITY.

Hint

Should the simulation results be transferable to several instantiable process-start or activity classes, the sim result mapping must be defined on a common basis (parent) class.

The values of the "fixed" attributes listed below do not result directly from other attributes:

	Description
fixedinfo	Attribute of the Type STRING, in which information about the origin of the results (e.g. simulation algorithm, type of result, ADOxx user, date and time of the simulation, number of cycletimes and so on) is entered.
fixedcycletime	Attribute of Type TIME, where the total cycletime of the process is stored.
fixedpersonalcosts	Attribute of Type DOUBLE, where the total personnel costs of a process or the personnel costs of an activity are saved.
fixednumber	Attribute of Type INTEGER, where the frequency of occurrence of an activity is stored.

Attention

The "fixed" attributes have to be defined for the particular attribute type.

By FROMCLASS additional classes (FromClassname) may be selected and from the fromattribute attribute values (FromAttributename) specified. The selected attributes of this class can be transferred back through toattribute into the respective attribute (ToAttributename).

The language which describes the definition of the sim result mapping for the Static library is based on the following syntax:

Non-terminal	Definition
Simresultmapping :	[ PERSON " Name_of_person_class " [ fixedinfo:" Name_of_info_attribute " ][ fixedworkload:" Name_of_workload_attribute " ][ fixedcapacity:" Name_of_capacity_attribute " ][ fixedpersonalcosts:" Name_of_personalcosts_attribute " ]{ FROMCLASS " Name_of_fromclass " fromattribute:" Name_of_fromattribute " toattribute:" Name_of_toattribute " } ] .

Simulation results can only be transferred into those performer classes (PersonClassName) defined in PERSON.

Hint

Should the simulation results be transferable to several instantiable performer classes, the simresult-mapping must be defined on a common basis (parent) class.

The values of the "fixed" attributes listed below do not directly result from other attributes:

	Description
fixedinfo	Attribute of the type STRING, where information about the origin of the results (e.g. simulation algorithm, type of result, ADOxx user, date and time of the simulation, number of cycletimes and so on) is stored.
fixedworkload	Attribute of type DOUBLE, where the workload of a performer is stored.
fixedcapacity	Attribute of type DOUBLE, into which the capacity of a performer is stored.
fixedpersonalcosts	Attribute of type DOUBLE, into which the personnel costs of a performer are entered.

Attention

The "fixed" attributes must be defined for the corresponding attribute type.

By FROMCLASS additional classes (FromClassname) may be selected and by fromattribute attribute values (FromAttributename) specified. The selected attributes of this class can be transferred back through toattribute into the respective attribute (ToAttributename).

Simulation definition - Variable check (Simulation)

The attribute "Variable check" defines whether the models have to undergo an extended consistency check before the simulation.

Selecting "on" (default setting) causes an appropriate error statement to occur, if uninitialised variables are used in the models to be simulated.

When the variable check is switched off ("off"), the simulation can also run if not initialised variables exist.

Agent definition (Simulation)

Knowledge of the agent evaluation concept is a necessary pre-condition for understanding the description of agent customising. For this, read the general introduction to the ADOxx evaluation agents in the ADOxx user manual.

With the help of the attribute "Agent definition" evaluation agents may be predefined in the application library - in part or in total. These predefined agents are then available in the window "Agents overview" in the Simulation Component of the Modelling Toolkit. They serve as templates ("Agent Types") for the creation of other agents.

Agent types are defined by entering text in the agent definition language described below. Each type of agent is described by a separate paragraph. When defining several agents a number of paragraphs may be linked to each other.

Hint

The maximum length allowed for the definition of an agent is 32,000 symbols.

Basically, the definition of an agent types always consists of two parts:

1. Specification of general setting concerning the agent as a whole.

2. Selection and configuration of the results to be determined. Each agent can calculate as many results as you wish. Specific settings have to be made during the customising for each of these results.

An example of the agent definition language with comments explains the connections and definition.

Enterprise Time - Days per year (Simulation)

An attribute where the basic settings for the working days per year can be specified.

The attribute value "Days per year" is used in combination with the attribute value "Hours per day" in the Simulation Component to convert the times into enterprise times (see user manual, chapter "Simulation"). This library attribute holds the default value.

Hint

The attribute "Days per year" is only defined for D libraries.

Enterprise Time - Hours per day (Simulation)

An attribute where the basic settings of the hours per working day can be defined.

The attribute value "Hours per day" is used together with the attribute value "Days per year" in the Simulation Component to convert the times into enterprise times (see user manual, chapter "Simulation"). This library attribute contains the default value.

Hint

The attribute "Hours per day" is only defined for D libraries.

Configuration of documentation (Documentation)

This attribute defines the settings for documentation purposes and consists of the following parts:

• Attribute modes
• Settings dialogue
• Menu entries

Configuration of documentation - Grammar

The language of settings concerning documentation configuration bases on the following syntax:

• Terminal symbols are written in bold.
• Non-terminal symbols are written in cursive.
• The end of a "production rule" is indicated by a single dot . symbol.
• Parts between square brackets [ ] are considered optional and can be used once (i.e. zero to one).
• Parts between curly brackets { } are considered optional and are repeatable (i.e. zero to many).
• Alternatives are separated by a vertical bar |.
• Three dots ... are used as placeholders to be replaced appropriate to the meaning (e.g. number value ranges).
• A boldly written Attention: is not a terminal symbol, but provides important information.

Non-terminal	Definition
DocuConfig:	AttrModeDef { ExportDef } DialogDef .
AttrModeDef:	ATTRIBUTEMODI " AttrModeEntry { AttrModeEntry } " .
AttrModeEntry	@ attrModeName @ @ attrModeKey @ .
ExportDef:	EXPORT " exportDialogTitle " menuname:" exportMenuName " filedescription:" exportFileTypeDescription " fileextension:" exportFileType " filename:attribute:" attributeName " smarticon:" ( html | rtf ) " visible: 0or1 [ ExportRequireFiles ] [ ExportCopyFiles ] [ ExportTempFiles ] { SourceDef } .
ExportRequireFiles:	requirefile1:" fileName " [ requirefile2:" fileName " [...]] .
ExportCopyFiles:	copy1:" fileName " [ copy2:" fileName " [...]] .
ExportTempFiles:	temp1:attribute:" attributeName " [ temp2:attribute:" attributeName " [...]] .
SourceDef:	SourceModel2SGML | SourceAdoScript | SourceModelGroups | SourceUserVariable .
SourceModel2SGML:	SOURCE "Model2SGML" filename:attribute:" attributeName " basename:attribute:" attributeName " subprocesses:attribute:" attributeName " [ sortmode:" SortMode "] [ translation:" TranslationTableEntry { TranslationTableEntry } " ] [ copydocuments:" absoluteOrRelativePath " ] [ modeltypes:" modelTypesName{; modelTypesName}" ] [ acfilter:attribute:" attributeName " ] ((libraryspecific:0 GeneralLibDef ) | (libraryspecific:1 GeneralLibDef SpecificLibDef { SpecificLibDef } ) ) .
SortMode:	Search for spread | Search for low | Alphabetical .
TranslationTableEntry:	@ SourceAttribName @ @ TranslatedAttribName @ .
GeneralLibDef:	LIBRARY LibDefAttrs .
SpecificLibDef:	LIBRARY " modelTypeName " LibDefAttrs .
LibDefAttrs:	mode:" modelTypeModeName " notebookattr:" attrModeName " graphics: 0or1 [ gfxformat:" GfxFormat " ] [ gfxdpi: gfxSize ] [ gfxmode:" ( unchanged | modelTypeModeName ) " ] [ gfxorientation:" GfxOrientation " ] [ gfxlayout:" layoutName " ] [ gfxdozoom: 0or1 gfxzoomlevels:" gfxSize { ; gfxSize } " ]
GfxFormat:	bmp | bmp1 | bmp24 | jpg | pcx8 | pcx24 | png | emf .
GfxOrientation:	unchanged | rotate left (counter clockwise) | rotate right (clockwise) | rotate by 180 degrees .
SourceAdoScript:	SOURCE "AdoScript" name:" scriptName " script: { AdoScript } VarDeclList .
SourceModelGroups:	SOURCE "ModelGroups" filename:attribute:" attributeName " exportall: 0or1 .
SourceUserVariable:	SOURCE "UserVariable" filename:attribute:" attributeName " VarDeclList .
VarDeclList:	var1:attribute:" attributeName " [ var2:attribute:" attributeName " [...]] .
DialogDef:	DIALOG { Notebook } .
0or1:	0 | 1 .

Configuration of documentation - Defining attribute modes

An attribute mode quotes which attributes of the modelling objects will be taken over into the documentation. After the key word ATTRIBUTEMODI follows a list of the available attribute modes.

Hint

The attribute modes of an application library can not be changed online. If you need a new mode or changes to an existing one please contact your ADOxx consultant.

Example:

ATTRIBUTEMODI "@Standard@@StdDocu@@Documentation@@Docu@@Documentation with simulationdata@@SimDocu@"

In the example there are three attribute modes with the name "standard", "documentation" "documentation with simulation data" and the included keys "StdDocu", "Docu", "SimDocu" are defined.

Configuration of documentation - Defining the settings dialogue

In the settings dialogue settings can be made which have effects on the generated documentation (e.g. should graphics be generated). The key word DIALOG is used to define which settings are available for the user.

Hint

You can group or remove the existing settings from the settings dialogue. New settings can not be added online. If you want to add new settings ask your ADOxx consultant.

The settings dialogue will be determined via the notebook definition "AttrRep":

Example:

DIALOG
notebook:"NOTEBOOK
CHAPTER \"General settings\"
ATTR \"Library specific settings\" ctrltype:check
GROUP \"General settings\"
ATTR \"Modus\" ctrltype:dropdown
ATTR \"Attribute modus\" ctrltype:dropdown
ATTR \"Generate graphics\" ctrltype:check
ATTR \"Orientation\" ctrltype:dropdown
ATTR \"Modus for graphic files\" ctrltype:dropdown
ATTR \"Page layout\" ctrltype:dropdown
ENDGROUP
#...
"

A CHAPTER element defines a new chapter in the settings dialogue. The chapter headline will be quoted after the keyword CHAPTER.

An ATTR element defines an insertion field for a setting possibility (e.g. group graphics, modus, page layout) in the according chapter of the setting dialogue. The name of the insertion field will be quoted after the key word ATTR.

The two elements GROUP and ENDGROUP group more settings. The setting dialogue will be framed around the insertion fields which are situated between the two elements. The frame gets a headline which is quoted after the key word GROUP.

Attention

As the notebook definition is situated between quotation marks of the elements DIALOG notebook:all quotation marks (") for the naming of chapter groups or insertion fields are masked i.e. replaced through \".

If you want to prevent that a user can make determined settings himself delete the according ATTR element from the notebook definition.

Configuration of documentation - Defining the menu entries

For every menu item you can do settings and reference to settings from other setting dialogues. From the setting dialogue referenced settings will be quoted through the key word attribute: followed by the name of the setting in the setting dialogue.

Hint

Which of the following settings are available depends on the application library.

You can assign to all attributes which have been assigned to the settings dialogue also fixed settings. Therefore you can make fixed settings and forbid the user to make changes.

To assign attributes to fixed settings change the according setting and remove the insertion from the notebook definition. If you like to e.g. generate only graphics with the orientation "steady", remove the setting

gfxorientation:attribute:" orientation "

through the setting

gfxorientation:" steady "

Now the graphics will be generated with the characteristic "steady", independently of the definition given by the user in the setting dialogue.

Then delete the line

ATTR \" orientation \"

from the notebook definition to remove the insertion field for the orientation from the setting dialogue.

Each menu insertion in the menu "documentation" represents a possibility for the user to generate the documentation. With the keyword EXPORT such a menu item will be created.

Example:

EXPORT "HTML - Generation"
    visible:1
    smarticon:html
    menuname:"\~HTML Generation"
    filename:attribute:"filename"
    filedescription:"HTML files"
    fileextension:"\*.htm"
    copy1:"boclogo.bmp"
    copy2:"db:\\\\icon.gif"
    requirefile1:"%Hboclogo.gif"
    temp1:"sgmlfilename"

In the element EXPORT the window title for the model selection for the documentation generation will be determined. The following attributes will be defined for this element:

Is the attribute visible: assigned to the value 1, the menu "documentation" in the import/export component will be displayed in the insertion through which the export will be started. If the value 0 is assigned to the attribute, no insertion will be added to the menu.

The name, which will be displayed in the "documentation" (import/export component) will be defined in the attribute menuname:.

The attribute smart icon:html and the smart icon:rtf are allowed to be defined in one EXPORT element of the documentation configuration. Over them the menu insertion will be determined, which will be called over the SmartIcons (smarticon:html) and (smarticon:rtf).

File type and file extension will be determined in filedescription: and fileextension: respectively.

The filename of the target file will be set in the filename:. This attribute will be set with the file name, which the user inserted in the export dialogue.

The attribute temp Number : will be set at the running time with the file name of a temporary file. Further temporary files can be generated through continuous counting.

The attribute copy Number : allows to quote the names of graphic files ( fileName ) that are included in the documentation. Number stands for a number to be entered (starting from one).

The attribute requirefile allows to attach the selected external files to the generated documentation. Before starting the documentation generation, the system checks whether these attached files exist or not. If there are files that are missing, an error message will be shown and the documentation generation will be cancelled. The key word %H will be replaced with the installation directory of ADOxx.

Hint

The file name (incl. path) must be quoted in inverted commas. The back slashes ( "\") in the path quotation of the file must be masked through '\' (e.g. "c:\\gfx\\logo.gif" for the file "logo.gif" in the directory "gfx" on the "C:" drive).

Hint

In order to include files, which are saved as external files in the ADOxx database,please quote as the path 'db:\' (e.g. "db:\\logo.gif" for the in the database saved file "logo.gif").

Settings for the SGML model export are in the element SOURCE "Model2SGML". The following attributes are defined:

Example:

SOURCE "Model2SGML"
    filename:attribute:"sgmlfilename"
    basename:attribute:"filename"
    sortmode:"deep search"
    modeltypes:"Dynamic model;process landscape"
    copydocuments:"docs\\"
    libraryspecific:0

The name for the SGML file will be quoted in the attribute filename:. The attribute will be saved with the name of the temporary file.

The file name for the target documentation file will be set in basename:. The attribute will be saved with the name given by the user.

The attribute subprocesses: contains information, whether the referenced models should also be exported. The values 1 or 0 will be assigned to the attribute, accordingly to the user decision (1= yes, 0=no).

The order of models contained in the generated documentation can be defined in sortmode:. Possible values are "deep search" "alphabetical" and "width search".

The names of the documentation attributes can be translated by the settings of translation:. Therefore, the user should assign to the settings a chain of values in the following form: @Attribute name@@Translation@.Attribute name is a name of an attribute in ToolName;.Translation contains the translated name of the attribute, which should be displayed instead of the attribute name from ToolName;.

modeltypes: permits the user to limit the group of models to be contained in the generated documentation to the defined model types. Please enter all the selected model types that should be contained in the documentation using as a separator ";".

copydocuments: allows the user to give a name of an absolute or relative catalogue, where all the external files should be copied into during documentation generation.

Hint

The external files will be copied during documentation generation, provided they are system files. In case an attribute "program call" (PROGRAMCALL) references to, for example, an Internet address, the file will not be copied (but link to the web page will be taken over to the generated documentation). If the files cannot be copied (e.g. in case of Internet address, where the file no longer exists), the window with adequate information will display (during documentation generation).

Switching on checkexternfilenames: means, that all referenced external files wil be carefully checked (value 1). The user will read warnings during documentation generation each time when a name of the external file contains things other than numbers and lower-case letters.

The attribute libraryspecific: can get the value 0 or 1. The value 1 means that the user has chosen (in the window with settings) "Settings specific for model types", on the other hand the value 0 means that the user has not chosen it.

The element SOURCE "Model2SGML" needs definitions for LIBRARY element of each model type as well as for a general LIBRARY element. LIBRARY elements contain attributes, which influences documentation generation (its content and way of presentation).

Selecting "Library specific settings" (in the settings dialogue window) means, that during documentation generation each model will be generated according to the settings defined in the LIBRARY element of the respective model type. If the option is not active, all the models are generated according to general settings. The following attributes are defined for each LIBRARY element:

Example:

LIBRARY "Dynamic model"
    gfxformat:"bmp"
    gfxdpi:"70"
    notebookattr:"Documentation"
    graphics:"1"
    gfxorientation:"Upright"
    gfxlayout:"Do not split graphic file"
    gfxmode:"unchanged"
    mode:"Standard"
    gfxdozoom:"1"
    gfxzoomlevels:"10;40;100"

The following list describes settings for all library elements:

Non-terminal	Definition
graphics	(INTEGER) has value 1 when graphics should be generated, value 0 if not.
[ mode ]	(ENUMERATION) The Mode, in which the documentaion should be generated. Classes will be shown and exported according to the mode settings.
[ notebookattr ]	(ENUMERATION) The attribute modi for an export of a document. The name of the attribute modi must be specified (not an attribute name / key).
[ gfxformat ]	(ENUMERATION) The file format for an export of a graphic.gfxformat must be entered, in case graphics has the value 1. Possible formats are bmp1, bmp24, pcx8, pcx24, png, jpg, emf and svg.
[ gfxdpi ]	(DOUBLE) The dpi (dots per inch) for graphics. gfxdpi must be entered when graphics has the value 1.
[ gfxmode ]	(ENUMERATION) The dpi (dots per inch) for graphics. gfxmode must be entered, in case graphics has the value 1.
[ gfxorientation ]	(ENUMERATION) Decide on graphic orientation during export. The possibilities are "do not change", "rotate right (clockwise)", "rotate left (counter-clockwise)" or "rotate by 180".gfxorientation must be entered, in case graphics has the value 1. Graphics in the file format EMF cannot be rotated!
[ gfxlayout ]	(ENUMERATION) The Page layout, which should be used during export.gfxlayout must be entered, in case graphics has the value 1.
[ gfxscale ]	(INTEGER) The zoom factor for graphics. gfxscale must be entered, in case graphics has value the 1.
[ gfxdozoom ]	(INTEGER) In case this setting has value 0, there will be exactly one graphic generated for each model. If_gfxdozoom_ equals 1, there will be exactly one graphic generated for each entry in gfxzoomlevels.
[ imagemaps ]	(INTEGER) The user can decide, whether graphics in HTML documentation should have hyperlinks (value: 1) or not (value: 0).

Attention

The page layout and modes defined here apply only to generated graphics files, which are contained in the process documentation and not in the documentation layout itself.

A post processor will be started in SOURCE "AdoScript" to convert the SGML file into a file having the target format. There will also be a DSSSL file entered here, which should be used for documentation generation. The following attributes will be defined for the element:

Example:

SOURCE "AdoScript"
    name:"Jade Converter"
    var1:attribute:"tempfilename"
    var2:attribute:"filename"
    var3:attribute:"homedir"
    script:"SYSTEM (\"\" + homedir + \"\\\\jade.exe -t html -d \\\"\" + homedir + \"\\\\std2htm3.dsl\\\" -o \\\"\" + filename + \"\\\" \\\"\" + tempfilename + \"\\\"\")"

name: defines the name of a script.

var Number : allows to define AdoScript variables, which will be used in the actual script. Number is used to enter the right number starting from one. The first variable in the example defines the name of the temporary file, the second variable defines the name, which was entered by the user in the export dialogue window and the third one defines the installation directory of ADOxx.

script: defines AdoScript, which calls the post processor.

SOURCE "ModelGroups" contains model group structure and model references for the purpose of export.

Example:

SOURCE "AdoScript"
    filename:attribute:"tempfilename"
    exportall:1

The name of the SGML file is entered in the attribute filename:. The attribute contains also the model group structure. The attribute will be created with the filename of the temporary file.

exportall: says, whether all model groups should be exported (value 1), or only those model groups, which have model references to the exported models (value 0).

SOURCE "UserVariable" allows the export of all the selected user settings from the settings dialogue window.

Example:

SOURCE "UserVariable"
    filename:attribute:"tempfilename"
    var1:attribute:"Header"
    var2:attribute:"Footer"
    var3:attribute:"Project"

The name of the SGML file is entered in the attribute filename:. This file contains user settings. The attribute will be created with the filename of the temporary file.

var Number : permits the user to define settings, which should be exported. Number is used to enter the right number starting from one.

Hint

The available settings depend on the application library. If you want to define or change current settings, please contact your ADOxx consultant.