Object-oriented modeling (OOM) is a practical and useful programming language that aids in modular design and programming reuse. It is based on the following characteristics:
- Designers define new types of objects.
- Operations are defined for objects.
- The operations thus designed are generic in form.
- Class definitions share common components using inheritance. (Snyder, 1986)
OOM has different notation standards like OMT, Fusion Methods, Unified Modeling Language (UML), Object-Role Modeling (ORM), etc. Here we compare UML and ORM notation standards of object modeling.
UML is a widely popular modeling system and has been initiated by the Object Management Group as a standard for object-oriented (OO) modeling. UML facilitates an object-oriented approach which helps in the transition to an object-oriented code. This is a difficult process in order to capture and validate data concepts and business rules in the domain experts and to help in changes in the structure of the application. OOM helps in solving these problems as it follows a fact-oriented approach. In this approach, communication takes place in simple sentences, and each type of sentence can be occupied with multiple instances and attributes, which are avoided in the base model.
Object-Role Modeling (ORM) is a fact-oriented approach that complements UML. This is so because both the models offer direct support for roles, n-ary associations, and objectified associations. ORM is a simple representation of the world simply in terms of objects which play roles.
In order to compare two modeling methods, it requires both a language and a procedure to guide the user of the model in using the language to construct models. It should be kept in mind that a language has syntaxes (marks), semantics (meaning), and pragmatics (use). Graphical or textual syntaxes are used for programming languages. These basic concepts of programming languages are used in distinguishing concepts like “abstract syntax” and “concrete syntax.” Theoretically, a conceptual model pays no attention to logical and physical level aspects such as the structure of the database to be used for the implementation and also ignores external aspects such as the kind of screen forms to be used for data entry.
The degree of expressability of a language is measured by the level to which it can be used to express or say. In an ideal condition, a conceptual language should be able to model all the details of the application domain, which has conceptual relevance totally. This is known as the hundred percent Principles. ORM can be described as a method by which modeling and querying an information system is done at the conceptual level and is used to map the link between the conceptual and logical levels. ORM focuses on data modeling, as the data perspective is more stable. It also provides a foundation for defining operations. Contrarily, UML is more expressive than ORM because it uses case, behavior, and implementation diagrams to model aspects beyond static structures. ORM diagrams are graphically more expressive than UML class diagrams. Further, ORM can be used in combination with diagrams from ULM since ORM diagrams may be abstracted to attribute views or transformed into UML class diagrams.
Abstraction mechanisms are very important with large models. They help in removing unnecessary details from immediate consideration of the user. ORM diagrams are usually more detailed and take up more space in the system in comparison to corresponding UML models. This aspect of the model, i.e., in ORM, provides little scope for abstraction mechanisms.
Numerous forms of mechanisms such as “modularization, refinement levels, feature toggles, layering, and object zoom” are used to conceal and demonstrate that portion of the model which is being used by the user or is an immediate requirement. ORM and ULM can both adopt these with minor variations. ORM also consists of a procedure for attribute abstraction which automatically generates a UML diagram as a display. ORM has a richer graphic than ULM. Even though the graphics of ORM is richer, the notation provided demonstrates a complete diagrammatic treatment of scheme alterations. The textual concepts used can partially counterbalance this advantage. With respect to their data modeling constructs, both UML and ORM have sufficient formal underpinning. Since the ORM and UML languages are roughly comparable with regard to abstraction mechanisms and formal foundations, the nest level of evaluation is on the criteria of expressability, clarity, stability, relevance, and validation.
In UML, oids assist in identifying data, but ORM requires having a reference scheme for human communication (e.g., referring to employees with their social security number). The classes in UML must have a name. They must also have attributes, operations, which are implemented as methods, and role-plays. The object types of ORM must have a name and role-plays. From the operations perspective, it should be noted that some of these might be handled in ORM as derived relationship types. A relationship instance in ORM is called a link in UML (e.g., Employee 101 works for Company ‘Visio’). A relationship type in ORM is called an association in UML (e.g., Employee works for Company). Object types in ORM are depicted as named ellipses, and the simple reference schemes are abbreviated in the parenthesis. The classes in UML are portrayed as rectangular names to which the attributes of the operations may be added.