Skip to Content
Version 10.1 by Helena on 2025/05/15 09:59
Show last authors
1 = 16 Appendix 1: A Short Guide to UML in the SDMX Information Model =
2
3 == 16.1 Scope ==
4
5 The scope of this document is to give a brief overview of the diagram notation used in UML. The examples used in this document have been taken from the SDMX UML model.
6
7 == 16.2 Use Cases ==
8
9 In order to develop the data models it is necessary to understand the functions that require to be supported. These are defined in a use case model. The use case model comprises actors and use cases and these are defined below.
10
11 The **actor** can be defined as follows:
12
13 “//An actor defines a coherent set of roles that users of the system can play when interacting with it. An actor instance can be played by either an individual or an external system”//
14
15 The actor is depicted as a stick man as shown below.
16
17 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_19d8e2a1.png||height="121" width="154"]]
18
19 **Figure 49 Actor**
20
21 The **use cas**e can be defined as follows:
22
23 “//A use case defines a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor”//
24
25 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_84d6f442.png||height="95" width="124"]]
26
27 **Figure 50 Use case**
28
29 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_11bb0513.png||height="91" width="371"]]
30
31 **Figure 51 Actor and use case**
32
33 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_35b02320.png||height="296" width="466"]]
34
35 **Figure 52 Extend use cases**
36
37 An extend use case is where a use case may be optionally extended by a use case that is independent of the using use case. The arrow in the association points to he owning use case of the extension. In the example above the Uses Data use case is optionally extended by the Uses Metadata use case.
38
39 == 16.3 Classes and Attributes ==
40
41 === 16.3.1 General ===
42
43 A class is something of interest to the user. The equivalent name in an entity-relationship model (E-R model) is the entity and the attribute. In fact, if the UML is used purely as a means of modelling data, then there is little difference between a class and an entity.
44
45 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_5488dc81.png||height="113" width="147"]]
46
47 **Figure 53 Class and its attributes**
48
49 Figure 53 shows that a class is represented by a rectangle split into three compartments. The top compartment is for the class name, the second is for attributes and the last is for operations. Only the first compartment is mandatory. The name of the class is Annotation, and it belongs to the package SDMX-Base. It is common to group related artefacts (classes, use-cases, etc.) together in packages. . Annotation has three “String” attributes – name, type, and url. The full identity of the attribute includes its class e.g. the name attribute is Annotation.name.
50
51 Note that by convention the class names use UpperCamelCase – the words are concatenated and the first letter of each word is capitalized. An attribute uses lowerCamelCase - the first letter of the first (or only) word is not capitalized, the remaining words have capitalized first letters.
52
53 === 16.3.2 Abstract Class ===
54
55 An abstract class is drawn because it is a useful way of grouping classes, and avoids drawing a complex diagram with lots of association lines, but where it is not foreseen that the class serves any other purpose (i.e. it is always implemented as one of its sub classes). In the diagram in this document an abstract class is depicted with its name in italics, and coloured white.
56
57 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_7fd7b0b0.png||height="80" width="486"]]
58
59 **Figure 54 Abstract and concrete classes**
60
61 == 16.4 Associations ==
62
63 === 16.4.1 General ===
64
65 In an E-R model these are known as relationships. A UML model can give more meaning to the associations than can be given in an E-R relationship. Furthermore, the UML notation is fixed (i.e. there is no variation in the way associations are drawn). In an E-R diagram, there are many diagramming techniques, and it is the relationship in an E-R diagram that has many forms, depending on the particular E-R notation used.
66
67 === 16.4.2 Simple Association ===
68
69 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_464f6c7a.png||height="259" width="221"]]
70
71 **Figure 55 A simple association**
72
73 Here the ,,DataflowDefinition,, class has an association with the DataStructureDefinition class. The diagram shows that a DataflowDefinition can have an association with only one ,,DataStructureDefinition,, (1) and that a DataStructureDefinition can be linked to many DataflowDefinitions (0..*). The association is sometimes named to give more semantics.
74
75 In UML it is possible to specify a variety of “multiplicity” rules. The most common ones are:
76
77 Zero or one (0..1)// //
78
79 Zero or many (0..*)// //
80
81 One or many (1..*)// //
82
83 Many (*)// //
84
85 Unspecified (blank)// //
86
87 === 16.4.3 Aggregation ===
88
89 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_d242c5fa.png||height="289" width="267"]]
90
91 **Figure 56: A simple aggregate association**
92
93 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_e053fbda.png||height="254" width="128"]]
94
95 **Figure 57 A composition aggregate association**
96
97 An association with an aggregation relationship indicates that one class is a subordinate class (or a part) of another class. In an aggregation relationship. There are two types of aggregation, a simple aggregation where the child class instance can outlive its parent class, and a composition aggregation where the child class's instance lifecycle is dependent on the parent class's instance lifecycle. In the simple aggregation it is usual, in the SDMX Information model, for this association to also be a reference to the associated class.
98
99 === 16.4.4 Association Names and Association-end (role) Names ===
100
101 It can be useful to name associations as this gives some more semantic meaning to the model i.e. the purpose of the association. It is possible for two classes to be joined by two (or more) associations, and in this case it is extremely useful to name the purpose of the association.
102
103 Figure 58 shows a simple aggregation between CategoryScheme and Category called ///items //(this means it is derived from the association between the super classes – in this case between the //ItemScheme// and the //Item,// and another between Category called ///hierarchy//.
104
105 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_20c6f399.png||height="306" width="222"]]
106
107 **Figure 58 Association names and end names**
108
109 Furthermore, it is possible to give role names to the association-ends to give more semantic meaning – such as parent and child in a tree structure association. The role is shown with “+” preceding the role name (e.g. in the diagram above the semantic of the association is that a ,,Item,, can have zero or one parent ,,Items,, and zero or many child ,,Item,,).
110
111 In this model the preference has been to use role names for associations between concrete classes and association names for associations between abstract classes. The reason for using an association name is often useful to show a physical association between two sub classes that inherit the actual association between the super class from which they inherit. This is possible to show in the UML with association names, but not with role names. This is covered later in “Derived Association”.
112
113 Note that in general the role name is given at just one end of the association.
114
115 === 16.4.5 Navigability ===
116
117 Associations are, in general, navigable in both directions. For a conceptual data model it is not necessary to give any more semantic than this.
118
119 However, UML allows a notation to express navigability in one direction only. In this model this “navigability” feature has been used to represent referencing. In other words, the class at the navigable end of the association is referenced from the class at the non-navigable end. This is aligned, in general, with the way this is implemented in the XML schemas.
120
121 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_c5020cf3.png||height="61" width="341"]]
122
123 **Figure 59 One way association**
124
125 Here it is possible to navigate from A to B, but there is no implementation support for navigation from B to A using this association.
126
127 === 16.4.6 Inheritance ===
128
129 Sometimes it is useful to group common attributes and associations together in a super class.
130
131 This is useful if many classes share the same associations with other classes, and have many (but not necessarily all) attributes in common. Inheritance is shown as a triangle at the super class.
132
133 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_8dc7563c.png||height="353" width="166"]]
134
135 **Figure 60 Inheritance**
136
137 Here the Dimension is derived from Component which itself is derived from
138
139 //IdentifiableArtefact//. Both Component and IdentifiableArtefact are abstract superclasses. The Dimension inherits the attributes and associations of all of the super classes in the inheritance tree. Note that a super class can be a concrete class (i.e. it exists in its own right as well as in the context of one of its sub classes), or an abstract class.
140
141 === 16.4.7 Derived association ===
142
143 It is often useful in a relationship diagram to show associations between sub classes that are derived from the associations of the super classes from which the sub classes inherit. A derived association is shown by “/” preceding the association name e.g. ///name//.
144
145 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_255f3480.png||height="329" width="705"]]
146
147 **Figure 61 Derived associations**
148
149 [[1>>path:#sdfootnote1anc||name="sdfootnote1sym"]] OLAP: On line analytical processing
150
151 [[2>>path:#sdfootnote2anc||name="sdfootnote2sym"]] The Codelist that extends 0..* Codelists is the 'extending' Codelist, while the Codelist(s) that are inherited is/are the 'extended' Codelist(s).
152
153 [[3>>path:#sdfootnote3anc||name="sdfootnote3sym"]] Source and target Data Structure Definition are either directly linked from the StructureMap or indirectly via the linked source and target Dataflow
154
155 [[4>>path:#sdfootnote4anc||name="sdfootnote4sym"]] Provider Scheme, Provider, Provision Agreement and Registered source refer both to data and reference metadata.
156
157 [[5>>path:#sdfootnote5anc||name="sdfootnote5sym"]] Or a part of a Dataflow, see also the chapter “Validation and Transformation Language” of the Section 6 of the SDMX Standards (“SDMX Technical Notes”), paragraph “Mapping dataflow subsets to distinct VTL data sets”.
158
159 [[6>>path:#sdfootnote6anc||name="sdfootnote6sym"]] Provided that the VTL consistency rules are accomplished (see the “Generic Model for Transformations” in the VTL User Manual and its sub-section “Transformation Consistency”).
160
161 [[7>>path:#sdfootnote7anc||name="sdfootnote7sym"]] For example, the **check** operator produces some new components in the result called by default **bool_var**, **errorcode**, **errorlevel**, **imbalance**. These names can be personalised if needed.
162
163 [[8>>path:#sdfootnote8anc||name="sdfootnote8sym"]] SDMX Technical Notes, chapter “Validation and Transformation Language”, section “References to SDMX artefacts from VTL statements”.
164
165 11 For a more thorough description of these conversions, see the Section 6 of the SDMX Standards (“SDMX Technical Notes”), chapter “Validation and Transformation Language”, section “Mapping between SDMX and VTL”.
166
167 [[9>>path:#sdfootnote9anc||name="sdfootnote9sym"]] SDMX Technical Notes, chapter “Validation and Transformation Language”, section “Mapping dataflow subsets to distinct VTL data sets”.
168
169 [[10>>path:#sdfootnote10anc||name="sdfootnote10sym"]] Or a part of a Dataflow, as described in the previous paragraph.
170
171 [[11>>path:#sdfootnote11anc||name="sdfootnote11sym"]] The default conversion table from VTL to SDMX is described in the the Section 6 of the SDMX Standards (“SDMX Technical Notes”), chapter “Validation and Transformation Language”, section “Mapping VTL basic scalar types to SDMX data types”.
172
173 15 About VTL internal and external representations, see also the VTL User Manual, section “Basic scalar types”, p.53.
174
175 [[12>>path:#sdfootnote12anc||name="sdfootnote12sym"]] See “Mapping VTL basic scalar types to SDMX data types” in the SDMX Technical Notes, chapter “Validation and Transformation Language”.
176
177 [[13>>path:#sdfootnote13anc||name="sdfootnote13sym"]] See “Mapping VTL basic scalar types to SDMX data types” in the SDMX Technical Notes, chapter “Validation and Transformation Language”.
178
179 [[14>>path:#sdfootnote14anc||name="sdfootnote14sym"]] See “Mapping VTL basic scalar types to SDMX data types” in the SDMX Technical Notes, chapter “Validation and Transformation Language.