Bank / gen5

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>

For the same category and model description, generate another instance that is structurally and semantically different from the previous ones

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

### Entities

1. **Bank**
   - **Country**: India
   - **Name**: State Bank of India
   - **BIC**: SBININBBXXX

2. **Accounts**
   - **Account 1**
     - **IBAN**: IN4321098765432109876543210
     - **Balance**: 3000
   - **Account 2**
     - **IBAN**: IN5432109876543210987654321
     - **Balance**: 15000
   - **Account 3**
     - **IBAN**: IN6543210987654321098765432
     - **Balance**: 45000
   - **Account 4**
     - **IBAN**: IN7654321098765432109876543
     - **Balance**: 600
   - **Account 5**
     - **IBAN**: IN8765432109876543210987654
     - **Balance**: 12000
   - **Account 6**
     - **IBAN**: IN9876543210987654321098765
     - **Balance**: 85000

3. **Persons**
   - **Person 1**
     - **First Name**: Rohan
     - **Last Name**: Sharma
     - **Age**: 29
   - **Person 2**
     - **First Name**: Priya
     - **Last Name**: Kapoor
     - **Age**: 35
   - **Person 3**
     - **First Name**: Arjun
     - **Last Name**: Iyer
     - **Age**: 42
   - **Person 4**
     - **First Name**: Anjali
     - **Last Name**: Gupta
     - **Age**: 37
   - **Person 5**
     - **First Name**: Vivek
     - **Last Name**: Rao
     - **Age**: 31

### Relationships

1. **Ownership Association**
   - **Account 1** is owned by:
     - **Rohan Sharma**
   - **Account 2** is owned by:
     - **Priya Kapoor**
     - **Arjun Iyer**
   - **Account 3** is owned by:
     - **Anjali Gupta**
     - **Rohan Sharma**
   - **Account 4** is owned by:
     - **Vivek Rao**
   - **Account 5** is owned by:
     - **Priya Kapoor**
   - **Account 6** is owned by:
     - **Anjali Gupta**
     - **Vivek Rao**

2. **Use Association**
   - **Account 1** is used by:
     - **Rohan Sharma**
     - **Priya Kapoor**
   - **Account 2** is used by:
     - **Arjun Iyer**
     - **Anjali Gupta**
   - **Account 3** is used by:
     - **Rohan Sharma**
     - **Vivek Rao**
   - **Account 4** is used by:
     - **Vivek Rao**
   - **Account 5** is used by:
     - **Priya Kapoor**
     - **Anjali Gupta**
   - **Account 6** is used by:
     - **Anjali Gupta**
     - **Rohan Sharma**

3. **AccountOfBanks Composition**
   - **Account 1**, **Account 2**, **Account 3**, **Account 4**, **Account 5**, and **Account 6** are all associated with:
     - **State Bank of India**

### Notes

- This instance presents an Indian context, featuring typical Indian names and the country's largest bank, adding a different geographic and cultural dimension.
- Structurally, it is complex with six accounts and five individuals, offering a wide range of ownership and user scenarios, including both single and dual ownerships.
- The model adheres to all constraints: every account has non-negative balances, and all owners are of legal age.

<domain_model>
model BankAccount

class Bank
attributes
    country:String
    name:String
    bic:String
end

class Account
attributes
    iban: String
    balance : Integer
end

class Person
attributes
    firstName:String
    lastName:String
    age : Integer
end

association Ownership between
    Person [1..2] role owner
    Account [*] role accounts
end

association Use between
    Person [*] role user
    Account [*]
end

composition AccountOfBanks between
    Bank [1] role bank
    Account [*] role accounts
end

constraints
context Account inv AdultOwners:
    self.owner->forAll(p | p.age >= 18)
	
context Account inv positiveBalance:
    self.balance >= 0
</domain_model>

<object_model>
!new Bank('stateBankOfIndia')
!stateBankOfIndia.country := 'India'
!stateBankOfIndia.name := 'State Bank of India'
!stateBankOfIndia.bic := 'SBININBBXXX'

!new Account('account18_1')
!account18_1.iban := 'IN4321098765432109876543210'
!account18_1.balance := 3000

!new Account('account18_2')
!account18_2.iban := 'IN5432109876543210987654321'
!account18_2.balance := 15000

