Class Diagram Concepts - woven-planet/opensafety-mbse GitHub Wiki
We use the UML standard notation for a class. This is a rectangle with 1-3 compartments. The top compartment is the class name, next down is the attribute compartment and then the methods compartment. We always use the title and attributes compartments and show the methods compartment only when a class has one or more methods defined.
In many UML class diagrams a class is meant to imply an object oriented programming class at some degree of detail. We don't do that. Our Executable UML is programming language and implementation platform independent. Consequently, we stick to mathematical rather than programming semantics as much as possible. For us then, a class is nothing more than a set definition. So if we defined a class such as 'Lane', for example, we are saying that 'Lane' is a useful abstraction modeled as a set definition. When the model is executing we would see the corresponding set populated with zero or more unique instances at any given point in time. How they are actually implemented in code is immaterial (from the modeler's perspective).
Our functional definition of a class is: A set of things (abstract or real) such that any given thing shares the same properties, behavior and conforms to the same rules, policies and constraints.
In addition to a class name, we sometimes show an alias as an abbreviated name in all caps. This abbreviation is often useful when writing action language (text inside of states, class methods, domain and external entity operations). You will see these in curly braces.
Each attribute is a characteristic that must apply to all instances of a class at all times. If an attribute is seen to be not-applicable or not-defined for any given instance of a class, then the model must be refactored. This is consistent with the 'same properties' aspect of the functional definition of a class.
Each attribute has an associated type (data type). An attribute that is non-referential (does not refer to some attribute in another class) is labeled with its type in the class rectangle. A referential attribute will be tagged with {R<num>, ...}
. If you follow the referenced relationships you will eventually land on its type in the class where it is originally defined.
An identifier is a set of one or more attributes, belonging to the same class, with the following property: if you supply a value for each attribute and search the class's current instance population at a given point in time you will find exactly one or zero corresponding instances.
A class may have more than one identifier. On the class diagram identifiers start as {I}
counting up as {I2}
, {I3}
, etc. The same attribute may participate in more than one identifier.
A relationship represents a rule by which instances of one (or the same class) may connect with one an other to reflect a constant or dynamic real world correspondence in the modeled subject matter.
If you are familiar with UML notation, you will notice that we aren't using something a little different for relationships. Here is a Class Diagram Notation Key you can use.