# Chapter 4: Domain Modeling

> **Course Code**: IS332 — Analysis and Design of Information Systems  
> **Faculty**: Faculty of Computers and Artificial Intelligence, Cairo University (FCAI-CU)  
> **Department**: Information Systems Department  
> **Instructor**: Dr. Sherif Zahran  
> **Primary Reference**: *Systems Analysis and Design in a Changing World* (7th Edition), Satzinger, Jackson, & Burd — Chapter 4  

---

## Table of Contents
- [4.0 Chapter Overview & Learning Objectives](#40-chapter-overview--learning-objectives)
- [4.1 Things in the Problem Domain](#41-things-in-the-problem-domain)
  - [4.1.1 What are "Things"?](#411-what-are-things)
  - [4.1.2 The Role of Domain Modeling in Systems Analysis](#412-the-role-of-domain-modeling-in-systems-analysis)
- [4.2 Techniques for Identifying Domain Classes](#42-techniques-for-identifying-domain-classes)
  - [4.2.1 Technique 1: The Brainstorming Technique](#421-technique-1-the-brainstorming-technique)
  - [4.2.2 Technique 2: The Noun Technique](#422-technique-2-the-noun-technique)
  - [4.2.3 Master Noun Classification Table (RMO Case Study)](#423-master-noun-classification-table-rmo-case-study)
- [4.3 Domain Classes, Attributes, and Values](#43-domain-classes-attributes-and-values)
  - [4.3.1 Domain Classes versus Instances](#431-domain-classes-versus-instances)
  - [4.3.2 Attributes and Values](#432-attributes-and-values)
  - [4.3.3 Identifiers (Keys), Compound Attributes, and Derived Attributes](#433-identifiers-keys-compound-attributes-and-derived-attributes)
- [4.4 Associations Among Things](#44-associations-among-things)
  - [4.4.1 UML Associations versus ERD Relationships](#441-uml-associations-versus-erd-relationships)
  - [4.4.2 Multiplicity (Cardinality) & Minimum/Maximum Constraints](#442-multiplicity-cardinality--minimummaximum-constraints)
  - [4.4.3 Types of Associations (Binary, Unary/Recursive, Ternary, N-ary)](#443-types-of-associations-binary-unaryrecursive-ternary-n-ary)
- [4.5 The UML Domain Model Class Diagram](#45-the-uml-domain-model-class-diagram)
  - [4.5.1 UML Domain Class Notation](#451-uml-domain-class-notation)
  - [4.5.2 Simple Domain Model Class Diagram](#452-simple-domain-model-class-diagram)
  - [4.5.3 University Course Enrollment Domain Model](#453-university-course-enrollment-domain-model)
- [4.6 Association Classes](#46-association-classes)
  - [4.6.1 Why and When are Association Classes Needed?](#461-why-and-when-are-association-classes-needed)
  - [4.6.2 Key Rules and Concatenated Identifiers](#462-key-rules-and-concatenated-identifiers)
  - [4.6.3 Case 1: Course Enrollment with Grades](#463-case-1-course-enrollment-with-grades)
  - [4.6.4 Case 2: Musical Band Booking Contract](#464-case-2-musical-band-booking-contract)
- [4.7 Generalization / Specialization Hierarchies (Inheritance)](#47-generalization--specialization-hierarchies-inheritance)
  - [4.7.1 Concepts of Superclasses and Subclasses](#471-concepts-of-superclasses-and-subclasses)
  - [4.7.2 Inheritance of Attributes and Associations](#472-inheritance-of-attributes-and-associations)
  - [4.7.3 Abstract Classes versus Concrete Classes](#473-abstract-classes-versus-concrete-classes)
  - [4.7.4 Case 1: Motor Vehicles Hierarchy](#474-case-1-motor-vehicles-hierarchy)
  - [4.7.5 Case 2: RMO CSMS Sales Hierarchy](#475-case-2-rmo-csms-sales-hierarchy)
- [4.8 Whole-Part Relationships (Aggregation and Composition)](#48-whole-part-relationships-aggregation-and-composition)
  - [4.8.1 The Whole-Part Paradigm](#481-the-whole-part-paradigm)
  - [4.8.2 Aggregation (Shared Whole-Part — Hollow Diamond)](#482-aggregation-shared-whole-part--hollow-diamond)
  - [4.8.3 Composition (Composite Whole-Part — Filled Diamond)](#483-composition-composite-whole-part--filled-diamond)
  - [4.8.4 Comprehensive Relationship Comparison Matrix](#484-comprehensive-relationship-comparison-matrix)
- [4.9 Complete RMO CSMS Domain Model Class Diagram](#49-complete-rmo-csms-domain-model-class-diagram)
- [4.10 Object Behavior: UML State Machine Diagrams](#410-object-behavior-uml-state-machine-diagrams)
  - [4.10.1 What is a State Machine Diagram?](#4101-what-is-a-state-machine-diagram)
  - [4.10.2 States, Transitions, and Transition Syntax](#4102-states-transitions-and-transition-syntax)
  - [4.10.3 Concurrency in State Machines: Synchronization Bars](#4103-concurrency-in-state-machines-synchronization-bars)
  - [4.10.4 Printer with Concurrent Processing Paths](#4104-printer-with-concurrent-processing-paths)
  - [4.10.5 Step-by-Step Methodology to Construct State Machine Diagrams](#4105-step-by-step-methodology-to-construct-state-machine-diagrams)
  - [4.10.6 Case 1: SaleItem State Machine Diagram](#4106-case-1-saleitem-state-machine-diagram)
  - [4.10.7 Case 2: InventoryItem State Machine Diagram](#4107-case-2-inventoryitem-state-machine-diagram)
- [4.11 Chapter Summary & Key Terminology Glossary](#411-chapter-summary--key-terminology-glossary)

---

## 4.0 Chapter Overview & Learning Objectives

While Chapter 3 addressed the functional processes and activities that the system performs (Use Cases), Chapter 4 investigates the **data and structural entities** that the system must remember, track, and manipulate: **Things in the Problem Domain**.

Domain modeling establishes the conceptual foundation for relational database design, software class structures, and business rules. Additionally, this chapter introduces **UML State Machine Diagrams** to model the dynamic lifecycle behavior of complex domain entities as they transition through operational states.

### Learning Objectives
After studying this chapter, students should be able to:
1. **Identify "Things" in the Problem Domain**: Apply the **Brainstorming Technique** and the **Noun Technique** to discover business entities.
2. **Classify Problem Domain Nouns**: Distinguish candidate domain classes from attributes, external users, and transient outputs.
3. **Model Domain Classes and Attributes**: Specify domain class notation, identifiers (keys), compound attributes, and multiplicity constraints.
4. **Distinguish and Apply UML Association Types**: Model binary, unary (recursive), and ternary associations, enforcing minimum and maximum multiplicity constraints.
5. **Construct Association Classes**: Recognize many-to-many (`*..*`) associations that possess attributes and apply concatenated primary key rules.
6. **Apply Generalization/Specialization (Inheritance)**: Model superclass-subclass hierarchies, inheritance of attributes and associations, and abstract classes.
7. **Differentiate Aggregation and Composition**: Distinguish between shared whole-part (aggregation) and tightly coupled existential whole-part (composition) relationships.
8. **Develop UML State Machine Diagrams**: Model object lifecycles, states, transition syntax (`Trigger [Guard] / Action`), and concurrent execution using synchronization bars.

---

## 4.1 Things in the Problem Domain

### 4.1.1 What are "Things"?
In systems analysis, **"Things"** are the physical objects, conceptual items, roles, transactions, and records in the real-world business environment that the information system must capture, store, process, and track.

- Things in the problem domain are not technical software artifacts (they are not tables, buttons, or arrays).
- They represent real-world entities that exist regardless of whether a computerized system is present (e.g., *Customers*, *Products*, *Orders*, *Invoices*, *Bank Accounts*).

---

### 4.1.2 The Role of Domain Modeling in Systems Analysis
Domain modeling serves as the structural anchor of the entire development lifecycle:
1. **Data Foundation**: Directly translates into relational database tables and foreign key relationships in systems design (Core Process 4).
2. **Object-Oriented Architecture**: Provides the foundational domain layer software classes in object-oriented programming (Core Process 5).
3. **Business Rule Enforcement**: Captures fundamental organizational policies (e.g., *"An order must be placed by exactly one customer"*).

```mermaid
flowchart LR
    RealWorld["Real-World Problem Domain
(Business Objects & Rules)"] --> DomainModel["UML Domain Model Class Diagram
(Conceptual Classes & Associations)"]
    DomainModel --> DBDesign["Relational Database Schema
(Tables, Keys, Normalization)"]
    DomainModel --> OODesign["Design Class Diagram (DCD)
(Domain Layer Software Classes)"]
```

---

## 4.2 Techniques for Identifying Domain Classes

Analysts use two primary, complementary techniques to discover domain classes:

```mermaid
flowchart TD
    Discovery["Techniques for Identifying Domain Classes"] --> Brainstorm["1. The Brainstorming Technique
Works with stakeholders to examine 6 universal categories of business things"]
    Discovery --> Nouns["2. The Noun Technique
Examines written requirements, user stories, and transcripts to classify every noun"]
```

---

### 4.2.1 Technique 1: The Brainstorming Technique

The **Brainstorming Technique** is a collaborative discovery method where analysts work directly with business users and domain experts to systematically examine **six universal categories of business things** (Figure 4-1):

| Category of Things | Description & Analytical Focus | Real-World RMO CSMS Examples |
|:---|:---|:---|
| **1. Tangible Things** | Physical objects that can be touched, inspected, manufactured, or moved. | Garments, Hiking Boots, Tents, Sleeping Bags, Warehouse Shipping Boxes. |
| **2. Roles Played** | Specific capacities or personas assumed by humans who interact with the business. | Customer, Purchasing Agent, Sales Representative, Shipping Clerk, Supplier Contact. |
| **3. Organizational Units** | Internal departments, divisions, physical branch offices, or third-party partner corporations. | Merchandising Department, Customer Support Division, Regional Warehouse, Store #12, Courier Company (FedEx). |
| **4. Devices** | Hardware peripherals, sensors, automated machinery, or handheld tools that interface with the system. | Point-of-Sale (POS) Register, Barcode Scanner, Tablet Device, Label Printer, CNC Milling Machine. |
| **5. Sites / Locations** | Physical geographic places, delivery addresses, headquarters, or warehouse storage bin coordinates. | Park City Headquarters, Salt Lake Distribution Center, Aisle 4 / Shelf B, Customer Shipping Address. |
| **6. Incidents / Events / Interactions** | Recorded business transactions, historical occurrences, customer service calls, or dispute settlements. | Order, Return, Shipment, Payment, Customer Service Call, Promotional Discount, Flight Booking. |

---

### 4.2.2 Technique 2: The Noun Technique

The **Noun Technique** is a rigorous, text-driven analytical method where analysts inspect all written requirements documents, user stories, use case descriptions, forms, and interview transcripts to identify and classify every single **noun**.

#### The Three-Way Noun Classification Standard
For every noun identified in the text, the analyst places it into one of three distinct categories:
1. **Include as a Domain Class**:
   - The noun represents a fundamental, independent business entity about which the system must store multiple attributes and remember over an extended period.
2. **Exclude Entirely**:
   - The noun represents an external user, an organizational department whose identity is already known, a computer system, or a transient output report that can be derived on the fly from stored data.
3. **Attribute of an Existing Domain Class**:
   - The noun represents a single property, measurement, or descriptor of another class rather than an independent entity (e.g., `Color`, `Price`, `ZipCode`).

```mermaid
flowchart TD
    IdentifyNoun["Identify Candidate Noun in Requirements Text"] --> ClassifyNoun{"What does this noun represent?"}

    ClassifyNoun -- "Fundamental business entity with multiple properties" --> IncludeClass["INCLUDE AS DOMAIN CLASS
(e.g., Customer, Product, Order)"]
    ClassifyNoun -- "A descriptor or measurement of another thing" --> MakeAttribute["TREAT AS ATTRIBUTE
(e.g., Color, UnitPrice, DateOfBirth)"]
    ClassifyNoun -- "External user, known entity, or derived report" --> ExcludeNoun["EXCLUDE ENTIRELY
(e.g., Accounting Dept, Printer, Monthly Report)"]
```

---

### 4.2.3 Master Noun Classification Table (RMO Case Study)

The following table documents the comprehensive noun analysis performed for RMO's CSMS (Figure 4-2 / Slides 20 & 21):

| Candidate Noun | Analytical Evaluation & Rationale | Final Classification Decision |
|:---|:---|:---|
| **Accounting** | Internal organizational department. We know who they are; no attributes need to be stored in the database. | **Exclude** |
| **Back order** | Could be a special subtype of order or a status value of an order line item. Requires further domain research. | **Research (Model as Status or Class)** |
| **Back-order information** | A printed or onscreen output that is dynamically calculated from unfulfilled orders. Not stored permanently. | **Exclude (Output)** |
| **Bank** | External financial clearinghouse. Only one bank partner used; no need to store bank entity records. | **Exclude** |
| **Catalog** | Seasonal merchandising collection. Must recall catalogs across past years and seasons (Winter, Spring). | **Include as Domain Class** |
| **Catalog activity reports** | Summarized management reports generated on demand. Derived from transaction logs. | **Exclude (Output)** |
| **Catalog details** | Refers to product items featured inside a catalog. Merged into `ProductItem` and `Catalog` association. | **Exclude / Merge** |
| **Change request** | A user input transaction that results in updating an existing order. Stored as an audit transaction. | **Include / Attribute** |
| **Charge adjustment** | An accounting adjustment transaction requiring managerial approval. | **Include as Domain Class** |
| **Color** | A specific property describing a clothing garment. Belongs to a product variant. | **Attribute (of ProductItem)** |
| **Confirmation** | An email or printed notice sent to a customer upon order completion. Derived output. | **Exclude (Output)** |
| **Credit card information** | Billing data. Could be an attribute of an Order or Customer. (PCI-DSS tokenization applies). | **Attribute (of Order/Customer)** |
| **Customer** | Central business entity. Requires storing dozens of attributes (names, addresses, billing profiles). | **Include as Domain Class** |
| **Customer account** | Financial tracking entity managing balances, credit holds, and loyalty Mountain Bucks. | **Include as Domain Class** |
| **Fulfillment reports** | Operational status reports produced dynamically from warehouse shipment records. | **Exclude (Output)** |
| **Inventory quantity** | Current physical stock count on hand in a warehouse. | **Attribute (of InventoryItem)** |
| **Management** | Organizational role. We know who they are; no operational attributes stored. | **Exclude** |
| **Marketing** | Internal corporate department. | **Exclude** |
| **Merchandising** | Internal corporate department. | **Exclude** |
| **Product** | General category or brand of apparel (e.g., "Men's Windbreaker"). | **Include as Domain Class** |
| **ProductItem** | Specific inventory stock-keeping unit (SKU) with exact size and color (e.g., "Men's Blue Large"). | **Include as Domain Class** |
| **Shipper** | Third-party commercial logistics carrier (FedEx, UPS). Must track account numbers, rates, and APIs. | **Include as Domain Class** |
| **Shipment** | The physical dispatch of a boxed parcel with courier tracking numbers and ship dates. | **Include as Domain Class** |

---

## 4.3 Domain Classes, Attributes, and Values

### 4.3.1 Domain Classes versus Instances
- **Domain Class**: A category, classification, or blueprint describing a collection of business objects that share identical attributes, associations, and operational rules.
- **Object Instance**: A specific, individual real-world realization of a domain class (e.g., Class: `Customer`; Instance: `John Doe, CustomerID = 10492`).

---

### 4.3.2 Attributes and Values
- **Attribute**: A named piece of specific information describing a domain class.
- **Value**: The concrete, actual data stored in a specific attribute for a particular object instance.

```
+--------------------------------------------------------------------------------+
|  CLASS: Customer                                                               |
+--------------------------------------------------------------------------------+
|  Attributes:                     Instance Values (for John Doe):               |
|    - customerId                    10492                                       |
|    - firstName                     John                                        |
|    - lastName                      Doe                                         |
|    - email                         jdoe@rockies.net                            |
|    - phone                         (555) 321-7788                              |
+--------------------------------------------------------------------------------+
```

---

### 4.3.3 Identifiers (Keys), Compound Attributes, and Derived Attributes

1. **Identifier (Key Attribute)**:
   - An attribute that uniquely distinguishes an individual object instance from all other instances in that class (e.g., `CustomerID`, `OrderNumber`, `SocialSecurityNumber`).
2. **Compound Attribute**:
   - An attribute that contains multiple sub-components that can be addressed together or independently (e.g., `CustomerName` composed of `FirstName` + `MiddleInitial` + `LastName`, or `Address` composed of `Street` + `City` + `State` + `Zip`).
3. **Derived Attribute**:
   - An attribute whose value is not stored directly in the database, but is computed on demand from other stored attributes (e.g., `Age` derived from `DateOfBirth`, or `LineItemSubtotal` derived from `Quantity * UnitPrice`). In UML notation, derived attributes are prefixed with a forward slash (`/`).

---

## 4.4 Associations Among Things

### 4.4.1 UML Associations versus ERD Relationships

In relational database design, connections between entities are called **Relationships** (modeled via Entity-Relationship Diagrams — ERDs). In object-oriented systems analysis, connections between classes are formally termed **Associations** (modeled via UML Class Diagrams).

#### The Two-Way Semantic Nature of Associations
Associations naturally apply in **both directions** and must be read and validated separately in each direction:
1. *Forward Direction*: A `Customer` **places** zero or more `Orders`.
2. *Reverse Direction*: An `Order` **is placed by** exactly one `Customer`.

```mermaid
flowchart LR
    Customer["Customer"] <-->|places / is placed by| Order["Order"]
```

---

### 4.4.2 Multiplicity (Cardinality) & Minimum/Maximum Constraints

**Multiplicity** is the UML term specifying how many instances of one class can be associated with an instance of another class. (The equivalent relational database term is **Cardinality**).

Every association endpoint defines two boundary constraints:
1. **Minimum Multiplicity**:
   - If minimum is **zero (`0`)**, the association is **optional**. (e.g., a newly registered customer does not have to place an order immediately: `0..*`).
   - If minimum is **at least one (`1`)**, the association is **mandatory**. (e.g., an order cannot exist without an associated customer: `1..1`).
2. **Maximum Multiplicity**:
   - Specifies the upper bound: either **one (`1`)** or **many (`*`)**.

#### UML Multiplicity Notation Reference Table (Figure 4-5)
| UML Multiplicity Symbol | Meaning | Minimum Constraint | Maximum Constraint |
|:---:|:---|:---:|:---:|
| `1` (or `1..1`) | Exactly one | 1 (Mandatory) | 1 |
| `0..1` | Zero or one | 0 (Optional) | 1 |
| `0..*` (or `*`) | Zero or more | 0 (Optional) | Many (Unbounded) |
| `1..*` | One or more | 1 (Mandatory) | Many (Unbounded) |
| `n..m` (e.g., `2..4`) | Specific fixed range | $n$ | $m$ |

---

### 4.4.3 Types of Associations (Binary, Unary/Recursive, Ternary, N-ary)

Associations are classified based on the number of participating classes (Slide 28):

```mermaid
flowchart TD
    AssocTypes["Types of Associations"] --> Binary["1. Binary Association
Connects exactly TWO different classes
(e.g., Customer <--> Order)"]
    AssocTypes --> Unary["2. Unary (Recursive) Association
Connects instances of the SAME class to each other
(e.g., Person <--> Person, Employee <--> Supervisor)"]
    AssocTypes --> Ternary["3. Ternary & N-ary Association
Connects THREE or more classes simultaneously
(e.g., Doctor + Patient + Pharmacy)"]
```

#### Unary (Recursive) Association Examples
- **Organizational Hierarchy**: An `Employee` manages zero or more subordinate `Employees`; each subordinate reports to exactly one supervisor `Employee`.
- **Bill of Materials (BOM)**: A manufactured `Part` is assembled from zero or more sub-`Parts`; a sub-`Part` is utilized within zero or more master `Parts`.
- **Marriage Relationship**: A `Person` is married to zero or one other `Person`.

```mermaid
classDiagram
    direction TB
    class Employee {
        +int employeeId
        +string name
        +string title
    }
    Employee "1" --> "*" Employee : manages / reports to
```

---

## 4.5 The UML Domain Model Class Diagram

### 4.5.1 UML Domain Class Notation (Figure 4-11)
In systems analysis (conceptual domain modeling), classes are drawn as **two-compartment rectangles**:
1. **Top Compartment**: The **Class Name** (capitalized singular noun, e.g., `Customer`, `Product`).
2. **Bottom Compartment**: The list of **Attributes** describing the class.

> [!IMPORTANT]
> ### 💡 Notice: No Methods During Analysis!
> Unlike software Design Class Diagrams (DCDs) constructed during technical design (Chapter 12), **conceptual domain model class diagrams do NOT show methods or software functions**. In analysis, we model the real-world problem domain data, not programming implementation methods.

---

### 4.5.2 Simple Domain Model Class Diagram (Figure 4-12)

```mermaid
classDiagram
    direction LR

    class Customer {
        +int customerId
        +string name
        +string email
        +string phone
    }

    class Order {
        +int orderNumber
        +date orderDate
        +string orderStatus
        +decimal orderTotal
    }

    class OrderItem {
        +int quantity
        +decimal unitPrice
        +decimal subtotal
    }

    Customer "1" -- "0..*" Order : places
    Order "1" -- "1..*" OrderItem : contains
```

> **Multiplicity Analysis**:
> - A `Customer` places **zero or more (`0..*`)** `Orders`.
> - An `Order` is placed by **exactly one (`1`)** `Customer`.
> - An `Order` contains **one or more (`1..*`)** `OrderItems`.
> - An `OrderItem` belongs to **exactly one (`1`)** `Order`.

---

### 4.5.3 University Course Enrollment Domain Model (Figure 4-14)

```mermaid
classDiagram
    direction LR

    class Course {
        +string courseNumber
        +string title
        +int creditHours
    }

    class CourseSection {
        +string sectionNumber
        +string dayAndTime
        +string roomNumber
    }

    class Instructor {
        +int facultyId
        +string name
        +string department
    }

    class Student {
        +int studentId
        +string name
        +string major
    }

    Course "1" -- "1..*" CourseSection : offers
    CourseSection "*" -- "1" Instructor : taught by
    CourseSection "1..*" -- "1..*" Student : enrolls
```

---

## 4.6 Association Classes

### 4.6.1 Why and When are Association Classes Needed?

In many-to-many (`*..*`) associations, attributes frequently emerge that **do not belong to either of the participating classes individually**, but instead describe the **association itself**.

- **The Problem**: In the university model above, where should a student's final course `Grade` be stored?
  - It cannot be stored in `Student`, because a student earns many different grades across different courses.
  - It cannot be stored in `CourseSection`, because a course section has many students with different grades.
- **The Solution**: An **Association Class**!
  - **Definition**: An association class is an association that is treated as a full class because it has its own attributes that must be recorded.
  - **UML Notation**: A class symbol connected to the association line via a **dashed line**.

---

### 4.6.2 Key Rules and Concatenated Identifiers (Slide 36)

> [!IMPORTANT]
> ### 💡 Fundamental Architectural Rules of Association Classes
> 1. **Identity Equivalence**: The association class is the *exact same semantic thing* as the association itself.
> 2. **Concatenated Primary Key**: The unique identifier (key) for an association class is **strictly formed by the concatenation of the primary keys of the attached endpoint classes**.
>    - For example: if `CourseSection` key is `CourseNumber + SectionNumber`, and `Student` key is `StudentID`, then the unique key for `CourseEnrollment` is `CourseNumber + SectionNumber + StudentID`.
> 3. **Architectural Error Check**: If more data is required to uniquely distinguish instances of the association class beyond the concatenation of the endpoint keys, the model is **fundamentally incorrect** and must be remodeled as an independent domain entity!

---

### 4.6.3 Case 1: Course Enrollment with Grades (Figure 4-16)

```mermaid
classDiagram
    direction LR

    class Student {
        +int studentId
        +string studentName
        +string major
    }

    class CourseSection {
        +string courseNumber
        +string sectionNumber
        +string term
    }

    class CourseEnrollment {
        +string grade
        +int attendanceCount
        +date enrollmentDate
    }

    Student "1..*" -- "1..*" CourseSection : enrolls in
    (Student, CourseSection) .. CourseEnrollment
```

---

### 4.6.4 Case 2: Musical Band Booking Contract (Figures 4-17 & 4-18)

Consider an agency representing musical bands that book concerts:
- A `Band` performs at many `Concerts`.
- A `Concert` festival features many `Bands`.
- What are the terms of the agreement? The `ContractFee`, `PerformanceTime`, and `CommissionRate` belong to the **Booking** association class!

```mermaid
classDiagram
    direction LR

    class Band {
        +int bandId
        +string bandName
        +string musicGenre
    }

    class Concert {
        +int concertId
        +string venueName
        +date concertDate
        +string city
    }

    class Booking {
        +decimal contractFee
        +decimal commissionRate
        +time performanceStartTime
        +int stageNumber
    }

    Band "1..*" -- "0..*" Concert : performs at
    (Band, Concert) .. Booking
```

> **Concatenated Key**: The primary key for `Booking` is `BandID + ConcertID`. It uniquely identifies each booking contract without ambiguity.

---

## 4.7 Generalization / Specialization Hierarchies (Inheritance)

### 4.7.1 Concepts of Superclasses and Subclasses

Human beings naturally organize complex knowledge through hierarchical classification based on similarities and differences:
- **Generalization**: The cognitive process of grouping things together based on their shared common characteristics (e.g., grouping cars, trucks, and motorcycles under the general category of *Motor Vehicle*).
- **Specialization**: The process of identifying specialized differences within a broader category.
- **Superclass**: The general, high-level class that consolidates common attributes and associations.
- **Subclass**: The specialized, lower-level class that extends the superclass with unique properties.

---

### 4.7.2 Inheritance of Attributes and Associations

- **Inheritance**: The object-oriented mechanism by which a subclass automatically receives and possesses **all attributes and associations** defined in its superclass, while adding its own unique properties.
- **The "IS-A" Rule**: An inheritance relationship is valid only if the subclass **is truly a specialized kind of the superclass** (e.g., *"A Car IS-A Motor Vehicle"*, *"An OnlineSale IS-A Sale"*).

---

### 4.7.3 Abstract Classes versus Concrete Classes

- **Abstract Class**:
  - A superclass that exists solely to define common attributes and behavior for subclasses, but which **can never be directly instantiated** in the real world.
  - In UML notation, the name of an abstract class is rendered in *Italics* or tagged with the `{abstract}` property.
  - *Example*: You never see a generic "Motor Vehicle" driving down the road; you see a concrete Car or a concrete Motorcycle.
- **Concrete Class**:
  - A class that can be directly instantiated with actual object instances (e.g., `Car`, `OnlineSale`).

---

### 4.7.4 Case 1: Motor Vehicles Hierarchy (Figure 4-19)

```mermaid
classDiagram
    direction BT

    class MotorVehicle {
        <<Abstract>>
        +string vinNumber
        +string make
        +string model
        +int year
        +decimal basePrice
    }

    class Car {
        +int numberOfDoors
        +bool hasTrunk
    }

    class Truck {
        +decimal cargoCapacityTons
        +int numberOfAxles
    }

    class Motorcycle {
        +int engineDisplacementCC
        +bool hasSidecar
    }

    Car --|> MotorVehicle : specializes (IS-A)
    Truck --|> MotorVehicle : specializes (IS-A)
    Motorcycle --|> MotorVehicle : specializes (IS-A)
```

---

### 4.7.5 Case 2: RMO CSMS Sales Hierarchy (Figure 4-20)

In RMO's retail enterprise, sales occur through three radically different sales channels, yet they share fundamental accounting properties:

```mermaid
classDiagram
    direction BT

    class Sale {
        <<Abstract>>
        +int saleId
        +date saleDate
        +time saleTime
        +decimal subTotal
        +decimal salesTax
        +decimal totalAmount
    }

    class OnlineSale {
        +string ipAddress
        +string browserType
        +string emailConfirmation
    }

    class InStoreSale {
        +int registerNumber
        +int cashierClerkId
        +string receiptBarcode
    }

    class TelephoneSale {
        +int phoneClerkId
        +string callerPhoneNumber
        +int callDurationSeconds
    }

    OnlineSale --|> Sale : IS-A
    InStoreSale --|> Sale : IS-A
    TelephoneSale --|> Sale : IS-A
```

> **Inheritance Verification**:
> - An `OnlineSale` automatically inherits `saleDate`, `subTotal`, `salesTax`, and `totalAmount` from `Sale`, while adding its unique `ipAddress`.
> - If `Sale` associates with `Customer`, then `OnlineSale`, `InStoreSale`, and `TelephoneSale` **automatically inherit that association** without needing separate association lines.

---

## 4.8 Whole-Part Relationships (Aggregation and Composition)

### 4.8.1 The Whole-Part Paradigm
In addition to general associations and generalization hierarchies, UML models **Whole-Part Relationships**, where one class represents the complete composite entity (the Whole) and other classes represent its constituent pieces (the Parts).

UML defines two distinct varieties of whole-part relationships:

```mermaid
flowchart TD
    WP["Whole-Part Relationships"] --> Agg["1. Aggregation (Shared Whole-Part)
• Symbol: Hollow / White Diamond
• Nature: Weak coupling; parts can exist independently
• Example: Computer <--> Peripheral Devices"]
    WP --> Comp["2. Composition (Composite Whole-Part)
• Symbol: Filled / Black Diamond
• Nature: Strong coupling; parts cannot exist without whole
• Example: Order <--> OrderItem"]
```

---

### 4.8.2 Aggregation (Shared Whole-Part — Hollow Diamond) (Figure 4-22)

- **Definition**: A whole-part relationship where the components (parts) can exist independently of the composite aggregate (the whole).
- **Notation**: An open, hollow white diamond (`◇`) on the side of the **Whole**.
- **Real-World Example**: A `Computer` and its `Printer` / `Keyboard` / `Monitor`. If the computer is decommissioned, the printer still exists and can be reassigned to another computer.

```mermaid
classDiagram
    direction LR

    class Computer {
        +string serialNumber
        +string processorType
        +int ramGB
    }

    class DisplayMonitor {
        +string screenResolution
        +decimal screenDiagonalInches
    }

    class PeripheralPrinter {
        +string printerModel
        +string ipAddress
    }

    Computer o-- "0..*" DisplayMonitor : aggregates (hollow diamond)
    Computer o-- "0..*" PeripheralPrinter : aggregates (hollow diamond)
```

---

### 4.8.3 Composition (Composite Whole-Part — Filled Diamond)

- **Definition**: A strict whole-part relationship where the parts **cannot exist independently** of the whole. The lifetime of the part is entirely bounded by the lifetime of the whole. If the whole is deleted, all constituent parts are destroyed.
- **Notation**: A solid, filled black diamond (`◆`) on the side of the **Whole**.
- **Real-World Example**: An `Order` and its `OrderItem` lines. An order line item cannot exist floating freely in space; if the order is purged from the database, all of its order line items are deleted.

```mermaid
classDiagram
    direction LR

    class Order {
        +int orderId
        +date orderDate
    }

    class OrderItem {
        +int lineNumber
        +int quantity
        +decimal unitPrice
    }

    Order *-- "1..*" OrderItem : composed of (filled diamond)
```

---

### 4.8.4 Comprehensive Relationship Comparison Matrix (Slide 45)

| UML Relationship Type | Visual UML Notation Symbol | Semantic Meaning | Real-World Software Example |
|:---|:---|:---|:---|
| **Association** | Plain solid line `──` | Standard bidirectional connection between independent classes. | `Customer` places `Order` |
| **Association Class** | Class linked via dashed line `---` to association line | A many-to-many association that contains its own descriptive attributes. | `Student` enrolls in `CourseSection` with `Grade` |
| **Generalization (Inheritance)** | Solid line with hollow triangular arrowhead pointing to Superclass `──▷` | "IS-A" classification hierarchy; subclasses inherit all attributes and associations. | `Car` IS-A `MotorVehicle` |
| **Aggregation** | Solid line with hollow white diamond at Whole `◇──` | Shared whole-part relationship; parts can exist independently of the whole. | `Computer` has `Monitor` |
| **Composition** | Solid line with solid black diamond at Whole `◆──` | Strict existential whole-part; parts cannot exist without the whole. | `Order` has `OrderItem` |

---

## 4.9 Complete RMO CSMS Domain Model Class Diagram

The following comprehensive UML Domain Model Class Diagram synthesizes all sales, customer, inventory, and fulfillment entities across the enterprise (Figure 4-25):

```mermaid
classDiagram
    direction TB

    class Customer {
        +int accountNo
        +string name
        +string email
        +string phone
        +decimal mountainBucks
    }

    class Sale {
        <<Abstract>>
        +int saleId
        +date saleDate
        +time saleTime
        +decimal totalAmount
    }

    class OnlineSale {
        +string ipAddress
        +string browserType
    }

    class InStoreSale {
        +int registerNo
        +int cashierId
    }

    class TelephoneSale {
        +int phoneClerkId
    }

    class OrderItem {
        +int quantity
        +decimal price
    }

    class ProductItem {
        +string skuNumber
        +string color
        +string size
    }

    class Product {
        +int productId
        +string description
        +string category
    }

    class Shipment {
        +int trackingNumber
        +date shipDate
    }

    class Shipper {
        +int shipperId
        +string name
        +string contactPhone
    }

    Customer "1" -- "0..*" Sale : places
    OnlineSale --|> Sale
    InStoreSale --|> Sale
    TelephoneSale --|> Sale

    Sale "1" *-- "1..*" OrderItem : composed of
    OrderItem "*" -- "1" ProductItem : specifies
    ProductItem "*" -- "1" Product : categorizes

    Shipment "1" -- "1..*" OrderItem : fulfills
    Shipper "1" -- "0..*" Shipment : transports
```

---

## 4.10 Object Behavior: UML State Machine Diagrams

### 4.10.1 What is a State Machine Diagram?

In object-oriented analysis, static class diagrams model the data structure of classes. However, certain complex domain objects undergo dramatic changes in condition, behavior, and business rules throughout their operational lifespan.

- **State**: A condition during the life of an object where it satisfies some condition, performs some activity, or waits for an external event.
- **State Machine Diagram**: A standard UML behavioral diagram that models the lifecycle of a single object as it transitions through various states in response to events.
- **When is a State Machine Diagram Needed?**: Not every class requires a state machine diagram. They are created **only for complex classes with significant lifecycle states and state-dependent business rules** (e.g., `Order`, `InventoryItem`, `SaleItem`, `Shipment`).

---

### 4.10.2 States, Transitions, and Transition Syntax (Figure 4-27)

```mermaid
stateDiagram-v2
    [*] --> InitialState : Trigger
    InitialState --> NextState : Trigger [Guard Condition] / Action Expression
    NextState --> [*] : Conclude
```

#### Transition Syntax Breakdown
A transition arrow connects an originating state to a destination state. The formal UML transition label follows this strict syntax:

$$	ext{	extbf{EventName}} \;\; [	ext{	extbf{GuardCondition}}] \;\; / \;\; 	ext{	extbf{ActionExpression}}$$

1. **Event Name (Trigger)**: The specific external or internal event that initiates the transition (e.g., `itemScanned`, `paymentApproved`, `reorderTriggered`).
2. **Guard Condition (enclosed in `[brackets]`)**: A boolean logical predicate that must evaluate to **True** for the transition to fire. If the condition is False, the transition is blocked. (e.g., `[stockAvailable > 0]`).
3. **Action Expression (preceded by `/`)**: A procedural action, calculation, or message that executes automatically during the transition (e.g., `/decrementStock()`, `/printReceipt()`).

---

### 4.10.3 Concurrency in State Machines: Synchronization Bars (Slides 50 & 51)

- **Concurrent States**: When an object is in two or more independent states simultaneously.
- **Concurrent Paths**: Parallel sequences of states that execute concurrently.
- **Synchronization Bar Notation**: Heavy solid bars used to split and join paths:
  - **Multiple Exits from a State**: Represents an **"OR" condition** (mutually exclusive decision branching).
  - **Multiple Exits from a Synchronization Bar (Fork)**: Represents an **"AND" condition** (all concurrent paths fire simultaneously).
  - **Synchronization Bar (Join)**: Recombines concurrent paths; execution halts until **all incoming paths finish**.

---

### 4.10.4 Printer with Concurrent Processing Paths (Slide 51)

Consider an enterprise network printer: while it is actively printing a document, it must concurrently monitor the network port for incoming jobs and check paper sensor trays:

```mermaid
stateDiagram-v2
    [*] --> Operational : PowerOn

    state Operational {
        [*] --> ForkPoint
        
        state fork_state <<fork>>
        ForkPoint --> fork_state
        
        fork_state --> PrintingSubsystem
        fork_state --> NetworkSubsystem

        state PrintingSubsystem {
            [*] --> IdlePrinter
            IdlePrinter --> ActivePrinting : PrintJobReceived
            ActivePrinting --> IdlePrinter : PrintJobCompleted
        }

        state NetworkSubsystem {
            [*] --> ListeningOnPort
            ListeningOnPort --> BufferingJob : DataPacketArrived
            BufferingJob --> ListeningOnPort : BufferFlushed
        }

        state join_state <<join>>
        PrintingSubsystem --> join_state
        NetworkSubsystem --> join_state
        join_state --> PowerDown
    }

    Operational --> [*] : PowerOff
```

---

### 4.10.5 Step-by-Step Methodology to Construct State Machine Diagrams

To construct rigorous state machine diagrams for complex domain classes (Slides 58 & 59):
1. **Review Domain Class Diagram**: Identify candidate classes whose behavior changes dramatically across time (e.g., `SaleItem`, `InventoryItem`).
2. **Brainstorm All Valid States**: List all operational conditions that the object experiences from creation to destruction.
3. **Identify Exit Transitions and Triggers**: Determine what events cause the object to exit each state.
4. **Build State Fragments**: Draw individual pairs of states connected by labeled transition arrows.
5. **Sequence Fragments in Chronological Order**: Connect the fragments from the initial pseudo-state (`[*]`) to the final pseudo-state (`[*]`).
6. **Identify Parallel Concurrent Paths**: Check if the object tracks multiple independent facets at once.
7. **Refine with Guards and Actions**: Add `[Guard]` predicates and `/Action` expressions to transitions.
8. **Test and Validate**: Trace sample operational scenarios to ensure no deadlocks or missing exit pathways exist.

---

### 4.10.6 Case 1: SaleItem State Machine Diagram (Figures 4-28 to 4-30)

In RMO's CSMS, each `SaleItem` on a customer order progresses through an extensive lifecycle:

| State Name | Operational Definition & Condition | Exit Transition Trigger |
|:---|:---|:---|
| **Created** | Item has been added to a customer's active shopping cart session. | `checkoutCompleted` |
| **Purchased** | Payment has been authorized; item is queued for warehouse picking. | `itemPicked` |
| **Shipped** | Package containing item has been scanned by courier (FedEx). | `deliveryConfirmed` |
| **Delivered** | Package arrived at customer destination. | `returnRequested` or `retentionExpired` |
| **Returned** | Customer returned merchandise; awaiting restocking inspection. | `inspectionCompleted` |
| **Restocked** | Item returned to warehouse bin; credit issued to customer. | *Terminal state* |

```mermaid
stateDiagram-v2
    [*] --> Created : itemAddedToCart
    Created --> Purchased : checkoutCompleted [paymentAuthorized]
    Created --> [*] : cartAbandoned

    Purchased --> Shipped : itemBoxedAndScanned / generateCourierTracking()
    
    Shipped --> Delivered : courierDeliveryScan
    
    Delivered --> Returned : returnInitiated [within30Days]
    Delivered --> [*] : warrantyPeriodElapsed

    Returned --> Restocked : itemInspectedAndApproved / issueCustomerCredit()
    Returned --> Disposed : itemDamaged / writeOffInventory()

    Restocked --> [*]
    Disposed --> [*]
```

---

### 4.10.7 Case 2: InventoryItem State Machine Diagram (Figures 4-31 to 4-33)

An `InventoryItem` in RMO's warehouse tracks the physical stock availability of garments:

```mermaid
stateDiagram-v2
    [*] --> InStock : receiveShipmentFromManufacturer

    InStock --> Reserved : allocateToCustomerOrder [availableStock > 0]
    
    Reserved --> Shipped : packageScannedOnDock / decrementInventory()
    Reserved --> InStock : customerCancelsOrder / releaseReservation()

    InStock --> OutOfStock : stockCountReachesZero / triggerSupplierReorder()
    
    OutOfStock --> InStock : supplierReplenishmentArrives

    Shipped --> [*]
```

---

## 4.11 Chapter Summary & Key Terminology Glossary

### Chapter Summary
- **Domain Modeling** discovers and formally specifies the real-world **Things in the Problem Domain** that the system must remember and track.
- Analysts identify domain classes using the **Brainstorming Technique** (6 categories of things) and the **Noun Technique** (classifying nouns as classes, attributes, or exclusions).
- **Domain Classes** define attributes and values; they **do not include methods** during systems analysis.
- **Associations** represent bidirectional links between classes, governed by **minimum and maximum multiplicity** constraints (optional vs. mandatory).
- Associations are categorized as **Binary** (between two classes), **Unary / Recursive** (between instances of the same class), or **Ternary / N-ary**.
- **Association Classes** model many-to-many associations that possess their own attributes; their unique key is strictly formed by the **concatenation of the endpoint keys**.
- **Generalization / Specialization Hierarchies** model inheritance ("IS-A"), where subclasses inherit all attributes and associations from superclasses. Classes may be **Abstract** or **Concrete**.
- **Whole-Part Relationships** are modeled as **Aggregation** (shared whole-part, hollow diamond) or **Composition** (existential whole-part, solid black diamond).
- **UML State Machine Diagrams** model the dynamic lifecycle behavior of complex domain objects, utilizing states, transitions (`Trigger [Guard] / Action`), and concurrency synchronization bars.

---

### Key Terminology Glossary
- **Abstract Class**: A generalized superclass that defines common attributes and associations for subclasses, but cannot be directly instantiated.
- **Action Expression**: A procedural task or calculation executed during a state machine transition, preceded by a slash (`/`).
- **Aggregation**: A whole-part relationship where components can exist independently of the whole, denoted by a hollow white diamond (`◇`).
- **Association**: A structural UML connection between classes indicating that instances interact or share a business relationship.
- **Association Class**: An association that is treated as a class because it has attributes of its own in a many-to-many relationship.
- **Binary Association**: An association between exactly two distinct classes.
- **Brainstorming Technique**: A discovery method where analysts examine six categories of things (tangible, roles, units, devices, sites, incidents) to identify domain classes.
- **Composition**: A strict whole-part relationship where components cannot exist without the whole, denoted by a solid black diamond (`◆`).
- **Compound Attribute**: An attribute composed of multiple sub-attributes (e.g., Address = Street + City + State + Zip).
- **Concrete Class**: A class that can be directly instantiated with real-world object instances.
- **Concurrent States**: When an object exists in two or more operational states simultaneously.
- **Derived Attribute**: An attribute computed dynamically from other stored data, denoted in UML with a forward slash (`/`).
- **Domain Class**: A category of real-world objects in the problem environment about which the information system stores data.
- **Domain Model Class Diagram**: A UML structural diagram showing the conceptual classes, attributes, and associations in the problem domain without methods.
- **Generalization**: The cognitive process of grouping classes based on shared characteristics into a common superclass.
- **Guard Condition**: A boolean predicate enclosed in `[brackets]` that must be True for a state transition to fire.
- **Inheritance**: The mechanism by which a subclass automatically receives all attributes and associations of its superclass.
- **Multiplicity**: The UML specification of the minimum and maximum number of associations allowed between class instances (synonymous with cardinality).
- **Noun Technique**: An analytical method that identifies domain classes by cataloging and categorizing every noun in requirements documents.
- **Specialization**: The process of creating specialized subclasses that extend a superclass with unique attributes.
- **State**: A condition during the life of an object where it satisfies a condition, performs an activity, or waits for an event.
- **State Machine Diagram**: A UML behavioral diagram modeling the states, transitions, and lifecycle events of an individual object.
- **Synchronization Bar**: A heavy bar in state and activity diagrams that splits paths into parallel concurrent execution (fork) or synchronizes them (join).
- **Things**: The physical objects, roles, locations, and transactions in the problem domain that the system must remember.
- **Transition**: The movement of an object from one state to another triggered by an event.
- **Unary Association (Recursive)**: An association connecting instances of the same class to each other.
- **Whole-Part Relationship**: A relationship where one class represents the complete whole and other classes represent constituent components.