HotelManagement / gen1

Your task is to generate a complete and diverse instance, in plain English, for a given category and based on a provided conceptual model description. The instance must adhere to these requirements: - Be self-contained: Include all required attributes, relationships, and related entities in full detail. - Conform to the model: Fulfill the constraints, multiplicities, relationships, and attributes defined in the class diagram model. - Understand the context: Ensure that its attributes and relationships are relevant. - Avoid duplication of instances: Take into consideration those instances previously built to avoid redundancy. - Semantic diversity: From a semantic point of view, incorporate varied scenarios, including regional, linguistic, or cultural differences. - Structural diversity: Include instances with different numbers of elements, different numbers of relationships and complexity, and create varied examples by changing entity attributes.

You are tasked with creating instances of a conceptual model in the UML-based Specification Environment (USE). You will receive: 1. The UML class diagram that the instance follows. 2. A sample syntax of instances creation. 3. A description of the instance that needs to be created.  Your goal is to generate these instances based on the provided description, adhering strictly to these requirements: - The output must be in plain text, with no additional comments, descriptions, or explanations. - Ensure that the created instance adheres to the provided description. - Follow the syntax sample provided, without deviation. - Take into account previously created instances to avoid using duplicate naming.

<role>
You are an expert software and system modeler. You are able to assess the semantic quality of object models that have been created to conform to a domain model. The models are defined in USE (UML-based Specification Environment) and OCL (Object Constraint Language).

Your primary capability is "Semantic Reality Checking". You do not just check for syntactic correctness; you check for real-world plausibility and logical consistency within a given domain.
</role>

<context>
The user will provide two types of content:
1. **Domain Model (.use)**: A class diagram definition including classes, attributes, enums, relationships, multiplicities and roles.
2. **Object Model (.soil)**: An object model. This object model can be seen as a script composed of instructions for the creation of objects, relationships and setting attribute values (snapshot).

Your goal is to act as a judge to determine if the object model represents a **REALISTIC** scenario based on the domain model and common sense real-world logic.
</context>

<definitions>
- **Realistic**: The object model is syntactically correct AND semantically plausible (e.g., A 'Person' has an age between 0 and 120; a 'Car' has a positive price).
- **Unrealistic**: The object model contains contradictions, impossible physical values, or nonsensical relationships (e.g., A 'Person' is their own father; a 'Product' has a negative weight).
- **Doubtful**: You cannot determine whether the object model is realistic or not.
</definitions>

<instructions>
Follow this thinking process strictly before generating the final output:

1. **Analyze the Domain (.use)**: Understand the classes and what they represent in the real world.
2. **Analyze the Instances (.soil)**: Map the created objects to their classes. Look at the specific values assigned to attributes and the relationships created between objects.
3. **Evaluate Semantics**:
    - Apply "Common Sense Knowledge" to the attribute values.
    - Check cardinality and relationship logic beyond simple OCL constraints.
    - Identify any outliers or logical fallacies.
4. **Determine Verdict**: Select one of the defined labels (Realistic/Unrealistic/Doubtful).
</instructions>

<constraints>
- **Tone**: Objective, Analytical, Technical.
- **Verbosity**: Low. Be direct.
- **Reasoning**: The "Why" section must be concise and specific, citing variable names, objects, or relationships when possible.
- Do not output the internal thinking process. Only output the final formatted result.
</constraints>

<output_format>
Structure your response exactly as follows:

**Response**: [Realistic | Unrealistic | Doubtful]
**Why**: [Concise explanation of your reasoning. If Unrealistic, specify the exact objects, values or relationships that break realism.]
</output_format>

<examples>
Example 1:
Input:

<domain_model>
class Person
attributes
    age: Integer
end
class Pet
attributes
    name: String
end
association Ownership between
    Person [1] role owner
    Pet [*] role pets
end
</domain_model>
<object_model>
!new Person('p1')
!p1.age := 250
!new Pet('pet1')
!pet1.name := 'Luna'
… 1.000 more pets creation …
!pet1000.name := 'Max'
!insert (p1, pet1) into Ownership
…1.000 more pets associated with p1 …
!insert (p1, pet1000) into Ownership
</object_model>

Output:

**Response**: Unrealistic
**Why**: The object 'p1' of class 'Person' has an age of 250, which exceeds the biologically plausible lifespan of a human. Although it is not plausible that 1 same person owns 1.000 pets.


Example 2:
Input:

<domain_model>
class Car
attributes
    brand: String
end
class Person
attributes
    name: String
end
association Ownership between
    Person [1] role owner
    Car [*] role cars
end
</domain_model>
<object_model>
!new Person('p1')
!p1.age := 19
!new Car('c1')
!c1.brand := 'Toyota'
!insert (p1, c1) into Ownership
</object_model>

Output:

**Response**: Realistic
**Why**: The object 'c1' has a valid, recognized real-world car brand assigned, and its plausible that a teenager has only one car.


Example 3:
Input:

<domain_model>
class Component
attributes
    setting_val: Integer
    config_mode: String
end
</domain_model>
<object_model>
!new Component('c1')
!c1.setting_val := 8080
!c1.config_mode := 'Legacy'
</object_model>

Output:

**Response**: Doubtful
**Why**: The class 'Component' and attribute 'setting_val' are generic and lack specific real-world semantic context. Without knowing what specific physical or software system this represents, it is impossible to determine if '8080' is a realistic value or an outlier.

</examples>

# Conceptual model description:
## Description
The Hotel Management model represents a system designed to manage hotel bookings and associated operations. The model includes various classes that represent key entities within the hotel management process, such as bookings, bills, customers, room reservations, and the rooms themselves. The purpose of this model is to streamline the tracking of hotel operations, including reservations, billing, and room management.

### Components
- **Booking**: Represents a hotel booking with attributes like `startDate` (String), `endDate` (String), `canceled` (Boolean), `bookingId` (Integer), and `confirmed` (Boolean), indicating booking details.
- **Bill**: Represents a financial transaction, containing a `price` (Real) and `billId` (Integer).
- **FreeRoomTypesDTO**: Contains details about available room types including `roomTypeDescription` (String), `numBeds` (Integer), `pricePerNight` (Real), and `numFreeRooms` (Integer).
- **Customer**: Represents a hotel guest with basic information, including `firstName` (String) and `lastName` (String).
- **RoomReservation**: Details about a room reservation with attributes `checkInDate` (String) and `checkOutDate` (String).
- **RoomExtra**: Represents additional services or items with `price` (Real) and `description` (String).
- **Room**: Provides details about a hotel room, including `numBeds` (Integer), `pricePerNight` (Real), `occupied` (Boolean), `blocked` (Boolean), and `roomNumber` (Integer).

## Relationships
- **BookingBill**: A Booking is associated with one or more Bills. Each Booking [1] can have zero or more Bills [0..*].
- **BookingCustomer**: A Booking is associated with exactly one Customer. Each Booking [1] is linked to exactly one Customer [1].
- **BookingRoomReservation**: A Booking can have multiple Room Reservations. Each Booking [1] is associated with zero or more Room Reservations [*].
- **RoomReservationExtras**: A Room Reservation can include multiple Room Extras. Each Room Reservation [1] is associated with zero or more Room Extras [*].
- **RoomReservationRoom**: A Room Reservation can involve multiple Rooms. Each Room Reservation [1] is associated with zero or more Rooms [*].
- **BillRoomReservation**: A Bill is associated with exactly one Room Reservation. Each Bill [1] is linked to exactly one Room Reservation [1].

## Invariants
- **positiveBill**: Ensures that the `price` attribute of a Bill is non-negative (`self.price >= 0`).
- **uniqueBillId**: Ensures that each Bill has a unique `billId` (`Bill.allInstances->isUnique(b | b.billId)`).
- **positiveNumBeds**: Ensures that each Room has a positive number of beds (`self.numBeds > 0`).

# Category: Baseline Instances
Create a baseline instance. This is an instance that represents a realistic typical/standard scenario. Ensure every class and relationship is present in the instance at least once.

# UML class diagram:
model HotelManagement

class Booking
attributes
    startDate : String
    endDate : String
    canceled : Boolean
    bookingId : Integer
    confirmed : Boolean
end

class Bill
attributes
    price : Real
    billId : Integer
end

class FreeRoomTypesDTO
attributes
    roomTypeDescription : String
    numBeds : Integer
    pricePerNight : Real
    numFreeRooms : Integer
end

class Customer
attributes
    firstName : String
    lastName : String
end

class RoomReservation
attributes
    checkInDate : String
    checkOutDate : String
end

class RoomExtra
attributes
    price : Real
    description : String
end

class Room
attributes
    numBeds : Integer
    pricePerNight : Real
    occupied : Boolean
    blocked : Boolean
    roomNumber : Integer
end

association BookingBill between
    Booking [1]
    Bill [0..*] role bills
end

association BookingCustomer between
    Booking [1]
    Customer [1] role customer
end

association BookingRoomReservation between
    Booking [1]
    RoomReservation [*] role roomReservations
end

association RoomReservationExtras between
    RoomReservation [1]
    RoomExtra [*] role roomExtras
end

association RoomReservationRoom between
    RoomReservation [1]
    Room [*] role room
end

association BillRoomReservation between
    Bill [1]
    RoomReservation [1] role roomReservation
end

constraints
context Bill inv positiveBill:
    self.price >= 0

context Bill inv uniqueBillId:
    Bill.allInstances->isUnique(b | b.billId)

context Room inv positiveNumBeds:
    self.numBeds > 0

# Syntax example of instances creation:
-- This is a comment example

-- Primitive data types:
    -- Integer i.e. 1, 2, 3, etc.
    -- Real i.e. 1.0, 21.89, 322.05556, etc.
    -- Boolean i.e. true or false
    -- String i.e. 'Hello World'

-- You can create instances with the following syntax:
!new <instance type>('<instance name>')
-- Example:
!new Client('client1')
!new Store('store4')

-- You can assign values to attributes for a created instance with the following syntax:
!<instance name>.<attribute name> := <value>
-- Example for different data types:
!client1.clientId := 1 -- For Integer
!client1.balance := 1123.45 -- For Real
!client1.name := 'John' -- For Strings
!store4.available := true -- For Boolean

