Hubbry Logo
Object diagramObject diagramMain
Open search
Object diagram
Community hub
Object diagram
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Object diagram
Object diagram
Object diagram
View on Wikipedia
from Wikipedia
Example of an object diagram.

In object-oriented programming, an object diagram[1] in the Unified Modeling Language (UML) is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time.

Overview

[edit]
UML diagram types
Structural UML diagrams
Behavioral UML diagrams

In the Unified Modeling Language (UML), an object diagram focuses on some particular set of objects and attributes, and the links between these instances. A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time. Early UML specifications described object diagrams as such:[2][3]

"An object diagram is a graph of instances, including objects and data values. A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The use of object diagrams is fairly limited, namely to show examples of data structure."

The latest UML 2.5.1 specification does not explicitly define object diagrams,[4] but provides a notation for "instances" of classifiers.[4]: 126 

Object diagrams and class diagrams are closely related[5] and use almost identical notation.[6] Both diagrams are meant to visualize static structure of a system. While class diagrams show classes, object diagrams display instances of classes (objects).[7] Object diagrams are more concrete than class diagrams. They are often used to provide examples or act as test cases for class diagrams. Only aspects of current interest in a model are typically shown on an object diagram.

Object diagram topics

[edit]

Instance specifications

[edit]

Each object and link on an object diagram is represented by an InstanceSpecification. This can show an object's classifier (e.g. an abstract or concrete class) and instance name, as well as attributes and other structural features using slots. Each slot corresponds to a single attribute or feature, and may include a value for that entity.

The name on an instance specification optionally shows an instance name, a ':' separator, and optionally one or more classifier names separated by commas. The contents of slots, if any, are included below the names, in a separate attribute compartment. A link is shown as a solid line, and represents an instance of an association.

Object diagram example

[edit]
Initially, when n=2, and f(n-2) = 0, and f(n-1) = 1, then f(n) = 0 + 1 = 1.

Consider one possible way of modeling production of the Fibonacci sequence.

In the first UML object diagram on the right, the instance in the leftmost instance specification is named v1, has IndependentVariable as its classifier, plays the NMinus2 role within the FibonacciSystem, and has a slot for the val attribute with a value of 0. The second object is named v2, is of class IndependentVariable, plays the NMinus1 role, and has val = 1. The DependentVariable object is named v3, and plays the N role. The topmost instance, an anonymous instance specification, has FibonacciFunction as its classifier, and may have an instance name, a role, and slots, but these are not shown here. The diagram also includes three named links, shown as lines. Links are instances of an association.

After the first iteration, when n = 3, and f(n-2) = 1, and f(n-1) = 1, then f(n) = 1 + 1 = 2.

In the second diagram, at a slightly later point in time, the IndependentVariable and DependentVariable objects are the same, but the slots for the val attribute have different values. The role names are not shown here.

After several more iterations, when n = 7, and f(n-2) = 5, and f(n-1) = 8, then f(n) = 5 + 8 = 13.

In the last object diagram, a still later snapshot, the same three objects are involved. Their slots have different values. The instance and role names are not shown here.

Usage

[edit]

If you are using a UML modeling tool, you will typically draw object diagrams using some other diagram type, such as on a class diagram. An object instance may be called an instance specification or just an instance. A link between instances is generally referred to as a link. Other UML entities, such as an aggregation or composition symbol (a diamond) may also appear on an object diagram.

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Object diagram

View on Grokipedia
from Grokipedia
An object diagram is a structural diagram in the (UML) that provides a snapshot of a system's detailed state at a particular moment in time, illustrating specific instances of classes—referred to as objects—and the relationships, or links, between them. As a specialized form of , object diagrams focus on runtime instances rather than the general structure of classes and associations, enabling modelers to visualize how abstract class definitions manifest in concrete examples. They are particularly valuable during the analysis phase of for testing the accuracy of s, verifying constraints such as multiplicities (e.g., one-to-many relationships), and exploring potential system behaviors before full implementation. Key elements in an object diagram include objects, represented as rectangles with an underlined name followed by a colon and the class name (e.g., customer1:Customer), which may also display specific attribute values to reflect the instance's state; links, depicted as solid lines connecting objects to show active associations; and occasionally slots for attribute values. Unlike class diagrams, which define static types, operations, and attributes generically, object diagrams omit compartments for methods and emphasize instance-specific details without altering the underlying architecture. Object diagrams complement other UML structural diagrams, such as class, component, and deployment diagrams, by instantiating their elements to demonstrate real-world applicability, and they can serve as test cases to validate model consistency across the system. They are commonly used in domains like , system design, and object-oriented modeling to bridge the gap between abstract specifications and executable instances.

