Bank / gen6

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**: Canada
   - **Name**: Royal Bank of Canada
   - **BIC**: ROYCCAT2XXX

2. **Accounts**
   - **Account 1**
     - **IBAN**: CA9112345678901234567890123
     - **Balance**: 4200
   - **Account 2**
     - **IBAN**: CA9234567890123456789012345
     - **Balance**: 9500
   - **Account 3**
     - **IBAN**: CA9345678901234567890123456
     - **Balance**: 300

3. **Persons**
   - **Person 1**
     - **First Name**: Liam
     - **Last Name**: O'Connor
     - **Age**: 38
   - **Person 2**
     - **First Name**: Emily
     - **Last Name**: Li
     - **Age**: 26
   - **Person 3**
     - **First Name**: Noah
     - **Last Name**: Thompson
     - **Age**: 44
   - **Person 4**
     - **First Name**: Sophia
     - **Last Name**: Patel
     - **Age**: 33

### Relationships

1. **Ownership Association**
   - **Account 1** is owned by:
     - **Liam O'Connor**
   - **Account 2** is owned by:
     - **Emily Li**
     - **Sophia Patel**
   - **Account 3** is owned by:
     - **Noah Thompson**

2. **Use Association**
   - **Account 1** is used by:
     - **Liam O'Connor**
     - **Sophia Patel**
   - **Account 2** is used by:
     - **Emily Li**
     - **Noah Thompson**
   - **Account 3** is used by:
     - **Noah Thompson**
     - **Liam O'Connor**

3. **AccountOfBanks Composition**
   - **Account 1**, **Account 2**, and **Account 3** are all associated with:
     - **Royal Bank of Canada**

### Notes

- This instance introduces a Canadian context, incorporating Canadian names and one of the country's leading banks, adding regional diversity.
- Structurally, it presents a straightforward scenario with three accounts and four individuals, each having varied ownership and use patterns, including both single and joint account management.
- All compliance requirements are met: account owners are all over 18 years old, and no account has a negative balance.

The last output is partially incorrect: 
temp.soil> !liamOConnor2.firstName := 'Liam'
temp.soil> !liamOConnor2.lastName := 'O''Connor'
<input>:line 1:28 extraneous input ''Connor'' expecting EOF

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('royalBankOfCanada')
!royalBankOfCanada.country := 'Canada'
!royalBankOfCanada.name := 'Royal Bank of Canada'
!royalBankOfCanada.bic := 'ROYCCAT2XXX'

!new Account('account20_1')
!account20_1.iban := 'CA9112345678901234567890123'
!account20_1.balance := 4200

!new Account('account20_2')
!account20_2.iban := 'CA9234567890123456789012345'
!account20_2.balance := 9500

!new Account('account20_3')
!account20_3.iban := 'CA9345678901234567890123456'
!account20_3.balance := 300

!new Person('liamOConnor2')
!liamOConnor2.firstName := 'Liam'
!liamOConnor2.lastName := 'O\'Connor'
!liamOConnor2.age := 38

!new Person('emilyLi')
!emilyLi.firstName := 'Emily'
!emilyLi.lastName := 'Li'
!emilyLi.age := 26

!new Person('noahThompson')
!noahThompson.firstName := 'Noah'
!noahThompson.lastName := 'Thompson'
!noahThompson.age := 44

!new Person('sophiaPatel')
!sophiaPatel.firstName := 'Sophia'
!sophiaPatel.lastName := 'Patel'
!sophiaPatel.age := 33

!insert (royalBankOfCanada, account20_1) into AccountOfBanks
!insert (royalBankOfCanada, account20_2) into AccountOfBanks
!insert (royalBankOfCanada, account20_3) into AccountOfBanks

!insert (liamOConnor2, account20_1) into Ownership

!insert (emilyLi, account20_2) into Ownership
!insert (sophiaPatel, account20_2) into Ownership

!insert (noahThompson, account20_3) into Ownership

!insert (liamOConnor2, account20_1) into Use
!insert (sophiaPatel, account20_1) into Use

!insert (emilyLi, account20_2) into Use
!insert (noahThompson, account20_2) into Use