-- You can create associations between instances with the following syntax:
!insert (<instance name1>, <instance name2>) into <association name>
-- Example:
!insert (client1, store4) into ClientStore

-- Custom data types usage:
    -- dataType Location
    -- operations
    --   Location(x : Real, y : Real)
    --   some other operations
    -- end
-- You can create custom data types by calling the constructor directly; in this case, the constructor of Location requires two arguments: x and y of type Real. So it can be used as follows:
!store4.location := Location(14.0, 289.0)

-- Enums usage:
    -- enum Type { Clothes, Shoes }
-- Can be used as follows:
!store4.type := #Clothes

# Instance description:
Please create the instance according to this specification:
## Baseline Instance: Typical Hotel Stay Scenario

### Entities and Attributes:

1. **Customer**
   - `firstName`: Maria
   - `lastName`: Fernandez

2. **Booking**
   - `startDate`: "2023-05-15"
   - `endDate`: "2023-05-20"
   - `canceled`: false
   - `bookingId`: 101
   - `confirmed`: true

3. **Bill** (For room reservation charges)
   - `price`: 750.0
   - `billId`: 201

4. **Bill** (For additional services)
   - `price`: 150.0
   - `billId`: 202

5. **FreeRoomTypesDTO**
   - `roomTypeDescription`: "Deluxe Suite"
   - `numBeds`: 2
   - `pricePerNight`: 150.0
   - `numFreeRooms`: 3

6. **RoomReservation**
   - `checkInDate`: "2023-05-15"
   - `checkOutDate`: "2023-05-20"

7. **RoomExtra** (Spa service)
   - `price`: 100.0
   - `description`: "Spa treatment package"

8. **RoomExtra** (Minibar usage)
   - `price`: 50.0
   - `description`: "Minibar consumption"

9. **Room**
   - `numBeds`: 2
   - `pricePerNight`: 150.0
   - `occupied`: true
   - `blocked`: false
   - `roomNumber`: 305

### Relationships and Associations:

1. **BookingCustomer**
   - The Booking with `bookingId` 101 is associated with Customer Maria Fernandez.

2. **BookingBill**
   - The Booking with `bookingId` 101 is associated with Bills `billId` 201 and `billId` 202.

3. **BookingRoomReservation**
   - The Booking with `bookingId` 101 is associated with one Room Reservation with `checkInDate` "2023-05-15" and `checkOutDate` "2023-05-20".

4. **RoomReservationExtras**
   - The Room Reservation is associated with RoomExtra: Spa service (`description`: "Spa treatment package", `price`: 100.0) and RoomExtra: Minibar usage (`description`: "Minibar consumption", `price`: 50.0).

5. **RoomReservationRoom**
   - The Room Reservation is associated with Room number 305, which has 2 beds.

6. **BillRoomReservation**
   - Bill `billId` 201 is associated with the Room Reservation for room charges.
   - Bill `billId` 202 is associated with the same Room Reservation for extra services.

### Invariants:
- `positiveBill`: Both bill prices, 750.0 and 150.0, are non-negative.
- `uniqueBillId`: `billId` 201 and `billId` 202 are unique.
- `positiveNumBeds`: Room 305 has more than 0 beds (`numBeds`: 2).

This baseline instance provides a complete, realistic representation of a typical hotel stay including all entities and relationships, ensuring involvement of every class and establishing standard interconnections.

The last output is partially incorrect: 
checking structure...
Multiplicity constraint violation in association `BillRoomReservation':
  Object `roomReservation1' of class `RoomReservation' is connected to 2 objects of class `Bill'
  at association end `bill' but the multiplicity is specified as `1'.

Please provide the complete output corrected

The last output is partially incorrect: 
checking structure...
Multiplicity constraint violation in association `BillRoomReservation':
  Object `bill2' of class `Bill' is connected to 0 objects of class `RoomReservation'
  at association end `roomReservation' but the multiplicity is specified as `1'.

Please provide the complete output corrected

<domain_model>
model HotelManagement

class Booking
attributes
    startDate : String
    endDate : String
    canceled : Boolean
    bookingId : Integer
    confirmed : Boolean
end

class Bill
attributes
    price : Real
    billId : Integer
end

class FreeRoomTypesDTO
attributes
    roomTypeDescription : String
    numBeds : Integer
    pricePerNight : Real
    numFreeRooms : Integer
end

class Customer
attributes
    firstName : String
    lastName : String
end

class RoomReservation
attributes
    checkInDate : String
    checkOutDate : String
end

class RoomExtra
attributes
    price : Real
    description : String
end

class Room
attributes
    numBeds : Integer
    pricePerNight : Real
    occupied : Boolean
    blocked : Boolean
    roomNumber : Integer
end

association BookingBill between
    Booking [1]
    Bill [0..*] role bills
end

association BookingCustomer between
    Booking [1]
    Customer [1] role customer
end

association BookingRoomReservation between
    Booking [1]
    RoomReservation [*] role roomReservations
end

association RoomReservationExtras between
    RoomReservation [1]
    RoomExtra [*] role roomExtras
end

association RoomReservationRoom between
    RoomReservation [1]
    Room [*] role room
end

association BillRoomReservation between
    Bill [1]
    RoomReservation [1] role roomReservation
end

constraints
context Bill inv positiveBill:
    self.price >= 0

context Bill inv uniqueBillId:
    Bill.allInstances->isUnique(b | b.billId)

context Room inv positiveNumBeds:
    self.numBeds > 0
</domain_model>

<object_model>
!new Customer('customer1')
!customer1.firstName := 'Maria'
!customer1.lastName := 'Fernandez'

!new Booking('booking1')
!booking1.startDate := '2023-05-15'
!booking1.endDate := '2023-05-20'
!booking1.canceled := false
!booking1.bookingId := 101
!booking1.confirmed := true

!new Bill('bill1')
!bill1.price := 750.0
!bill1.billId := 201

!new Bill('bill2')
!bill2.price := 150.0
!bill2.billId := 202

!new FreeRoomTypesDTO('freeRoomType1')
!freeRoomType1.roomTypeDescription := 'Deluxe Suite'
!freeRoomType1.numBeds := 2
!freeRoomType1.pricePerNight := 150.0
!freeRoomType1.numFreeRooms := 3

!new RoomReservation('roomReservation1')
!roomReservation1.checkInDate := '2023-05-15'
!roomReservation1.checkOutDate := '2023-05-20'

!new RoomExtra('roomExtra1')
!roomExtra1.price := 100.0
!roomExtra1.description := 'Spa treatment package'

!new RoomExtra('roomExtra2')
!roomExtra2.price := 50.0
!roomExtra2.description := 'Minibar consumption'

!new Room('room1')
!room1.numBeds := 2
!room1.pricePerNight := 150.0
!room1.occupied := true
!room1.blocked := false
!room1.roomNumber := 305

!insert (booking1, customer1) into BookingCustomer

!insert (booking1, bill1) into BookingBill
!insert (booking1, bill2) into BookingBill

!insert (booking1, roomReservation1) into BookingRoomReservation

!insert (roomReservation1, roomExtra1) into RoomReservationExtras
!insert (roomReservation1, roomExtra2) into RoomReservationExtras

!insert (roomReservation1, room1) into RoomReservationRoom

!insert (bill1, roomReservation1) into BillRoomReservation
!insert (bill2, roomReservation1) into BillRoomReservation
</object_model>

Your task is to generate a complete and diverse instance, in plain English, for a given category and based on a provided conceptual model description. The instance must adhere to these requirements: - Be self-contained: Include all required attributes, relationships, and related entities in full detail. - Conform to the model: Fulfill the constraints, multiplicities, relationships, and attributes defined in the class diagram model. - Understand the context: Ensure that its attributes and relationships are relevant. - Avoid duplication of instances: Take into consideration those instances previously built to avoid redundancy. - Semantic diversity: From a semantic point of view, incorporate varied scenarios, including regional, linguistic, or cultural differences. - Structural diversity: Include instances with different numbers of elements, different numbers of relationships and complexity, and create varied examples by changing entity attributes.

You are tasked with creating instances of a conceptual model in the UML-based Specification Environment (USE). You will receive: 1. The UML class diagram that the instance follows. 2. A sample syntax of instances creation. 3. A description of the instance that needs to be created.  Your goal is to generate these instances based on the provided description, adhering strictly to these requirements: - The output must be in plain text, with no additional comments, descriptions, or explanations. - Ensure that the created instance adheres to the provided description. - Follow the syntax sample provided, without deviation. - Take into account previously created instances to avoid using duplicate naming.

<role>
You are an expert software and system modeler. You are able to assess the semantic quality of object models that have been created to conform to a domain model. The models are defined in USE (UML-based Specification Environment) and OCL (Object Constraint Language).

Your primary capability is "Semantic Reality Checking". You do not just check for syntactic correctness; you check for real-world plausibility and logical consistency within a given domain.
</role>

<context>
The user will provide two types of content:
1. **Domain Model (.use)**: A class diagram definition including classes, attributes, enums, relationships, multiplicities and roles.
2. **Object Model (.soil)**: An object model. This object model can be seen as a script composed of instructions for the creation of objects, relationships and setting attribute values (snapshot).

Your goal is to act as a judge to determine if the object model represents a **REALISTIC** scenario based on the domain model and common sense real-world logic.
</context>

<definitions>
- **Realistic**: The object model is syntactically correct AND semantically plausible (e.g., A 'Person' has an age between 0 and 120; a 'Car' has a positive price).
- **Unrealistic**: The object model contains contradictions, impossible physical values, or nonsensical relationships (e.g., A 'Person' is their own father; a 'Product' has a negative weight).
- **Doubtful**: You cannot determine whether the object model is realistic or not.
</definitions>

<instructions>
Follow this thinking process strictly before generating the final output:

1. **Analyze the Domain (.use)**: Understand the classes and what they represent in the real world.
2. **Analyze the Instances (.soil)**: Map the created objects to their classes. Look at the specific values assigned to attributes and the relationships created between objects.
3. **Evaluate Semantics**:
    - Apply "Common Sense Knowledge" to the attribute values.
    - Check cardinality and relationship logic beyond simple OCL constraints.
    - Identify any outliers or logical fallacies.
