Generalization (Ch 26) a generalization is a relationship between a general thing (the superclass or parent class) and a more specific kind of thing (the subclass or child class) example: a MemberOfStaff is a specialized kind of LibraryMember LibraryMember MemberOfStaff

Generalization example continued: everything a LibraryMember can do, a MemberOfStaff can do a LibraryMember can borrow a book, so can a MemberOfStaff there are some things that a MemberOfStaff can do that a LibraryMember cannot (the specialization aspect) the MemberOfStaff has all the attributes the LibraryMember has, and possibly more (again, the specialization aspect) LibraryMember MemberOfStaff

a Generalization example: a SavingsAccount is a specialized kind of BankAccount a ChequingAccount is a specialized kind of BankAccount an Asset may be a BankAccount, RealEstate, or a Security Asset RealEstateBankAccountSecurity SavingsAccountChequingAccount

Text: All members of a conceptual subclass set are members of their superclass set 100% of the conceptual superclass’s definition should be applicable to the subclass. The subclass must conform to 100% of the superclass’s: attributes associations A conceptual subclass is a kind of superclass - is-a-kind-of is usually referred to as is-a

Figure 26.7 Payment Amount: money Cash Payment Credit PaymentCheque Payment Sale Pays-for 1 1 Every payment, regardless of whether it is cash, credit, or cheque, has an Amount and it is associated with a Sale CreditCardCheque *

Motivation for partitioning a conceptual class into subclasses: the subclass has additional attributes of interest the subclass has additional associations of interest the subclass is operated on, handled, reacted to, or manipulated differently than the superclass or other subclasses the subclass concept represents an animate thing that behaves differently than the superclass or other subclasses Examples a chequing account will accrue interest differently from a savings account a loan account will have different associations from a savings account

Figure The name Payment is italicized - meaning it is an abstract class It will never be instantiated - only its subtypes will exist

Figure 26.7 Payment Amount: money Cash Payment Credit PaymentCheque Payment Sale Pays-for 1 1 Credit and Cheque participate in other associations CreditCardCheque *

Watch for objects that are performing roles, or moving from one state to another. ROT: Do not model with subclasses. Model with states. Text: Consider payments that begin as unauthorized and may eventually become authorized. Do not model as: Payment Unauthorized Payment Authorized Payment

Text: Instead of Payment Unauthorized Payment Authorized Payment Use: PaymentState Unauthorized StateAuthorized State Payment Is-in 1 1 Figure 26.13

Ch 27 - Refining the Domain Model 27.1 Association Classes 27.2 Aggregation and Composition 27.4 Association Role Names 27.5 Roles as Concepts vs Roles in Associations 27.6 Derived Elements 27.8 Reflexive Associations

Aggregation and Composition both are associations used to denote that an object from one class is part of an object of another class HonoursProgrammeCourse An example of Aggregation: a course is part of an honours programme. The same module could be part of several honours courses “Software Engineering with Objects and Components 2” is part of both the “Software Engineering” and the “Computer Science” honours programmes

Aggregation and Composition BoardSquare Composition is similar to, but stronger than aggregation. If you specify composition, then you are saying that one object owns its parts. A Board is made up of several Squares. A Square will belong to just one Board. If a Board is deleted, then its Squares are deleted too.

Aggregation and Composition InvoiceInvoiceLine Consider Invoices and their Invoice Lines Question: Is the association aggregation or composition? ? ?

Aggregation and Composition Figure 27.6

Association Class When we want to treat an association as a class (it has data or associations itself), we introduce an Association Class Figure: 27.3: Business rule: a store has a different merchant ID for each service

Top of Figure 27.4 (ignore rest of it) Many to many associations likely candidate for an Association Class limitation above: each person has at most one association with each company - we’ll re-examine this later when we look at history

Figure Can be very accurate: one person plays more than one role More difficult to implement: may need to mutate an object from one class to another