!new Account('account18_3')
!account18_3.iban := 'IN6543210987654321098765432'
!account18_3.balance := 45000

!new Account('account18_4')
!account18_4.iban := 'IN7654321098765432109876543'
!account18_4.balance := 600

!new Account('account18_5')
!account18_5.iban := 'IN8765432109876543210987654'
!account18_5.balance := 12000

!new Account('account18_6')
!account18_6.iban := 'IN9876543210987654321098765'
!account18_6.balance := 85000

!new Person('rohanSharma')
!rohanSharma.firstName := 'Rohan'
!rohanSharma.lastName := 'Sharma'
!rohanSharma.age := 29

!new Person('priyaKapoor')
!priyaKapoor.firstName := 'Priya'
!priyaKapoor.lastName := 'Kapoor'
!priyaKapoor.age := 35

!new Person('arjunIyer')
!arjunIyer.firstName := 'Arjun'
!arjunIyer.lastName := 'Iyer'
!arjunIyer.age := 42

!new Person('anjaliGupta')
!anjaliGupta.firstName := 'Anjali'
!anjaliGupta.lastName := 'Gupta'
!anjaliGupta.age := 37

!new Person('vivekRao')
!vivekRao.firstName := 'Vivek'
!vivekRao.lastName := 'Rao'
!vivekRao.age := 31

!insert (stateBankOfIndia, account18_1) into AccountOfBanks
!insert (stateBankOfIndia, account18_2) into AccountOfBanks
!insert (stateBankOfIndia, account18_3) into AccountOfBanks
!insert (stateBankOfIndia, account18_4) into AccountOfBanks
!insert (stateBankOfIndia, account18_5) into AccountOfBanks
!insert (stateBankOfIndia, account18_6) into AccountOfBanks

!insert (rohanSharma, account18_1) into Ownership

!insert (priyaKapoor, account18_2) into Ownership
!insert (arjunIyer, account18_2) into Ownership

!insert (anjaliGupta, account18_3) into Ownership
!insert (rohanSharma, account18_3) into Ownership

!insert (vivekRao, account18_4) into Ownership

!insert (priyaKapoor, account18_5) into Ownership

!insert (anjaliGupta, account18_6) into Ownership
!insert (vivekRao, account18_6) into Ownership

!insert (rohanSharma, account18_1) into Use
!insert (priyaKapoor, account18_1) into Use

!insert (arjunIyer, account18_2) into Use
!insert (anjaliGupta, account18_2) into Use

!insert (rohanSharma, account18_3) into Use
!insert (vivekRao, account18_3) into Use

!insert (vivekRao, account18_4) into Use

!insert (priyaKapoor, account18_5) into Use
!insert (anjaliGupta, account18_5) into Use

!insert (anjaliGupta, account18_6) into Use
!insert (rohanSharma, account18_6) into Use
</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>

For the same category and model description, generate another instance that is structurally and semantically different from the previous ones

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

In the historical and vibrant capital of Egypt, a reputable bank known as **"NileDelta Bank"** thrives by blending modern banking practices with regional traditions. Here are the details of NileDelta Bank:

- **Bank**:
  - `country`: "Egypt"
  - `name`: "NileDelta Bank"
  - `bic`: "NILDELBK001"

Within NileDelta Bank, there lies an account with a minimalistic approach to banking designed for everyday utilities and small transactions:

- **Account**:
  - `iban`: "EG64NILDB000000123456789045"
  - `balance`: 100 (An account primarily used for day-to-day expenditures and minor savings)

This account is owned by a single individual, focusing on singular management and individual banking needs, examining the boundaries of simplicity and essential banking:

1. **Person (Sole Owner)**:
   - `firstName`: "Amina"
   - `lastName`: "Hassan"
   - `age`: 22

Amina precisely embodies the requirement of adulthood, steering the account with independence, central to daily life expenses and learning financial management early in life.

Additionally, the account is actively used by a diverse group of non-owner users, reflecting extended family interactions and support typical in closely-knit communities:

2. **Person (User, not an owner)**:
   - `firstName`: "Youssef"
   - `lastName`: "Ali"
   - `age`: 23

3. **Person (User, not an owner)**:
   - `firstName`: "Sara"
   - `lastName`: "Mahmoud"
   - `age`: 21