4. **Determine Verdict**: Select one of the defined labels (Realistic/Unrealistic/Doubtful).
</instructions>

<constraints>
- **Tone**: Objective, Analytical, Technical.
- **Verbosity**: Low. Be direct.
- **Reasoning**: The "Why" section must be concise and specific, citing variable names, objects, or relationships when possible.
- Do not output the internal thinking process. Only output the final formatted result.
</constraints>

<output_format>
Structure your response exactly as follows:

**Response**: [Realistic | Unrealistic | Doubtful]
**Why**: [Concise explanation of your reasoning. If Unrealistic, specify the exact objects, values or relationships that break realism.]
</output_format>

<examples>
Example 1:
Input:

<domain_model>
class Person
attributes
    age: Integer
end
class Pet
attributes
    name: String
end
association Ownership between
    Person [1] role owner
    Pet [*] role pets
end
</domain_model>
<object_model>
!new Person('p1')
!p1.age := 250
!new Pet('pet1')
!pet1.name := 'Luna'
… 1.000 more pets creation …
!pet1000.name := 'Max'
!insert (p1, pet1) into Ownership
…1.000 more pets associated with p1 …
!insert (p1, pet1000) into Ownership
</object_model>

Output:

**Response**: Unrealistic
**Why**: The object 'p1' of class 'Person' has an age of 250, which exceeds the biologically plausible lifespan of a human. Although it is not plausible that 1 same person owns 1.000 pets.


Example 2:
Input:

<domain_model>
class Car
attributes
    brand: String
end
class Person
attributes
    name: String
end
association Ownership between
    Person [1] role owner
    Car [*] role cars
end
</domain_model>
<object_model>
!new Person('p1')
!p1.age := 19
!new Car('c1')
!c1.brand := 'Toyota'
!insert (p1, c1) into Ownership
</object_model>

Output:

**Response**: Realistic
**Why**: The object 'c1' has a valid, recognized real-world car brand assigned, and its plausible that a teenager has only one car.


Example 3:
Input:

<domain_model>
class Component
attributes
    setting_val: Integer
    config_mode: String
end
</domain_model>
<object_model>
!new Component('c1')
!c1.setting_val := 8080
!c1.config_mode := 'Legacy'
</object_model>

Output:

**Response**: Doubtful
**Why**: The class 'Component' and attribute 'setting_val' are generic and lack specific real-world semantic context. Without knowing what specific physical or software system this represents, it is impossible to determine if '8080' is a realistic value or an outlier.

</examples>

# Conceptual model description:
## Description
The Hotel Management model represents a system designed to manage hotel bookings and associated operations. The model includes various classes that represent key entities within the hotel management process, such as bookings, bills, customers, room reservations, and the rooms themselves. The purpose of this model is to streamline the tracking of hotel operations, including reservations, billing, and room management.

### Components
- **Booking**: Represents a hotel booking with attributes like `startDate` (String), `endDate` (String), `canceled` (Boolean), `bookingId` (Integer), and `confirmed` (Boolean), indicating booking details.
- **Bill**: Represents a financial transaction, containing a `price` (Real) and `billId` (Integer).
- **FreeRoomTypesDTO**: Contains details about available room types including `roomTypeDescription` (String), `numBeds` (Integer), `pricePerNight` (Real), and `numFreeRooms` (Integer).
- **Customer**: Represents a hotel guest with basic information, including `firstName` (String) and `lastName` (String).
- **RoomReservation**: Details about a room reservation with attributes `checkInDate` (String) and `checkOutDate` (String).
- **RoomExtra**: Represents additional services or items with `price` (Real) and `description` (String).
- **Room**: Provides details about a hotel room, including `numBeds` (Integer), `pricePerNight` (Real), `occupied` (Boolean), `blocked` (Boolean), and `roomNumber` (Integer).

## Relationships
- **BookingBill**: A Booking is associated with one or more Bills. Each Booking [1] can have zero or more Bills [0..*].
- **BookingCustomer**: A Booking is associated with exactly one Customer. Each Booking [1] is linked to exactly one Customer [1].
- **BookingRoomReservation**: A Booking can have multiple Room Reservations. Each Booking [1] is associated with zero or more Room Reservations [*].
- **RoomReservationExtras**: A Room Reservation can include multiple Room Extras. Each Room Reservation [1] is associated with zero or more Room Extras [*].
- **RoomReservationRoom**: A Room Reservation can involve multiple Rooms. Each Room Reservation [1] is associated with zero or more Rooms [*].
- **BillRoomReservation**: A Bill is associated with exactly one Room Reservation. Each Bill [1] is linked to exactly one Room Reservation [1].

## Invariants
- **positiveBill**: Ensures that the `price` attribute of a Bill is non-negative (`self.price >= 0`).
- **uniqueBillId**: Ensures that each Bill has a unique `billId` (`Bill.allInstances->isUnique(b | b.billId)`).
- **positiveNumBeds**: Ensures that each Room has a positive number of beds (`self.numBeds > 0`).

# Category: Boundary Instances
Create a boundary case instance. This is an instance that focuses on the extreme upper or lower limits of valid input ranges. For example:
- Upper or lower limits of multiplicities.
- For numbers in a range, the minimum and maximum valid values.
- Empty collections when possible, i.e., when they do not violate the semantics of the model or its constraints.

Continue with the following description, creating the instance according to the syntax example and this specification: 
## Boundary Case Instance for Hotel Management

### Booking Details
- **Booking 101**:
  - `startDate`: "2023-12-30"
  - `endDate`: "2024-01-02"
  - `canceled`: False
  - `bookingId`: 101
  - `confirmed`: True

### Customer
- **Anika Sng**:
  - `firstName`: "Anika"
  - `lastName`: "Sng"

### Bills
1. **Bill 501**:
   - `price`: 0.0 (Testing the minimum positive value for a `Bill` price)
   - `billId`: 501

2. **Bill 502**:
   - `price`: 9999.99 (Testing an upper boundary for a `Bill` price)
   - `billId`: 502

### FreeRoomTypesDTO
- **Free Room Type Details**:
  - `roomTypeDescription`: "Suite"
  - `numBeds`: 6 (Upper boundary for number of beds, assuming a large family suite configuration)
  - `pricePerNight`: 1500.00
  - `numFreeRooms`: 0 (Edge case: All rooms of this type are booked)

### RoomReservation
- **Reservation for Booking 101**:
  - `checkInDate`: "2023-12-30"
  - `checkOutDate`: "2024-01-02"

### RoomExtras
1. **Room Extra 1**:
   - `price`: 0.0 (Testing no additional charge service, e.g., complimentary service)
   - `description`: "Free WiFi"

2. **Room Extra 2**:
   - `price`: 250.0
   - `description`: "Buffet Breakfast for two"

### Rooms
1. **Room 301**:
   - `numBeds`: 6 (Testing the upper boundary limit for a large room or suite)
   - `pricePerNight`: 1000.0
   - `occupied`: True
   - `blocked`: False
   - `roomNumber`: 301

2. **Room 302**:
   - `numBeds`: 1 (Testing the minimum valid number of beds)
   - `pricePerNight`: 80.0
   - `occupied`: False
   - `blocked`: True (Testing a blocked room for maintenance)
   - `roomNumber`: 302

### Relationships
- **Booking 101 to Anika Sng**: One-to-one association as per model.
- **Booking 101 to Bills**: Includes Bill 501 and Bill 502 to represent zero and an upper boundary price.
- **Booking 101 to Room Reservation**: Links to the Room Reservation for the specified dates.
- **Room Reservation to Extras**: Includes both complimentary and paid extras, Room Extra 1 and Room Extra 2 respectively.
- **Room Reservation to Rooms**: Engages Room 301 and involves Room 302 to represent the boundaries.

This instance captures the extreme boundaries of the system with various relationships and numerical edge cases such as free services and maximum prices, providing a comprehensive test of the structural and business rules prescribed by the model.

The last output is partially incorrect: 
checking structure...
Multiplicity constraint violation in association `BillRoomReservation':
  Object `roomReservation3' of class `RoomReservation' is connected to 2 objects of class `Bill'
  at association end `bill' but the multiplicity is specified as `1'.

Please provide the complete output corrected

The last output is partially incorrect: 
checking structure...
Multiplicity constraint violation in association `BillRoomReservation':
  Object `bill7' of class `Bill' is connected to 0 objects of class `RoomReservation'
  at association end `roomReservation' but the multiplicity is specified as `1'.

Please provide the complete output corrected

<domain_model>
model HotelManagement

class Booking
attributes
    startDate : String
    endDate : String
    canceled : Boolean
    bookingId : Integer
    confirmed : Boolean
end

class Bill
attributes
    price : Real
    billId : Integer
end

class FreeRoomTypesDTO
attributes
    roomTypeDescription : String
    numBeds : Integer
    pricePerNight : Real
    numFreeRooms : Integer
end

class Customer
attributes
    firstName : String
    lastName : String
end

class RoomReservation
attributes
    checkInDate : String
    checkOutDate : String
end

class RoomExtra
attributes
    price : Real
    description : String
end

class Room
attributes
    numBeds : Integer
    pricePerNight : Real
    occupied : Boolean
    blocked : Boolean
    roomNumber : Integer
end

association BookingBill between
    Booking [1]
    Bill [0..*] role bills
end

association BookingCustomer between
    Booking [1]
    Customer [1] role customer
end

association BookingRoomReservation between
    Booking [1]
    RoomReservation [*] role roomReservations
end

association RoomReservationExtras between
    RoomReservation [1]
    RoomExtra [*] role roomExtras
end

association RoomReservationRoom between
    RoomReservation [1]
    Room [*] role room
end

association BillRoomReservation between
    Bill [1]
    RoomReservation [1] role roomReservation
end

constraints
context Bill inv positiveBill:
    self.price >= 0

context Bill inv uniqueBillId:
    Bill.allInstances->isUnique(b | b.billId)

context Room inv positiveNumBeds:
    self.numBeds > 0
</domain_model>

<object_model>
!new Customer('customer3')
!customer3.firstName := 'Anika'
!customer3.lastName := 'Sng'

!new Booking('booking3')
!booking3.startDate := '2023-12-30'
!booking3.endDate := '2024-01-02'
!booking3.canceled := false
!booking3.bookingId := 101
!booking3.confirmed := true

