Visits: 43
Study report Part 2 Semantic model definition using ISO/IEC 19505 OMG UML
Nobuyuki SAMBUICHI
ISO/TC295 Audit data services/SG1 Semantic model Convener
In the 2023 version of ISO/IEC 11179, we can define the UML semantic model and hierarchical logical data model with the ISO/IEC 11179-3 terms without using ISO 15000-5 CCS.
The electronic version of ISO/IEC 11179-1:2023 and ISO/IEC 11179-3:2023 can be downloaded from the
ISO/IEC Information Technology Task Force (ITTF) web site.
Proposal for tabular natation of UML model is described in the following page.
Do you know ISO/IEC 11179-31:2023(en)?
I’m sorry, but as an AI with a knowledge cutoff in September 2021, I don’t have specific information about ISO/IEC 11179-31:2023. The ISO/IEC 11179 is a standard for metadata registries (MDR), a set of international standards relating to the representation of data about data, but I cannot provide information about updates or amendments made after my last training data.
If it’s been recently released, you’ll probably need to look for official resources or databases that keep up-to-date with new ISO standards. ISO standards are typically available for purchase and sometimes available in part or in summary through national standards organizations, libraries, or companies that deal specifically with that area of standardization.
1. Comments on Part 2
Analysis of semantic models and message development frameworks for Audit Data Services — Part 2: Technical explanation with GL_Details as Proof Of Concept
1.1. Draft 4.2.4.2 ACCOUNT SEGMENT
Contains associated Account Segment information.
Table 3 — Properties of Account Segment
|
Property term |
Representation term |
Description |
|
Account Segment Number |
STRING |
Sequence number of the associated Account Segment. |
|
Account Segment Code |
STRING |
Account Segment Code. |
Table 4 — Relations of Account Segment
|
Object class term to |
Relation type |
Cardinality |
|
GL ACCOUNT SEGMENT |
ASSOCIATION |
n..1 |
1.2. Attribute not fully listed in Table 3
Table 56 of ISO 21378:2019 — 4.5.5 GL Account Segment GL_Account Segment defines 6 fields, whereas Table 4 of Part 2 defines only 2 attributes.
Recommended change:
To avoid unnecessary discussion, define all fields defined in ISO 21378:2019.
1.3. The association representation in Table 4 does not follow the UML standard
Table 4 — Relations of Account Segment Cardinality does not follow ISO/IEC 19505 OMG UML.
Following two standard documents
ISO/IEC 19505-1:2012(en) Information technology — Object Management Group Unified Modeling Language (OMG UML) — Part 1: Infrastructure and
ISO/IEC 19505-2:2012(en) Information technology – Object Management Group Unified Modeling Language (OMG UML), Superstructure
SHALL be the normative reference document.
Associations are defined in the following clauses.
11.4.1 Association (Part 1)
7.3.3 Association (from Kernel) (Part 2)
1.4. Types of association in ISO/IEC 19505
Following dialogue with ChatGPT will provide general understandings for Association in ISO/IEC 19505 OMG UML.
ChatGPT is reported mixed with part1 and part2, but it is well summarized.
What is the definition of association in OMG UML 2.0?
Provide kinds of association and how to express characteristics such as occurence of end point class. Provide reference chapter number in ISO/IEC 19505-1:2012(E) and ISO/IEC 19505-2:2012(E) with your answer.
In OMG UML 2.0, an association represents a relationship between two or more classifiers (classes or other types) within a system. It captures a structural connection and interaction between the associated classifiers. The association describes how instances of these classifiers are connected or related to each other.
OMG UML 2.0 does not explicitly define different kinds of associations, but it provides flexibility to model various types of associations based on the characteristics and semantics of the connected classifiers. Some common kinds of associations include:
Binary Association: An association between two classifiers. It is the simplest form of association.
N-ary Association: An association between three or more classifiers. It allows multiple classifiers to be connected together.
Aggregation: An association representing a whole-part relationship, where one classifier (the whole) is composed of or includes other classifiers (the parts). Aggregation is denoted by a diamond-shaped symbol on the side of the whole classifier.
Composition: A stronger form of aggregation, where the parts are exclusive to the whole and have a lifecycle dependency on the whole. Composition is denoted by a filled diamond-shaped symbol on the side of the whole classifier.
Qualified Association: An association with additional qualifiers that further describe the relationship between the classifiers. Qualifiers can be attributes or associations themselves.
Regarding the references you mentioned, ISO/IEC 19505-1:2012(E) and ISO/IEC 19505-2:2012(E) are the official specifications for the UML 2.5.1 standard, not specifically UML 2.0. The UML 2.0 specification does not have an official ISO/IEC standard number. However, the concepts and characteristics of associations in UML 2.0 are also applicable to UML 2.5.1.
If you are specifically looking for information in the UML 2.5.1 specification, the relevant chapters are as follows:
ISO/IEC 19505-1:2012(E) – UML Infrastructure: Chapter 7 – Association (NOTE This chapter is in 19505-2)
ISO/IEC 19505-2:2012(E) – UML Superstructure: Chapter 11 – Associations (NOTE This chapter is in 19505-1)
Please note that the chapter numbers may vary slightly depending on the specific edition or version of the UML specification. It’s always best to refer to the official UML specification documents for the most accurate and up-to-date information.
TC295 will define following 3 types of association.
Association is a binary association and expressed as an ASSOCIATION.
Composition is aSpecial case of Aggregation association and expressed as an HAS_A. A table without Composition is not usable.
Specialization is a Generalization and Specialization relationship and not defined in ISO/IEC 19505. This type of association is required to support rich reusability of the semantic model and is expressed as IS_A.
1.5. Multiplicity in ISO/IEC 19505
We shall follow the multiplicity notation from UML. There is no definition on cardinality n..1 .
Following texts are summary by ChatGPT.
In the ISO/IEC 19505-2:2012(E) standard, specifically in Chapter 7.3.3 “Association” from the UML Superstructure, the definition and characteristics of associations are described. Here is a summary of the key points covered in that section:
An association is a structural relationship between two or more classifiers, representing a connection and interaction between them.
Associations are depicted as solid lines connecting the participating classifiers.The standard does not explicitly define different types of associations, but various kinds of associations can be modeled based on the semantics and characteristics of the connected classifiers.
Each end of the association represents the participation of a classifier in the relationship.
Multiplicity is used to express the cardinality or number of instances that can participate in the association from each end.
Multiplicity is represented using notation such as “0..1” (zero or one instance), “1” (exactly one instance), “0..” (zero or more instances), “1..” (one or more instances), or specific numerical ranges.
The multiplicity of each endpoint is typically shown near the end of the association line, adjacent to the classifier it represents.
If the multiplicity is not specified, it is considered to be “1” by default, meaning exactly one instance is expected.The multiplicity range can be extended to include additional constraints using OCL (Object Constraint Language) expressions or other means.
It’s important to note that the specific details and conventions for drawing associations and expressing multiplicities may vary slightly depending on the modeling tool or diagramming style being used. However, the concepts and principles outlined in the ISO/IEC 19505-2:2012(E) standard provide the foundation for understanding associations and their characteristics in UML.
Summary of ISO/IEC 19505-2:2012(en)
The following adornments are shown on the four association ends in Figure 7.22.
In Figure 7.22 – Association ends with various adornments
The following adornments are shown on the four association ends in Figure 7.22.
• Names a, b, and d on three of the ends.
• Multiplicities 0..1 on a, * on b, 1 on the unnamed end, and 0..1 on d.
• Specification of ordering on b.
• Subsetting on d. For an instance of class C, the collection d is a subset of the collection b. This is equivalent to the OCL
constraint:
context C inv: b→includesAll(d)
ISO/IEC 19505-2:2012(en)
ISO/IEC 19505-1:2012(E) defines notation for the Multiplicities for the end point in Clause 9.12.1 MultiplicityElement as follows;
9.12.1 MultiplicityElement
Notation
The specific notation for a MultiplicityElement is defined by the concrete subclasses. In general, the notation will include
a multiplicity specification, which is shown as a text string containing the bounds of the interval, and a notation for
showing the optional ordering and uniqueness specifications.The multiplicity bounds are typically shown in the format:
<lower-bound>’..’ <upper-bound>
where <lower-bound> is a non-negative integer and <upper-bound> is an unlimited natural number. The asterisk (*) is
used as part of a multiplicity specification to represent the unlimited (or infinite) upper bound.If the Multiplicity is associated with an element whose notation is a text string (such as an attribute, etc.), the multiplicity
string will be placed within square brackets ([]) as part of that text string. Figure 9.33 shows two multiplicity strings as
part of attribute specifications within a class symbol.If the Multiplicity is associated with an element that appears as a symbol (such as an association end), the multiplicity
string is displayed without square brackets and may be placed near the symbol for the element. Figure 9.34 shows two
multiplicity strings as part of the specification of two association ends.The specific notation for the ordering and uniqueness specifications may vary depending on the specific subclass of
MultiplicityElement. A general notation is to use a property string containing ordered or unordered to define the ordering,
and unique or nonunique to define the uniqueness.
ISO/IEC 19505-1:2012(en) 9.12.1 MultiplicityElement
1.6. Explanation of Multiplicity
Following questions to ChatGPT are intended to clarify the meaning of multiplicity.
What is the meaning of multiplicity 0..1 for starting end pint of the association?
In the context of an association in UML, the multiplicity expression “0..1” for the starting endpoint of the association signifies that there can be zero or one instance of the associated classifier participating in the relationship.
Here’s what the “0..1” multiplicity notation means:
“0” indicates that the participation is optional, meaning there may not be any instances associated with the starting end of the association.
“1” indicates that if there is participation, it can involve at most one instance associated with the starting end of the association.
In practical terms, this means that the association allows for the possibility of having no instances associated with the starting end, or having a single instance associated with it. It provides flexibility in modeling scenarios where the participation of the classifier on the starting end may or may not be present, but if it is present, it can only be associated with a single instance.
For example, consider an association between the classes “Car” and “Owner” where the multiplicity of the Car end is “0..1”. This implies that a car may or may not have an owner (optional participation), but if it does have an owner, it can only have one owner.
It’s important to note that the interpretation and application of multiplicity constraints may vary depending on the specific modeling context and the intent of the model. The precise semantics of the association, including multiplicity constraints, should be clarified and agreed upon within the modeling and design process.
What is the meaning of multiplicity 0 fro both starting and ending end point?
When both the starting and ending endpoints of an association in UML have a multiplicity of “0”, it signifies that the participation of instances on both ends is optional. Here’s what the multiplicity “0” notation means in this context:
“0” indicates that the participation is optional, meaning there may or may not be instances associated with the respective ends of the association.
In practical terms, this means that neither end of the association is required to have any associated instances. Instances can choose to participate or not participate in the relationship.
For example, consider an association between the classes “Student” and “Course” where the multiplicity of both ends is “0”. This implies that a student may or may not be enrolled in any courses, and a course may or may not have any enrolled students. Both participation scenarios are possible, but not mandatory.
It’s important to note that the interpretation and application of multiplicity constraints may vary depending on the specific modeling context and the intent of the model. The precise semantics of the association, including multiplicity constraints, should be defined and understood within the context of the system being modeled.
What does class attribute multiplicity mean? Let me explain with some examples.
In UML, the multiplicity of a class attribute specifies the number of instances that can be associated with the attribute. It indicates the cardinality or count of the values that can be held by the attribute for each instance of the class. The multiplicity can be defined for both simple attributes (such as integers, strings, etc.) and associations.
Here are some examples to illustrate the meaning of multiplicity for class attributes:
Single-valued attribute:
Multiplicity: “1”
Meaning: Each instance of the class can have exactly one value assigned to this attribute. It is a mandatory attribute.
Optional attribute:
Multiplicity: “0..1”
Meaning: Each instance of the class can have zero or one value assigned to this attribute. It is an optional attribute that may or may not have a value.
Multi-valued attribute:
Multiplicity: “*”
Meaning: Each instance of the class can have any number of values (zero or more) assigned to this attribute. It allows multiple values to be stored in the attribute.
Bounded range of values:
Multiplicity: “2..5”
Meaning: Each instance of the class can have a minimum of two and a maximum of five values assigned to this attribute. It restricts the number of values within a specific range.
These examples demonstrate how the multiplicity of a class attribute defines the permissible number of values associated with that attribute for each instance of the class. The multiplicity notation allows for a wide range of cardinality expressions, including exact values, ranges, and special symbols like “*”, which represents unlimited or unbounded multiplicity.
It’s important to note that the precise semantics of attribute multiplicity can vary depending on the modeling context and the conventions established within the project or organization. It is crucial to clarify and document the intended meaning and behavior of attributes in the specific system being modeled.
2. UML diagram for Account Segment
This diagram specifies every field listed in ISO 21378:2019.
PK is notate with representation and associations are defined arrow between classes with Multiplicities adornments and attribute name.
Referencing GL_Account_Segment from GL_Details cannot explain in UML
https://www.sambuichi.jp/?p=10132
.Source code for the diagram above by Mermaid
classDiagram
class Customized_Account_Segment["Customized Account Segment"]
Customized_Account_Segment : +~String_PK~ Customized_Account_Segment_Code
Customized_Account_Segment : +~note~ To_simplify_notation,_other_attributes_are_omitted
class GL_Details["GL Details"]
GL_Details : +~String_PK~ Journal_ID
GL_Details : +~note~ To_simplify_notation,_other_attributes_are_omitted
class Chart_Of_Accounts["Chart of Accounts"]
Chart_Of_Accounts : ~String_PK~ GL_Account_Number
Chart_Of_Accounts : +~note~ To_simplify_notation,_other_attributes_are_omitted
class GL_Account_Segment["Account Segment"]
GL_Account_Segment : +~String_PK~ Account_Segment_Number
GL_Account_Segment : +~String_REF~ GL_Account_Number
GL_Account_Segment : +~String~ Account_Segment_Name
GL_Account_Segment : +~String~ Corresponding_File
GL_Account_Segment : +~String~ Account_Segment_Description
GL_Account_Segment : +~String_REF~ Customized_Account_Segment_Code
GL_Account_Segment "0..*" <-- "1" GL_Details : Account_Segment_Number
GL_Account_Segment "0..1" --> "1" Chart_Of_Accounts : GL_Account_Number
GL_Account_Segment "1..1" --> "0..1" Customized_Account_Segment : Customized_Account_Segment_CodePK means Primary key and REF means Reference identifier.
NOTE
Although ISO 21387:2019 defines the primary key as a combination of Account_Segment_Number and GL_Account_Number, it is recommended to have a single primary key for each object class.
3. Revised table definition for Account Segment
3.1. Proposed table format change for Part 2 4.1.2
Part2 specifies following table definition in Sub-clause 4.1.2 Representation of object classes
4.1.2.1 Representation of object class properties
Table 1 — Object class properties (model)
Property term Representation term Description The object class properties table [Table 1] has the following columns:
Property term
Name of the property
Representation term
A representation term is a word, or a combination of words, that semantically represent the data type (value domain) of a data element.
Examples used in this document are:
— Date
— Time
— String
— Amount
— Identifier
— Boolean
Description
Description of the property
Note: Properties can have a “value domain” which is the permitted range of values. That can be defined in a code list or through a rule. This is not elaborated in the proof of concept.
Summary of ISO/TC 295
Table 3 (revised) — GL Account Segment
|
Property term |
Representation term |
Description |
|
GL Account Number |
String |
The GL account number. |
|
Account Segment Number |
String |
The number of the Account Segment. |
|
Account Segment Name |
String |
The name of the Account Segment. |
|
Corresponding File |
String |
The table corresponding to account segment. |
|
Account Segment Description |
String |
The detailed description of the Account Segment Name. |
|
Customized Account Segment Code |
String |
The code of the customized account segment. Shall match the Customized Account Segment Code in the BAS Customized Account Segment table. |
4.1.2.2 Representation of object class relations
Table 2 — Object class relations (model)
Object class term to Relation type Cardinality The object class relations table [Table 2] has the following columns:
Object class term to
Object class term to is the name of the object class with which the described object class has a relationship.Relation type
In this document the following relation types are used:
— Association
— Composition
— Specialization
Specialization is denoted by relation type “IS_A” in this document.Cardinality
Cardinality captures how many of one object class instances participates in the relationship with how many of the other object class instance.
Summary of ISO/TC 295
A starting endpoint multiplicity value of 1 is assumed. The cardinality in Table 2 corresponds to the multiplicity value of the terminating endpoint.
4.1.2.2 The representation of object class relationships assumes that the starting endpoint has a multiplicity of 1, but as in this case, the cardinality of the starting endpoint shall be reported to be clearly understood. This is a tabular representation of Figure 1.
Table 4 (revised) — Association of GL Account Segment
|
Property term |
Object class term from |
Starting (from) Cardinality |
Relation type |
Object class term to |
Ending (to) Cardinality |
|
Account Segment Number |
GL Account Segment |
0..* |
Association |
GL Details |
1 |
|
GL Account Segment |
0..* |
Association |
NOTE: There are many object class associated to GL Account Segment. To simplify, other object classes are omitted |
1 |
|
|
GL Account Number |
Chart Of Accounts |
1 |
Association |
GL Account Segment |
0..1 |
|
Customized Account Segment Code |
Customized Account Segment |
0..1 |
Association |
GL Account Segment |
1 |
Note: Both to and from are required to distinguish between associated object classes.
Note: 1 is equivalent to 1..1 .
To use a GL account segment, you need a GL detail that references the GL account number. However, from a GL detail perspective, the GL account segment is optional and not always defined. Also, a GL detail can have any number of associations to GL account segments.
4. ISO 11179:2023 and cardinality of attributes
ISO/IEC 11179-3 Metamodel for registry common facilities support new terms to specify Metadata such as cardinality, association, composite.
Introduction
In ISO/IEC 11179-3, the structure of a Metadata Registry is specified in the form of a conceptual data model. ISO/IEC 11179-3 specifies a metamodel for “registry common facilities”, which is intended to be extended by other parts of ISO/IEC 11179 for specific purposes.
This document provides a specification of the extensions to the registry metamodel specified in ISO/IEC 11179-3 to enable the registration of metadata about data elements and associated concepts, such as “data element concepts”, “conceptual domains” and “value domains”. Generically, these are all referred to as “metadata items”. Such metadata are necessary to clearly describe, record, analyse, classify and administer data.
This document is part of the 4th edition modularization of the ISO/IEC 11179 series. It extracts the Data Description package from ISO/IEC 11179-3:2013 to make it more accessible and renames it “Metamodel for data specification registration”. At the same time, some enhancements have been made as follows:
— support for externally defined “reference enumerated conceptual domains” (7.4.2.6) and “reference enumerated value domains” (7.4.2.13);
— support for sub-setting of value domains (7.7) and conceptual domains (7.8) within a specified context;
— support for composite data elements and data types (7.9);
— finer-grained conformance options (see 5.3);
— relaxation of some constraints in the standard, while giving registration authorities the ability to enforce them if they wish (see 6.5).
In the 2023 version, we can define the UML semantic model and hierarchical logical data model with the following terms without using ISO 15000-5 CCS.
3 Terms and definitions
3.1 Terms related to metamodel constructs
3.1.1
class
<metamodel> description of a set ofobjects(3.2.1) that share the sameattributes(3.1.11), operations, methods, relati`onships (3.1.4) and semantics
Note 1 to entry: Adapted from ISO/IEC 19505-2:2012, 7.3.7[27].
3.1.2
abstract class
<metamodel>class(3.1.1) that does not provide a complete declaration and typically cannot be instantiated
Note 1 to entry: An abstract class is intended to be used by other classes as a general class forspecialization(3.1.8).
Note 2 to entry: Cf. concrete class (3.1.3).
Note 3 to entry: Adapted from ISO/IEC 19505-1:2012, 9.19.1[26] Classifier.isAbstract
3.1.3
concrete class
<metamodel>class(3.1.1) that can be instantiated
Note 1 to entry: Cf.abstract class(3.1.2).
3.1.4
relationship
<metamodel> connection among model elements
Note 1 to entry: In this document, a relationship is one of: anassociation(3.1.5), ageneralization(3.1.7) or aspecialization(3.1.8).
3.1.5
association
<metamodel> semanticrelationship(3.1.4) between twoclasses(3.1.1) or between two or more instances of the same class
Note 1 to entry: An association is a type of relationship.
Note 2 to entry: Adapted from ISO/IEC 19505-2:2012, 7.3.3[27] Association.
3.1.7
generalization
<metamodel>relationship(3.1.4) between a more general class (the parent) and a more specific class (the child) that is fully consistent with the general class and that adds additional information
Note 1 to entry: A generalization is a type ofrelationship(3.1.4).
Note 2 to entry: The more general class is referred to as thesuperclass(3.1.9).
Note 3 to entry: The more specific class is referred to as asubclass(3.1.10).
Note 4 to entry: A generalization is directed from the subclass to the superclass.
Note 5 to entry: ‘Fully consistent’ means that the subclass has all of theattributes(3.1.11) andrelationships(3.1.4) of the superclass.
Note 6 to entry: cf.specialization(3.1.8); generalization is the inverse of specialization.
Note 7 to entry: Adapted from ISO/IEC 19505-2:2012, 7.3.20[27].
3.1.8
specialization
<metamodel>relationship(3.1.4) between a more general class (the parent) and a more specific class (the child) that is fully consistent with the general class and that adds additional information
Note 1 to entry: A specialization is a type ofrelationship(3.1.4).
Note 2 to entry: The more general class is referred to as thesuperclass(3.1.9).
Note 3 to entry: The more specific class is referred to as asubclass(3.1.10).
Note 4 to entry: A specialization is directed from the superclass to the subclass.
Note 5 to entry: ‘Fully consistent’ means that the subclass has all of theattributes(3.1.11) andrelationships(3.1.4) of the superclass.
Note 6 to entry: cf.generalization(3.1.7); specialization is the inverse of generalization.
Note 7 to entry: Adapted from ISO/IEC 19505-2:2012, 7.3.20[27].
3.1.9
superclass
<metamodel>class(3.1.1) that is ageneralization(3.1.7) of one or more other classes
Note 1 to entry: The classes being generalized are known assubclasses(3.1.10).
Note 2 to entry: In UML, subclasses of a superclass are by default notdisjoint(3.2.39). This document specifies when subclasses are required to be disjoint. Further, when the superclass is not intended to be instantiated alone, this document shows the superclass as abstract, thus preventing the superclass being instantiated other than through one or more of its subclasses. Anabstract class(3.1.2) is indicated by showing the class name in italics in any class diagram that uses it.
Note 3 to entry: A particular class can be a superclass with respect to one relationship, but a subclass with respect to another relationship.
3.1.10
subclass
<metamodel> class (3.1.1) that is a specialization (3.1.8) of another class
Note 1 to entry: The class being specialized is known as the superclass (3.1.9).
Note 2 to entry: In UML, subclasses of a superclass are by default not disjoint (3.2.39). This document specifies when subclasses are required to be disjoint. Further, when the superclass is not intended to be instantiated alone, this document shows the superclass as abstract, thus preventing the superclass being instantiated other than through one or more of its subclasses. An abstract class (3.1.2) is indicated by showing the class name in italics in any class diagram that uses it.
Note 3 to entry: A particular class can be a subclass with respect to one relationship, but a superclass with respect to another relationship.
3.1.11
attribute
<metamodel>characteristic(3.2.4) of anobject(3.2.1) or set of objects
3.1.12
composite attribute
<metamodel>attribute(3.1.11) whosedatatype(3.1.13) is non-atomic
EXAMPLE See Administered_Item.registration_state (9.4.2.4), where registration_state is a composite attribute with Registration_State (9.4.4) as its composite datatype (3.1.15).
3.1.13
datatype
set of distinct values, characterized by properties of those values and by operations on those values3.2 Terms related to concepts
3.2.1
object
anything perceivable or conceivable
Note 1 to entry: Objects can be material (e.g. ‘engine’, ‘sheet of paper’, ‘diamond’), immaterial (e.g. ‘conversion ratio’, ‘project plan’) or imagined (e.g. ‘unicorn’, ‘scientific hypothesis’).3.2.2
object class
set of ideas, abstractions or things in the real world that are identified with explicit boundaries and meaning and whose properties and behaviour follow the same rules3.2.3
property
quality common to all members of an` object class` (3.2.2)3.2.4
characteristic
abstraction of aproperty(3.2.3)
EXAMPLE ‘Having a cable for connecting with a computer’ as a characteristic of the concept ‘cord mouse’.
Note 1 to entry: Characteristics are used for describingconcepts(3.2.7).3.2.7
concept
unit of knowledge created by a unique combination ofcharacteristics(3.2.4)
Note 1 to entry: Concepts are not necessarily bound to particular natural languages. They are, however, influenced by the social or cultural background which often leads to different categorizations.
Note 2 to entry: A concept is independent of its representation.3.2.8
concept relation
relation betweenconcepts(3.2.7)3.2.37
cardinality
number of elements in a set
Note 1 to entry: cf.multiplicity(3.2.38).
Note 2 to entry: Adapted from ISO/IEC 19501:2005[25], Glossary.
3.2.38
multiplicity
specification of the range of allowablecardinalities(3.2.37) that a set can assume
Note 1 to entry: Multiplicity specifications can be given for roles withinassociations(3.1.5) orattributes(3.1.11) within aclass(3.1.1).
Note 2 to entry: A multiplicity is a (possibly infinite) subset of the non-negative integers.
Note 3 to entry: Adapted from ISO/IEC 19501:2005, Glossary.
5. ISO 11179 and cardinality of attributes
Sometimes it is better not to define cardinality at the semantic modeling level defined by UML.
Object classes are based on ISO 11179 and this standard does not support attribute cardinality.
The next dialog explains this issue.
Can iso 11179 define multiplicity for attribute?
ISO/IEC 11179 is a standard that provides guidelines for managing metadata registries, specifically focusing on the registration and administration of data elements. While ISO/IEC 11179 does not explicitly define multiplicity for attributes, it provides guidelines for defining and registering data elements, which can include attributes.
ISO/IEC 11179 defines various concepts and components related to data elements, such as data element concepts, data element names, and data element descriptions. It provides a framework for standardizing the representation and management of data elements in a metadata registry.
Multiplicity, in the context of attribute cardinality or the number of values that can be associated with an attribute, is not explicitly addressed in ISO/IEC 11179. The standard focuses more on the structure and administration of metadata, including naming conventions, identification, and classification of data elements.
However, ISO/IEC 11179 can still be used as a reference for managing metadata and providing guidelines for describing attributes within a metadata registry. Organizations can adopt ISO/IEC 11179 principles and adapt them to suit their specific needs, including the representation of attribute multiplicity within their metadata management practices.
It’s worth noting that ISO/IEC 11179 is not exclusively dedicated to attribute multiplicity, but rather provides broader guidelines for metadata management and data element registration.