Both Youssef and Sara, while not owning the account, contribute and engage through limited roles, showcasing flexibility and support among peers for everyday financial needs.

This scenario illustrates:
- A modest, personal account balance focused on essential spending.
- Sole ownership offering personal financial autonomy.
- Inclusion of peer support and usage, reflecting communal ties in financial practices integrating both personal independence and community assistance.

<domain_model>
model BankAccount

class Bank
attributes
    country:String
    name:String
    bic:String
end

class Account
attributes
    iban: String
    balance : Integer
end

class Person
attributes
    firstName:String
    lastName:String
    age : Integer
end

association Ownership between
    Person [1..2] role owner
    Account [*] role accounts
end

association Use between
    Person [*] role user
    Account [*]
end

composition AccountOfBanks between
    Bank [1] role bank
    Account [*] role accounts
end

constraints
context Account inv AdultOwners:
    self.owner->forAll(p | p.age >= 18)
	
context Account inv positiveBalance:
    self.balance >= 0
</domain_model>

<object_model>
!new Bank('nileDeltaBank')
!nileDeltaBank.country := 'Egypt'
!nileDeltaBank.name := 'NileDelta Bank'
!nileDeltaBank.bic := 'NILDELBK001'

!new Account('account21')
!account21.iban := 'EG64NILDB000000123456789045'
!account21.balance := 100

!new Person('aminaHassan')
!aminaHassan.firstName := 'Amina'
!aminaHassan.lastName := 'Hassan'
!aminaHassan.age := 22

!new Person('youssefAli')
!youssefAli.firstName := 'Youssef'
!youssefAli.lastName := 'Ali'
!youssefAli.age := 23

!new Person('saraMahmoud')
!saraMahmoud.firstName := 'Sara'
!saraMahmoud.lastName := 'Mahmoud'
!saraMahmoud.age := 21

!insert (nileDeltaBank, account21) into AccountOfBanks

!insert (aminaHassan, account21) into Ownership

!insert (aminaHassan, account21) into Use
!insert (youssefAli, account21) into Use
!insert (saraMahmoud, account21) into Use
</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>

For the same category and model description, generate another instance that is structurally and semantically different from the previous ones

Continue with the following description, creating the instance according to the syntax example and this specification: 
### Complex Instance: An Eastern European and Middle Eastern Banking Scenario

#### Banks
1. **Bank1:**
   - **Country:** Poland
   - **Name:** Warszawski Bank
   - **BIC:** WBPL10456

2. **Bank2:**
   - **Country:** United Arab Emirates
   - **Name:** Emirates Finance Corporation
   - **BIC:** EFUAE67890

#### Persons
1. **Person1:**
   - **First Name:** Katarzyna
   - **Last Name:** Nowak
   - **Age:** 38

2. **Person2:**
   - **First Name:** Abdul
   - **Last Name:** Al-Farsi
   - **Age:** 45

3. **Person3:**
   - **First Name:** Lech
   - **Last Name:** Mazur
   - **Age:** 53

4. **Person4:**
   - **First Name:** Fatima
   - **Last Name:** Khan
   - **Age:** 31

5. **Person5:**
   - **First Name:** Zofia
   - **Last Name:** Kwiatkowska
   - **Age:** 50

#### Accounts
1. **Account1:**
   - **IBAN:** PL9088776655A
   - **Balance:** 4500
   - **Bank:** Warszawski Bank
   - **Owners:** Katarzyna Nowak
   - **Users:** Katarzyna Nowak, Lech Mazur

2. **Account2:**
   - **IBAN:** AE4455667788B
   - **Balance:** 9100
   - **Bank:** Emirates Finance Corporation
   - **Owners:** Abdul Al-Farsi
   - **Users:** Abdul Al-Farsi, Fatima Khan

3. **Account3:**
   - **IBAN:** PL3322110044C
   - **Balance:** 12000
   - **Bank:** Warszawski Bank
   - **Owners:** Lech Mazur, Zofia Kwiatkowska
   - **Users:** Lech Mazur, Zofia Kwiatkowska, Katarzyna Nowak

4. **Account4:**
   - **IBAN:** AE9988776644D
   - **Balance:** 2500
   - **Bank:** Emirates Finance Corporation
   - **Owners:** Fatima Khan, Abdul Al-Farsi
   - **Users:** Fatima Khan