!new Bill('bill6')
!bill6.price := 0.0
!bill6.billId := 501

!new Bill('bill7')
!bill7.price := 9999.99
!bill7.billId := 502

!new FreeRoomTypesDTO('freeRoomType3')
!freeRoomType3.roomTypeDescription := 'Suite'
!freeRoomType3.numBeds := 6
!freeRoomType3.pricePerNight := 1500.00
!freeRoomType3.numFreeRooms := 0

!new RoomReservation('roomReservation3')
!roomReservation3.checkInDate := '2023-12-30'
!roomReservation3.checkOutDate := '2024-01-02'

!new RoomExtra('roomExtra5')
!roomExtra5.price := 0.0
!roomExtra5.description := 'Free WiFi'

!new RoomExtra('roomExtra6')
!roomExtra6.price := 250.0
!roomExtra6.description := 'Buffet Breakfast for two'

!new Room('room3_301')
!room3_301.numBeds := 6
!room3_301.pricePerNight := 1000.0
!room3_301.occupied := true
!room3_301.blocked := false
!room3_301.roomNumber := 301

!new Room('room3_302')
!room3_302.numBeds := 1
!room3_302.pricePerNight := 80.0
!room3_302.occupied := false
!room3_302.blocked := true
!room3_302.roomNumber := 302

!insert (booking3, customer3) into BookingCustomer

!insert (booking3, bill6) into BookingBill
!insert (booking3, bill7) into BookingBill

!insert (booking3, roomReservation3) into BookingRoomReservation

!insert (roomReservation3, roomExtra5) into RoomReservationExtras
!insert (roomReservation3, roomExtra6) into RoomReservationExtras

!insert (roomReservation3, room3_301) into RoomReservationRoom
!insert (roomReservation3, room3_302) into RoomReservationRoom

!insert (bill6, roomReservation3) into BillRoomReservation

!insert (bill7, roomReservation3) into BillRoomReservation
</object_model>

Your task is to generate a complete and diverse instance, in plain English, for a given category and based on a provided conceptual model description. The instance must adhere to these requirements: - Be self-contained: Include all required attributes, relationships, and related entities in full detail. - Conform to the model: Fulfill the constraints, multiplicities, relationships, and attributes defined in the class diagram model. - Understand the context: Ensure that its attributes and relationships are relevant. - Avoid duplication of instances: Take into consideration those instances previously built to avoid redundancy. - Semantic diversity: From a semantic point of view, incorporate varied scenarios, including regional, linguistic, or cultural differences. - Structural diversity: Include instances with different numbers of elements, different numbers of relationships and complexity, and create varied examples by changing entity attributes.

You are tasked with creating instances of a conceptual model in the UML-based Specification Environment (USE). You will receive: 1. The UML class diagram that the instance follows. 2. A sample syntax of instances creation. 3. A description of the instance that needs to be created.  Your goal is to generate these instances based on the provided description, adhering strictly to these requirements: - The output must be in plain text, with no additional comments, descriptions, or explanations. - Ensure that the created instance adheres to the provided description. - Follow the syntax sample provided, without deviation. - Take into account previously created instances to avoid using duplicate naming.

<role>
You are an expert software and system modeler. You are able to assess the semantic quality of object models that have been created to conform to a domain model. The models are defined in USE (UML-based Specification Environment) and OCL (Object Constraint Language).

Your primary capability is "Semantic Reality Checking". You do not just check for syntactic correctness; you check for real-world plausibility and logical consistency within a given domain.
</role>

<context>
The user will provide two types of content:
1. **Domain Model (.use)**: A class diagram definition including classes, attributes, enums, relationships, multiplicities and roles.
2. **Object Model (.soil)**: An object model. This object model can be seen as a script composed of instructions for the creation of objects, relationships and setting attribute values (snapshot).

Your goal is to act as a judge to determine if the object model represents a **REALISTIC** scenario based on the domain model and common sense real-world logic.
</context>

<definitions>
- **Realistic**: The object model is syntactically correct AND semantically plausible (e.g., A 'Person' has an age between 0 and 120; a 'Car' has a positive price).
- **Unrealistic**: The object model contains contradictions, impossible physical values, or nonsensical relationships (e.g., A 'Person' is their own father; a 'Product' has a negative weight).
- **Doubtful**: You cannot determine whether the object model is realistic or not.
</definitions>

<instructions>
Follow this thinking process strictly before generating the final output:

1. **Analyze the Domain (.use)**: Understand the classes and what they represent in the real world.
2. **Analyze the Instances (.soil)**: Map the created objects to their classes. Look at the specific values assigned to attributes and the relationships created between objects.
3. **Evaluate Semantics**:
    - Apply "Common Sense Knowledge" to the attribute values.
    - Check cardinality and relationship logic beyond simple OCL constraints.
    - Identify any outliers or logical fallacies.
4. **Determine Verdict**: Select one of the defined labels (Realistic/Unrealistic/Doubtful).
</instructions>

<constraints>
- **Tone**: Objective, Analytical, Technical.
- **Verbosity**: Low. Be direct.
- **Reasoning**: The "Why" section must be concise and specific, citing variable names, objects, or relationships when possible.
- Do not output the internal thinking process. Only output the final formatted result.
</constraints>

<output_format>
Structure your response exactly as follows:

**Response**: [Realistic | Unrealistic | Doubtful]
**Why**: [Concise explanation of your reasoning. If Unrealistic, specify the exact objects, values or relationships that break realism.]
</output_format>

<examples>
Example 1:
Input:

<domain_model>
class Person
attributes
    age: Integer
end
class Pet
attributes
    name: String
end
association Ownership between
    Person [1] role owner
    Pet [*] role pets
end
</domain_model>
<object_model>
!new Person('p1')
!p1.age := 250
!new Pet('pet1')
!pet1.name := 'Luna'
… 1.000 more pets creation …
!pet1000.name := 'Max'
!insert (p1, pet1) into Ownership
…1.000 more pets associated with p1 …
!insert (p1, pet1000) into Ownership
</object_model>

Output:

**Response**: Unrealistic
**Why**: The object 'p1' of class 'Person' has an age of 250, which exceeds the biologically plausible lifespan of a human. Although it is not plausible that 1 same person owns 1.000 pets.


Example 2:
Input:

<domain_model>
class Car
attributes
    brand: String
end
class Person
attributes
    name: String
end
association Ownership between
    Person [1] role owner
    Car [*] role cars
end
</domain_model>
<object_model>
!new Person('p1')
!p1.age := 19
!new Car('c1')
!c1.brand := 'Toyota'
!insert (p1, c1) into Ownership
</object_model>

Output:

**Response**: Realistic
**Why**: The object 'c1' has a valid, recognized real-world car brand assigned, and its plausible that a teenager has only one car.


Example 3:
Input:

<domain_model>
class Component
attributes
    setting_val: Integer
    config_mode: String
end
</domain_model>
<object_model>
!new Component('c1')
!c1.setting_val := 8080
!c1.config_mode := 'Legacy'
</object_model>

Output:

**Response**: Doubtful
**Why**: The class 'Component' and attribute 'setting_val' are generic and lack specific real-world semantic context. Without knowing what specific physical or software system this represents, it is impossible to determine if '8080' is a realistic value or an outlier.

</examples>

# Conceptual model description:
## Description
The Hotel Management model represents a system designed to manage hotel bookings and associated operations. The model includes various classes that represent key entities within the hotel management process, such as bookings, bills, customers, room reservations, and the rooms themselves. The purpose of this model is to streamline the tracking of hotel operations, including reservations, billing, and room management.

### Components
- **Booking**: Represents a hotel booking with attributes like `startDate` (String), `endDate` (String), `canceled` (Boolean), `bookingId` (Integer), and `confirmed` (Boolean), indicating booking details.
- **Bill**: Represents a financial transaction, containing a `price` (Real) and `billId` (Integer).
- **FreeRoomTypesDTO**: Contains details about available room types including `roomTypeDescription` (String), `numBeds` (Integer), `pricePerNight` (Real), and `numFreeRooms` (Integer).
- **Customer**: Represents a hotel guest with basic information, including `firstName` (String) and `lastName` (String).
- **RoomReservation**: Details about a room reservation with attributes `checkInDate` (String) and `checkOutDate` (String).
- **RoomExtra**: Represents additional services or items with `price` (Real) and `description` (String).
- **Room**: Provides details about a hotel room, including `numBeds` (Integer), `pricePerNight` (Real), `occupied` (Boolean), `blocked` (Boolean), and `roomNumber` (Integer).

## Relationships
- **BookingBill**: A Booking is associated with one or more Bills. Each Booking [1] can have zero or more Bills [0..*].
- **BookingCustomer**: A Booking is associated with exactly one Customer. Each Booking [1] is linked to exactly one Customer [1].
- **BookingRoomReservation**: A Booking can have multiple Room Reservations. Each Booking [1] is associated with zero or more Room Reservations [*].
- **RoomReservationExtras**: A Room Reservation can include multiple Room Extras. Each Room Reservation [1] is associated with zero or more Room Extras [*].
- **RoomReservationRoom**: A Room Reservation can involve multiple Rooms. Each Room Reservation [1] is associated with zero or more Rooms [*].
- **BillRoomReservation**: A Bill is associated with exactly one Room Reservation. Each Bill [1] is linked to exactly one Room Reservation [1].

## Invariants
- **positiveBill**: Ensures that the `price` attribute of a Bill is non-negative (`self.price >= 0`).
- **uniqueBillId**: Ensures that each Bill has a unique `billId` (`Bill.allInstances->isUnique(b | b.billId)`).
- **positiveNumBeds**: Ensures that each Room has a positive number of beds (`self.numBeds > 0`).

# Category: Complex Instances
Create a complex instance that is realistic and contains multiple interrelated entities and/or entities that are involved in multiple constraints.

Continue with the following description, creating the instance according to the syntax example and this specification: 
## Complex Instance Description

Welcome to the Royal Oaks Hotel, a sophisticated retreat situated on the beautiful coastline of Santorini, Greece, renowned for its stunning sunset views and exquisite hospitality. This particular instance details a complex scenario involving various interconnected entities within our hotel management model.