Fundamentals

Definition

An object diagram is a type of static structure diagram in the (UML) that shows a snapshot of the instances of classifiers—such as objects and data values—and their relationships at a specific point in time. It represents a concrete realization of the system's state, depicting object instances with their specific attribute values and the links that interconnect them. The purpose of an object diagram is to illustrate particular examples of the abstractions specified in class diagrams, thereby aiding in the validation of design models by demonstrating feasible runtime configurations and clarifying how classes manifest in practice. These diagrams emphasize the detailed state of a system without prescribing evolution or interactions over time. Key characteristics of object diagrams include their focus on instances rather than abstract classes, the explicit inclusion of attribute values via slots, and the portrayal of link states that reflect current associations between objects. Unlike dynamic behavior diagrams such as sequence diagrams, object diagrams remain static, capturing only a momentary view of the system's structure.

Historical Development

The origins of object diagrams trace back to the early object-oriented analysis and design methods that preceded the standardization of UML. Grady Booch's method, detailed in his 1991 book Object-Oriented Analysis and Design with Applications, included object diagrams as one of six diagram types to model instances of classes, their attributes, and interactions, emphasizing the representation of system snapshots for design validation. Similarly, James Rumbaugh's (OMT), introduced in the 1991 book Object-Oriented Modeling and Design, incorporated object diagrams within its object model to illustrate static instances and relationships, building on class diagrams to depict runtime configurations in data-intensive systems. These approaches, along with influences from earlier object visualization techniques in environments like Smalltalk—where object inspectors provided graphical views of instance states—laid the groundwork for formalizing instance-level modeling. Object diagrams were formally introduced as a standard element of UML in version 1.1, adopted by the (OMG) in November 1997, as part of the static modeling suite alongside to provide concrete snapshots of system instances. The UML 1.1 specification defined them as graphs of instances, including objects and data values, to illustrate examples and test validity, drawing directly from Booch's object diagrams and OMT's instance representations. This integration aimed to unify disparate notations, with the OMG's adoption marking a shift toward a standardized for object-oriented systems. Subsequent minor revisions, such as UML 1.3 in 2000, refined the notation by specifying object rectangles with underlined names and attribute slots, while embedding them within behavioral elements like collaborations. The evolution continued with UML 2.0, finalized by OMG in 2005, which enhanced object diagrams by aligning them more closely with the metamodel's InstanceSpecification concept, allowing for precise depiction of slots (attribute values) and links as instances of associations for better interoperability and tool support. Further refinements appeared in UML 2.5 (2015) and 2.5.1 (2017), where notation updates improved clarity for structured classifiers—such as nested rectangles for internal parts—and integrated diagram interchange standards to facilitate exchange between modeling tools, emphasizing their role in visualizing complex instance relationships without altering core semantics. These changes prioritized precision in representing dynamic snapshots while maintaining with earlier versions.

Components and Notation

Objects and Attributes

