 "Friday", "Saturday", "Sunday"} Date ::= SET {month, day} Fig. 1.17 A model property in textual representation The name of the primitive is CAS/calInfoConfirm, where CAS/callnfo is the name of the operation it refers, and Confirm tells that the primitive carries a confirmation that the operation has ben successfully executed. The rest of the specification describes the parameters of the primitive, using an ASN.1-like notation. Parts of the textual information could be annotated in a collaboration diagram, e.g. as a symbol for an event (an instance of the primitive), annotated with the abbreviated name of the primitive, excluding parameters, as shown in Fig. 1.18. CAS/callInfoConfirm provider Fig. 1.18 Event notation in a collaboration diagram However, in reality, there is seldom room for also describing the parameters in a diagram. Merely listing all primitive names of an interface is often too much, or the model can become incomprehensible. Therefore, from a specification point of view, the primary purpose of a graphical model is not to display complete information, but to act as a place holder and an access structure for more detailed information. Sections of detailed information could be given a graphical representation to support annotating visualized models, but that is more a tool issue than a language issue. However, most annotations should not be a permanent part of the visualized model, but selectable by the mod- eller and by users of the model. 1 Introduction to Systems Modelling 1.6.3 Model Structure Representation Due to the complexity of the systems we want to model, system models may become very large and complex. Furthermore, there will be many persons working on the model in parallel over a long time. It is therefore necessary to structure large models into fragments in some way. There are at least two aspects of fragmentation to be considered: Different types of fragments should represent different types of system proper- ties, SO that each fragment represents a natural specification object. Als