30.152
Domain Modeling with UML Class Diagrams

Introduction

Conceptual domain modeling (or conceptual data modeling) is a process used in database design, systems design, and software engineering to create a high-level representation of the information that will be managed by a system. This type of modeling focuses on identifying the key concepts and their relationships within a specific domain of interest, rather than detailing the technical implementation. It serves as a foundation for further development and design activities, including the creation of more detailed models and the actual database and system implementation. Here are the main aspects of conceptual domain modeling:

1. Identifying Key Concepts: The first step is to identify the main entities or concepts within the domain. These could be physical objects, events, or ideas relevant to the domain of interest.

2. Defining Relationships: After identifying the key concepts, the next step is to define the relationships between them. This includes understanding how entities interact with each other, their dependencies, and their hierarchies.

3. Capturing Attributes: While the primary focus is on concepts and their relationships, conceptual modeling also involves capturing the essential attributes of each concept. These attributes represent the properties or characteristics of the entities.

4. Abstraction: Conceptual domain modeling abstracts away the technical details and focuses on the domain itself. It aims to create a model that is understandable by stakeholders who may not have a technical background, such as business analysts, domain experts, and end-users.

5. Purpose and Use: The model serves as a communication tool among stakeholders and as a guide for system designers and developers. It helps ensure that the system development aligns with the business requirements and domain needs.

6. Techniques and Notations: Various modeling techniques and notations can be used for conceptual domain modeling, including Entity-Relationship Diagrams (ERD), Unified Modeling Language (UML), and domain-specific languages designed for particular domains or industries.

Conceptual domain modeling is essential in the early stages of system development as it helps clarify requirements, reduce complexity, and prevent misunderstandings later in the development process. It ensures that the system’s design and implementation will meet the users’ needs and align with the business objectives.

Conceptual vs Logical Data Modeling

Conceptual modeling and logical data modeling are both key steps in the process of database design and system development, but they operate at different levels of abstraction and serve distinct purposes. Understanding the differences between these two modeling phases is essential for effectively capturing requirements and designing a system that meets its intended goals. Below a breakdown of how conceptual modeling differs from logical data modeling:

Conceptual Modeling:

• Level of Abstraction: Conceptual modeling is at a higher level of abstraction. It focuses on the broad and fundamental structure of the domain without getting into the specifics of how the model will be implemented in a database system.
• Purpose: The primary goal is to capture and represent the main entities, concepts, and relationships within the domain of interest. It’s about understanding what the system needs to represent, rather than how it will be technically achieved.
• Audience: It is intended for a wide range of stakeholders, including domain experts, business analysts, and end-users, to ensure that the model accurately reflects the real-world context it aims to represent.
• Detail Level: Conceptual models are less detailed and do not specify attributes or primary keys. They focus on the high-level relationships and entities.
• Notation: Commonly uses Entity-Relationship Diagrams (ERD) without much detail, Unified Modeling Language (UML) class diagrams, or other high-level diagrams to illustrate the concepts and relationships.

Logical Data Modeling:

• Level of Abstraction: Logical data modeling is one step lower in the abstraction level than conceptual modeling. It starts to consider how the conceptual model will be implemented, without being tied to a specific database technology.
• Purpose: The goal is to translate the conceptual model into a more detailed model that specifies tables, columns, data types, and constraints. It defines the structure of the data as it will be stored in the database.
• Audience: It is mainly intended for database designers and developers who are responsible for implementing the model in a database management system.
• Detail Level: Logical models are more detailed than conceptual models. They specify entity attributes, primary keys, foreign keys, and the normalization of tables to eliminate redundancy.
• Notation: Uses detailed ERDs that include specific attributes and data types, or other database modeling notations, to prepare for the physical implementation.

In essence, conceptual modeling is about understanding and documenting the domain from a high-level perspective, while logical data modeling takes that understanding and begins the process of designing how it will be technically realized in a database, focusing on table structures and integrity constraints. These steps are complementary and sequentially linked in the system development lifecycle, ensuring that the transition from domain-specific concepts to a technical implementation is smooth and aligned with the initial requirements.

Role of UML

