If we return to the “full-on” domain model diagram for a moment, you can see that it includes various types of relationships:
- Aggregation relationship between
Payment Transactionwhich tells us that a single instance of
Payment Historyhas 0 or more
Payment Transactionswithin them
- Association relationship between
Coupon Blockwhich implies that a single
Subscriptionhas 1 or more
Coupon Blockassociated with it. Association creates PK FK relationship in the DB schema between the 2 entities
- Inheritance/Generalization relationship between
Payment Methodis the superclass (its attributes and operations) being inherited by subclasses:
Specifying the multiplicity of class relationships allows you to pin down the details in your domain model. Multiplicity can be specified at the source and target ends of each relationship arrow. The target end generally has more of an effect on the generated code, while the source end (while occasionally used) is more useful for documentation purposes.
If you don’t specify the multiplicity, the default is 0..* (zero to many).
Other value ranges may also be used such as 1..4. This would be interpreted in most cases as “one to many”, but may also be put to use for data validation.
If you’re interested in the specifics, the Reference section includes a full list of relationship types recognised by CodeBot, along with how they’re represented in the generated system.