The Browse & Edit Class dialog is opened when you select Class from the Edit menu. The dialog allows inspection of OM diagram classes and objects across page and diagram borders.
An object model class is defined as the union of the attributes and operations in the class and object symbols, see Class Definition Summary, and the purpose of the Browse & Edit Class dialog is to display and ensure consistency when editing this combined information.
The Browse & Edit Class dialog is a modal dialog which is divided in two parts. The browsing functionality is placed at the top part of the dialog, where all classes in the scope, and all occurrences of each class are listed in two option menus. Below, in the editing part, the name of the class, all attributes and all operations are available.
The Browse & Edit Class dialog is available when a single class or object symbol has been selected:
By using the topmost part of the Browse & Edit Class dialog it is possible to browse amongst all class and object symbols within the scope. The scope is either the entire Organizer module where the diagram is contained, or the diagram itself if it is not contained in an Organizer module. The module concept is described in Module and in Module.
By using the lower part of the Browse & Edit Class dialog it is possible to edit the name, attributes and operations of a class. The change will propagate into all class symbols of this class in OM diagrams within the module where the diagram is contained. The attributes and operations will be presented in a list. This list is parsed information from the texts in the class symbols. If a particular text contains syntax errors, it may lead to that attributes and operations contained in the same text do not appear in this list.
Figure 296 : The Browse & Edit Class dialog
|
|
The scope label is a non-editable text field that describes the scope that the Browse & Edit Class dialog is operating in. The scope can be either a single OM diagram or all OM diagrams within an Organizer module.
The Classes in Scope option menu contains a list of all classes within the scope. By selecting one of the classes in this menu the corresponding symbol will be shown and selected in the drawing area.
One class can be represented by several class symbols. The Show Symbol in option menu lists all occurrences of the class currently selected in the Classes in Scope option menu. The notation in the menu is <diagram-name>/<page-name>. By selecting an occurrence in this menu the corresponding symbol will be shown and selected in the drawing area.
The name field is an editable text field that initially contains the name of the class that is being edited.
By editing the class name field, it is possible to update all occurrences of that class name in class and object symbols in the current scope when the OK button is clicked.
The Attributes and Operations buttons select whether the attributes/operations list will contain a list of all attributes or all operations defined for the selected class. Only one of the attributes and operations buttons will be selected at any time.
The attributes/operations list contains an alphabetically sorted list of the attributes or operations defined for the currently selected class.
The clear button removes the currently selected operation or attribute from the Attribute/Operations list.
By clearing an attribute or operation using the clear button, that attribute or operation will be removed from all relevant class and object symbols using the current class name in the current scope when the OK button is clicked.
The name field contains the name of the currently selected attribute or operation in the Attribute/Operations list, if any.
Editing this field will change the definition of that attribute or operation in all relevant class and object symbols using the current class name in the current scope when the OK button is clicked.
The parameters field is an editable text field that contains the parameters of a class operation. It is only editable when an operation is selected in the Attribute/Operations list.
Editing this field will change the definition of the selected operation in all relevant class and object symbols using the current class name in the current scope when the OK button is clicked.
The type field is an editable text field that is only editable when an attribute or an operation is selected in the Attribute/Operations list.
Depending on the current selection, the type field contains:
By editing this field, the type of the selected attribute or the return type of the selected operation and later clicking the OK button, the type of the selected attribute or operation will be updated in all relevant class and object symbols using the current class name in the current scope.
Note that default values for attributes cannot be inspected or changed in the Browse & Edit Class dialog.
The OK button will close the Browse & Edit Class dialog and update all appropriate class and object symbols in the diagrams in the current scope as described for the scope label.
Note that no changes are made in the diagrams until the OK button is clicked. This makes it possible to specify several changes in the dialog and later disregard them by clicking the Cancel button.
The values are syntactically checked, so it is not possible to add syntax errors to your classes by using the Browse & Edit Class dialog. Also, it may be impossible to delete syntactically incorrect text from symbols using the Browse & Edit Class dialog, since the Browse & Edit Class dialog relies on information obtained by parsing the relevant symbol text compartments.
It is possible to undo the changes made by the Browse & Edit Class operation. Note that this undo operation may affect more than one diagram.
The Cancel button will close the Browse & Edit Class dialog and discard any changes specified in the dialog. However, if the selection has changed in the drawing area after using any of the browsing functionality, this selection will not be canceled.
All changes made in the Browse & Edit Class dialog will be lost.
The Line Details window is opened when you select Line Details from the Edit menu. It is used to inspect, and edit the properties of the currently selected line. In particular, most of the line attribute objects that are available for the different line types can only be created from the Line Details window1.
Some line attribute objects contain editable text, and clearing that text, whether by editing in the Line Details window or directly in the diagram, will remove the attribute.
Changes made in the Line Details window will take immediate effect and will be shown in the drawing area. These changes can be undone with the Undo menu command.
Unlike the Browse & Edit Class dialog, the Line Details window is modeless and can remain open while you continue to work with the diagrams. The contents of the window will be updated to reflect the current selection. If there is none or more than one selected line, the fields in the Line Details window will be dimmed.
The OM Editor supports four different types of lines and the contents of the Line Details window depends on the type of the currently selected line:
Figure 297 : The Line Details window when an association line is selected
|
|
Figure 298 : The Line Details window when an aggregation line is selected
|
|
Figure 299 : The Line Details window when a generalization line is selected
|
|
The Name field is an editable text field that contains the name of the selected aggregation or association.
Unlike the other text fields in the Line Details window, the line attribute object defined by the name field is permanent and is not destroyed even if the name field is cleared.
This field is only available when an aggregation or association line is selected.
The Discriminator field is an editable text field that changes the discriminator text attribute of the generalization.
This field is only available when a generalization line is selected.
The Reversed Name field is an editable text field that allows the specification of a reversed name for an aggregation or association.
This field is only available when an aggregation or association line is selected.
Each of these two buttons toggle an option that shows or hides the optional arrow defining the direction of the name attribute or the reversed name attribute, respectively.
The direction and position of the arrow will be automatically calculated from the position and size of the associated name attribute as well as the direction of the line.
Typically it is desirable to use arrows to enhance clarity when defining both name and reversed name fields.
These buttons are only available when an aggregation or association line is selected.
The Role Name fields are editable text fields that allow you to create and edit the role attributes belonging to each end of the association or aggregation.
These fields are only available when an aggregation or association line is selected.
The Role Multiplicity fields are editable text fields that allow you to create and edit the multiplicity attributes of each end of an association or aggregation.
The name field is only available when an aggregation or association line is selected.
Selecting the Ordered toggle creates an uneditable text attribute containing the text "{ordered}". Deselecting the Ordered toggle removes this text attribute.
The ordered text attribute can be specified both in the primary and the reverse direction.
These buttons are only available when an aggregation or association line is selected.
Selecting the Sorted toggle creates an uneditable text attribute containing the text "{sorted}". Deselecting the Sorted toggle removes this text attribute.
The sorted text attribute can be specified both in the primary and the reverse direction.
These buttons are only available when an aggregation or association line is selected.
The Qualifiers fields are editable text fields that allow you to create and edit the qualifier fields in the forward and reverse direction respectively.
These fields are only available when an aggregation or association line is selected.
The Derived button is a toggle option that indicates whether the selected association or aggregation should be marked as derived, i.e. crossed by a small slanting line.
This button is only available when an association line is selected.
The Constraint field is an editable text field that allows you to create and edit the constraint line attribute object.
This field is only available when an association or aggregation line is selected.
The Close button closes the Line Details window.
The Symbol Details window is opened when you select Symbol Details from the Edit menu. It is used to inspect, and edit the stereotype and properties fields of the currently selected class or object symbol. These two symbol attribute types can only be created from the Symbol Details window. However, when created they can be edited directly in the diagram.
Figure 300 : The Symbol Details dialog
|
|
Changes made in the Symbol Details window will take immediate effect and will be shown in the drawing area. These changes can be undone with the Undo menu command.
Unlike the Browse & Edit Class dialog, the Symbol Details window is modeless and can remain open while you continue to work with the diagrams. The contents of the window will be updated to reflect the current selection. If multiple class or object symbols or any other symbol or line is selected the Symbol Details window will be dimmed.
The placement of the stereotype and properties texts in the class and object symbol is described in Class Symbols.
To convert state charts to SDL, you select Convert SC to SDL from the Tools Menu.
Following are the transformation rules that are applied to the SC diagram:
| SC | SDL |
|---|---|
|
Note: |
Variable declaration
|
| SC | SDL |
|---|---|
|
For all transitions from A to B
|
|
|
For all transitions from A to B
|
|
|
|
Comment symbol
|
|
|
|
If actions and/or send events are specified in the transition labels, insert action(s)/send event(s) last in the generated transition.
| SC | SDL |
|---|---|
|
|
Spontaneous transition
|
|
|
|
|
|
Continuous signal
Note: Priority is required if more than one continuous signal exist from the same state. This must be manually added. |
|
|
Enabling condition
|
| SC | SDL |
|---|---|
|
Note: Exactly one start state, with an unlabeled transition, should exist in the hierarchical state. |
|
|
Note: An unlabeled transition should exist out from the hierarchical state. |
|
|
Note: |
|
Depending of text contents:
| SC | SDL |
|---|---|
|
If text starts with `call': |
Procedure call
|
|
If quoted text: |
Informal task
|
|
Otherwise: |
Task
|
| SC | SDL |
|---|---|
|
No destination given: |
Output
|
|
Destination given: |
Output
|
To paste, you select Paste from the Edit Menu. The rules for Paste will be described below.
When pasting the selection, the MSC Editor will process each individual object contained in the selection, adjust it to the grids if required and connect it, if feasible, to the "closest" object(s) in the drawing area.
If the MSC Editor fails in pasting some of the objects contained in the selection, the rest of the objects will nevertheless be pasted but without an error message being displayed.
When pasting a selection that consists of multiple objects, the MSC Editor attempts, as long as feasible, to preserve the original appearance of the selection.
When pasting individual objects, the MSC Editor processes the objects as follows:
When you add an instance head symbol, an instance axis line is drawn that connects the symbol to the bottom of the drawing area. The instance axis line cannot be drawn manually. It will be truncated or elongated when you add or move an instance end or stop symbol upwards or downwards. See Adding an Instance End Symbol and Adding a Stop Symbol.
The instance head symbol has three text fields:
Figure 301 : The meaning of the instance head text fields
|
|
A condition or MSC reference describes either a global system state referring to all instances contained in the MSC or a state referring to a subset of instances (a non-global condition or MSC reference). The minimum subset is a single instance.
For two MSCs, the second is a continuation of the first if its initial global condition is identical to the final global condition of the first. Identifying an intermediate global condition can be used when breaking down an MSC into two parts.
By means of non-global conditions, combinations of MSCs with different sets of instances can also be defined. The continuation then refers only to the common subset of instances.
The following general rule applies to the continuation of two MSCs (MSC1 and MSC2, with a non-empty common set of instances).
MSC2 is a continuation of MSC1 if, for each instance which both MSCs have in common:
An inline expression symbol is in SDT always global and connected to all instances. The inline expression symbol is created from two inline expression symbol parts:
To display and modify status, you select Status from the Edit menu.
Z.120 specifies two appearances for the timer symbol, depending on whether the timer has expired (i.e. timeout) or whether the timer is reset. The appearance of the timer is illustrated in Figure 302.
|
|
Separate timer symbols has no need for an implicit reset. The timer can be set two times in a row without an implicit reset in-between.
Figure 303 : Separate Timer status
|
|
To display information about a selected MSC object, you select Info Window from the Window menu.
This opens a dialog displaying additional information about the currently selected MSC object. The information that is available depends on what object is selected, and this is described in the table below.
| Selected Object | Information Available |
|---|---|
|
Instance head |
|
|
Instance end |
|
|
Stop |
|
|
Process create |
|
|
Message output (the message output is selected by clicking close to the message base) |
|
|
Message input (the message input is selected by clicking close to the message end) |
|
|
Timer |
|
|
Separate timer |
|
|
Action symbol |
|
|
Condition |
|
|
MSC Reference symbol |
|
|
Text symbol |
|
|
Comment symbol |
|
|
Inline symbol |
When managing working on a long (vertically extended) MSC, the kind of instance in the instance head may not be visible in the drawing area.
The instance ruler (illustrated in Figure 304) shows the kind of the instance heads that are not currently visible in the drawing area. It reduces the amount of scrolling up or down when working on an MSC. The instance ruler may be shown or hidden with an option (see Instance Ruler).
Figure 304 : The instance ruler
|
|
This section describes the functionality behind tracing a simulation in an MSC.
The MSC Editor may be used as a graphical trace tool, which features the automatic generation of an MSC from a simulation.
First, the scope of trace should, if necessary, be set to the unit which is currently of interest. This is done with the command Set-MSC-Trace.
The graphical trace is then started with a dedicated command from the simulator monitor. See Start-Interactive-MSC-Log. In response to this command, the following happens:
The mapping rules which govern how SDL events are transformed into MSC symbols, lines and textual elements are summarized in the following table:
| SDL concept | MSC Concept |
|---|---|
|
Signal |
Message |
|
Signal to self |
Message to self |
|
Timer |
Timer
|
|
Create a process |
Process Create |
|
Stop a process |
Stop |
|
Environment |
Environment2 |
|
System |
Instance |
|
Substructure |
Instance |
|
Block |
Instance |
|
Process |
Instance |
|
State |
Condition3 |
|
Task |
Action4 |
|
Comment |
Comment |
When running the simulation, each SDL event of interest (in the scope of MSC Trace) that takes place will cause the corresponding MSC symbol to be drawn in the drawing area of the MSC Editor.
Default layouting algorithms are used. Each event causes the insertion point to be translated downwards with one vertical spacing unit, keeping the intuitive feeling of absolute order between events. An event could be, for instance, the output or the input of an SDL signal. However, if an output event is immediately followed by an input event, no translation will take place.
The MSC Editor will automatically enlarge the MSC size when the MSC has grown so that it reaches the bottom or right of the drawing area. The MSC is enlarged according to a preference parameter.
A distinction is made between the reception and the consumption of messages:
Each time an SDL process is dynamically created, a process create will be drawn from the source instance axis, and the created instance will be positioned according to the insert and grouping modes that is set. This guarantees that no overlapping instance axes will take place.
The MSC Editor will automatically enlarge the MSC size when the MSC has grown so that it reaches the bottom or right of the drawing area. The drawing area is enlarged according to the value of a preference parameter.
If an instance is stopped (by a stop symbol), the space which becomes available beneath the instance end symbol will not be reused for new instance axes.
Figure 305 : Timer status as shown on the MSC
|
|
1:env. This instance is normally placed at the left of the drawing area.
Figure 306 : The use of the instance text fields in a simulation
|
|
Having terminated the trace (either by stopping the simulation or turning the MSC trace off), you are responsible for saving the MSC(s) that are the results of the simulation.
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.
In general, a somewhat restricted version of the lexical rules of SDL apply for names. These rules have the following noteworthy properties:
/* 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).
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 names must follow certain restrictions since they are used to identify the diagram with respect to other tools.
Diagramname ::= <name>
Pagename ::= <name>
Each page name must be unique within its containing diagram.
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 guillemot («») but it can also be written as two angle brackets. To type the left/right guillemot in the text window, press <Ctrl> when you type the left/right angle bracket.
Classname ::= <name> | <name> `:' `:' <name> | <empty>
AttributesCompartment ::=
{ <stereotype> <attribute> <note> }*
<stereotype> ::= `<' `<' <name> `>' `>' |
`«' <name> `»' |
<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.
OperationsCompartment ::=
{ <stereotype> <operation> <note> }*
<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.
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.
Objectname ::= <name> `:' <classname> | <name> | <empty>
The object attributes compartment syntax is identical to the Class Attributes Compartment Syntax.
Text symbols are not subject to any syntax rules.
The current version of the OM Editor does not implement any syntax checks on the contents of the textual attribute objects of lines.
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.
In general, a somewhat restricted version of the lexical rules of SDL apply for names. These rules have the following noteworthy properties:
/* 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.
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 variables or 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.
The diagram name identifies the diagram.
<DiagramName> ::= <name>
The page name identifies the page within a diagram.
<PageName> ::= <name>
Each page name must be unique within its containing diagram.
The textual information in state symbols' state sections is divided into three compartments with different syntax.
The name identifies the state.
<NameCompartment> ::=
[<name>]
State variables' syntax is defined by the following grammar:
<StateVariableCompartment> ::=
{[<visibility>] <variable> [<property>]}*
<visibility> ::=
`+' |
`#' |
`-'
<variable> ::=
<name>
[`:' <type-expression>]
[`=' <value-expression>]
<property> ::=
`{' <property-spec> {`,' <property-spec>}* `}'
<property-spec> ::=
<keyword> [`=' <value-expression>]
<keyword> ::=
<name>
<type-expression> ::=
<expression>
<value-expression> ::=
<expression>
<expression> ::= SDL-PR expression
Two state variables are considered identical if they have the same name and type.
Internal activities' syntax is defined by the following grammar:
<InternalActivityCompartment> ::=
{<internal-event> `/' <action-expression>}*
<internal-event> ::=
<event-signature> |
`entry' |
`exit' |
`do'
<event-signature> ::=
<name> [`(' [<argument> {`,' <argument>}*] `)']
<argument> ::=
<expression>
<action-expression> ::=
<expression>
Two 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 symbols are not subject to any syntax rules.
The textual information in the transition label attribute of transition lines is defined by the following grammar:
<TransitionLabel> ::=
[<event-signature>]
[`[' <guard-condition> `]']
[`/' <action-list>]
[`^' <sendevent-list>]
<guard-condition> ::=
<expression>
<action-list> ::=
<action-expression> {`,' <action-expression>}*
<sendevent-list> ::=
<sendevent> {`,' <sendevent>}*
<sendevent> ::=
[<destination-expression> `.']
<event-signature>
<destination-expression> ::=
<expression>
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 rules3 are enforced automatically by the HMSC Editor and are not described here.
The lexical elements follow MSC'96. These rules have the following noteworthy properties:
<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.
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:
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.
The page name identifies the page within a document.
<page name> ::= <name>
Each page name must be unique within its containing diagram.
The text in a text symbol is an informal explanatory text.
<text text> ::= <text>
The text has no (formal) semantic and no restrictions.
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> ::= name
Global conditions indicate possible continuations of Message sequence charts containing the same the same set of instances by means of condition name identification.
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>
<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>
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 rules4 are enforced automatically by the MSC Editor and are not described here.
The lexical elements follow MSC'96. They are identical to the lexical rules for HMSC, see Summary of Lexical Rules for further information.
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:
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.
In addition to the symbols that are common HMSC symbols, the MSC Editor supports the following symbols that contains text.
The text in a comment symbol is an informal explanatory text.
<comment text> ::= <text>
The text has no (formal) semantic and no restrictions.
The text identifies the entity
<instance name> ::= name <message name> ::= name <timer name> ::= name
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>.
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> `>>'
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>
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}+
There is a growing number of publications devoted to object modeling techniques. The following two sources have been selected as defining the Object Model supported by the OM Editor:
[5]
Unified Modeling Language, version 1.1, Sept. 1997
UML Semantics (document ad/97-08-04)
UML Notation Guide (document ad/97-08-05)
Object Management Group
ftp://ftp.omg.org/pub/docs/ad/
[6] Object Oriented Modeling and Design
Rumbaugh, Blaha, Premerlani, Eddy, Lorensen
Prentice-Hall (1991)
ISBN 0-13-630054-5
There is a growing number of publications devoted to state chart techniques. The following source has been selected as defining the State Chart supported by the SC Editor:
[7] Unified Modeling Language, version 1.1, Sept. 1997
UML Semantics (document ad/97-08-04)
UML Notation Guide (document ad/97-08-05)
Object Management Group
ftp://ftp.omg.org/pub/docs/ad/
[8] Unified Modeling Language, version 1.0, January 1997
UML Semantics (document ad/97-01-03)
UML Notation Guide (document ad/97-01-09)
Object Management Group
ftp://ftp.omg.org/pub/docs/ad/
[9] Z.120 (1996).
Message Sequence Chart (MSC).
ITU-T, Geneva, April 1996
[10] Object-Oriented Software Engineering
-- A Use Case Driven Approach.
I. Jacobson.
Addison-Wesley, 1992
[11] Tutorial on Message Sequence Charts (MSC'96)
Ekkart Rudolph, Jens Grabowski, and Peter Graubman
[12] The Unified Modeling Language User Guide
Grady Booch, Ivar Jacobson, James Rumbaugh.
Addison-Wesley, 1998
[13] The Unified Modeling Language Reference Manual
James Rumbaugh, Ivar Jacobson, Grady Booch.
Addison-Wesley, 1998
[14] The Unified Software Development Process
Ivar Jacobson, James Rumbaugh, Grady Booch.
Addison-Wesley, 1999