Lesson 5

The use of object diagrams is fairly limited, mainly to show examples of data structures. During the analysis phase of a project, you might create a class diagram to describe the structure of a system and then create a set of object diagrams as test cases to verify the accuracy and completeness of the class diagram. Before you create a class diagram, you might create an object diagram to discover facts about specific model elements and their links, or to illustrate specific examples of the classifiers that are required.

An object diagram shows this relation between the instantiated classes and the defined class, and the relation between these objects in the system. They are be useful to explain smaller portions of your system, when your system class diagram is very complex, and also sometimes modeling recursive relationship in diagram. The best way to illustrate what an object diagram look like is to show the object diagram derived from the corresponding class diagram.
The following Order Management System shows their relationships. This small class diagram shows that a university Department can contain lots of other Departments and the object diagram below instantiates the class diagram, replacing it by a concrete example.

In this module, you learned the notation for the object diagram. The object diagram is used to analyze the objects in the problem domain to determine the class requirements. After the class diagram has been developed, the object diagram is used to test the class model. Expresses possible object combinations of a specific class diagram. It is typically used to exemplify a class diagram.
Object diagrams explain and illustrate complex class diagrams. They are pictures of objects and their relationships at a specific moment in time. Object diagrams are drawn with objects and links. Links are instances of associations and aggregations. Because an object diagram is a snapshot, multiplicity is not shown (the actual links at that moment in time are shown instead).

An information model in software engineering is a representation of concepts and the relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. Typically it specifies relations between kinds of things, but may also include relations with individual things. It can provide sharable, stable, and organized structure of information requirements or knowledge for the domain context.

It is very easy to put together a class diagram and assume that it is correct. One should not put off testing until you have coded your application. Test every time you add information to your model. Let the models do the work of finding discrepancies for you. The modeler should take notice of errors early, while they are cheap and less painful to fix.

The term information model in general is used for models of individual things, such as facilities, buildings, process plants, etc. In those cases the concept is specialised to

1. facility information model,
2. building information model,
3. plant information model.

Such an information model is an integration of a model of the facility with the data and documents about the facility. Within the field of software engineering and data modeling an information model is usually an abstract, formal representation of entity types that may include their properties, relationships and the operations that can be performed on them. The entity types in the model may be kinds of real-world objects, such as devices in a network or occurrences. The types themselves may be abstract such as for the entities used in a billing system. Typically, they are used to model a constrained domain that can be described by a closed set of entity types, properties, relationships and operations.
An information model provides formalism to the description of a problem domain without constraining how that description is mapped to an actual implementation in software. There may be many mappings of the information model. Such mappings are called data models, irrespective of whether they are object models entity relationship models or XML schemas.

The word model used in this section has a more specific meaning than the word normally does when discussing UML models. Model is a stereotype that you apply to a package to signify that it is a complete view of the system from a particular perspective. A package of stereotype <<model>> is an overall grouping of other packages and subsystems used to represent a particular view of a real-world physical system. You can build many model views of a physical system, each for a different stakeholder. For example, if you were to create models of a hotel reservation system, you might have a

1. business-model view for management,
2. a logical-analysis view and
3. a physical-design view for programmers and database analysts, and
4. an implementation view for (IT) people.

Your goal for modeling the business-model view would be to create a complete representation of the business from a manager's perspective. In addition, it would detail the people involved and the business process flows that occurred. However, the business-model view wouldn't detail the programming code that ran the applications. That information would be provided in the physical-design view for programmers and database analysts.
You could compare a <<model>> view with the various drawings used to architect a building. There are physical building blueprints, electrical design schematics, plumbing schematics, and so forth, each providing a complete model of the physical building, but a different view. Each view is created for a different stakeholder.

Objects are identified with a name, colon, and class name. The object name can be left off to indicate an anonymous object. The object icon consists of two compartments, one for the name and one for the attributes. Attributes are described with a name and the current value.

Operations are not defined on objects because every object of the same class would model identical operations, creating redundancy in the model. Objects are connected using links. Classes are connected using associations. Links are defined with a name and optional roles. Multiplicity and constraints are not relevant with a link.

This module introduced you to the following terms:

1. Link:A relationship between two objects
2. Object:A uniquely identifiable entity composed of information, behaviors, and relationships with other entities.

In the next module, we will explore the third diagram in the logical view, the activity diagram.

Click the Quiz link below to check your knowledge with a short, multiple-choice quiz addressing the lessons you have worked through in this module.
Object Diagram - Quiz