### Booking Details

- **Booking**:
  - **StartDate**: "2023-11-20"
  - **EndDate**: "2023-11-27"
  - **Canceled**: False
  - **BookingId**: 1007
  - **Confirmed**: True

### Customer Information

- **Customer**:
  - **FirstName**: "Sophia"
  - **LastName**: "Martinez"

### Billing Details

- **Bill**:
  - **Price**: 1325.00
  - **BillId**: 3002

### RoomReservation Details

1. **RoomReservation 1**:
   - **CheckInDate**: "2023-11-20"
   - **CheckOutDate**: "2023-11-24"

2. **RoomReservation 2**:
   - **CheckInDate**: "2023-11-24"
   - **CheckOutDate**: "2023-11-27"

### Associated Rooms

- **Room 101**:
  - **NumBeds**: 2
  - **PricePerNight**: 150.00
  - **Occupied**: True
  - **Blocked**: False
  - **RoomNumber**: 101

- **Room 105**:
  - **NumBeds**: 3
  - **PricePerNight**: 200.00
  - **Occupied**: True
  - **Blocked**: False
  - **RoomNumber**: 105

### Room Extras

- **RoomExtra**:
  - **Price**: 30.00
  - **Description**: "Daily Breakfast Buffet"

- **RoomExtra**:
  - **Price**: 45.00
  - **Description**: "Sunset Wine Tasting Event"

### FreeRoomTypesDTO

- **RoomType**:
  - **RoomTypeDescription**: "Suite with Sea View"
  - **NumBeds**: 2
  - **PricePerNight**: 220.00
  - **NumFreeRooms**: 1

### Relationships

- **Booking 1007**:
  - Associated with **Customer** Sophia Martinez.
  - Linked to **Bill 3002** for a total of 1325.00 EUR.
  - Involves two **RoomReservations** (Reservation 1 & 2).

- **RoomReservation 1**:
  - Includes Room **101**.
  - Has RoomExtras: "Daily Breakfast Buffet" and "Sunset Wine Tasting Event".
  - Linked to **Bill 3002** (First four nights).

- **RoomReservation 2**:
  - Consists of Room **105**.
  - Includes **RoomExtra**: "Daily Breakfast Buffet".
  - Linked to **Bill 3002** (Last three nights).

This complex instance illustrates a detailed multi-room reservation experience complete with associated customer, financial, and supplementary services data, reflecting the intricate needs of hotel management and guest satisfaction. The customer, Sophia Martinez, enjoys a full week stay at the Royal Oaks Hotel, capitalizing on an upgraded experience with exquisite sightseeing and cultural activities.

The last output is partially incorrect: 
checking structure...
Multiplicity constraint violation in association `BillRoomReservation':
  Object `bill8' of class `Bill' is connected to 2 objects of class `RoomReservation'
  at association end `roomReservation' but the multiplicity is specified as `1'.
Multiplicity constraint violation in association `RoomReservationExtras':
  Object `roomExtra7' of class `RoomExtra' is connected to 2 objects of class `RoomReservation'
  at association end `roomReservation' but the multiplicity is specified as `1'.

Please provide the complete output corrected

The last output is partially incorrect: 
checking structure...
Multiplicity constraint violation in association `BillRoomReservation':
  Object `roomReservation4_2' of class `RoomReservation' is connected to 0 objects of class `Bill'
  at association end `bill' but the multiplicity is specified as `1'.
Multiplicity constraint violation in association `RoomReservationExtras':
  Object `roomExtra8' of class `RoomExtra' is connected to 2 objects of class `RoomReservation'
  at association end `roomReservation' but the multiplicity is specified as `1'.

Please provide the complete output corrected

<domain_model>
model HotelManagement

class Booking
attributes
    startDate : String
    endDate : String
    canceled : Boolean
    bookingId : Integer
    confirmed : Boolean
end

class Bill
attributes
    price : Real
    billId : Integer
end

class FreeRoomTypesDTO
attributes
    roomTypeDescription : String
    numBeds : Integer
    pricePerNight : Real
    numFreeRooms : Integer
end

class Customer
attributes
    firstName : String
    lastName : String
end

class RoomReservation
attributes
    checkInDate : String
    checkOutDate : String
end

class RoomExtra
attributes
    price : Real
    description : String
end

class Room
attributes
    numBeds : Integer
    pricePerNight : Real
    occupied : Boolean
    blocked : Boolean
    roomNumber : Integer
end

association BookingBill between
    Booking [1]
    Bill [0..*] role bills
end

association BookingCustomer between
    Booking [1]
    Customer [1] role customer
end

association BookingRoomReservation between
    Booking [1]
    RoomReservation [*] role roomReservations
end

association RoomReservationExtras between
    RoomReservation [1]
    RoomExtra [*] role roomExtras
end

association RoomReservationRoom between
    RoomReservation [1]
    Room [*] role room
end

association BillRoomReservation between
    Bill [1]
    RoomReservation [1] role roomReservation
end

constraints
context Bill inv positiveBill:
    self.price >= 0

context Bill inv uniqueBillId:
    Bill.allInstances->isUnique(b | b.billId)

context Room inv positiveNumBeds:
    self.numBeds > 0
</domain_model>

<object_model>
!new Customer('customer4')
!customer4.firstName := 'Sophia'
!customer4.lastName := 'Martinez'

!new Booking('booking4')
!booking4.startDate := '2023-11-20'
!booking4.endDate := '2023-11-27'
!booking4.canceled := false
!booking4.bookingId := 1007
!booking4.confirmed := true

!new Bill('bill8')
!bill8.price := 1325.00
!bill8.billId := 3002

!new RoomReservation('roomReservation4_1')
!roomReservation4_1.checkInDate := '2023-11-20'
!roomReservation4_1.checkOutDate := '2023-11-24'

!new RoomReservation('roomReservation4_2')
!roomReservation4_2.checkInDate := '2023-11-24'
!roomReservation4_2.checkOutDate := '2023-11-27'

!new Room('room4_101')
!room4_101.numBeds := 2
!room4_101.pricePerNight := 150.00
!room4_101.occupied := true
!room4_101.blocked := false
!room4_101.roomNumber := 101

!new Room('room4_105')
!room4_105.numBeds := 3
!room4_105.pricePerNight := 200.00
!room4_105.occupied := true
!room4_105.blocked := false
!room4_105.roomNumber := 105

!new RoomExtra('roomExtra7')
!roomExtra7.price := 30.00
!roomExtra7.description := 'Daily Breakfast Buffet'

!new RoomExtra('roomExtra9')
!roomExtra9.price := 45.00
!roomExtra9.description := 'Sunset Wine Tasting Event'

!new FreeRoomTypesDTO('freeRoomType4')
!freeRoomType4.roomTypeDescription := 'Suite with Sea View'
!freeRoomType4.numBeds := 2
!freeRoomType4.pricePerNight := 220.00
!freeRoomType4.numFreeRooms := 1

!insert (booking4, customer4) into BookingCustomer

!insert (booking4, bill8) into BookingBill

!insert (booking4, roomReservation4_1) into BookingRoomReservation
!insert (booking4, roomReservation4_2) into BookingRoomReservation

!insert (roomReservation4_1, room4_101) into RoomReservationRoom
!insert (roomReservation4_1, roomExtra7) into RoomReservationExtras
!insert (roomReservation4_1, roomExtra9) into RoomReservationExtras

!insert (roomReservation4_2, room4_105) into RoomReservationRoom
!insert (roomReservation4_2, roomExtra7) into RoomReservationExtras

!insert (bill8, roomReservation4_1) into BillRoomReservation
!insert (bill8, roomReservation4_2) into BillRoomReservation
</object_model>

Your task is to generate a complete and diverse instance, in plain English, for a given category and based on a provided conceptual model description. The instance must adhere to these requirements: - Be self-contained: Include all required attributes, relationships, and related entities in full detail. - Conform to the model: Fulfill the constraints, multiplicities, relationships, and attributes defined in the class diagram model. - Understand the context: Ensure that its attributes and relationships are relevant. - Avoid duplication of instances: Take into consideration those instances previously built to avoid redundancy. - Semantic diversity: From a semantic point of view, incorporate varied scenarios, including regional, linguistic, or cultural differences. - Structural diversity: Include instances with different numbers of elements, different numbers of relationships and complexity, and create varied examples by changing entity attributes.

You are tasked with creating instances of a conceptual model in the UML-based Specification Environment (USE). You will receive: 1. The UML class diagram that the instance follows. 2. A sample syntax of instances creation. 3. A description of the instance that needs to be created.  Your goal is to generate these instances based on the provided description, adhering strictly to these requirements: - The output must be in plain text, with no additional comments, descriptions, or explanations. - Ensure that the created instance adheres to the provided description. - Follow the syntax sample provided, without deviation. - Take into account previously created instances to avoid using duplicate naming.

<role>
You are an expert software and system modeler. You are able to assess the semantic quality of object models that have been created to conform to a domain model. The models are defined in USE (UML-based Specification Environment) and OCL (Object Constraint Language).

Your primary capability is "Semantic Reality Checking". You do not just check for syntactic correctness; you check for real-world plausibility and logical consistency within a given domain.
</role>

<context>
The user will provide two types of content:
1. **Domain Model (.use)**: A class diagram definition including classes, attributes, enums, relationships, multiplicities and roles.
2. **Object Model (.soil)**: An object model. This object model can be seen as a script composed of instructions for the creation of objects, relationships and setting attribute values (snapshot).

Your goal is to act as a judge to determine if the object model represents a **REALISTIC** scenario based on the domain model and common sense real-world logic.
</context>

<definitions>
- **Realistic**: The object model is syntactically correct AND semantically plausible (e.g., A 'Person' has an age between 0 and 120; a 'Car' has a positive price).
- **Unrealistic**: The object model contains contradictions, impossible physical values, or nonsensical relationships (e.g., A 'Person' is their own father; a 'Product' has a negative weight).
- **Doubtful**: You cannot determine whether the object model is realistic or not.
</definitions>

<instructions>
Follow this thinking process strictly before generating the final output:

1. **Analyze the Domain (.use)**: Understand the classes and what they represent in the real world.
2. **Analyze the Instances (.soil)**: Map the created objects to their classes. Look at the specific values assigned to attributes and the relationships created between objects.
3. **Evaluate Semantics**:
    - Apply "Common Sense Knowledge" to the attribute values.
    - Check cardinality and relationship logic beyond simple OCL constraints.
    - Identify any outliers or logical fallacies.
4. **Determine Verdict**: Select one of the defined labels (Realistic/Unrealistic/Doubtful).
</instructions>

<constraints>
- **Tone**: Objective, Analytical, Technical.
- **Verbosity**: Low. Be direct.
- **Reasoning**: The "Why" section must be concise and specific, citing variable names, objects, or relationships when possible.
- Do not output the internal thinking process. Only output the final formatted result.
</constraints>

<output_format>
Structure your response exactly as follows:

**Response**: [Realistic | Unrealistic | Doubtful]
**Why**: [Concise explanation of your reasoning. If Unrealistic, specify the exact objects, values or relationships that break realism.]
</output_format>

<examples>
Example 1:
Input:

<domain_model>
class Person
attributes
    age: Integer
end
class Pet
attributes
    name: String
end
association Ownership between
    Person [1] role owner
    Pet [*] role pets
end
</domain_model>
<object_model>
!new Person('p1')
!p1.age := 250
!new Pet('pet1')
!pet1.name := 'Luna'
… 1.000 more pets creation …
!pet1000.name := 'Max'
!insert (p1, pet1) into Ownership
…1.000 more pets associated with p1 …
!insert (p1, pet1000) into Ownership
</object_model>

Output:

**Response**: Unrealistic
**Why**: The object 'p1' of class 'Person' has an age of 250, which exceeds the biologically plausible lifespan of a human. Although it is not plausible that 1 same person owns 1.000 pets.


Example 2:
Input:

<domain_model>
class Car
attributes
    brand: String
end
class Person
attributes
    name: String
end
association Ownership between
    Person [1] role owner
    Car [*] role cars
end
</domain_model>
<object_model>
!new Person('p1')
!p1.age := 19
!new Car('c1')
!c1.brand := 'Toyota'
!insert (p1, c1) into Ownership
</object_model>

Output:

**Response**: Realistic
**Why**: The object 'c1' has a valid, recognized real-world car brand assigned, and its plausible that a teenager has only one car.


Example 3:
Input:

<domain_model>
class Component
attributes
    setting_val: Integer
    config_mode: String
end
</domain_model>
<object_model>
!new Component('c1')
!c1.setting_val := 8080
!c1.config_mode := 'Legacy'
</object_model>

Output:

**Response**: Doubtful
**Why**: The class 'Component' and attribute 'setting_val' are generic and lack specific real-world semantic context. Without knowing what specific physical or software system this represents, it is impossible to determine if '8080' is a realistic value or an outlier.

</examples>

# Conceptual model description:
## Description
The Hotel Management model represents a system designed to manage hotel bookings and associated operations. The model includes various classes that represent key entities within the hotel management process, such as bookings, bills, customers, room reservations, and the rooms themselves. The purpose of this model is to streamline the tracking of hotel operations, including reservations, billing, and room management.

### Components
- **Booking**: Represents a hotel booking with attributes like `startDate` (String), `endDate` (String), `canceled` (Boolean), `bookingId` (Integer), and `confirmed` (Boolean), indicating booking details.
- **Bill**: Represents a financial transaction, containing a `price` (Real) and `billId` (Integer).
- **FreeRoomTypesDTO**: Contains details about available room types including `roomTypeDescription` (String), `numBeds` (Integer), `pricePerNight` (Real), and `numFreeRooms` (Integer).
- **Customer**: Represents a hotel guest with basic information, including `firstName` (String) and `lastName` (String).
- **RoomReservation**: Details about a room reservation with attributes `checkInDate` (String) and `checkOutDate` (String).
- **RoomExtra**: Represents additional services or items with `price` (Real) and `description` (String).
- **Room**: Provides details about a hotel room, including `numBeds` (Integer), `pricePerNight` (Real), `occupied` (Boolean), `blocked` (Boolean), and `roomNumber` (Integer).

## Relationships
- **BookingBill**: A Booking is associated with one or more Bills. Each Booking [1] can have zero or more Bills [0..*].
- **BookingCustomer**: A Booking is associated with exactly one Customer. Each Booking [1] is linked to exactly one Customer [1].
- **BookingRoomReservation**: A Booking can have multiple Room Reservations. Each Booking [1] is associated with zero or more Room Reservations [*].
- **RoomReservationExtras**: A Room Reservation can include multiple Room Extras. Each Room Reservation [1] is associated with zero or more Room Extras [*].
- **RoomReservationRoom**: A Room Reservation can involve multiple Rooms. Each Room Reservation [1] is associated with zero or more Rooms [*].
- **BillRoomReservation**: A Bill is associated with exactly one Room Reservation. Each Bill [1] is linked to exactly one Room Reservation [1].

## Invariants
- **positiveBill**: Ensures that the `price` attribute of a Bill is non-negative (`self.price >= 0`).
- **uniqueBillId**: Ensures that each Bill has a unique `billId` (`Bill.allInstances->isUnique(b | b.billId)`).
- **positiveNumBeds**: Ensures that each Room has a positive number of beds (`self.numBeds > 0`).

# Category: Edge Instances
Create an edge case instance. This is an instance that behaves within but at the limit of the expected behavior. This instance must focus on a scenario that is unusual or unlikely in real life but possible according to the syntax and semantics of the model. In terms of semantics, take into account constraints, multiplicities, and uncommon combinations of relationships and attributes.

Continue with the following description, creating the instance according to the syntax example and this specification: 
## Edge Case Instance: Extended Stay Booking During a Cultural Festival

### Description:
This instance represents an uncommon scenario where a long-term hotel booking coincides with a large cultural festival. The customer books the hotel room for an extended period, includes an exhaustive list of room extras, and accumulates a complex billing pattern. This creates multiple bills for ancillary services, showcasing both a high-value transaction and a culturally unique scenario.

### Entities and Relationships:

#### Booking:
- **Attributes**:
  - `startDate`: "20-10-2023"
  - `endDate`: "20-11-2023"
  - `canceled`: `False`
  - `bookingId`: 101
  - `confirmed`: `True`

#### Customer:
- **Attributes**:
  - `firstName`: "Lakshmi"
  - `lastName`: "Iyer"

#### RoomReservation:
1. **RoomReservation1**
   - **Attributes**:
     - `checkInDate`: "20-10-2023"
     - `checkOutDate`: "10-11-2023"
2. **RoomReservation2**
   - **Attributes**:
     - `checkInDate`: "10-11-2023"
     - `checkOutDate`: "20-11-2023"

#### Room:
1. **Room101**
   - **Attributes**:
     - `numBeds`: 2
     - `pricePerNight`: 150.00
     - `occupied`: `True`
     - `blocked`: `False`
     - `roomNumber`: 301

#### RoomExtra:
1. **Extra1** 
   - **Attributes**:
     - `price`: 50.00
     - `description`: "Daily Spa Access"
2. **Extra2**
   - **Attributes**:
     - `price`: 30.00
     - `description`: "Cultural Festival Tickets"
3. **Extra3**
   - **Attributes**:
     - `price`: 20.00
     - `description`: "Premium Breakfast"

#### Bill:
1. **Bill1**
   - **Attributes**:
     - `price`: 3200.00
     - `billId`: 501
2. **Bill2**
   - **Attributes**:
     - `price`: 600.00
     - `billId`: 502
3. **Bill3**
   - **Attributes**:
     - `price`: 200.00
     - `billId`: 503

### Relationships:

- **BookingCustomer**:
  - Booking ID 101 is associated with Customer "Lakshmi Iyer".

- **BookingRoomReservation**:
  - Booking ID 101 is linked to both RoomReservation1 and RoomReservation2.

- **BookingBill**:
  - Booking ID 101 has related bills: Bill1, Bill2, and Bill3.

- **RoomReservationExtras**:
  - RoomReservation1 includes Extra1 and Extra2.
  - RoomReservation2 includes Extra3.

- **RoomReservationRoom**:
  - RoomReservation1 involves Room101.
  - RoomReservation2 involves Room101 (for the extended stay).

- **BillRoomReservation**:
  - Bill1 is linked to RoomReservation1 (covering the first 21 days at standard room rate and some extras).
  - Bill2 is linked to RoomReservation2 (covering the remaining days alongside the final extra).
  - Bill3 is specifically for cultural festival-related expenses and unique meetings hosted at the hotel venue.

### Special Scenario Characteristics:
- The booking spans an entire month, during peak festival season.
- Multiple Room Reservations are combined to form a continuous stay strategy due to segmentation for billing purposes.
- Extraordinary number of extras are requested, reflecting cultural events and personal wellness options.
- Multiple bills exist to separate room charges from event-specific costs, highlighting comprehensive customer services.

This instance captures unique operations during a high-demand cultural period, confirming complex billing and reservation management under unusual, although technically valid, conditions.

The last output is partially incorrect: 
checking structure...
Multiplicity constraint violation in association `BillRoomReservation':
  Object `roomReservation5_1' of class `RoomReservation' is connected to 2 objects of class `Bill'
  at association end `bill' but the multiplicity is specified as `1'.
Multiplicity constraint violation in association `RoomReservationRoom':
  Object `room5_301' of class `Room' is connected to 2 objects of class `RoomReservation'
  at association end `roomReservation' but the multiplicity is specified as `1'.

Please provide the complete output corrected

The last output is partially incorrect: 
checking structure...
Multiplicity constraint violation in association `BillRoomReservation':
  Object `roomReservation5_2' of class `RoomReservation' is connected to 2 objects of class `Bill'
  at association end `bill' but the multiplicity is specified as `1'.
Multiplicity constraint violation in association `RoomReservationRoom':
  Object `room5_301' of class `Room' is connected to 2 objects of class `RoomReservation'
  at association end `roomReservation' but the multiplicity is specified as `1'.

Please provide the complete output corrected

<domain_model>
model HotelManagement

class Booking
attributes
    startDate : String
    endDate : String
    canceled : Boolean
    bookingId : Integer
    confirmed : Boolean
end

class Bill
attributes
    price : Real
    billId : Integer
end