The Unified Modeling Language (UML) is a standardized modeling language used in the field of software engineering and systems design to specify, visualize, construct, and document the artifacts of software systems, as well as non-software systems. UML was developed to unify the diverse modeling notations that were used in the early days of object-oriented design and to provide a consistent and comprehensive modeling approach applicable across different types of systems and domains. It is now widely adopted for modeling software applications and is supported by many tools that facilitate the design and development process.

Overview of UML

• Purpose: UML aims to provide a standard way to visualize the design of a system, facilitating a common understanding among stakeholders, such as business analysts, developers, and testers.

• Use Cases: It is used across the software development lifecycle, from requirements gathering and analysis, through design, to implementation. UML can model application structures, behaviors, and architectures, among other aspects.

• Diagrams: UML includes a set of graphic notation techniques to create visual models of software systems. These diagrams are categorized into two main types: structure diagrams and behavior diagrams.

Structure Diagrams

These diagrams emphasize what components make up a system and how they are related. Key structure diagrams include:

1. Class Diagram: Shows how classes (the building blocks of an application) relate to each other and the static structure of the system.
2. Component Diagram: Describes how a software system is split up into components and shows the dependencies among these components.
3. Composite Structure Diagram: Highlights the internal structure of a class and the collaborations that this structure makes possible.
4. Deployment Diagram: Focuses on the physical deployment of artifacts (e.g., software) on nodes (e.g., hardware).
5. Object Diagram: Represents instances of classes and their relationships at a specific point in time.
6. Package Diagram: Shows how the system is divided into packages and the dependencies among them.

Behavior Diagrams

These diagrams represent the dynamic aspects of a system, showing how the system behaves and interacts. Key behavior diagrams include:

1. Use Case Diagram: Illustrates the functionality provided by the system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.
2. Sequence Diagram: Shows how objects interact in a particular scenario of a use case, in a sequential order.
3. Activity Diagram: Represents the flow of control or data flow within a system, highlighting the sequence and conditions for coordinating lower-level behaviors.
4. State Machine Diagram: Describes the states an object or an interaction may be in, as well as the transitions between these states.
5. Communication Diagram: Focuses on the interaction between objects, emphasizing the structural organization of objects that send and receive messages.
6. Interaction Overview Diagram: Offers an overview of the flow of control where nodes are interactions or interaction uses.

Standardization and Usage

UML has been standardized by the Object Management Group (OMG), an international technology standards consortium. The standard undergoes periodic revisions to incorporate new methodologies and improvements.

UML’s versatility allows it to be applied in various domains, not just software engineering. It can be used for business process modeling, systems engineering, and more. Despite its comprehensive nature, the complexity of UML means that projects may only use a subset of its diagrams and features, tailored to their specific needs.

This lesson focuses on one of the diagrams in the UML: Class Diagrams. They are used for modeling structure, specifically data, so they are ideal for visually expressing a conceptual domain data model.

UML Class Diagrams

The Class Diagram is one of the most widely used diagrams in the modeling of domains, ontologies, and object-oriented systems. It serves as a cornerstone for both the system’s structure and its behavior, providing a static view of an application or a domain’s information objects. A UML Class Diagram describes the types of objects (classes/entities/concepts) in a domain and the various kinds of static relationships that exist among them. Here’s an overview of its key components and how they are used:

Classes

A class is depicted as a rectangle divided into three parts: the top part contains the class’s name, the middle part contains the class’s attributes, and the bottom part lists the methods or operations the class can perform. Classes represent the main objects and concepts in a domain. For ontology modeling, methods are often omitted and the third compartment is often used for the class’ glossary entry or description.

Attributes

Attributes, shown in the second section of a class, represent the properties, characteristics, or data that objects of the class hold. They are typically variables or types associated with the class.

Operations

Operations, detailed in the third section, are the functions or methods the class can execute. These include the behaviors that objects of the class can perform. For ontology modeling, methods are often omitted and the third compartment is often used for the class’ glossary entry or description.

Relationships

Class diagrams include several types of relationships to show how classes interact with one another:

• Association: This represents a general ‘uses-a’ relationship between two or more classes, indicating that instances of one class connect to instances of another. The association can be unidirectional or bidirectional, depicted with a line connecting the classes.

