a generalization is a relationship between a general thing (the 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 StaffMember is a specialized kind of LibraryMember a StudentMember is a specialized kind of LibraryMember LibraryMember StaffMember StudentMember Sept 2003 Ron McFadyen 91.3913

Multiple subclasses can be grouped to indicate they are related Generalization (Ch 26) Multiple subclasses can be grouped to indicate they are related subclasses LibraryMember StaffMember StudentMember It then becomes meaningful to consider certain constraints: complete, incomplete, disjoint, overlapping Sept 2003 Ron McFadyen 91.3913

Inheritance of attributes and behaviour: LibraryMember Generalization Inheritance of attributes and behaviour: everything a LibraryMember can do, a StaffMember can do everything a LibraryMember can do, a StudentMember can do If a LibraryMember can borrow a book, so can a StaffMember and a StudentMember a StaffMember and a StaffMember have all the attributes the LibraryMember has, and possibly more Specialization: there are some things that a specialized class can do that a LibraryMember cannot StaffMember StudentMember Sept 2003 Ron McFadyen 91.3913

a SavingsAccount is a specialized kind of BankAccount example: a SavingsAccount is a specialized kind of BankAccount a ChequingAccount is a specialized kind of BankAccount a BankAccount is a specialized kind of Asset RealEstate is … Asset RealEstate BankAccount Security SavingsAccount ChequingAccount Sept 2003 Ron McFadyen 91.3913

The subclass must conform to 100% of the superclass’s: attributes 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 Sept 2003 Ron McFadyen 91.3913

Figure 26.7 Every payment, regardless of whether it is cash, credit, or cheque, has an Amount and it is associated with a Sale Pays-for Payment Sale 1 1 Amount: money Cash Payment Credit Payment Cheque Payment * 1 1 1 CreditCard Cheque Sept 2003 Ron McFadyen 91.3913

Motivation for partitioning a conceptual class into subclasses: subclass has additional attributes of interest subclass has additional associations of interest 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 Sept 2003 Ron McFadyen 91.3913

The name Payment is italicized - meaning it is an abstract class Figure 26.12 The name Payment is italicized - meaning it is an abstract class An abstract class is a class that will never be instantiated; only its subclasses can exist If “Payment” was not in italics then a Payment could exist that is not a Cash, Credit, or Check payment Sept 2003 Ron McFadyen 91.3913

Credit Payment and Cheque Payment participate in other associations Figure 26.7 Credit Payment and Cheque Payment participate in other associations Pays-for Payment Sale 1 1 Amount: money Cash Payment Credit Payment Cheque Payment * 1 1 1 CreditCard Cheque Sept 2003 Ron McFadyen 91.3913

ROT: Do not model with subclasses. Model with states. 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 Sept 2003 Ron McFadyen 91.3913

Text: Instead of Figure 26.13 Payment Unauthorized Payment Use: Is-in Payment PaymentState * 1 Unauthorized State Authorized State Sept 2003 Ron McFadyen 91.3913

Every payment has getStatus and cancel operations Is-in Payment PaymentState Every payment has getStatus and cancel operations * 1 getStatus() cancel() A payment that is not authorized has an authorize operation, but authorize cannot be executed by a payment that has already been authorized. Cancel has two different implementations (polymorphism). Unauthorized State Authorized State authorize() cancel() cancel() Sept 2003 Ron McFadyen 91.3913

Exercise: In some organizations, Purchase Orders and Invoices are modeled as separate classes; in other organizations, they are considered as Orders that evolve over time from being Purchase Order-like to eventually being Invoice-like when they can be paid. So, in the latter case you have Order and Orderline classes that change state over time. How can we model these? Sept 2003 Ron McFadyen 91.3913

Shown inside curly braces {…} incomplete complete disjoint overlapping Constraints Shown inside curly braces {…} incomplete complete disjoint overlapping mammal {disjoint, incomplete} dog cat Sept 2003 Ron McFadyen 91.3913

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.8 Reflexive Associations 27.10 Packages Sept 2003 Ron McFadyen 91.3913

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

Aggregation and Composition Composition is similar to, but stronger than aggregation. If you specify composition, then you are saying that one object owns its parts. Board Square * 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. What is the multiplicity at the composition end of the association? Sept 2003 Ron McFadyen 91.3913

Aggregation and Composition Consider Invoices and their Invoice Lines Question: Is the association aggregation or composition? ? ? * Invoice InvoiceLine Sept 2003 Ron McFadyen 91.3913

Aggregation and Composition Consider Sales and their SalesLineItems Is the association an aggregation or a composition? ? ? * Sale SalesLineItem Sept 2003 Ron McFadyen 91.3913

Aggregation and Composition Consider the Product Catalogue and its Product Specifications. Is the association an aggregation or a composition? Consider the General Calendar and its Course Specifications. Is the association an aggregation or a composition? Consider the Registration Guide and its Course Offerings. Is the association an aggregation or a composition? Sept 2003 Ron McFadyen 91.3913

Aggregation and Composition Figure 27.6 0..7 Several associations sharing the same aggregation/composition can be drawn with converging lines Finger Hand 0..1 Palm 0..1 Thumb Sept 2003 Ron McFadyen 91.3913

Aggregation and Composition Suppose a document comprises a TOC, a preface, a number of sections, and possibly an index. composition or aggregation? Sept 2003 Ron McFadyen 91.3913

Association Class Figure: 27.3: Business rule: a store has a different merchant ID for each service Association Class: a modeling element that is both an association and a class. It has attributes, operations, multiplicities, etc. It can participate in other relationships. Sept 2003 Ron McFadyen 91.3913

Top of Figure 27.4 (ignore rest of it) Many to many associations likely candidate for an Association Class Limitation !!! each company object can be associated to a person object only once. If we wanted to provide for a person to be employed by the same company more than once, we would need to promote Employment to be a regular class. How do we model this? Sept 2003 Ron McFadyen 91.3913

Reflexive Association An association involving the same class more than once. 1 Person 1 marries Sept 2003 Ron McFadyen 91.3913

Reflexive Association An association involving the same class more than once. * Person * marries Sept 2003 Ron McFadyen 91.3913

Reflexive Association An association involving the same class more than once. * Part * comprises Sept 2003 Ron McFadyen 91.3913

Figure 27.11 Contrasting two models 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 Sept 2003 Ron McFadyen 91.3913

Packages are used to organize model elements. Figures 27.21 shows the POS Domain package comprising the Payments, Product, etc. packages 27.22 the core package 27.23 the payments package … name Sept 2003 Ron McFadyen 91.3913