![]() |
![]() |
![]() |
![]() |
![]() |
Syntax Summary
Object Model Syntax
While the intent of Object Model diagrams is to give as large flexibility as possible to analysis and specification activities, the different editing support facilities provided by the OM Editor requires textual data to follow certain syntactic conventions.
This section details the syntax rules that are imposed by the OM Editor on textual data only. Graphical syntax rules are enforced automatically by the OM Editor and are not described here.
Summary of Lexical Rules
In general, a somewhat restricted version of the lexical rules of SDL apply for names. These rules have the following noteworthy properties:
- It is possible to break a name over more than one line by using the underscore at the end of the line to escape the newline.
- It is possible to have identifiers consisting entirely of numeric characters; e.g. "223" is a valid identifier.
- Identifiers are not case sensitive.
- Comments can be used anywhere in the texts. A comment is defined as an SDL comment, i.e. /* this is a comment */
For more information on the SDL lexical rules, see the Z.100 recommendation.
The primary restriction is that identifiers containing spaces are not considered legal.
<name> ::= identifier as described above.<c-string> ::= string as bounded by " characters.<sdl-string> ::= string delimited by ` (apostrophes).Class Definition Summary
When interpreting OM diagrams, all class and object symbols within all pages within all diagrams in a single module must be considered. A class definition is considered to be the conceptual union of the information contained in all class symbols with the same name, as well as all object symbols declared as instances of that class.
This means that the definition of a class can be distributed over several symbols, pages and even diagrams. The definitions in class symbols with the same name are then merged to obtain the complete definition of the class; support for this is provided by the Browse & Edit Class dialog.
Thus, when defining classes, it is acceptable to have identical attributes or operations defined several times, either in the same or different class or object symbols. The identical definitions are simply redundant, and do not affect the correctness of the complete class definition.
Note, however, that each unnamed class objects is considered distinct, so that each unnamed class symbol defines its own class.
Diagram Name Syntax
Diagram names must follow certain restrictions since they are used to identify the diagram with respect to other tools.
Diagramname ::= <name>Page Name Syntax
Pagename ::= <name>Each page name must be unique within its containing diagram.
Class Symbol Syntax
The textual information in class symbols is divided into five compartments of which three have their own syntax. The stereotype and properties compartments are not checked for syntax.
In the attributes and operation compartments the stereotype concept as described in Object Model Literature References can be used. The syntax chosen supports the single characters left/right guillemet («») but it can also be written as two angle brackets. To type the left/right guillemet in the text window, press <Ctrl> when you type the left/right angle bracket.
Class Name Compartment Syntax
Classname ::= <name> |<name> `:' `:' <name> |<empty>Class Attributes Compartment Syntax
ClassAttributesCompartment ::={ <stereotype> <classattribute> <note> }*<stereotype> ::= `<' `<' <name> `>' `>' |`«' <name> `»' |<empty><classattribute> ::=<visibility> <attribute><visibility> ::=`+' |`-' |`#' |<empty><attribute> ::=
<name> <value> |
<name> `:' <type> <value><type> ::= <name><value> ::= `=' <valueitem> | <empty><valueitem> ::=
<name> |
`-' <name> |
`+' <name> |
<c-string> |
<sdl-string> |`(` <valueitemlist> `)' |
`{` <valueitemlist> `}'<valueitemlist> ::=
<valueitem> |
<valueitemlist> `,' <valueitem><note> ::=
`{` <name> `}' |
`{` <name> `=' <name> `}' |
<empty>Two attributes are considered identical if they have the same name and type. Note that attributes defining different values are still considered identical.
Class Operations Compartment Syntax
ClassOperationsCompartment ::={ <stereotype> <classoperation> <note> }*<classoperation> ::=<visibility> <operation>
<operation> ::=
<name> <return> |
<name> `(` `)' <return> |
<name> `(` <parameterlist> `)' <return><parameterlist> ::=
parameter |
parameterlist `,' parameter<parameter> ::=
<type> |
<name> `:' <type><return> ::=
`:' <name> |
<empty>Two operations are considered identical only if the name, parameter list and the return fields are all the same. Thus "op", "op(a)" and "op:t" are all unequal, while "op(a)", "OP(A)" define the same operation.
Note however that "op" and "op()" are not considered equal, since the OM Editor does not interpret an omitted parameter list as an empty parameter list.
Object Symbol Syntax
The textual information in object symbols is divided into four compartments of which two have their own syntax. The stereotype and properties compartments are not checked for syntax.
Object Name Compartment Syntax
Objectname ::=
<name> `:' <classname> |
<name> |
<empty>Object Attributes Compartment Syntax
ObjectAttributesCompartment ::={ <stereotype> <attribute> <note> }*Text Symbol Syntax
Text symbols are not subject to any syntax rules.
Line Syntax
The current version of the OM Editor does not implement any syntax checks on the contents of the textual attribute objects of lines.
State Chart Syntax
While the intent of State Chart diagrams is to give as large flexibility as possible to analysis and specification activities, the different editing support facilities provided by the SC Editor requires textual data to follow certain syntactic conventions.
This section details the syntax rules that are imposed by the SC Editor on textual data only. Graphical syntax rules are enforced automatically by the SC Editor and are not described here.
Summary of Lexical Rules
In general, a somewhat restricted version of the lexical rules of SDL apply for names. These rules have the following noteworthy properties:
- It is possible to break a name over more than one line by using the underscore at the end of the line to escape the new line.
- It is possible to have identifiers consisting entirely of numeric characters; e.g. "223" is a valid identifier.
- Identifiers are not case sensitive.
- Comments can be used anywhere in the texts. A comment is defined as an SDL comment, i.e. /* this is a comment */
For more information on the SDL lexical rules, see the Z.100 recommendation.
The primary restriction is that identifiers containing spaces are not considered legal.
<name> ::= identifier as described above.State Definition Summary
UML allows some expressions in text segments to be defined by the tool vendors. For State Charts such expressions should follow SDL/PR syntax, but this is not checked by the SC Editor.
When interpreting SC diagrams, all state symbols within all pages within all diagrams in a single module must be considered. A state definition is considered to be the conceptual union of the information contained in all state symbols with the same name.
This means that the definition of a state can be distributed over several symbols, pages and even diagrams. The definitions in state symbols with the same name are then merged to obtain the complete definition of the state.
Thus, when defining states, it is acceptable to have identical activities defined several times, either in the same or different state symbols. The identical definitions are simply redundant, and do not affect the correctness of the complete state definition.
Note, however, that each unnamed state object is considered distinct, so that each unnamed state symbol defines its own state.
Diagram Name Syntax
The diagram name identifies the diagram.
<DiagramName> ::= <name>Page Name Syntax
The page name identifies the page within a diagram.
<PageName> ::= <name>Each page name must be unique within its containing diagram.
State Symbol Syntax
The textual information in state symbols' state sections is divided into three compartments with different syntax.
Name Compartment Syntax
The name identifies the state.
<NameCompartment> ::=[<name>]Internal Activity Compartment Syntax
Internal activities' syntax is defined by the following grammar:
<InternalActivityCompartment> ::={<internal-activity>}*<internal-activity> ::=<event-signature>[<guard-condition>][`/' <action-expr>]|<reserved-action-label> `/' <action-expr><reserved-action-label> ::=`entry' | `exit' | `do'<event-signature> ::=<name> [<argument-list>] |<predefined-event> `(' <argument> `)'<predefined-event> ::=`when' | `after'<argument-list> ::=`(' [<argument> {`,' <argument>}*] `)'<argument> ::=<expression><guard-condition> ::=`[` <expression> `]'<action-expr> ::=<expression><expression> ::=SDL/PR expressionTwo events are considered identical only if the name and the argument list are all the same. Thus "op" and "op(a)" are unequal, while "op(a)", "OP(A)" define the same event.
Note however that "op" and "op()" are not considered equal, since the SC Editor does not interpret an omitted parameter list as an empty parameter list.
Text Symbol Syntax
Text symbols are not subject to any syntax rules.
Transition Line Syntax
The textual information in the transition label attribute of transition lines is defined by the following grammar:
<TransitionLabel> ::=[<event-signature>][<guard-condition>][<action-list>]<action-list> ::=`/' <action-expr> {`;' <action-expr>}*DP Syntax
While the intent of Deployment diagrams is to give as large flexibility as possible to analysis and specification activities, the different editing support facilities provided by the DP Editor require textual data to follow certain syntactic conventions.
This section details the syntax rules that are imposed by the DP Editor on textual data only. Graphical syntax rules are enforced automatically by the DP Editor and are not described here.
Summary of Lexical Rules
In general, a somewhat restricted version of the lexical rules of SDL apply for names. These rules have the following noteworthy properties:
- It is possible to break a name over more than one line by using the underscore at the end of the line to escape the newline.
- It is possible to have identifiers consisting entirely of numeric characters; e.g. "223" is a valid identifier.
- Identifiers are not case sensitive.
- Comments can be used anywhere in the texts. A comment is defined as an SDL comment, i.e. /* this is a comment */
For more information on the SDL lexical rules, see the Z.100 recommendation.
The primary restriction is that identifiers containing spaces are not considered legal.
<name> ::= identifier as described above.Diagram Name Syntax
The diagram name identifies the diagram.
<DiagramName> ::= <name>Node Symbol Syntax
<NodeName> ::= <name> |<empty>There are no syntax checks on the stereotype and properties texts.
Component Symbol Syntax
The name identifies the component.
<ComponentName> ::= <name> |<empty>There are no syntax checks on the stereotype and properties texts.
Thread Symbol Syntax
The name identifies the thread.
<ThreadName> ::= <name> |<empty>Object Symbol Syntax
The name identifies the object.
<ObjectName> ::= <name> |<empty>There are no syntax checks on the stereotype, properties and qualifier texts.
Text Symbol Syntax
Text symbols are not subject to any syntax rules.
Line Syntax
The DP Editor does not implement any syntax checks on the contents of the textual attribute objects of lines.
HMSC Syntax
While the intent of High level MSC diagrams is to give as large flexibility as possible to analysis and specification activities, the different editing support facilities provided by the HMSC Editor requires textual data to follow certain syntactic conventions as specified in MSC'96.
This section details the syntax rules that are imposed by the HMSC Editor on textual data only. Graphical syntax rules1 are enforced automatically by the HMSC Editor and are not described here.
Summary of Lexical Rules
The lexical elements follow MSC'96. These rules have the following noteworthy properties:
- An underscore followed by on or more spaces is ignored completely, e.g. A_ B denotes the same <name> as AB. This use of underline makes it possible to split keywords over multiple lines since control characters (e.g. newline) is treated as a space.
- It is possible to have identifiers consisting entirely of numeric characters; e.g. "223" is a valid identifier.
- Identifiers are not case sensitive.
- Comments (<note> in Z.120) can be used anywhere between lexical units. A <note> is started by the characters /* outside a <note> and terminated by the characters */ inside a <note>.
For more information on the MSC lexical rules, see the Z.120 recommendation.
Syntax rules in Symbols
The descriptions below describes what text is allowed in the different symbols, it is not a description of the grammar in PR-form.
The grammar below informally describes the lexical units used as terminal symbols. Refer to Z.120 for a complete description.
<name> ::= identifier as described above.<text> ::= approximately the ASCII character set.In the sections below each symbol will be described in the following manner:
- A short description of the symbol and/or its contents and purpose.
- The symbols textual grammar
- Possibly any semantic restriction and/or notes. Refer to Z.120 for a complete description of the semantics that apply.
Diagram Name Syntax
The diagram name identifies the MSC to the outside world.
Diagramname ::= <name>Diagram names must follow certain restrictions since they are used to identify the diagram with respect to other tools.
Page Name Syntax
The page name identifies the page within a document.
<page name> ::= <name>Each page name must be unique within its containing diagram.
Text Symbol Syntax
The text in a text symbol is an informal explanatory text.
<text text> ::= <text>The text has no (formal) semantic and no restrictions.
Condition Symbol Syntax
Global conditions can be used to restrict how MSC's can be composed in High level MSC's.
<condition name list> ::=
<condition name> { `,' <condition name> }*
<condition name> ::= nameGlobal conditions indicate possible continuations of Message sequence charts containing the same the same set of instances by means of condition name identification.
Reference Symbol Syntax
MSC References are used to refer to other MSC's of the MSC document.
<msc ref expr> ::=
<msc ref par expr> { `alt' <msc ref par expr> }*
<msc ref par expr> ::=
<msc ref seq expr> { `par' <msc ref seq expr> }*
<msc ref seq expr> ::=
<msc ref exc expr> { `seq' <msc ref exc expr> }*
<msc ref exc expr> ::=
[ `exc' ] <msc ref opt expr>
<msc ref opt expr> ::=
[ `opt' ] <msc ref loop expr>
<msc ref loop expr> ::=
[ `loop' [ <loop boundary> ] ]
{
`empty' |
<msc name> [ <parameter substitution> ] |
( <msc ref expr> )
}
<parameter substitution> ::=
`subst' <substitution list> `end'
<substitution list> ::=
<substitution> [ `;' <substitution list> ]
<substitution> ::=
<replace message> |
<replace instance> |
<replace msc>
<replace message> ::=
[ `msg' ] <message name> `by' <message name>
<replace instance> ::=
[ `inst' ] <instance name> `by' <instance name>
<replace msc> ::=
[ `msc' ]
{ `empty' | <msc name> } `by'
{ `empty' | <msc name> }<msc name> ::= <name>
<message name> ::= <name>
<instance name> ::= <name>MSC Syntax
While MSC diagrams allows the user to specify the analysis and specification activities in great detail with graphical symbols, there are also fields that get their meaning from textual information only. The different editing support facilities provided by the MSC Editor checks textual data to follow certain syntactic conventions as specified in MSC'96.
This section details the syntax rules that are imposed by the MSC Editor on textual data only. Graphical syntax rules2 are enforced automatically by the MSC Editor and are not described here.
Summary of Lexical Rules
The lexical elements follow MSC'96. They are identical to the lexical rules for HMSC, see Summary of Lexical Rules for further information.
Syntax Rules in Symbols
The descriptions below describes what text is allowed in the different symbols, i.e. it is not a description of the grammar in PR-form.
The grammar below informally describes the lexical units used as terminal symbols. Refer to Z.120 for a complete description.
<name> ::= identifier as described above.<text> ::= approximately the ASCII character set.In the sections below each symbol will be described in the following manner:
- A short description of the symbol and/or its contents and purpose.
- The symbols textual grammar
- Possibly any semantic restriction and/or notes. Refer to Z.120 for a complete description of the semantics that apply.
Syntax Common with HMSC
All symbols that can take textual input in the HMSC are also present (and the same) as those found in the MSC. See Syntax rules in Symbols for further information.
Syntax Specific for MSC
In addition to the symbols that are common HMSC symbols, the MSC Editor supports the following symbols that contains text.
Comment Symbol Syntax
The text in a comment symbol is an informal explanatory text.
<comment text> ::= <text>The text has no (formal) semantic and no restrictions.
Instance, Message and Timer Name syntax
The text identifies the entity
<instance name> ::= name<message name> ::= name<timer name> ::= nameParameter Syntax
Both on messages and instance creations have parameters. In addition the MSC also supports parameters on timers (currently nonstandard). The Z.120 grammar for parameters is defined as follows:
<parameter list> ::=
<parameter name> [ `,' <parameter list> ]This grammar is neither able to allow empty parameter lists, nor to take parameters that are generated from SDL. Furthermore, the grammar does not allow string literals. The MSC Editor (and associated tools) supports the following, more relaxed, grammar:
<parameter list> ::=
[ <relaxed name> { `,' <relaxed name> } * ]<relaxed name> ::=
<parameter name> [ `(` <relaxed name> `)' }<parameter name> ::=<name> |
<character string> |
<character string 2>The grammar of <character string 2> is the same as the grammar for the Z.120 <character string> except that the apostrophe is regarded as the Z.120 <other character> and the double quote `"' is regarded as an <apostrophe>.
Instance Kind Syntax
The instance kind describes the type of the instance
<instance kind>::=
[ <kind denominator> ] <identifier><kind denominator> ::=
`system' | `block' | `process' | `service'
| <name><identifier> ::= [ <qualifier> ] <name><qualifier> ::= `<<' <text> `>>'Decomposition Syntax
This text is present if the instance is decomposed and describes the name of the diagram that explains the decomposed instance in greater detail.
<decomposition> ::=
`decomposed' [ <substructure reference> ]<substructure referrence> ::=
`as' <message sequence chart name>Inline Heading Syntax
This is the syntax for the text area in the inline expressions symbols.
<inline heading> ::=
`alt' |
`par' |
`exc' |
`opt' |
`loop' [<loop boundary>]<loop boundary> ::=
`<' <inf natural> [ `,' <inf natural> ] `>'<inf natural> ::= `inf' | <natural name><natural name> ::= {0|1|2|3|4|5|6|7|8|9}+1 2
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |