NOTE
The following list of terms relates primarily to the artifacts you are likely to encounter in a UML class diagram. The UML has many other forms of diagrams that may be beneficial if you are seriously getting into OO modeling (for example, sequence diagrams, use case diagrams, and activity diagrams). For those interested in pursuing OO concepts further, a highly recommended (and delightfully short) book is "UML Distilled" by Martin Fowler97
Table 31. Object-oriented glossary of terms
| Name of OO concept or term | Description of OO concept or term (as seen by data modelers!) |
|---|
| Class | Traditional data modelers speak in terms of entities and their attributes, and relationships between those entities.
There are strong parallels in the OO world. OO modelers talk in terms of classes (instead of entities) and their attributes, and associations (instead of relationships) between those classes.
The most significant difference, however, is that classes include code for accessing and manipulating the data. The code that defines how to access or change the data is known as the "method", and the signature for calling it is known as its "operation". |
| Object | Traditional relational database practitioners think in terms of sets of data. For example, a relational table may have many rows, but data access and manipulation is based on sets of rows (though the "set" may, in some cases, have only one row).
In contrast, in the OO world, we are more oriented towards individual objects – hence the name "object-oriented". As a very roughly approximation, if an entity (and possibly its implementation as a relational table) is something like a class (but without its operations/methods), then one row in a table is something like an object. But I did say it was just an approximation. |
| Attribute | Just as relational entities have attributes, so do classes. Some significant differences include:
The ability of OO classes to have much richer, user-defined data types.
The ability to define multiplicity greater than one; i.e., something like having a repeating group that, in relational terms, would breach first normal form. |
| Method | When you work out the "method" you'll use to access or manipulate a bit of data, and attach this code to a class, it's called a method! |
| Operation | The "signature" for a method includes items such as its name and parameters. If you like, it's the template shape for how you get things done, and the underlying method is the actual code that does the work. Often, in a UML class diagram, you will see the class name in the top box, the attributes in the next box, and the operations in the third box of a class. So you can see what methods can be called via their operation signatures, but you can't see the actual method's code. |
| Polymorphism | A horrible word and one I hope you don't need to use. But if pushed, in simple terms, it means that if you have two classes with the same method against them but different code, the system is smart enough to not get the methods confused. For example, if you have a "DisplayMe" method against an Employee class, and also a "DisplayMe" method against a Project class, and you ask an Employee object to display itself, it will behave as you would hope (and not display itself as if it's a Project). |
| Encapsulation | The idea behind encapsulation, or "information hiding", is that the attributes of a class are not directly visible from outside the class. You only get to interact with their values via operations/methods. For example, an Employee class might have a "Get Age" method, but you can't tell from the outside whether age is calculated on the fly or stored as data. |
| Object ID | For those with a relational background, you may choose to see an object's identifier as a surrogate key. However, in contrast to many relational implementations where the surrogate is unique within one table, in the OO world the Object ID is unique across the whole domain. |
| Data Type | Attributes in a relational database have a data type. It might be a Date, an Integer, a Boolean, and so on. Some relational database systems offer little more than a handful of pre-packaged data types.
In the OO world, you have a similar concept, but the primitive data types (such as Date, Integer, Boolean, etc.) can be supplemented by rich user-defined data types. For what it's worth, the data types are defined as classes, just as the business things like Employee or Project are also classes. This means that your new data types can have their own operations/methods to provide functionality, and also can be made up of attributes with data types. |
| Association | An association between a pair of classes approximates a relationship between a pair of entities in the data modeler's world. And just like a relationship records optionality and cardinality, an association records multiplicity. For example, a relationship that is "optional / many" would translate to an association that has a multiplicity of "0‥*" (where the zero indicates a minimum of zero, and the "*" represents a maximum of "many").
Additionally, the UML notation has special symbols for containment, where an open diamond represents aggregation (the "child" has a life of its own) and composition (if a "parent" is deleted, the child ceases to exist, just like in a relational cascade delete).
Further, in the OO world you can specify a many-to-many association without the need for a resolution entity /class, and not only model it that way but actually implement it directly, e.g., in an object-oriented database management system such as Gemstone or Versant. |
| Multiplicity | Multiplicity records the minimum and maximum numbers, and can be used in all sort of places. The two of primary interest here are multiplicities in associations (somewhat aligned to the idea of optionality and cardinality on relationships between entities) and multiplicities against attributes (e.g. an attribute of Given Name in a Person class might have a multiplicity of "1‥3" to indicate a minimum of one given name and a maximum of three). |
| Property | A collective term for the attributes and associations of a class. |
| Inheritance | Entities in a data modeler's entity-relationship diagram can have supertypes for generalized entities and subtypes for specialized entities. An OO class model can similarly have superclasses and subclasses. The link between a superclass and a subclass is known as inheritance; i.e., the subclass is said to "inherit" the attributes (and operations) of its superclass.
And then there's multiple inheritance, where a subclass has two (or more) superclasses. But this concept introduces complexity and danger, and is not even supported by some OO platforms. |
| Persistence | This simply means that the data for an object is stored somewhere for later retrieval and reuse. The ability to store data is motherhood and apple pie for relational database people, so it takes a bit of getting used to that you might have objects and their data that are used for a short time, but never stored.
As a side comment, often the data in an object is mapped to a relational database for storage, but there are object databases that exist and that handle persistence of objects in a much more natural manner. They just typically don't have the market presence of the mainstream relational database management systems. |