5. **Account5:**
   - **IBAN:** PL6677889900E
   - **Balance:** 0
   - **Bank:** Warszawski Bank
   - **Owners:** Katarzyna Nowak, Lech Mazur
   - **Users:** Katarzyna Nowak

#### Description
- **Warszawski Bank** in Poland and **Emirates Finance Corporation** in the UAE provide significant banking services to their respective regions, with a focus on both personal and commercial financial needs.
- **Katarzyna Nowak** keeps an account with a considerable balance at Warszawski Bank, which also benefits **Lech Mazur** through shared financial activities, suggesting cooperative investment or familial support.
- **Abdul Al-Farsi** commands a well-funded account with Emirates Finance Corporation, shared with **Fatima Khan**, indicating regional investment interests or business collaborations typical in the UAE's financial environment.
- **Lech Mazur** and **Zofia Kwiatkowska** co-manage a high-value account at Warszawski Bank, involving **Katarzyna Nowak** as a user, showcasing cross-utilization for personal investments or collective family funds.
- **Fatima Khan** and **Abdul Al-Farsi** share a joint account with Emirates Finance Corporation, a common practice in the Middle East for managing family finances or co-owned business revenue.
- **Katarzyna Nowak** and **Lech Mazur** collectively own a dormant account at Warszawski Bank, indicating potential future financial plans or reserved funds awaiting activation.

This scenario typifies financial behavior in Eastern Europe and the Middle East, emphasizing individual and communal financial strategies, with joint accounts supporting both personal and entrepreneurial aspirations across culturally diverse communities.

<domain_model>
model BankAccount

class Bank
attributes
    country:String
    name:String
    bic:String
end

class Account
attributes
    iban: String
    balance : Integer
end

class Person
attributes
    firstName:String
    lastName:String
    age : Integer
end

association Ownership between
    Person [1..2] role owner
    Account [*] role accounts
end

association Use between
    Person [*] role user
    Account [*]
end

composition AccountOfBanks between
    Bank [1] role bank
    Account [*] role accounts
end

constraints
context Account inv AdultOwners:
    self.owner->forAll(p | p.age >= 18)
	
context Account inv positiveBalance:
    self.balance >= 0
</domain_model>

<object_model>
!new Bank('warszawskiBank')
!warszawskiBank.country := 'Poland'
!warszawskiBank.name := 'Warszawski Bank'
!warszawskiBank.bic := 'WBPL10456'

!new Bank('emiratesFinanceCorp')
!emiratesFinanceCorp.country := 'United Arab Emirates'
!emiratesFinanceCorp.name := 'Emirates Finance Corporation'
!emiratesFinanceCorp.bic := 'EFUAE67890'

!new Person('katarzynaNowak')
!katarzynaNowak.firstName := 'Katarzyna'
!katarzynaNowak.lastName := 'Nowak'
!katarzynaNowak.age := 38

!new Person('abdulAlFarsi')
!abdulAlFarsi.firstName := 'Abdul'
!abdulAlFarsi.lastName := 'Al-Farsi'
!abdulAlFarsi.age := 45

!new Person('lechMazur')
!lechMazur.firstName := 'Lech'
!lechMazur.lastName := 'Mazur'
!lechMazur.age := 53

!new Person('fatimaKhan')
!fatimaKhan.firstName := 'Fatima'
!fatimaKhan.lastName := 'Khan'
!fatimaKhan.age := 31

!new Person('zofiaKwiatkowska')
!zofiaKwiatkowska.firstName := 'Zofia'
!zofiaKwiatkowska.lastName := 'Kwiatkowska'
!zofiaKwiatkowska.age := 50

!new Account('account28_1')
!account28_1.iban := 'PL9088776655A'
!account28_1.balance := 4500

!new Account('account28_2')
!account28_2.iban := 'AE4455667788B'
!account28_2.balance := 9100

!new Account('account28_3')
!account28_3.iban := 'PL3322110044C'
!account28_3.balance := 12000

!new Account('account28_4')
!account28_4.iban := 'AE9988776644D'
!account28_4.balance := 2500

!new Account('account28_5')
!account28_5.iban := 'PL6677889900E'
!account28_5.balance := 0

