Bank / gen3

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**: Brazil
   - **Name**: Banco do Brasil
   - **BIC**: BRASBRRJXXX

2. **Accounts**
   - **Account 1**
     - **IBAN**: BR1500000000001110000123456C1
     - **Balance**: 7500
   - **Account 2**
     - **IBAN**: BR1500000000002220000234567C2
     - **Balance**: 18000
   - **Account 3**
     - **IBAN**: BR1500000000003330000345678C3
     - **Balance**: 2500

3. **Persons**
   - **Person 1**
     - **First Name**: Thiago
     - **Last Name**: Almeida
     - **Age**: 45
   - **Person 2**
     - **First Name**: Marina
     - **Last Name**: Costa
     - **Age**: 24
   - **Person 3**
     - **First Name**: Carlos
     - **Last Name**: Silva
     - **Age**: 50
   - **Person 4**
     - **First Name**: Larissa
     - **Last Name**: Mendes
     - **Age**: 33
   - **Person 5**
     - **First Name**: Juliana
     - **Last Name**: Santos
     - **Age**: 27

### Relationships

1. **Ownership Association**
   - **Account 1** is owned by:
     - **Thiago Almeida**
     - **Larissa Mendes**
   - **Account 2** is owned by:
     - **Carlos Silva**
     - **Marina Costa**
   - **Account 3** is owned by:
     - **Juliana Santos**

2. **Use Association**
   - **Account 1** is used by:
     - **Thiago Almeida**
     - **Larissa Mendes**
     - **Marina Costa**
   - **Account 2** is used by:
     - **Carlos Silva**
     - **Thiago Almeida**
   - **Account 3** is used by:
     - **Juliana Santos**
     - **Larissa Mendes**
     - **Carlos Silva**

3. **AccountOfBanks Composition**
   - **Account 1**, **Account 2**, and **Account 3** are all associated with:
     - **Banco do Brasil**

### Notes

- This instance showcases a Brazilian setting, incorporating cultural relevance with common Brazilian names and one of Brazil's prominent banks.
- Structurally, it presents a scenario with different patterns of ownership and usage. Additionally, there is one account with only a single owner and used by multiple persons, reflecting real-world complexity.
- It ensures all constraints are met, with account owners all over the age of 18 and no accounts having a negative balance.

<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('bancoDoBrasil')
!bancoDoBrasil.country := 'Brazil'
!bancoDoBrasil.name := 'Banco do Brasil'
!bancoDoBrasil.bic := 'BRASBRRJXXX'

!new Account('account9_1')
!account9_1.iban := 'BR1500000000001110000123456C1'
!account9_1.balance := 7500

!new Account('account9_2')
!account9_2.iban := 'BR1500000000002220000234567C2'
!account9_2.balance := 18000

!new Account('account9_3')
!account9_3.iban := 'BR1500000000003330000345678C3'
!account9_3.balance := 2500

!new Person('thiagoAlmeida')
!thiagoAlmeida.firstName := 'Thiago'
!thiagoAlmeida.lastName := 'Almeida'
!thiagoAlmeida.age := 45

!new Person('marinaCosta')
!marinaCosta.firstName := 'Marina'
!marinaCosta.lastName := 'Costa'
!marinaCosta.age := 24

!new Person('carlosSilva')
!carlosSilva.firstName := 'Carlos'
!carlosSilva.lastName := 'Silva'
!carlosSilva.age := 50

!new Person('larissaMendes')
!larissaMendes.firstName := 'Larissa'
!larissaMendes.lastName := 'Mendes'
!larissaMendes.age := 33

!new Person('julianaSantos')
!julianaSantos.firstName := 'Juliana'
!julianaSantos.lastName := 'Santos'
!julianaSantos.age := 27

!insert (bancoDoBrasil, account9_1) into AccountOfBanks
!insert (bancoDoBrasil, account9_2) into AccountOfBanks
!insert (bancoDoBrasil, account9_3) into AccountOfBanks

!insert (thiagoAlmeida, account9_1) into Ownership
!insert (larissaMendes, account9_1) into Ownership

!insert (carlosSilva, account9_2) into Ownership
!insert (marinaCosta, account9_2) into Ownership

!insert (julianaSantos, account9_3) into Ownership

!insert (thiagoAlmeida, account9_1) into Use
!insert (larissaMendes, account9_1) into Use
!insert (marinaCosta, account9_1) into Use

!insert (carlosSilva, account9_2) into Use
!insert (thiagoAlmeida, account9_2) into Use