In object diagrams, individual objects are represented as rectangles divided into compartments, with the top compartment containing the object's name underlined to denote its status as an instance rather than a class . The name typically follows the format objectName : ClassName, where objectName is the specific identifier of the instance and ClassName indicates the classifier or type from which it is instantiated; for example, person:Person illustrates an object named "person" of the class. This notation emphasizes the snapshot of a system's state at a particular moment, capturing concrete instances rather than abstract classes. Anonymous objects, which lack a , are depicted simply as :ClassName, such as :Order, allowing representation of unnamed instances within the . The attribute compartment, located below the name compartment, displays the object's current state through slots formatted as attributeName = value, providing name-value pairs that reflect the values of the object's at the diagram's reference time. For instance, in an object employee:Employee, attributes might include name = "Alice", age = 30, and salary = 75000, each on a separate line to list the relevant structural features. Multiplicity can be indicated for attributes representing collections, such as phones = {"123-456", "789-012"} with an appropriate indicator like {ordered} if the order matters, though this is often contextual. Derived or computed attributes, which are calculated rather than directly stored, are prefixed with a slash, as in /totalSalary = 75000, signaling that the value is derived from other attributes or operations. Constraints on object attributes are enclosed in curly braces {} and placed adjacent to the relevant slot or compartment to specify additional conditions or invariants, such as {age >= 18} for an age attribute, ensuring the diagram adheres to defined rules. Multi-objects, representing collections of similar instances, are shown with a multiplicity indicator like * prefixed to the name, for example *{item:Product}, or sometimes as a dashed enclosing multiple solid object to denote a group like an or . These elements collectively provide a precise visualization of object internals, focusing on static values without implying dynamic behavior. In object diagrams, links represent instances of associations between objects and are depicted as solid lines connecting the relevant object symbols. These lines illustrate the runtime connections among object instances, providing a snapshot of how associations from class diagrams are realized at a specific moment. For binary associations, the solid line connects two objects directly, while for n-ary associations, a () may be used at the association end to denote the point. Object diagrams support several types of relationships beyond basic association links. Association links, the most common, show direct connections between objects as instances of binary or n-ary associations. Dependency links are represented by dashed arrows pointing from the client object to the supplier object, indicating that one object's behavior relies on another. Realization links appear as dashed lines with a closed triangular arrowhead at the realized end or annotated with the «realize» keyword, denoting that one element implements the specification of another. Role names, such as "employer" at one end and "employee" at the other, are labeled near the link ends to specify the roles played by the connected objects in the relationship. Multiplicity indicators on links specify the number of participating instances, using notations like "1" for exactly one, "0..1" for zero or one, or "1..*" for one or more, placed in square brackets near the relevant end. Qualifiers, which refine associations by selecting specific instances based on attribute values (e.g., an account number), are shown as small rectangles attached to the link ends containing the qualifier attribute. is indicated by s: a filled shows unidirectional traversal from source to target, while no arrow or an open arrow denotes bidirectional ; a (x) at an end marks non-. Links may also include attributes or constraints to provide additional details about the connection. Link attributes, if present, are listed in a compartment along the link similar to object attributes. Constraints, such as {ordered} to indicate a sequenced collection or {xor} for exclusive options, are enclosed in braces near the link or in attached notes, enforcing conditions on the relationship. These notations ensure that object diagrams precisely capture the structural interactions in a system.

Construction and Examples

Steps to Create

Creating an object diagram begins with selecting the foundational elements from an existing , which serves as the static model for the system's structure. The first step involves identifying the relevant classes that participate in a specific or runtime state, then instantiating specific objects as examples of those classes. This selection focuses on classes whose interactions or states are pertinent to the diagram's purpose, such as illustrating a particular system configuration or testing model validity. Once classes are identified, the next step is to assign concrete values to the attributes of each object instance, capturing a snapshot of the system at a particular moment. These values should reflect a realistic , such as the current state during program execution, and adhere to the attribute types and constraints defined in the . For instance, if a class has an attribute for balance in a banking system, a specific object might be assigned a numerical value like 1500.50 to represent its runtime data. This step emphasizes the dynamic aspect of objects, differentiating them from the abstract specifications in class diagrams. With instances defined, proceed to visually represent the objects by drawing rectangular notations, each containing the object's name (underlined) and optionally its class type separated by a colon, followed by attribute slots populated with the assigned values. Then, add links between objects to depict active associations, using solid lines that mirror the associations from the but instantiated for the scenario. These links may include role names to show how the objects relate at runtime, such as a connection between a object and an order object. Basic components like objects and links form the core of this representation. The final step requires applying specialized notations for any constraints, such as using guillemets («constraint») or notes attached to elements, and ensuring multiplicities and roles align with the class diagram's definitions. Validate the diagram by checking that all object states and relationships satisfy the class invariants, such as ensuring no attribute violates type restrictions or that association cardinalities are respected. This verification confirms the object diagram as a valid instantiation of the static model. Object diagrams can be constructed manually through sketching on paper or whiteboards for initial ideation, but for precision and collaboration, specialized software tools are recommended. Tools like Enterprise Architect from Sparx Systems or provide UML-compliant templates, automated validation features, and export options to streamline the process and enforce notation standards.