!insert (warszawskiBank, account28_1) into AccountOfBanks
!insert (emiratesFinanceCorp, account28_2) into AccountOfBanks
!insert (warszawskiBank, account28_3) into AccountOfBanks
!insert (emiratesFinanceCorp, account28_4) into AccountOfBanks
!insert (warszawskiBank, account28_5) into AccountOfBanks

!insert (katarzynaNowak, account28_1) into Ownership

!insert (abdulAlFarsi, account28_2) into Ownership

!insert (lechMazur, account28_3) into Ownership
!insert (zofiaKwiatkowska, account28_3) into Ownership

!insert (fatimaKhan, account28_4) into Ownership
!insert (abdulAlFarsi, account28_4) into Ownership

!insert (katarzynaNowak, account28_5) into Ownership
!insert (lechMazur, account28_5) into Ownership

!insert (katarzynaNowak, account28_1) into Use
!insert (lechMazur, account28_1) into Use

!insert (abdulAlFarsi, account28_2) into Use
!insert (fatimaKhan, account28_2) into Use

!insert (lechMazur, account28_3) into Use
!insert (zofiaKwiatkowska, account28_3) into Use
!insert (katarzynaNowak, account28_3) into Use

!insert (fatimaKhan, account28_4) into Use

!insert (katarzynaNowak, account28_5) into Use
</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>

For the same category and model description, generate another instance that is structurally and semantically different from the previous ones

Continue with the following description, creating the instance according to the syntax example and this specification: 
**Instance: Digital Nomad Group Portfolio Management**

### Entities

- **Bank:**
  - `country`: Estonia
  - `name`: Baltic Digital Bank
  - `bic`: BALTETEE01

- **Person:**
  - `firstName`: Erik
  - `lastName`: Savisaar
  - `age`: 38

- **Person:**
  - `firstName`: Katarina
  - `lastName`: Petrov
  - `age`: 29

- **Person:**
  - `firstName`: Miguel
  - `lastName`: Alvarez
  - `age`: 42

- **Account:**
  - `iban`: EE98-7654-3212-0004
  - `balance`: 200_000

- **Account:**
  - `iban`: EE12-3456-7890-5678
  - `balance`: 3_500

- **Account:**
  - `iban`: EE34-5678-9012-7890
  - `balance`: 15_000

### Relationships

- **Ownership Association:**
  - **Account EE98-7654-3212-0004**:
    - Owners: Erik Savisaar, Katarina Petrov, Miguel Alvarez (A collective investment account managed by three entrepreneurial digital nomads pooling their resources to manage a diverse investment portfolio across industries.)

- **Ownership Association:**
  - **Account EE12-3456-7890-5678**:
    - Owners: Katarina Petrov (An individual account for Katarina to manage daily expenses related to her freelance work and travel.)

- **Ownership Association:**
  - **Account EE34-5678-9012-7890**:
    - Owners: Miguel Alvarez (A separate account to handle income from consultancy work across Europe, maintaining financial solvency while on the move.)

- **Use Association:**
  - **Account EE98-7654-3212-0004**:
    - Users: Erik Savisaar, Katarina Petrov, Miguel Alvarez (All owners actively engage in decision-making for strategic investment choices and funds allocation, reflecting their collaborative dynamic.)

- **Use Association:**
  - **Account EE12-3456-7890-5678**:
    - Users: Erik Savisaar (Erik assists Katarina with financial advisory to maximize her expense management while ensuring her ventures remain profitable.)

- **Use Association:**
  - **Account EE34-5678-9012-7890**:
    - Users: Katarina Petrov (Katarina supports Miguel in bookkeeping and documenting financial interactions to ensure compliant reporting and fiscal health.)

- **AccountOfBanks Composition:**
  - **Baltic Digital Bank:**
    - Accounts: EE98-7654-3212-0004, EE12-3456-7890-5678, EE34-5678-9012-7890

### Explanation

This edge case features a unique setup tailored to the lifestyle of digital nomads focusing on flexibility, independence, and global connectivity:

- The core account EE98-7654-3212-0004, collaboratively owned by all three professionals, emphasizes a modern investment model where like-minded individuals unite their financial strength to leverage investment opportunities, harnessing geo-independent earnings for collective growth.