• Aggregation: A special type of association that represents a ‘has-a’ relationship but with a whole/part distinction, suggesting that one class is a part of another but can exist independently.

• Composition: A stronger form of aggregation implying a strong lifecycle dependency between the whole and its parts. When the whole is destroyed, its parts are also destroyed.

• Inheritance (Generalization): This depicts an ‘is-a’ relationship, indicating that one class (the subclass) is a specialized form of another class (the superclass). It is shown with a line and an empty arrowhead pointing from the subclass to the superclass.

• Dependency: A relationship where one class depends on another because it uses it at some point in time. It’s a weaker relationship than association, represented by a dashed line.

• Realization: A relationship where an interface class is implemented by another class. The interface class defines a set of operations that the implementing class must perform.

Multiplicity

Multiplicity notations are used to indicate the number of instances of one class that can be associated with one instance of another class. For example, “1..*” indicates that one instance of the first class can be associated with many instances of the second class.

Visibility

Visibility symbols (such as + for public, - for private, and # for protected) can precede attribute and operation names to indicate their accessibility.

Use Cases

Class diagrams are fundamental in object-oriented design and development, used for:

• Visualizing the ontology of a business domain.
• Visualizing the object-oriented structure of a system.
• Planning the system before coding begins.
• Documenting class and object interactions in a system.

By providing a high-level view of a system or of a domain, class diagrams help developers and data architects understand the overall structure, making it easier to build and maintain the system or to manage an ontology. They are essential tools in the software and data development lifecycle, particularly during the design phase, where they guide the creation of the system’s data architecture or a domain’s ontology.

Defining Model Scope

A conceptual model is a model of all necessary classes and attributes plus relationships that are needed to address the needs defined in the “use cases”. So, a data architect or system designers needs to first define the use cases, i.e., how the model will support users and data needs. We commonly use the “user story” format for this, for example:

1. As an instructor, I want to post an assignment.
2. As an instructor, I want to see when the student submitted the assignment.
3. As a student, I want to submit a solution to an assignment.

So, from that you can identify the necessary classes, attributes, and relationships:

• Instructor
• Assignment
• Submission (with date)
• Solution
• Student

Without the use cases, there is no scope boundary and it is not obvious to tell when modeling should stop.

Lectures

UML Class Diagrams are an alternative visual notation to ER Diagrams. They are commonly used for conceptual data modeling and ontology design. The Class Diagram is one of the 12 diagrams of the Unified Modeling Language. It is a diagram used to show the classes (or entities) in a system or domain. The two lectures below provide an overview of the purpose of conceptual modeling and how to construct a conceptual model in a UML Class Diagram.

Summary

In this lesson, we covered several topics related to visual modeling of object-oriented systems and domain ontologies:

1. Conceptual Domain Modeling: We discussed what conceptual domain modeling is, highlighting its focus on identifying key concepts and relationships within a specific domain of interest. This process aims to create a high-level representation of information to be managed by a system or database, emphasizing the importance of abstraction and serving as a foundation for further system and data architecture development activities.

2. Differences Between Conceptual and Logical Data Modeling: We explored the differences between conceptual modeling and logical data modeling. Conceptual modeling operates at a higher level of abstraction, focusing on the broad structure of the domain and its entities and relationships without delving into technical implementation details. In contrast, logical data modeling provides a more detailed blueprint that specifies tables, columns, data types, and constraints, preparing for the physical database design.

3. Unified Modeling Language (UML): An overview of UML was provided, outlining its purpose as a standardized modeling language to specify, visualize, construct, and document the artifacts of both software and non-software systems. We discussed the two main types of UML diagrams—structure diagrams and behavior diagrams—and their roles in visualizing different aspects of a system.

4. UML Class Diagram Overview: Finally, we delved into the specifics of the UML Class Diagram, one of the most fundamental diagrams in UML for object-oriented design, conceptual data modeling, and ontology visualization. We covered its key components, including classes, attributes, operations, and various types of relationships (association, aggregation, composition, inheritance, dependency, realization), as well as multiplicity and visibility.

---

Files & Resources

All Files for Lesson 30.152

---

References

None.

Errata

Let us know.