Basic Example

A basic example of an object diagram can be found in a university enrollment system, where classes such as and Course are instantiated to show specific relationships at a given moment. Consider an instance where a student named Bob with ID 123 is enrolled in a course coded M101. This scenario illustrates the "enrolls" association between a student and a course. In the diagram, objects are depicted as rectangles divided into compartments: the top compartment contains the object name underlined (e.g., student1), followed by a colon and the class name (e.g., student1:Student); the middle compartment lists attribute slots with their values (e.g., name = "Bob", id = 123 for the student object, and title = "Math", code = M101 for the course object named course1:Course). A solid line connects the two objects to represent the link, labeled with the association role "enrolls". This snapshot reveals the runtime state: Bob (student1) is actively enrolled in the Math course (course1), providing a concrete example of between instances rather than abstract classes. It demonstrates how object diagrams capture dynamic configurations, such as current enrollments, to test or illustrate implementations without simulating full behavior. Common pitfalls in creating such diagrams include overlooking link directions, which can imply incorrect (e.g., assuming bidirectional when the association is unidirectional from student to course), and providing incomplete attribute values, such as omitting the ID or , which obscures the snapshot's precision and fails to fully represent the object's state.

Applications and Comparisons

Role in UML Modeling

Object diagrams play a central role in the UML modeling process by providing concrete instantiations of abstract class structures, thereby facilitating the transition from to practical . They are integral to phases such as validation, where they serve to test the viability of class diagrams through specific examples of object instances and their links, helping developers confirm that the proposed structure can support real-world scenarios. In testing, object diagrams model expected system states to validate behavior against requirements, while in , they offer visual snapshots that clarify complex relationships for stakeholders and teams. A key benefit of object diagrams lies in their ability to bridge the gap between abstract class models and concrete implementations, allowing teams to instantiate classes with actual attribute values and associations to reveal inconsistencies or omissions early in the development cycle. This early detection of design flaws enhances overall model quality and reduces costly revisions later. Additionally, in contexts like , object diagrams illustrate problem domain examples to refine user needs into tangible object interactions; during , they map existing codebases to visual representations of runtime instances; and for , they capture system snapshots to diagnose issues in object states and relationships. Despite these advantages, object diagrams have inherent limitations due to their static nature, capturing only a single moment in the system's lifecycle rather than dynamic behaviors or sequences over time. They are thus ill-suited for modeling interactions, state changes, or processes, requiring complementary UML diagrams like sequence or state machines for comprehensive behavioral analysis.

Differences from Class Diagrams

Class diagrams in UML provide an abstract, timeless blueprint of a system's static structure, depicting classes as templates with their attributes defined by types, operations, and potential associations between them. These diagrams focus on the general design and possible configurations, serving as a foundational model for object-oriented systems without reference to specific runtime states. In contrast, object diagrams capture a concrete, time-specific snapshot of the system, illustrating particular instances of classes—known as objects—with their actual attribute values and realized links representing current relationships. A primary distinction lies in their level of and scope: class diagrams emphasize generality and potentiality, modeling types and structural relationships that apply across multiple instances, whereas object diagrams prioritize specificity and actuality, showing how those types manifest in a particular scenario. Notably, object diagrams omit representations of operations, which are a feature of classes in s, as they concentrate on structural snapshots rather than behavioral elements. Object diagrams also serve to test the feasibility of a by demonstrating viable instantiations and interactions, thereby validating the abstract model's practicality in real-world contexts. In practice, class diagrams are employed during the initial design phase to establish the system's and reusable components, while object diagrams are utilized for exemplification—such as illustrating examples in —or validation, confirming that the class-based design can support concrete implementations without contradictions. This complementary usage highlights their distinct yet interconnected roles within UML modeling, where class diagrams provide the "what" of the system's structure and object diagrams the "how" in specific cases.
AspectClass DiagramsObject Diagrams
Abstraction LevelAbstract (types and potentials)Concrete (instances and actuals)
Time DependencyTimeless blueprintSpecific snapshot
Key ElementsClasses, attribute types, operations, associationsObjects, attribute values, links
Primary Focus and general Validation and
Add your contribution
Related Hubs
User Avatar
No comments yet.