class FreeRoomTypesDTO
attributes
    roomTypeDescription : String
    numBeds : Integer
    pricePerNight : Real
    numFreeRooms : Integer
end

class Customer
attributes
    firstName : String
    lastName : String
end

class RoomReservation
attributes
    checkInDate : String
    checkOutDate : String
end

class RoomExtra
attributes
    price : Real
    description : String
end

class Room
attributes
    numBeds : Integer
    pricePerNight : Real
    occupied : Boolean
    blocked : Boolean
    roomNumber : Integer
end

association BookingBill between
    Booking [1]
    Bill [0..*] role bills
end

association BookingCustomer between
    Booking [1]
    Customer [1] role customer
end

association BookingRoomReservation between
    Booking [1]
    RoomReservation [*] role roomReservations
end

association RoomReservationExtras between
    RoomReservation [1]
    RoomExtra [*] role roomExtras
end

association RoomReservationRoom between
    RoomReservation [1]
    Room [*] role room
end

association BillRoomReservation between
    Bill [1]
    RoomReservation [1] role roomReservation
end

constraints
context Bill inv positiveBill:
    self.price >= 0

context Bill inv uniqueBillId:
    Bill.allInstances->isUnique(b | b.billId)

context Room inv positiveNumBeds:
    self.numBeds > 0
</domain_model>

<object_model>
!new Customer('customer5')
!customer5.firstName := 'Lakshmi'
!customer5.lastName := 'Iyer'

!new Booking('booking5')
!booking5.startDate := '20-10-2023'
!booking5.endDate := '20-11-2023'
!booking5.canceled := false
!booking5.bookingId := 101
!booking5.confirmed := true

!new RoomReservation('roomReservation5_1')
!roomReservation5_1.checkInDate := '20-10-2023'
!roomReservation5_1.checkOutDate := '10-11-2023'

!new RoomReservation('roomReservation5_2')
!roomReservation5_2.checkInDate := '10-11-2023'
!roomReservation5_2.checkOutDate := '20-11-2023'

!new Room('room5_301')
!room5_301.numBeds := 2
!room5_301.pricePerNight := 150.00
!room5_301.occupied := true
!room5_301.blocked := false
!room5_301.roomNumber := 301

!new RoomExtra('extra5_1')
!extra5_1.price := 50.00
!extra5_1.description := 'Daily Spa Access'

!new RoomExtra('extra5_2')
!extra5_2.price := 30.00
!extra5_2.description := 'Cultural Festival Tickets'

!new RoomExtra('extra5_3')
!extra5_3.price := 20.00
!extra5_3.description := 'Premium Breakfast'

!new Bill('bill9')
!bill9.price := 3200.00
!bill9.billId := 501

!new Bill('bill10')
!bill10.price := 600.00
!bill10.billId := 502

!new Bill('bill11')
!bill11.price := 200.00
!bill11.billId := 503

!insert (booking5, customer5) into BookingCustomer

!insert (booking5, roomReservation5_1) into BookingRoomReservation
!insert (booking5, roomReservation5_2) into BookingRoomReservation

!insert (booking5, bill9) into BookingBill
!insert (booking5, bill10) into BookingBill
!insert (booking5, bill11) into BookingBill

!insert (roomReservation5_1, extra5_1) into RoomReservationExtras
!insert (roomReservation5_1, extra5_2) into RoomReservationExtras

!insert (roomReservation5_2, extra5_3) into RoomReservationExtras

!insert (bill9, roomReservation5_1) into BillRoomReservation
!insert (bill10, roomReservation5_2) into BillRoomReservation
!insert (bill11, roomReservation5_1) into BillRoomReservation

!new Room('room5_302')
!room5_302.numBeds := 2
!room5_302.pricePerNight := 150.00
!room5_302.occupied := true
!room5_302.blocked := false
!room5_302.roomNumber := 302

!insert (roomReservation5_1, room5_301) into RoomReservationRoom
!insert (roomReservation5_2, room5_302) into RoomReservationRoom
</object_model>

Your task is to generate a complete and diverse instance, in plain English, for a given category and based on a provided conceptual model description. The instance must adhere to these requirements: - Be self-contained: Include all required attributes, relationships, and related entities in full detail. - Conform to the model: Fulfill the constraints, multiplicities, relationships, and attributes defined in the class diagram model. - Understand the context: Ensure that its attributes and relationships are relevant. - Avoid duplication of instances: Take into consideration those instances previously built to avoid redundancy. - Semantic diversity: From a semantic point of view, incorporate varied scenarios, including regional, linguistic, or cultural differences. - Structural diversity: Include instances with different numbers of elements, different numbers of relationships and complexity, and create varied examples by changing entity attributes.

You are tasked with creating instances of a conceptual model in the UML-based Specification Environment (USE). You will receive: 1. The UML class diagram that the instance follows. 2. A sample syntax of instances creation. 3. A description of the instance that needs to be created.  Your goal is to generate these instances based on the provided description, adhering strictly to these requirements: - The output must be in plain text, with no additional comments, descriptions, or explanations. - Ensure that the created instance adheres to the provided description. - Follow the syntax sample provided, without deviation. - Take into account previously created instances to avoid using duplicate naming.

<role>
You are an expert software and system modeler. You are able to assess the semantic quality of object models that have been created to conform to a domain model. The models are defined in USE (UML-based Specification Environment) and OCL (Object Constraint Language).

Your primary capability is "Semantic Reality Checking". You do not just check for syntactic correctness; you check for real-world plausibility and logical consistency within a given domain.
</role>

<context>
The user will provide two types of content:
1. **Domain Model (.use)**: A class diagram definition including classes, attributes, enums, relationships, multiplicities and roles.
2. **Object Model (.soil)**: An object model. This object model can be seen as a script composed of instructions for the creation of objects, relationships and setting attribute values (snapshot).

Your goal is to act as a judge to determine if the object model represents a **REALISTIC** scenario based on the domain model and common sense real-world logic.
</context>

<definitions>
- **Realistic**: The object model is syntactically correct AND semantically plausible (e.g., A 'Person' has an age between 0 and 120; a 'Car' has a positive price).
- **Unrealistic**: The object model contains contradictions, impossible physical values, or nonsensical relationships (e.g., A 'Person' is their own father; a 'Product' has a negative weight).
- **Doubtful**: You cannot determine whether the object model is realistic or not.
</definitions>

<instructions>
Follow this thinking process strictly before generating the final output:

1. **Analyze the Domain (.use)**: Understand the classes and what they represent in the real world.
2. **Analyze the Instances (.soil)**: Map the created objects to their classes. Look at the specific values assigned to attributes and the relationships created between objects.
3. **Evaluate Semantics**:
    - Apply "Common Sense Knowledge" to the attribute values.
    - Check cardinality and relationship logic beyond simple OCL constraints.
    - Identify any outliers or logical fallacies.
4. **Determine Verdict**: Select one of the defined labels (Realistic/Unrealistic/Doubtful).
</instructions>

<constraints>
- **Tone**: Objective, Analytical, Technical.
- **Verbosity**: Low. Be direct.
- **Reasoning**: The "Why" section must be concise and specific, citing variable names, objects, or relationships when possible.
- Do not output the internal thinking process. Only output the final formatted result.
</constraints>

<output_format>
Structure your response exactly as follows:

**Response**: [Realistic | Unrealistic | Doubtful]
**Why**: [Concise explanation of your reasoning. If Unrealistic, specify the exact objects, values or relationships that break realism.]
</output_format>

<examples>
Example 1:
Input:

<domain_model>
class Person
attributes
    age: Integer
end
class Pet
attributes
    name: String
end
association Ownership between
    Person [1] role owner
    Pet [*] role pets
end
</domain_model>
<object_model>
!new Person('p1')
!p1.age := 250
!new Pet('pet1')
!pet1.name := 'Luna'
… 1.000 more pets creation …
!pet1000.name := 'Max'
!insert (p1, pet1) into Ownership
…1.000 more pets associated with p1 …
!insert (p1, pet1000) into Ownership
</object_model>

Output:

**Response**: Unrealistic
**Why**: The object 'p1' of class 'Person' has an age of 250, which exceeds the biologically plausible lifespan of a human. Although it is not plausible that 1 same person owns 1.000 pets.


Example 2:
Input:

<domain_model>
class Car
attributes
    brand: String
end
class Person
attributes
    name: String
end
association Ownership between
    Person [1] role owner
    Car [*] role cars
end
</domain_model>
<object_model>
!new Person('p1')
!p1.age := 19
!new Car('c1')
!c1.brand := 'Toyota'
!insert (p1, c1) into Ownership
</object_model>

Output:

**Response**: Realistic
**Why**: The object 'c1' has a valid, recognized real-world car brand assigned, and its plausible that a teenager has only one car.


Example 3:
Input:

<domain_model>
class Component
attributes
    setting_val: Integer
    config_mode: String
end
</domain_model>
<object_model>
!new Component('c1')
!c1.setting_val := 8080
!c1.config_mode := 'Legacy'
</object_model>

Output:

**Response**: Doubtful
**Why**: The class 'Component' and attribute 'setting_val' are generic and lack specific real-world semantic context. Without knowing what specific physical or software system this represents, it is impossible to determine if '8080' is a realistic value or an outlier.

</examples>

# Conceptual model description:
## Description
The Hotel Management model represents a system designed to manage hotel bookings and associated operations. The model includes various classes that represent key entities within the hotel management process, such as bookings, bills, customers, room reservations, and the rooms themselves. The purpose of this model is to streamline the tracking of hotel operations, including reservations, billing, and room management.

### Components
- **Booking**: Represents a hotel booking with attributes like `startDate` (String), `endDate` (String), `canceled` (Boolean), `bookingId` (Integer), and `confirmed` (Boolean), indicating booking details.
- **Bill**: Represents a financial transaction, containing a `price` (Real) and `billId` (Integer).
- **FreeRoomTypesDTO**: Contains details about available room types including `roomTypeDescription` (String), `numBeds` (Integer), `pricePerNight` (Real), and `numFreeRooms` (Integer).
- **Customer**: Represents a hotel guest with basic information, including `firstName` (String) and `lastName` (String).
- **RoomReservation**: Details about a room reservation with attributes `checkInDate` (String) and `checkOutDate` (String).
- **RoomExtra**: Represents additional services or items with `price` (Real) and `description` (String).
- **Room**: Provides details about a hotel room, including `numBeds` (Integer), `pricePerNight` (Real), `occupied` (Boolean), `blocked` (Boolean), and `roomNumber` (Integer).