!insert (julianaSantos, account9_3) into Use
!insert (larissaMendes, account9_3) into Use
!insert (carlosSilva, account9_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: 
**Instance Description:**

In bustling Mumbai, a large, multinational bank named **"GlobalTrust Bank"** operates with a commitment to innovation and customer satisfaction. The specifics of this financial institution are:

- **Bank**:
  - `country`: "India"
  - `name`: "GlobalTrust Bank"
  - `bic`: "GLTRINBB001"

At the forefront of their customer offerings, GlobalTrust Bank manages a joint savings account featuring the minimum positive balance allowed by the model, highlighting the lower threshold of financial engagement:

- **Account**:
  - `iban`: "IN75TEST0000012345678901"
  - `balance`: 1 (This account is meant for basic transactions and shared saving goals)

This account is managed by its two equal owners, illustrating the collaborative ownership possible within the system:

1. **Person (Owner 1)**:
   - `firstName`: "Neha"
   - `lastName`: "Sharma"
   - `age`: 28

2. **Person (Owner 2)**:
   - `firstName`: "Arvind"
   - `lastName`: "Kumar"
   - `age`: 32

Both Neha and Arvind fulfill the age constraint, ensuring mature management and utilization of the joint account aimed towards familial use and planning.

The account also functions as a hub for several family members to interact with, though they are not owners, which illustrates an expanded user scenario without infringing on ownership multiplicities:

3. **Person (User, not an owner)**:
   - `firstName`: "Rohit"
   - `lastName`: "Sharma"
   - `age`: 19

4. **Person (User, not an owner)**:
   - `firstName`: "Priya"
   - `lastName`: "Kumar"
   - `age`: 22

Featuring Rohit and Priya as younger users, this account presents an educational platform for financial literacy within the family, where access and control are appropriately distinguished between ownership and usage.

This instance demonstrates:
- Minimal positive balance exemplifying boundary financial status.
- Maximum ownership within a cooperative family framework.
- Additional non-owner involvement illustrating educational and utilitarian account functions.

<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('globalTrustBank')
!globalTrustBank.country := 'India'
!globalTrustBank.name := 'GlobalTrust Bank'
!globalTrustBank.bic := 'GLTRINBB001'

!new Account('account12')
!account12.iban := 'IN75TEST0000012345678901'
!account12.balance := 1

!new Person('nehaSharma')
!nehaSharma.firstName := 'Neha'
!nehaSharma.lastName := 'Sharma'
!nehaSharma.age := 28

!new Person('arvindKumar')
!arvindKumar.firstName := 'Arvind'
!arvindKumar.lastName := 'Kumar'
!arvindKumar.age := 32

!new Person('rohitSharma')
!rohitSharma.firstName := 'Rohit'
!rohitSharma.lastName := 'Sharma'
!rohitSharma.age := 19

!new Person('priyaKumar')
!priyaKumar.firstName := 'Priya'
!priyaKumar.lastName := 'Kumar'
!priyaKumar.age := 22

!insert (globalTrustBank, account12) into AccountOfBanks

!insert (nehaSharma, account12) into Ownership
!insert (arvindKumar, account12) into Ownership

!insert (nehaSharma, account12) into Use
!insert (arvindKumar, account12) into Use
!insert (rohitSharma, account12) into Use
!insert (priyaKumar, account12) 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: A South American and Asian Banking Scenario

#### Banks
1. **Bank1:**
   - **Country:** Brazil
   - **Name:** Banco do Brasil
   - **BIC:** BBRA00012

2. **Bank2:**
   - **Country:** India
   - **Name:** Bharat Bank
   - **BIC:** BHIN67234

#### Persons
1. **Person1:**
   - **First Name:** Carlos
   - **Last Name:** Oliveira
   - **Age:** 23

2. **Person2:**
   - **First Name:** Priya
   - **Last Name:** Sharma
   - **Age:** 36

3. **Person3:**
   - **First Name:** Vinicius
   - **Last Name:** Fernandez
   - **Age:** 40

4. **Person4:**
   - **First Name:** Aditi
   - **Last Name:** Gupta
   - **Age:** 29

5. **Person5:**
   - **First Name:** Anil
   - **Last Name:** Kapoor
   - **Age:** 48

#### Accounts
1. **Account1:**
   - **IBAN:** BR0011223344I
   - **Balance:** 800
   - **Bank:** Banco do Brasil
   - **Owners:** Carlos Oliveira
   - **Users:** Carlos Oliveira, Vinicius Fernandez

2. **Account2:**
   - **IBAN:** IN8765432109J
   - **Balance:** 2500
   - **Bank:** Bharat Bank
   - **Owners:** Priya Sharma
   - **Users:** Priya Sharma, Anil Kapoor

3. **Account3:**
   - **IBAN:** BR5566778899K
   - **Balance:** 5000
   - **Bank:** Banco do Brasil
   - **Owners:** Vinicius Fernandez
   - **Users:** Vinicius Fernandez, Carlos Oliveira, Aditi Gupta

4. **Account4:**
   - **IBAN:** IN1098765432L
   - **Balance:** 3000
   - **Bank:** Bharat Bank
   - **Owners:** Aditi Gupta, Anil Kapoor
   - **Users:** Aditi Gupta, Priya Sharma

#### Description
- **Banco do Brasil** and **Bharat Bank** are key financial institutions in Brazil and India, respectively, supporting diverse customer bases and financial ecosystems.
- **Carlos Oliveira**, though one of the younger account holders, manages a modest account with Banco do Brasil, illustrating early financial independence and the assistance of **Vinicius Fernandez**, who potentially acts as a mentor or family support.
- **Priya Sharma** alone owns a savings account with Bharat Bank, indicating a focus on personal finance and wealth accumulation, with **Anil Kapoor** having use access, likely for collaborative financial planning purposes.
- **Vinicius Fernandez** maintains an individual high-balance account at Banco do Brasil, used by **Carlos Oliveira** and **Aditi Gupta**, signaling potentially shared interests in investment or partnership business ventures.
- **Aditi Gupta** and **Anil Kapoor** co-own an account at Bharat Bank, supporting mid-range transactions or investments, while **Priya Sharma** utilizes it for personal or professional engagements, showcasing intertwined business or familial relationships.

This instance reflects regional financial behaviors where personal, familial, and professional networks interplay significantly, showcasing South American individualism combined with Asian collaborative account management and support systems.

<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('bancoDoBrasil')
!bancoDoBrasil.country := 'Brazil'
!bancoDoBrasil.name := 'Banco do Brasil'
!bancoDoBrasil.bic := 'BBRA00012'

!new Bank('bharatBank')
!bharatBank.country := 'India'
!bharatBank.name := 'Bharat Bank'
!bharatBank.bic := 'BHIN67234'

!new Person('carlosOliveira')
!carlosOliveira.firstName := 'Carlos'
!carlosOliveira.lastName := 'Oliveira'
!carlosOliveira.age := 23

!new Person('priyaSharma')
!priyaSharma.firstName := 'Priya'
!priyaSharma.lastName := 'Sharma'
!priyaSharma.age := 36

!new Person('viniciusFernandez')
!viniciusFernandez.firstName := 'Vinicius'
!viniciusFernandez.lastName := 'Fernandez'
!viniciusFernandez.age := 40

!new Person('aditiGupta')
!aditiGupta.firstName := 'Aditi'
!aditiGupta.lastName := 'Gupta'
!aditiGupta.age := 29

!new Person('anilKapoor')
!anilKapoor.firstName := 'Anil'
!anilKapoor.lastName := 'Kapoor'
!anilKapoor.age := 48

!new Account('account17_1')
!account17_1.iban := 'BR0011223344I'
!account17_1.balance := 800

!new Account('account17_2')
!account17_2.iban := 'IN8765432109J'
!account17_2.balance := 2500

!new Account('account17_3')
!account17_3.iban := 'BR5566778899K'
!account17_3.balance := 5000

!new Account('account17_4')
!account17_4.iban := 'IN1098765432L'
!account17_4.balance := 3000

!insert (bancoDoBrasil, account17_1) into AccountOfBanks
!insert (bharatBank, account17_2) into AccountOfBanks
!insert (bancoDoBrasil, account17_3) into AccountOfBanks
!insert (bharatBank, account17_4) into AccountOfBanks

!insert (carlosOliveira, account17_1) into Ownership

!insert (priyaSharma, account17_2) into Ownership

!insert (viniciusFernandez, account17_3) into Ownership

!insert (aditiGupta, account17_4) into Ownership
!insert (anilKapoor, account17_4) into Ownership

!insert (carlosOliveira, account17_1) into Use
!insert (viniciusFernandez, account17_1) into Use

!insert (priyaSharma, account17_2) into Use
!insert (anilKapoor, account17_2) into Use

!insert (viniciusFernandez, account17_3) into Use
!insert (carlosOliveira, account17_3) into Use
!insert (aditiGupta, account17_3) into Use

!insert (aditiGupta, account17_4) into Use
!insert (priyaSharma, account17_4) 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: Cross-Cultural Fund Management Collaboration**

### Entities

- **Bank:**
  - `country`: Kenya
  - `name`: Umoja Trust Bank
  - `bic`: UMLKKE22

- **Person:**
  - `firstName`: Amina
  - `lastName`: Njeri
  - `age`: 28

- **Person:**
  - `firstName`: Priya
  - `lastName`: Sethi
  - `age`: 36

- **Person:**
  - `firstName`: Leo
  - `lastName`: Schmidt
  - `age`: 33

- **Account:**
  - `iban`: KE29-7654-3210-0002
  - `balance`: 250_000

- **Account:**
  - `iban`: KE34-8765-4321-0003
  - `balance`: 50

### Relationships

- **Ownership Association:**
  - **Account KE29-7654-3210-0002**:
    - Owners: Amina Njeri, Priya Sethi, Leo Schmidt (An extended collaboration between professionals from different regions to manage a substantial fund intended for a community development project.)

- **Ownership Association:**
  - **Account KE34-8765-4321-0003**:
    - Owners: Priya Sethi (A personal account for handling routine transactions and personal savings while stationed in Kenya.)

- **Use Association:**
  - **Account KE29-7654-3210-0002**:
    - Users: Amina Njeri, Leo Schmidt (While Amina has primary control over transactional decisions to facilitate local project management, Leo monitors remotely to ensure adherence to fiscal strategies.)

- **Use Association:**
  - **Account KE34-8765-4321-0003**:
    - Users: Amina Njeri (Amina assists Priya with local transactions and financial tasks, leveraging her familiarity with local financial practices.)

- **AccountOfBanks Composition:**
  - **Umoja Trust Bank:**
    - Accounts: KE29-7654-3210-0002, KE34-8765-4321-0003

### Explanation

This instance embodies a complex and culturally rich scenario:

- The high-balance account KE29-7654-3210-0002 is a unique case of cross-border, cross-cultural collaboration. Amina, Priya, and Leo represent a trio combining expertise in local application, strategic insights, and operational support for a large community project fund.
  
- Account KE34-8765-4321-0003 is owned solely by Priya but actively used by Amina, showing a supportive dynamic where local knowledge facilitates effortless account maintenance while Priya manages her personal finances during her stay.

- The complexity is further highlighted by the extended ownership association in the high-value account, with ownership stretching beyond the typical two-person setup, reflecting trust and shared mission among different professionals.

- The use and management roles depict a well-orchestrated synergy, blending global expertise and local execution, an uncommon but viable setup made possible by advanced communications and a modern banking system. This also demonstrates an integrated effort towards community upliftment via intelligent financial strategy and management.

The last output is partially incorrect: 
checking structure...
Multiplicity constraint violation in association `Ownership':
  Object `account15_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('umojaTrustBank')
!umojaTrustBank.country := 'Kenya'
!umojaTrustBank.name := 'Umoja Trust Bank'
!umojaTrustBank.bic := 'UMLKKE22'

!new Person('aminaNjeri')
!aminaNjeri.firstName := 'Amina'
!aminaNjeri.lastName := 'Njeri'
!aminaNjeri.age := 28

!new Person('priyaSethi')
!priyaSethi.firstName := 'Priya'
!priyaSethi.lastName := 'Sethi'
!priyaSethi.age := 36

!new Person('leoSchmidt')
!leoSchmidt.firstName := 'Leo'
!leoSchmidt.lastName := 'Schmidt'
!leoSchmidt.age := 33

!new Account('account15_1')
!account15_1.iban := 'KE29-7654-3210-0002'
!account15_1.balance := 250000

!new Account('account15_2')
!account15_2.iban := 'KE34-8765-4321-0003'
!account15_2.balance := 50

!insert (umojaTrustBank, account15_1) into AccountOfBanks
!insert (umojaTrustBank, account15_2) into AccountOfBanks

!insert (aminaNjeri, account15_1) into Ownership
!insert (priyaSethi, account15_1) into Ownership

!insert (priyaSethi, account15_2) into Ownership

!insert (aminaNjeri, account15_1) into Use
!insert (leoSchmidt, account15_1) into Use

!insert (aminaNjeri, account15_2) 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: Small Business Partnership with Complex Usage

### Banks
- **Bank Unity**
  - `country`: "Canada"
  - `name`: "Northern Trust Bank"
  - `bic`: "NTBCA22"

- **Bank Continental**
  - `country`: "Italy"
  - `name`: "Mediterranean Commerce Bank"
  - `bic`: "MCBIT33"

### Persons
- **Person G**
  - `firstName`: "Giovanni"
  - `lastName`: "Rossi"
  - `age`: 45

- **Person H**
  - `firstName`: "Marco"
  - `lastName`: "Bertoli"
  - `age`: 38

- **Person I**
  - `firstName`: "Alicia"
  - `lastName`: "Johnson"
  - `age`: 28

- **Person J**
  - `firstName`: "Samantha"
  - `lastName`: "Lee"
  - `age`: 26

### Accounts

#### Account 5
- **Details**:
  - `iban`: "CA91 1000 3000 0002"
  - `balance`: 15000
- **Bank Association**:
  - Associated with **Bank Unity**
- **Ownership**:
  - Owned by **Person G** and **Person H**
- **Use**:
  - Used by **Person G**, **Person H**, **Person I**, and **Person J**

#### Account 6
- **Details**:
  - `iban`: "IT20 X054 2811 1010"
  - `balance`: 8000
- **Bank Association**:
  - Associated with **Bank Continental**
- **Ownership**:
  - Owned by **Person I** and **Person J**
- **Use**:
  - Used by **Person I**, **Person J**, and **Person H**

### Violations & Overconstraints

1. **Excessive User Distribution in Account 5**:
   - Account 5, associated with a Canadian bank, is used by four people, emphasizing the layered complexities of small business scenarios. Officially, the model allows multiple users per account, but it highlights the need for more nuanced access control mechanisms within shared business operations, potentially clashing with overly general model constraints.
  
2. **Cross-border Account Complexity (Account 6)**:
   - Account 6, with an Italian bic, underscores a realistic cross-national account usage where usage dynamics risk superficial representation. Owners from different continents complicate permissible real-world operations due to taxation, residence, and legal discrepancies, not covered by multiplicities.

3. **Concurrent Multi-bank Involvement**:
   - While each person has accounts bound to respective banks, the intertwining ownership roles and cross-bank utilisations signal gaps in the model's linear composition construct, perhaps revealing the need for linked dependency recognition in a multi-national scenario for accountability.

This instance embodies the layered intricacies faced by small businesses with international dealings, reflecting on the issues of shared access and legislation diversity. It uncovers constraints potentially counterproductive due to a lack of definitions around complex professional usage and extensive co-ownership necessities.

<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('bankUnity')
!bankUnity.country := 'Canada'
!bankUnity.name := 'Northern Trust Bank'
!bankUnity.bic := 'NTBCA22'

!new Bank('bankContinental')
!bankContinental.country := 'Italy'
!bankContinental.name := 'Mediterranean Commerce Bank'
!bankContinental.bic := 'MCBIT33'

!new Person('giovanniRossi')
!giovanniRossi.firstName := 'Giovanni'
!giovanniRossi.lastName := 'Rossi'
!giovanniRossi.age := 45

!new Person('marcoBertoli')
!marcoBertoli.firstName := 'Marco'
!marcoBertoli.lastName := 'Bertoli'
!marcoBertoli.age := 38

!new Person('aliciaJohnson')
!aliciaJohnson.firstName := 'Alicia'
!aliciaJohnson.lastName := 'Johnson'
!aliciaJohnson.age := 28

!new Person('samanthaLee')
!samanthaLee.firstName := 'Samantha'
!samanthaLee.lastName := 'Lee'
!samanthaLee.age := 26

!new Account('account13_5')
!account13_5.iban := 'CA91 1000 3000 0002'
!account13_5.balance := 15000

!new Account('account13_6')
!account13_6.iban := 'IT20 X054 2811 1010'
!account13_6.balance := 8000

!insert (bankUnity, account13_5) into AccountOfBanks
!insert (bankContinental, account13_6) into AccountOfBanks

!insert (giovanniRossi, account13_5) into Ownership
!insert (marcoBertoli, account13_5) into Ownership

!insert (aliciaJohnson, account13_6) into Ownership
!insert (samanthaLee, account13_6) into Ownership

!insert (giovanniRossi, account13_5) into Use
!insert (marcoBertoli, account13_5) into Use
!insert (aliciaJohnson, account13_5) into Use
!insert (samanthaLee, account13_5) into Use

!insert (aliciaJohnson, account13_6) into Use
!insert (samanthaLee, account13_6) into Use
!insert (marcoBertoli, account13_6) into Use
</object_model>