Most
notational elements were taken from existing signs related to events, risks, and
payments, such as traf?¬?c signs and currency. Figure 6.7 shows the notation for some
modeling concepts when using the language to create speci?¬?cations.
Aspeci?¬?c question on the notation dealt with showing detailed properties of model
elements. Since insurance elements usually had 5??“10 properties, showing all would
make large symbols that took most of the modeling space. Instead, the functionality of
the modeling tools was used to hide the details and make them available via browsers
and dialogs related to the model element. The symbols were used to showjust the most
important information, such as name, given name, and composite information. Since
the modeling concepts were new in the beginning, each symbol showed its type name
too. Later, once the language had been used, this extra cue for identifying the different
types was removed.
Since it was not always desirable to specify inheritance with an explicit
relationship, each domain element was modi?¬?ed by adding an inheritance property
FIGURE 6.6 A part of the metamodel specifying model hierarchies by allowing a
decomposition from an object type Package to the Product modeling language
type. Its value was then the possible supertype. This property type was de?¬?ned as an
object, instead of using name matching, so that the details of the supertype could be
130 INSURANCE PRODUCTS
viewed during model creation.
Pages:
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259