- Individual accounts EE12-3456-7890-5678 and EE34-5678-9012-7890 reflect the personal financial strategies of Katarina and Miguel, possessing distinct sources of income, from freelance projects to consultancy engagements, which sustain their nomadic needs.

- The dynamic of shared engagement in their joint financial ventures highlights the self-governing, democratic approach to financial management among the group, with roles that balance individual and collaborative interests.

- Use associations cross-pollinate knowledge between experts, enabling cross-support on fiscal strategies and practices outside each person’s core expertise, benefiting from collective intellect while nurturing personal advancement. 

This instance encapsulates a non-traditional financial structure, perfectly suited to the versatility and agility required by digital nomads, emphasizing cooperative growth, individual pursuits, and efficient resource management in a globally connected profession.

The last output is partially incorrect: 
checking structure...
Multiplicity constraint violation in association `Ownership':
  Object `account27_1' of class `Account' is connected to 3 objects of class `Person'
  at association end `owner' but the multiplicity is specified as `1..2'.

Please provide the complete output corrected

<domain_model>
model BankAccount

class Bank
attributes
    country:String
    name:String
    bic:String
end

class Account
attributes
    iban: String
    balance : Integer
end

class Person
attributes
    firstName:String
    lastName:String
    age : Integer
end

association Ownership between
    Person [1..2] role owner
    Account [*] role accounts
end

association Use between
    Person [*] role user
    Account [*]
end

composition AccountOfBanks between
    Bank [1] role bank
    Account [*] role accounts
end

constraints
context Account inv AdultOwners:
    self.owner->forAll(p | p.age >= 18)
	
context Account inv positiveBalance:
    self.balance >= 0
</domain_model>

<object_model>
!new Bank('balticDigitalBank')
!balticDigitalBank.country := 'Estonia'
!balticDigitalBank.name := 'Baltic Digital Bank'
!balticDigitalBank.bic := 'BALTETEE01'

!new Account('account27_1')
!account27_1.iban := 'EE98-7654-3212-0004'
!account27_1.balance := 200000

!new Account('account27_2')
!account27_2.iban := 'EE12-3456-7890-5678'
!account27_2.balance := 3500

!new Account('account27_3')
!account27_3.iban := 'EE34-5678-9012-7890'
!account27_3.balance := 15000

!new Person('erikSavisaar')
!erikSavisaar.firstName := 'Erik'
!erikSavisaar.lastName := 'Savisaar'
!erikSavisaar.age := 38

!new Person('katarinaPetrov')
!katarinaPetrov.firstName := 'Katarina'
!katarinaPetrov.lastName := 'Petrov'
!katarinaPetrov.age := 29

!new Person('miguelAlvarez')
!miguelAlvarez.firstName := 'Miguel'
!miguelAlvarez.lastName := 'Alvarez'
!miguelAlvarez.age := 42

!insert (balticDigitalBank, account27_1) into AccountOfBanks
!insert (balticDigitalBank, account27_2) into AccountOfBanks
!insert (balticDigitalBank, account27_3) into AccountOfBanks

!insert (erikSavisaar, account27_1) into Ownership
!insert (katarinaPetrov, account27_1) into Ownership

!insert (katarinaPetrov, account27_2) into Ownership

!insert (miguelAlvarez, account27_3) into Ownership

!insert (erikSavisaar, account27_1) into Use
!insert (katarinaPetrov, account27_1) into Use
!insert (miguelAlvarez, account27_1) into Use

!insert (erikSavisaar, account27_2) into Use

!insert (katarinaPetrov, account27_3) into Use
</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>

For the same category and model description, generate another instance that is structurally and semantically different from the previous ones

Continue with the following description, creating the instance according to the syntax example and this specification: 
## Scenario: Non-Profit Organization with Volunteer Access

### Banks
- **Bank Cooperative**
  - `country`: "Kenya"
  - `name`: "Unity Cooperative Bank"
  - `bic`: "UCBKE44"

### Persons
- **Person N**
  - `firstName`: "Amina"
  - `lastName`: "Kareem"
  - `age`: 52

- **Person O**
  - `firstName`: "Victor"
  - `lastName`: "Mwangi"
  - `age`: 47

- **Person P**
  - `firstName`: "Grace"
  - `lastName`: "Achola"
  - `age`: 30