## Relationships
- **BookingBill**: A Booking is associated with one or more Bills. Each Booking [1] can have zero or more Bills [0..*].
- **BookingCustomer**: A Booking is associated with exactly one Customer. Each Booking [1] is linked to exactly one Customer [1].
- **BookingRoomReservation**: A Booking can have multiple Room Reservations. Each Booking [1] is associated with zero or more Room Reservations [*].
- **RoomReservationExtras**: A Room Reservation can include multiple Room Extras. Each Room Reservation [1] is associated with zero or more Room Extras [*].
- **RoomReservationRoom**: A Room Reservation can involve multiple Rooms. Each Room Reservation [1] is associated with zero or more Rooms [*].
- **BillRoomReservation**: A Bill is associated with exactly one Room Reservation. Each Bill [1] is linked to exactly one Room Reservation [1].

## Invariants
- **positiveBill**: Ensures that the `price` attribute of a Bill is non-negative (`self.price >= 0`).
- **uniqueBillId**: Ensures that each Bill has a unique `billId` (`Bill.allInstances->isUnique(b | b.billId)`).
- **positiveNumBeds**: Ensures that each Room has a positive number of beds (`self.numBeds > 0`).

# Category: Overconstraint Detection
Create an instance that represents a real-life scenario that is logically valid but violates the model's multiplicities or constraints, exposing overly restrictive or unrealistic restrictions.

Continue with the following description, creating the instance according to the syntax example and this specification: 
## Instance: Overly Restrictive Booking Scenario

### Scenario Description:
A frequent hotel guest, Mrs. Lucia Fernández, plans a family vacation and tries to secure a group booking across multiple rooms in a coastal Spanish hotel. This leads to an issue when attempting to identify how many room reservations a single booking can encompass.

#### Booking
- **startDate**: "2023-07-15"
- **endDate**: "2023-07-21"
- **canceled**: False
- **bookingId**: 1001
- **confirmed**: True

#### Customer
- **firstName**: Lucia
- **lastName**: Fernández

#### RoomReservations (Attempt to make multiple reservations under a single booking)
- **RoomReservation 1**:
  - **checkInDate**: "2023-07-15"
  - **checkOutDate**: "2023-07-21"
  - **Associated Rooms**:
    - **Room 101**
    - **Room 102**

- **RoomReservation 2**:
  - **checkInDate**: "2023-07-15"
  - **checkOutDate**: "2023-07-21"
  - **Associated Rooms**:
    - **Room 201**
    - **Room 202**

- **RoomReservation 3**:
  - **checkInDate**: "2023-07-15"
  - **checkOutDate**: "2023-07-21"
  - **Associated Rooms**:
    - **Room 301**
    - **Room 302**

#### Bills
- **Bill 1** (linked to RoomReservation 1):
  - **price**: 2400.0
  - **billId**: 501
- **Bill 2** (linked to RoomReservation 2):
  - **price**: 2300.0
  - **billId**: 502
- **Bill 3** (linked to RoomReservation 3):
  - **price**: 2500.0
  - **billId**: 503

#### FreeRoomTypesDTO (For Reference)
- **roomTypeDescription**: "Family Suite"
- **numBeds**: 3
- **pricePerNight**: 200.0
- **numFreeRooms**: 2

#### Room
- **Room 101**:
  - **numBeds**: 2
  - **pricePerNight**: 150.0
  - **occupied**: True
  - **blocked**: False
  - **roomNumber**: 101
- **Room 102**:
  - **numBeds**: 2
  - **pricePerNight**: 150.0
  - **occupied**: True
  - **blocked**: False
  - **roomNumber**: 102

#### RoomExtra (Example linked extras for reservations)
- **RoomExtra 1**:
  - **price**: 50.0
  - **description**: "Breakfast Buffet"
- **RoomExtra 2**:
  - **price**: 30.0
  - **description**: "Parking Facility"

### Violation Note:
The attempt to include more than one RoomReservation per Booking logically fits scenarios such as group bookings or reservations for large families. However, the complexity here leads us to a conflict with practical management, where each booking could intuitively be expected to handle multiple reservations under a singular customer group, yet our current model constraints do not explicitly allow a single customer to handle multiple reservations efficiently.

<domain_model>
model HotelManagement

class Booking
attributes
    startDate : String
    endDate : String
    canceled : Boolean
    bookingId : Integer
    confirmed : Boolean
end

class Bill
attributes
    price : Real
    billId : Integer
end

class FreeRoomTypesDTO
attributes
    roomTypeDescription : String
    numBeds : Integer
    pricePerNight : Real
    numFreeRooms : Integer
end

class Customer
attributes
    firstName : String
    lastName : String
end

class RoomReservation
attributes
    checkInDate : String
    checkOutDate : String
end

class RoomExtra
attributes
    price : Real
    description : String
end

class Room
attributes
    numBeds : Integer
    pricePerNight : Real
    occupied : Boolean
    blocked : Boolean
    roomNumber : Integer
end

association BookingBill between
    Booking [1]
    Bill [0..*] role bills
end

association BookingCustomer between
    Booking [1]
    Customer [1] role customer
end

association BookingRoomReservation between
    Booking [1]
    RoomReservation [*] role roomReservations
end

association RoomReservationExtras between
    RoomReservation [1]
    RoomExtra [*] role roomExtras
end

association RoomReservationRoom between
    RoomReservation [1]
    Room [*] role room
end

association BillRoomReservation between
    Bill [1]
    RoomReservation [1] role roomReservation
end

constraints
context Bill inv positiveBill:
    self.price >= 0

context Bill inv uniqueBillId:
    Bill.allInstances->isUnique(b | b.billId)

context Room inv positiveNumBeds:
    self.numBeds > 0
</domain_model>

<object_model>
!new Customer('customer2')
!customer2.firstName := 'Lucia'
!customer2.lastName := 'Fernández'

!new Booking('booking2')
!booking2.startDate := '2023-07-15'
!booking2.endDate := '2023-07-21'
!booking2.canceled := false
!booking2.bookingId := 1001
!booking2.confirmed := true

!new RoomReservation('roomReservation2_1')
!roomReservation2_1.checkInDate := '2023-07-15'
!roomReservation2_1.checkOutDate := '2023-07-21'

!new RoomReservation('roomReservation2_2')
!roomReservation2_2.checkInDate := '2023-07-15'
!roomReservation2_2.checkOutDate := '2023-07-21'

!new RoomReservation('roomReservation2_3')
!roomReservation2_3.checkInDate := '2023-07-15'
!roomReservation2_3.checkOutDate := '2023-07-21'

!new Bill('bill3')
!bill3.price := 2400.0
!bill3.billId := 501

!new Bill('bill4')
!bill4.price := 2300.0
!bill4.billId := 502

!new Bill('bill5')
!bill5.price := 2500.0
!bill5.billId := 503

!new FreeRoomTypesDTO('freeRoomType2')
!freeRoomType2.roomTypeDescription := 'Family Suite'
!freeRoomType2.numBeds := 3
!freeRoomType2.pricePerNight := 200.0
!freeRoomType2.numFreeRooms := 2

!new Room('room2_101')
!room2_101.numBeds := 2
!room2_101.pricePerNight := 150.0
!room2_101.occupied := true
!room2_101.blocked := false
!room2_101.roomNumber := 101

!new Room('room2_102')
!room2_102.numBeds := 2
!room2_102.pricePerNight := 150.0
!room2_102.occupied := true
!room2_102.blocked := false
!room2_102.roomNumber := 102

!new Room('room2_201')
!room2_201.numBeds := 2
!room2_201.pricePerNight := 150.0
!room2_201.occupied := true
!room2_201.blocked := false
!room2_201.roomNumber := 201

!new Room('room2_202')
!room2_202.numBeds := 2
!room2_202.pricePerNight := 150.0
!room2_202.occupied := true
!room2_202.blocked := false
!room2_202.roomNumber := 202

!new Room('room2_301')
!room2_301.numBeds := 2
!room2_301.pricePerNight := 150.0
!room2_301.occupied := true
!room2_301.blocked := false
!room2_301.roomNumber := 301

!new Room('room2_302')
!room2_302.numBeds := 2
!room2_302.pricePerNight := 150.0
!room2_302.occupied := true
!room2_302.blocked := false
!room2_302.roomNumber := 302

!new RoomExtra('roomExtra3')
!roomExtra3.price := 50.0
!roomExtra3.description := 'Breakfast Buffet'

!new RoomExtra('roomExtra4')
!roomExtra4.price := 30.0
!roomExtra4.description := 'Parking Facility'

!insert (booking2, customer2) into BookingCustomer

!insert (booking2, roomReservation2_1) into BookingRoomReservation
!insert (booking2, roomReservation2_2) into BookingRoomReservation
!insert (booking2, roomReservation2_3) into BookingRoomReservation

!insert (roomReservation2_1, room2_101) into RoomReservationRoom
!insert (roomReservation2_1, room2_102) into RoomReservationRoom

!insert (roomReservation2_2, room2_201) into RoomReservationRoom
!insert (roomReservation2_2, room2_202) into RoomReservationRoom

!insert (roomReservation2_3, room2_301) into RoomReservationRoom
!insert (roomReservation2_3, room2_302) into RoomReservationRoom

!insert (roomReservation2_1, roomExtra3) into RoomReservationExtras
!insert (roomReservation2_1, roomExtra4) into RoomReservationExtras

!insert (roomReservation2_2, roomExtra3) into RoomReservationExtras
!insert (roomReservation2_2, roomExtra4) into RoomReservationExtras

!insert (roomReservation2_3, roomExtra3) into RoomReservationExtras
!insert (roomReservation2_3, roomExtra4) into RoomReservationExtras

!insert (bill3, roomReservation2_1) into BillRoomReservation
!insert (bill4, roomReservation2_2) into BillRoomReservation
!insert (bill5, roomReservation2_3) into BillRoomReservation
</object_model>