Jump to content

Unified Modeling Language (UML)



  • Ontologically Committed

  • Categorical



  • Parent-arity Type Instance

  • Transitivity

  • Boundedness Type Instance - Downward

  • Boundedness Type Instance - Number of Fixed Levels

  • Stratification Type Instance

  • Formal Generation - Whole Part - Fusion

  • Formal Generation - Whole Part - Complement

  • Formal Generation - Type Instance - Fusion

  • Formal Generation - Super Sub Type - Fusion

  • Formal Generation - Super Sub Type - Complement

  • Relation Class-ness Type Instance

  • Relation Class-ness Super Sub Type



  • No data to show


  • Merelogy

  • Time

  • Indexicals: Here And Now


F.35 UML 

F.35.1 Overview 

The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system. 

The creation of UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design. It was developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software in 1994 – 1995, with further development led by them through 1996. 

In 1997, UML was adopted as a standard by the Object Management Group (OMG), and has been managed by this organization ever since. In 2005, UML was also published by the International Organization for Standardization (ISO) as an approved ISO standard. Since then the standard has been periodically revised to cover the latest revision of UML. 

From https://en.wikipedia.org/wiki/Unified_Modeling_Language

See also: http://uml.org/, https://www.iso.org/standard/32620.html (ISO Standard NB v1.4.2)

F.35.2 Top-level 



From OMG® Unified Modeling Language® (OMG UML®) – Version 2.5.1 (Normative URL: https://www.omg.org/spec/UML/

F.35.3 Key characteristics 

A generic data model with a focus on describing computer systems. Supports multiple inheritance and classification, though as these are typically not feasible in programming languages, these are not usually used. Typically, first order, though limited functionality through generalisation sets (powertypes) to move up to higher orders (see extract below). 

F.35.4 Relevant Extracts 

From OMG® Unified Modeling Language® (OMG UML®) – Version 2.5.1 (Normative URL: https://www.omg.org/spec/UML/

Extract 1 

6.3 On the Semantics of UML 

6.3.1 Models and What They Model 

A model is always a model of something. The thing being modeled can generically be considered a system within some domain of discourse. The model then makes some statements of interest about that system, abstracting from all the details of the system that could possibly be described, from a certain point of view and for a certain purpose. For an existing system, the model may represent an analysis of the properties and behavior of the system. For a planned system, the model may represent a specification of how the system is to be constructed and behave. 

A UML model consists of three major categories of model elements, each of which may be used to make statements about different kinds of individual things within the system being modeled (termed simply “individuals” in the following). These categories are: 

  • Classifiers. A classifier describes a set of objects. An object is an individual with a state and relationships to other objects. The state of an object identifies the values for that object of properties of the classifier of the object. (In some cases, a classifier itself may also be considered an individual; for example, see the discussion of static structural features in sub clause 9.4.3.) 
  • Events. An event describes a set of possible occurrences. An occurrence is something that happens that has some consequence with regard to the system. 
  • Behaviors. A behavior describes a set of possible executions. An execution is a performance of a set of actions (potentially over some period of time) that may generate and respond to occurrences of events, including accessing and changing the state of objects. (As described in sub clause 13.2, behaviors are themselves modeled in UML as kinds of classifiers, so that executions are essentially modeled as objects. However, for the purposes of the present discussion, it is clearer to consider behaviors and executions to be in a separate semantic category than classifiers and objects.) 

Extract 2 

9.7 Generalization Sets 

9.7.1 Summary 

GeneralizationSet provides a way to group Generalizations into orthogonal dimensions. A GeneralizationSet may be associated with a Classifier called its powertype. These techniques provide additional expressive power for organizing classification hierarchies. 


9.7.3 Semantics 

Generalizations may be grouped to represent orthogonal dimensions of generalization. Each group is represented by a GeneralizationSet. The generalizationSet property designates the GeneralizationSets to which the Generalization belongs. All of the Generalizations in a particular GeneralizationSet shall have the same general Classifier. 

The isCovering property of GeneralizationSet specifies whether the specific Classifiers of the Generalizations in that set are complete, in the following sense: if isCovering is true, then every instance of the general Classifier is an instance of (at least) one of the specific Classifiers. The isDisjoint property specifies whether the specific Classifiers of the Generalizations in that set may overlap, in the following sense: if isDisjoint is true, then no instance of any of the specific Classifiers may also be an instance of any other of the specific Classifiers. By default, both properties are false. 

A GeneralizationSet may optionally be associated with a Classifier called its powertype. This means that for every Generalization in the GeneralizationSet, the specializing Classifier is uniquely associated with an instance of the powertype, i.e., there is a 1-1 correspondence between instances of the powertype and specializations in the GeneralizationSet, so that the powertype instances and the corresponding Classifiers may be treated as semantically equivalent. How this semantic equivalence is implemented and how its integrity is maintained is not defined within the scope of UML. 

Return to top

Return to Appendix : Candidate source top-level ontologies – longlist

Return to Contents

Continue to Appendix G: Prior ontological commitment literature


User Feedback

Recommended Comments

There are no comments to display.

  • Create New...