- **Person Q**
  - `firstName`: "Elijah"
  - `lastName`: "Wanjiku"
  - `age`: 32

### Accounts

#### Account 9
- **Details**:
  - `iban`: "KE74 5678 1234 0001"
  - `balance`: 5000
- **Bank Association**:
  - Associated with **Bank Cooperative**
- **Ownership**:
  - Owned by **Person N** and **Person O**
- **Use**:
  - Used by **Person N**, **Person O**, **Person P**, and **Person Q**

#### Account 10
- **Details**:
  - `iban`: "KE55 2345 6789 0012"
  - `balance`: 7500
- **Bank Association**:
  - Associated with **Bank Cooperative**
- **Ownership**:
  - Owned by **Person N**
- **Use**:
  - Used exclusively by **Person N**

### Violations & Overconstraints

1. **High User Count in Account 9**:
   - Account 9 is accessed by four individuals, including volunteers and organizers, reflecting typical non-profit fund management challenges where flexibility is necessary for operational logistics. The model’s strict user boundary could inadequately represent such diverse participative scenarios, indicating overconstraint in actual user multiplicity or responsibilities.

2. **Single Owner Limitation in Account 10**:
   - Owned singly by **Person N**, Account 10 highlights situations where singular ownership oversimplifies ownership dynamics of major accounts, especially in organizations that may need collective decision-making authority, pointing out lack of support for nested authorizations or collective ownership structures beyond two.

3. **Volunteer Access Representation**:
   - Account 9 models access by personnel beyond official owners, relevant in real-world non-profit operations where volunteer engagement is critical. While permissible, limited awareness of access diversity may present information and decision divergences overlooked by current composition rules and owner restrictions.

This instance captures the unique needs of non-profit organizations with various stakeholders requiring access to resources. It reveals challenges in capturing the flexibility required in financial systems supporting altruistic operations through volunteer coordination and evolving management practices, along with intricate access and ownership layers.

<domain_model>
model BankAccount

class Bank
attributes
    country:String
    name:String
    bic:String
end

class Account
attributes
    iban: String
    balance : Integer
end

class Person
attributes
    firstName:String
    lastName:String
    age : Integer
end

association Ownership between
    Person [1..2] role owner
    Account [*] role accounts
end

association Use between
    Person [*] role user
    Account [*]
end

composition AccountOfBanks between
    Bank [1] role bank
    Account [*] role accounts
end

constraints
context Account inv AdultOwners:
    self.owner->forAll(p | p.age >= 18)
	
context Account inv positiveBalance:
    self.balance >= 0
</domain_model>

<object_model>
!new Bank('unityCooperativeBank')
!unityCooperativeBank.country := 'Kenya'
!unityCooperativeBank.name := 'Unity Cooperative Bank'
!unityCooperativeBank.bic := 'UCBKE44'

!new Account('account23_9')
!account23_9.iban := 'KE74 5678 1234 0001'
!account23_9.balance := 5000

!new Account('account23_10')
!account23_10.iban := 'KE55 2345 6789 0012'
!account23_10.balance := 7500

!new Person('aminaKareem')
!aminaKareem.firstName := 'Amina'
!aminaKareem.lastName := 'Kareem'
!aminaKareem.age := 52

!new Person('victorMwangi')
!victorMwangi.firstName := 'Victor'
!victorMwangi.lastName := 'Mwangi'
!victorMwangi.age := 47

!new Person('graceAchola')
!graceAchola.firstName := 'Grace'
!graceAchola.lastName := 'Achola'
!graceAchola.age := 30

!new Person('elijahWanjiku')
!elijahWanjiku.firstName := 'Elijah'
!elijahWanjiku.lastName := 'Wanjiku'
!elijahWanjiku.age := 32

!insert (unityCooperativeBank, account23_9) into AccountOfBanks
!insert (unityCooperativeBank, account23_10) into AccountOfBanks

!insert (aminaKareem, account23_9) into Ownership
!insert (victorMwangi, account23_9) into Ownership

!insert (aminaKareem, account23_10) into Ownership

!insert (aminaKareem, account23_9) into Use
!insert (victorMwangi, account23_9) into Use
!insert (graceAchola, account23_9) into Use
!insert (elijahWanjiku, account23_9) into Use

!insert (aminaKareem, account23_10) into Use
</object_model>