!insert (noahThompson, account20_3) into Use
!insert (liamOConnor2, account20_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 the progressive and dynamic city of São Paulo, a well-known financial entity, **"BrasilBank"**, operates with a mission to deliver broad access to financial services. The parameters of BrasilBank are as follows:

- **Bank**:
  - `country`: "Brazil"
  - `name`: "BrasilBank"
  - `bic`: "BRASBRSP001"

Within BrasilBank’s offerings is a financially robust account meant for both personal and small business operations:

- **Account**:
  - `iban`: "BR18BRAS00000012345678901"
  - `balance`: 250,000 (This account is used for managing a micro-business alongside personal expenditures)

This account is owned and co-managed by a pair of partners, each contributing distinct skills towards running a joint enterprise:

1. **Person (Owner 1)**:
   - `firstName`: "Carlos"
   - `lastName`: "Silva"
   - `age`: 29

2. **Person (Owner 2)**:
   - `firstName`: "Fernanda"
   - `lastName`: "Lima"
   - `age`: 35

Both Carlos and Fernanda meet the criterion of being adults, effectively overseeing an account pivotal for business purposes and day-to-day personal needs.

In addition to the owners, the account enlists users without ownership rights, demonstrating its comprehensive nature in facilitating business operations through a capable team:

3. **Person (User, not an owner)**:
   - `firstName`: "Marcelo"
   - `lastName`: "Pereira"
   - `age`: 40

4. **Person (User, not an owner)**:
   - `firstName`: "Ana"
   - `lastName`: "Souza"
   - `age`: 27

Marcelo and Ana, though not owners, actively utilize the account in their roles as employees or consultants, providing a clear separation of management and operational functions, characteristic of collaborative and delegated tasks.

This instance underscores:
- A significantly high balance to support business and personal initiatives.
- Dual ownership maximizing collaborative efforts in business endeavors.
- Engaged non-owner users for operational efficiency, harnessing a blend of business acumen and trust within corporate and personal realms.

<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('brasilBank')
!brasilBank.country := 'Brazil'
!brasilBank.name := 'BrasilBank'
!brasilBank.bic := 'BRASBRSP001'

!new Account('account25')
!account25.iban := 'BR18BRAS00000012345678901'
!account25.balance := 250000

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

!new Person('fernandaLima')
!fernandaLima.firstName := 'Fernanda'
!fernandaLima.lastName := 'Lima'
!fernandaLima.age := 35

!new Person('marceloPereira')
!marceloPereira.firstName := 'Marcelo'
!marceloPereira.lastName := 'Pereira'
!marceloPereira.age := 40

!new Person('anaSouza')
!anaSouza.firstName := 'Ana'
!anaSouza.lastName := 'Souza'
!anaSouza.age := 27

!insert (brasilBank, account25) into AccountOfBanks

!insert (carlosSilva, account25) into Ownership
!insert (fernandaLima, account25) into Ownership

!insert (marceloPereira, account25) into Use
!insert (anaSouza, account25) 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: Scandinavian and South Asian Banking Scenario

#### Banks
1. **Bank1:**
   - **Country:** Sweden
   - **Name:** Svenska Kapitalbank
   - **BIC:** SKSE90123

2. **Bank2:**
   - **Country:** Bangladesh
   - **Name:** Dhaka Savings Bank
   - **BIC:** DSBD76980

#### Persons
1. **Person1:**
   - **First Name:** Sigrid
   - **Last Name:** Blomqvist
   - **Age:** 44

2. **Person2:**
   - **First Name:** Rahul
   - **Last Name:** Roy
   - **Age:** 37

3. **Person3:**
   - **First Name:** Anders
   - **Last Name:** Lindberg
   - **Age:** 59

4. **Person4:**
   - **First Name:** Tara
   - **Last Name:** Khan
   - **Age:** 27

5. **Person5:**
   - **First Name:** Linnea
   - **Last Name:** Nordin
   - **Age:** 35

#### Accounts
1. **Account1:**
   - **IBAN:** SE1234567890F
   - **Balance:** 18000
   - **Bank:** Svenska Kapitalbank
   - **Owners:** Sigrid Blomqvist
   - **Users:** Sigrid Blomqvist, Linnea Nordin

2. **Account2:**
   - **IBAN:** BD1122334455G
   - **Balance:** 4700
   - **Bank:** Dhaka Savings Bank
   - **Owners:** Rahul Roy
   - **Users:** Rahul Roy, Tara Khan

3. **Account3:**
   - **IBAN:** SE7890123456H
   - **Balance:** 3500
   - **Bank:** Svenska Kapitalbank
   - **Owners:** Anders Lindberg
   - **Users:** Anders Lindberg, Sigrid Blomqvist

4. **Account4:**
   - **IBAN:** BD5544332211I
   - **Balance:** 250
   - **Bank:** Dhaka Savings Bank
   - **Owners:** Tara Khan, Rahul Roy
   - **Users:** Tara Khan

5. **Account5:**
   - **IBAN:** SE4567890123J
   - **Balance:** 5000
   - **Bank:** Svenska Kapitalbank
   - **Owners:** Linnea Nordin, Sigrid Blomqvist
   - **Users:** Linnea Nordin, Anders Lindberg

#### Description
- **Svenska Kapitalbank** in Sweden and **Dhaka Savings Bank** in Bangladesh offer unique regional financial products, accommodating a blend of wealth management and personal banking needs.
- **Sigrid Blomqvist** maintains a high-balance savings account at Svenska Kapitalbank, also used by **Linnea Nordin**, reflecting a robust financial strategy with possible mentorship or family business aspects.
- **Rahul Roy** holds a solid account at Dhaka Savings Bank, shared with **Tara Khan**, indicating collaborative saving or business investments, potentially within the family or close community networks.
- **Anders Lindberg** operates an account at Svenska Kapitalbank with **Sigrid Blomqvist** as a secondary user, showcasing intertwined financial activities typical of Scandinavian cooperative financial planning.
- **Tara Khan** and **Rahul Roy** co-own a smaller account at Dhaka Savings Bank, possibly used for daily expenses or educational investment purposes.
- **Linnea Nordin** and **Sigrid Blomqvist** share ownership of a mid-range account at Svenska Kapitalbank, facilitating flexible financial arrangements or joint ventures, with **Anders Lindberg** as a trusted user.

This scenario highlights the confluence of individual savings practice and collaborative financial management in Scandinavia and South Asia, demonstrating personal and collective financial practices supporting familial and entrepreneurial goals across culturally rich regions.

<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('svenskaKapitalbank')
!svenskaKapitalbank.country := 'Sweden'
!svenskaKapitalbank.name := 'Svenska Kapitalbank'
!svenskaKapitalbank.bic := 'SKSE90123'

!new Bank('dhakaSavingsBank')
!dhakaSavingsBank.country := 'Bangladesh'
!dhakaSavingsBank.name := 'Dhaka Savings Bank'
!dhakaSavingsBank.bic := 'DSBD76980'

!new Person('sigridBlomqvist')
!sigridBlomqvist.firstName := 'Sigrid'
!sigridBlomqvist.lastName := 'Blomqvist'
!sigridBlomqvist.age := 44

!new Person('rahulRoy')
!rahulRoy.firstName := 'Rahul'
!rahulRoy.lastName := 'Roy'
!rahulRoy.age := 37

!new Person('andersLindberg')
!andersLindberg.firstName := 'Anders'
!andersLindberg.lastName := 'Lindberg'
!andersLindberg.age := 59

!new Person('taraKhan')
!taraKhan.firstName := 'Tara'
!taraKhan.lastName := 'Khan'
!taraKhan.age := 27

!new Person('linneaNordin')
!linneaNordin.firstName := 'Linnea'
!linneaNordin.lastName := 'Nordin'
!linneaNordin.age := 35

!new Account('account30_1')
!account30_1.iban := 'SE1234567890F'
!account30_1.balance := 18000

!new Account('account30_2')
!account30_2.iban := 'BD1122334455G'
!account30_2.balance := 4700

!new Account('account30_3')
!account30_3.iban := 'SE7890123456H'
!account30_3.balance := 3500

!new Account('account30_4')
!account30_4.iban := 'BD5544332211I'
!account30_4.balance := 250

!new Account('account30_5')
!account30_5.iban := 'SE4567890123J'
!account30_5.balance := 5000

!insert (svenskaKapitalbank, account30_1) into AccountOfBanks
!insert (dhakaSavingsBank, account30_2) into AccountOfBanks
!insert (svenskaKapitalbank, account30_3) into AccountOfBanks
!insert (dhakaSavingsBank, account30_4) into AccountOfBanks
!insert (svenskaKapitalbank, account30_5) into AccountOfBanks

!insert (sigridBlomqvist, account30_1) into Ownership

!insert (rahulRoy, account30_2) into Ownership

!insert (andersLindberg, account30_3) into Ownership

!insert (taraKhan, account30_4) into Ownership
!insert (rahulRoy, account30_4) into Ownership

!insert (linneaNordin, account30_5) into Ownership
!insert (sigridBlomqvist, account30_5) into Ownership

!insert (sigridBlomqvist, account30_1) into Use
!insert (linneaNordin, account30_1) into Use

!insert (rahulRoy, account30_2) into Use
!insert (taraKhan, account30_2) into Use

!insert (andersLindberg, account30_3) into Use
!insert (sigridBlomqvist, account30_3) into Use

!insert (taraKhan, account30_4) into Use

!insert (linneaNordin, account30_5) into Use
!insert (andersLindberg, account30_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: Non-Profit Environmental Initiative**

### Entities

- **Bank:**
  - `country`: South Africa
  - `name`: Ubuntu Green Bank
  - `bic`: UGBZAZAJ

- **Person:**
  - `firstName`: Thabo
  - `lastName`: Nkosi
  - `age`: 50

- **Person:**
  - `firstName`: Maya
  - `lastName`: Khanna
  - `age`: 47

- **Person:**
  - `firstName`: Sofia
  - `lastName`: Garcia
  - `age`: 52

- **Account:**
  - `iban`: ZA20-4567-8912-3410
  - `balance`: 500_000

- **Account:**
  - `iban`: ZA11-7890-1234-5678
  - `balance`: 2_000

### Relationships

- **Ownership Association:**
  - **Account ZA20-4567-8912-3410**:
    - Owners: Thabo Nkosi, Maya Khanna, Sofia Garcia (The primary account dedicated to managing funds for their collaborative non-profit focused on environmental restoration and sustainability projects.)

- **Ownership Association:**
  - **Account ZA11-7890-1234-5678**:
    - Owners: Thabo Nkosi, Maya Khanna (A secondary account used for local community-based initiatives, requiring fewer resources but continuous oversight.)

- **Use Association:**
  - **Account ZA20-4567-8912-3410**:
    - Users: Thabo Nkosi, Maya Khanna, Sofia Garcia (Each owner plays an active role in budgeting, project funding distribution, and scrutiny of expenses to ensure transparency and effectiveness in initiatives.)

- **Use Association:**
  - **Account ZA11-7890-1234-5678**:
    - Users: Sofia Garcia (Sofia personally oversees small-scale initiatives’ financial activities to ensure rapid response capabilities and direct engagement with community volunteers.)

- **AccountOfBanks Composition:**
  - **Ubuntu Green Bank:**
    - Accounts: ZA20-4567-8912-3410, ZA11-7890-1234-5678

### Explanation

This instance showcases a scenario where a non-profit organization effectively manages its resources across diverse projects:

- The main account, ZA20-4567-8912-3410, represents major funding for expansive environmental projects led by Thabo, Maya, and Sofia, each bringing distinct expertise and overseeing decisions that impact large-scale initiatives aimed at ecological balance and restoration.

- The smaller account, ZA11-7890-1234-5678, highlights grassroots efforts requiring swift action, with Thabo and Maya directly engaging their experience to efficiently deploy resources for community-level projects.

- The use of each account encapsulates an operational model where top-level management also actively engages at operational fronts, symbolizing unity in purpose from the organizational core to field execution.

- Sofia's lead on the secondary account reflects tactical delegation in operations, supporting localized tasks with immediacy and personal intervention for maximized impact and community rapport.

- This instance, through structure and purpose, embodies sustainability, collaboration, and effective resource management in non-profit frameworks that aim to effectuate meaningful environmental progress.

<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('ubuntuGreenBank')
!ubuntuGreenBank.country := 'South Africa'
!ubuntuGreenBank.name := 'Ubuntu Green Bank'
!ubuntuGreenBank.bic := 'UGBZAZAJ'

!new Account('account29_1')
!account29_1.iban := 'ZA20-4567-8912-3410'
!account29_1.balance := 500000

!new Account('account29_2')
!account29_2.iban := 'ZA11-7890-1234-5678'
!account29_2.balance := 2000

!new Person('thaboNkosi')
!thaboNkosi.firstName := 'Thabo'
!thaboNkosi.lastName := 'Nkosi'
!thaboNkosi.age := 50

!new Person('mayaKhanna')
!mayaKhanna.firstName := 'Maya'
!mayaKhanna.lastName := 'Khanna'
!mayaKhanna.age := 47

!new Person('sofiaGarcia')
!sofiaGarcia.firstName := 'Sofia'
!sofiaGarcia.lastName := 'Garcia'
!sofiaGarcia.age := 52

!insert (ubuntuGreenBank, account29_1) into AccountOfBanks
!insert (ubuntuGreenBank, account29_2) into AccountOfBanks

!insert (thaboNkosi, account29_1) into Ownership
!insert (mayaKhanna, account29_1) into Ownership

!insert (thaboNkosi, account29_2) into Ownership
!insert (mayaKhanna, account29_2) into Ownership

!insert (thaboNkosi, account29_1) into Use
!insert (mayaKhanna, account29_1) into Use
!insert (sofiaGarcia, account29_1) into Use

!insert (sofiaGarcia, account29_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: Multi-Regional Tech Startup with Dynamic Ownership

### Banks
- **Bank Innovate**
  - `country`: "Germany"
  - `name`: "Tech Innovators Bank"
  - `bic`: "TIBDE4F"

### Persons
- **Person R**
  - `firstName`: "Sven"
  - `lastName`: "Schneider"
  - `age`: 36

- **Person S**
  - `firstName`: "Luisa"
  - `lastName`: "Garcia"
  - `age`: 42

- **Person T**
  - `firstName`: "Jamal"
  - `lastName`: "Owens"
  - `age`: 28

- **Person U**
  - `firstName`: "Fatima"
  - `lastName`: "Hassan"
  - `age`: 33

### Accounts

#### Account 11
- **Details**:
  - `iban`: "DE89 3704 0044 0532"
  - `balance`: 100000
- **Bank Association**:
  - Associated with **Bank Innovate**
- **Ownership**:
  - Owned by **Person R** and **Person S**
- **Use**:
  - Used by **Person R**, **Person S**, **Person T**, and **Person U**

#### Account 12
- **Details**:
  - `iban`: "DE44 5001 0517 5400"
  - `balance`: 150000
- **Bank Association**:
  - Associated with **Bank Innovate**
- **Ownership**:
  - Owned by **Person R** and **Person U**
- **Use**:
  - Used by **Person R** and **Person T**

### Violations & Overconstraints

1. **Extensive User Network in Account 11**:
   - Account 11, with four distinct users, underscores complexities in a tech startup where various team members, including developers and administrators, may need access for disbursements or financial audits, revealing a potential underestimation of user engagement or roles in the model constraints.

2. **Dynamic Ownership in Account 12**:
   - Reflects a scenario where dynamic reallocation of ownership is necessary, resembling real-world tech startups where shares and ownership stakes can change rapidly. The model, however, restricts this flexibility by limiting ownership dynamics or needing explicit enumeration for temporary or interval-based ownership structures.

3. **Cumulative Use Roles**:
   - Account 12 being used by varying individuals across different operations reflects collaborative financial practices required in startups, prompting evaluation of whether more role-specific multiplicities should capture varied complexities beyond owner-defined uses or account interactions in constraints.

This instance portrays a tech startup's need for flexible financial and collaborative operations that accommodate agile shifts in ownership and resource use. It questions whether current ownership and usage multiplicities adequately reflect quick adaptability requirements inherent in such entrepreneurial environments.

<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('techInnovatorsBank')
!techInnovatorsBank.country := 'Germany'
!techInnovatorsBank.name := 'Tech Innovators Bank'
!techInnovatorsBank.bic := 'TIBDE4F'

!new Account('account26_11')
!account26_11.iban := 'DE89 3704 0044 0532'
!account26_11.balance := 100000

!new Account('account26_12')
!account26_12.iban := 'DE44 5001 0517 5400'
!account26_12.balance := 150000

!new Person('svenSchneider')
!svenSchneider.firstName := 'Sven'
!svenSchneider.lastName := 'Schneider'
!svenSchneider.age := 36

!new Person('luisaGarcia')
!luisaGarcia.firstName := 'Luisa'
!luisaGarcia.lastName := 'Garcia'
!luisaGarcia.age := 42

!new Person('jamalOwens')
!jamalOwens.firstName := 'Jamal'
!jamalOwens.lastName := 'Owens'
!jamalOwens.age := 28

!new Person('fatimaHassan')
!fatimaHassan.firstName := 'Fatima'
!fatimaHassan.lastName := 'Hassan'
!fatimaHassan.age := 33

!insert (techInnovatorsBank, account26_11) into AccountOfBanks
!insert (techInnovatorsBank, account26_12) into AccountOfBanks

!insert (svenSchneider, account26_11) into Ownership
!insert (luisaGarcia, account26_11) into Ownership

!insert (svenSchneider, account26_12) into Ownership
!insert (fatimaHassan, account26_12) into Ownership

!insert (svenSchneider, account26_11) into Use
!insert (luisaGarcia, account26_11) into Use
!insert (jamalOwens, account26_11) into Use
!insert (fatimaHassan, account26_11) into Use

!insert (svenSchneider, account26_12) into Use
!insert (jamalOwens, account26_12) into Use
</object_model>