1. 1 Generalizations Multiple Inheritance Polymorphism Class Design – Another Look – Part 11

2. 2 Class Design Steps  Create Initial Design Classes  Identify Persistent Classes  …  Define Dependencies  Define Associations  Define Generalizations In analysis, inheritance that was inherent to the problem domain may have been defined. Class Design is where generalizations are defined to improve/ease the implementation. Design is the real activity of inventing inheritance.  Resolve Use-Case Collisions  Handle Non-Functional Requirements in General  Checkpoints

3. 3 Generalization  Is a notational convenience allows us to define common structure and behavior in one place and re-use it where we find repeated behavior and structure.  Makes ‘change’ and ‘maintenance’ easier: Extracts common properties into classes of their own

4. 4 Define Generalizations  Purpose Identify areas of reuse Refine existing inheritance hierarchies so that they can be implemented efficiently  Things to look for: Abstract classes vs. concrete classes Multiple inheritance problems Generalization vs. Aggregation Generalization to support implementation reuse Generalization to support polymorphism Generalization to support metamorphosis Generalization simulation

5. 5 Review: Generalization  Is a ‘relationship where one class shares the structure and/or behavior of one or more classes  “Is-a-kind of” relationship  Should always be able to say that your generalized class ‘is a kind of’ parent class.  Can us terms ‘ancestor’ and ‘descendent’ instead of super-class and subclass.  In analysis, used sparingly to model shared behavioral semantics only (generalization that passes the ‘is a’ test).  Generalization to promote and support reuse is determined In Design. Account balance name number Withdraw() CreateStatement() Checking Savings GetInterest() Superclass (parent) Subclasses Generalization Relationship descendents ancestor

6. 6 Generalization in Analysis and in Design  In analysis, the generalization should be used to reflect shared definitions/semantics and promote “brevity of expression”  (i.e., the use of generalization makes the definitions of the abstractions easier to document and understand).  When generalization is found, a common super-class is created to contain the common attributes, associations, aggregations, and operations.  Common behavior is removed from the classes which become sub-classes of the common super-class.  A generalization relationship is drawn from the sub-class to the super-class

7. 7 Lion talk () Tiger talk () Animal {abstract} talk () {abstract} There are no direct instances of Animal All objects are either lions or tigers Abstract class Abstract operation Communication Discriminator Abstract and Concrete Classes  Abstract classes cannot have any objects Exist only for other classes to inherit from it  Concrete classes are used to instantiate objects An operation can also be tagged as abstract. Meaning: no implementation exists for the op in the class where it is specified. (A class that contains at least one abstract operation must be an abstract class.)

8. 8 Lion talk () Tiger talk () Animal {abstract} talk () {abstract} All objects are either lions or tigers Abstract class Abstract operation Communication Discriminator Inheritance and implementation  Classes inheriting from abstract classes must provide implementation for the abstract operations, or the operations are considered abstract in subclass; the subclass is considered abstract, as well.  Concrete classes have implementations for all operations. In UML, we designate as abstract w/tag {abstract} For abstract operations, {abstract} is as indicated. Can indicate abstract item in italics. A discriminator can be used to indicate on what basis the generalization / specialization occurred. Discriminator describes a characteristic that differs in each of the subclasses. Here: ‘communication’

9. 9 AirplaneHelicopterWolfHorse FlyingThingAnimal Bird multiple inheritance Use multiple inheritance only when needed, and always with caution ! Multiple Inheritance – inheriting from more than one class.  Bird inherits from Flying Thing and Animal  Conceptually simple; necessary for modeling real world accurately. Potentially, implementation problems. Not all languages support it.  This representation will probably need adjustment in design and implementation.  Generally, a class inherits from only one class.

10. 10 Name clashes on attributes or operations Repeated inheritance FlyingThing color getColor Animal color getColor Bird FlyingThing Animal Bird AnimateObject color Multiple Inheritance: Problems in Design and Implementation. Resolution of these problems is implementation-dependent In general, multiple inheritance causes problems if any of the multiple parents has structure or behavior that overlaps. If the class inherits from several classes, you must check how the relationships, operations, and attributes are named in the ancestors.

11. 11 Name clashes on attributes or operations Repeated inheritance FlyingThing color getColor Animal color getColor Bird FlyingThing Animal Bird AnimateObject color Multiple Inheritance: Problems in Design and Implementation. Two issues associated with multiple inheritance: 1.Name collisions: both ancestors have attributes / ops with same name. If same name appears in several ancestors, you must describe what this means to the specific inheriting class, e.g., by qualifying the name to indicate source of declaration. 2.Repeated inheritance: Same ancestor is being inherited by a descendant more once. When it occurs, the inheritance hierarchy will have a ‘diamond shape’ (above) Descendents end up with multiple copies of an ancestor.

12. 12 A bit more on multiple inheritance  If you are using repeated inheritance, you must have a clear definition of its semantics; in most cases this is defined by the programming language supporting the multiple inheritance.  In general, the programming language rules governing multiple inheritance are complex, and often difficult to use correctly. Use multiple inheritance only when needed, and always with caution.  Delegation: Use delegation as a workaround to multiple inheritance problems. (ahead)

13. 13 Four Standard Generalization Constraints  Complete End of the inheritance tree  All children in the generalization relationship have been defined in the model.  No more children can be defined.  The leaves of the inheritance hierarchy cannot be specialized any further.  Use the complete constraint to explicitly note that the generalization hierarchy has not been fully specified in the model.

14. 14 Four Standard Generalization Constraints  Incomplete Inheritance tree may be extended All children in the generalization relationship have not been defined in the model. More children may be defined. Leaves in the hierarchy may be specialized. Use this constraint to explicitly note that the generalization hierarchy has not been fully specified in the model.

15. 15 Four Standard Generalization Constraints  These only apply in the context of multiple inheritance: Disjoint  An object of the parent cannot have more than of the children as its type.  Subclasses mutually exclusive  Disjoint is used to support the modeling of static classification, where an object cannot change its type at run-time.  Doesn’t support multiple inheritance Overlapping  An object of the parent may have more than of the children as its type.  Overlapping is used to support the modeling of dynamic classification, where an object can change its type at run-time.  It shows the potential types of an object.  Subclasses are not mutually exclusive  Supports multiple inheritance

16. 16 Example: Generalization Constraints Asset Real Estate Bank Account Security Saving Checking StockBond {disjoint} {disjoint,complete} {disjoint} End of inheritance hierarchy Multiple inheritance not supported Complete: The Saving and Checking classes cannot be specialized (a generalization relationship cannot be defined in which they are the parent). These classes (and siblings) mark the end of the inheritance hierarchy. Disjoint: A BankAccount object cannot be both a Saving and a Checking account (i.e., no multiple inheritance where parents in the multiple inheritance are the children of BankAccount).

17. 17 Example: Generalization Constraints (cont.) Vehicle Water Vehicle Land Vehicle Amphibious Vehicle {overlapping} Multiple inheritance supported This example demonstrates the use of overlapping constraint. The AmphibiousVehicle class can inhierit from both LandVehicle and WaterVehicle, which both inherit from Vehicle.

18. 18 Window WindowWithScrollbar Scrollbar Is this a correct use of generalization? If not, what would be a better way to model the info which maintains generalization “is-a” semantics? Generalization vs. Aggregation  Generalization and aggregation are often confused Generalization represents an “is-a” or “kind-of” relationship; one object. Aggregation represents a “part-of” relationship  Relates multiple objects;

19. 19 Scrollbar Window WindowWithScrollbar 11 Window WindowWithScrollbar Scrollbar A WindowWithScrollbar “is a” Window A WindowWithScrollbar “contains a” Scrollbar Generalization vs. Aggregation

20. 20 Generalization Uses:  Generalization can be used to support multiple goals: Some are: Share Common Properties and Behavior Share Implementation Implement Polymorphism Implement Metamorphosis  Will look at each of these uses of generalization ahead…

21. 21 Project Guidelines for using Generalization.  A project should have guidelines for determining the good use of generalization. The best class approach is to articulate the various styles of generalization.  These goals/uses can be used to help define these different styles, as well as assist in identifying where generalization can be used in the model.  Take care to keep the use of generalization understandable. At the very least you should know the purpose of each

22. 22 Generalization Uses  Share Common Properties and Behavior This is the first use of generalization that we have been talking about to this point.  Share Implementation  Implement Polymorphism  Implement Metamorphosis

23. 23 List insertTop (Item) insertBottom (Item) removeTop () removeBottom () insert (Item, position) Stack Animal talk () LionTiger talk () Do these classes follow the IS-A style of programming? Generalization: Share Common Properties and Behavior  Follows the Is-A style of programming  Class substitutability A subtype is a type of relationship expressed with inheritance. A subtype specifies that the descendent is a type of the ancestor and must follow the rules of the Is-A style of programming.

24. 24 List insertTop (Item) insertBottom (Item) removeTop () removeBottom () insert (Item, position) Stack Animal talk () LionTiger talk () Do these classes follow the IS-A style of programming? Generalization: Share Common Properties and Behavior  The Is-A style of programming states that the descendent is-a type of the ancestor and can fill in for all its ancestors in any situation. The Is-A style passes the Liskov Substitution Principle: “If for each object O1 of type S there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when O1 is substituted for O2 then S is a subtype of T.” SO???

25. 25 Animal talk () LionTiger talk () Generalization: Share Common Properties and Behavior (contd) List insertTop (Item) insertBottom (Item) removeTop () removeBottom () insert (Item, position) Stack The classes on the left-hand side of the diagram do follow the is-a style of programming: a Lion is-an Animal and a Tiger is-an animal. The classes on the right-hand side of the diagram do NOT follow the Is-A style of programming: a Stack is not a List. A Stack needs some of the behavior of a List but not all of the behavior. If a method expects a List, then the operation insert(position) should be successful. If the method is passed a Stack, then the insert(position) will fail.

26. 26 Generalization Uses  Share Common Properties and Behavior  Share Implementation This use of generalization is where there are some services or structure provided by a class that you want to leverage in the implementation of another class.  Implement Polymorphism  Implement Metamorphosis

27. 27 List insertBottom (Item) removeBottom () insert (Item, position) Stack SequentialContainer insertTop (Item) removeTop () List insertTop (Item) insertBottom (Item) removeTop () removeBottom () insert (Item, position) Stack Generalization: Share Implementation-Factoring  Factoring is useful if there are some services provided by one class that you want to leverage in the implementation of another class.  When you factor, extract the functionality you want to reuse and inherit it from the new base class.  Supports the reuse of the implementation of another class  Cannot be used if class you want to “reuse” cannot be changed

28. 28 List insertBottom (item) removeBottom () insert (Item, position) remove (position) Stack push (Item) pop (): Item 1 1 List insertTop (Item) insertBottom (Item) removeTop () removeBottom () insert (Item, position) Stack Generalization Alternative: Share Implementation: Delegation (1 of 2)  Supports the reuse of the implementation of another class. Use a composition relationship to reuse desired functionality  Can be used if the class you want to “reuse” cannot be changed. All operations that require the “reused” service are ‘passed through’ to the contained class instance.

29. 29 List insertBottom (item) removeBottom () insert (Item, position) remove (position) Stack push (Item) pop (): Item 1 1 List insertTop (Item) insertBottom (Item) removeTop () removeBottom () insert (Item, position) Stack Generalization Alternative: Share Implementation: Delegation (2 of 2)  With delegation, you lose the benefit of polymorphic behavior, but you do have a model that more clearly expresses the nature of the domain (being that its NOT is-a)  This is commonly used by mix-ins. Implementing mix-ins with composition permits run-time binding to objects rather than compile time binding enforced by inheritance. Note: You can also use delegation as a workaround to multiple inheritance problems discussed earlier. Have the subclass inherit from one of the super classes, and then use aggregation from the subclass to access the structure and behaviors of the other classes.

30. 30 List insertBottom (Item) removeBottom () insert (Item, position) remove (position) insertTop (Item) Stack push (Item) pop () > Sharing Implementation: Implementation Inheritance The use of an > stereotype can be used to model implementation inheritance.  Implementation inheritance is where the implementation of a specific element is inherited/reused.  Implementation inheritance often leads to illogical inheritance hierarchies that are difficult to understand and to maintain. Thus it is not recommended that you use inheritance only for implementation reuse, unless something else is recommended in using your programming language. Maintenance of this kind of reuse is usually quite tricky. In the example, any change in the class List can imply large changes of all classes inheriting the class List. Beware of this and inherit only stable classes. Inheritance will actually freeze the implementation of the class List, because changes to it are too expensive.

31. 31 List insertBottom (Item) removeBottom () insert (Item, position) remove (position) insertTop (Item) Stack push (Item) pop () push() and pop() can access methods of List but instances of Stack cannot > Sharing Implementation: Implementation Inheritance  Ancestor public operations, attributes and relationships are NOT visible to clients of descendent class instances  Descendent class must define all access to ancestor operations, attributes, and relationships

32. 32 Generalization Uses  Share Common Properties and Behavior  Share Implementation  Implement Polymorphism Generalization can also be used to implement polymorphism. In the Architectural Design module, we discussed how interfaces directly implement polymorphism Here, we will discuss how generalization can also be used to implement polymorphism.  Implement Metamorphosis

33. 33 Manufacturer A Manufacturer B Manufacturer C OO Principle: Encapsulation Review: What is Polymorphism?  The ability to hide many different implementations behind a single interface Polymorphism was introduced in the Intro to OO module. This is a review slide. Comes from Greek: poly – many; morph – forms. Every implementation of the interface must implement at least the interface. The implementation can in some cases implement more than the interface.

34. 34 Generalization: Implement Polymorphism Without Polymorphism With Polymorphism Animal talk () LionTiger talk () if animal = “Lion” then do the Lion talk else if animal = “Tiger” then do the Tiger talk end do the Animal talk Inheritance provides a way to implement polymorphism in cases where poly is implemented the same way for a set of classes. This means that abstract base classes that simply declare inherited operations, but which have no implementations of the operations, can be replaced with interfaces. Inheritance now can be (but need not be) restricted to inheritance of implementations only. Polymorphism is not generalization; generalization is one way to implement polymorphism. Poly via generalization is the ability to define alternate methods for operations of the ancestor class in the descendent classes. This can reduce the amount of code to be written, and help abstract the interface to descendent classes. Poly is an advantage of inheritance realized during implementation and at run-time. (Environments use dynamic binding, meaning that the actual code to execute is determined at run-time vs. compile time.

35. 35 Polymorphism: Use of Interfaces vs. Generalization (i.e., abstract base classes)  Interfaces allow us to define poly in a declarative way, unrelated to implementation. Two elements are polymorphic with respect to a set of behaviors if they realize the same interfaces. Interfaces support implementation-independent representation of polymorphism Interfaces are orthogonal to class inheritance lineage; two different classifiers may realize the same interface but be unrelated in their class hierarchies.  Interfaces are pure specifications of behavior (i.e., a set of operation signature); an abstract base class may define attributes and associations as well.

36. 36 Polymorphism: Use of Interfaces vs. Generalization (i.e.,abstract base classes)  Interfaces are totally independent of inheritance  Generalization: used to re-use implementations  Interfaces are used to re-use and formalize behavioral specifications  Generalization provides a way to implement poly in cases where poly is implemented the same way for a set of classes.  The use of generalization to support poly was discussed earlier.

37. 37 Polymorphism via Generalization Design Decisions  If designing the use of generalization to support polymorphism, there are three decisions to make: Provide interface only to descendant classes?  Design ancestor as an abstract class and only design methods for the descendent classes. Provide interface and default behavior to descendent classes?  Design ancestor as a concrete class with a default method and allow descendents to refine the method. (Allow polymorphic operations) Provide interface and mandatory behavior to descendent classes?  Design ancestor as a concrete class and disallow descendents from defining their own method for the operations (Do not allow polymorphic operations)

38. 38 Generalization Uses  Share Common Properties and Behavior  Share Implementation  Implement Polymorphism  Implement Metamorphosis Generalization can also be used to implement metamorphosis. This term and the use of generalization to implement it, are the subjects of the next few slides.

39. 39 Metamorphosis exists in the real world How should it be modeled? What is Metamorphosis?  Metamorphosis 1. a change in form, structure, or function; specifically the physical change undergone by some animals, as of the tadpole to the frog 2. any marked change, as in character, appearance, or condition Webster’s New World Dictionary, Simon & Schuster, Inc., 1979

40. 40 FulltimeStudent name address studentID gradDate ParttimeStudent name address maxNumCourses studentID Example: Metamorphosis  In the university, there are full time students and part time students Full time students have an expected graduation date but part time students do not Part time students may take a maximum of 3 courses where there is no maximum for full time students

41. 41 What happens if a part-time student becomes a full-time student? FulltimeStudent Student name address studentID gradDate ParttimeStudent maxNumCourses Modeling Metamorphosis: One Approach  An generalization relationship may be created

42. 42 11 Classification ParttimeClassification maxNumCourses Student name address studentID FulltimeClassification gradDate FulltimeStudent Student name address studentID gradDate ParttimeStudent maxNumCourses Modeling Metamorphosis: Another Approach  Inheritance may be used to model common structure, behavior and/or relationships to the “changing” parts This example shows the ‘before’ and ‘after’ with regards to I implementing metamorphosis.

43. 43 : Student : Fulltime Classification : Student Manager : Parttime Classification delete create change to full time Modeling Metamorphosis: Another Approach (contd)  Metamorphosis is accomplished by the object “talking” to the changing parts

44. 44 studentID 1 1 ResidentInformation dorm room roomKeyID Student name address 1 0..1 1 Classification 1 Metamorphosis and Flexibility  This technique also adds to the flexibility of the model ParttimeClassification maxNumCourses FulltimeClassification gradDate In this example, a student may also live on campus. In this case, there is a dorm identifier, a room number, and a room key number. ResidentInformation is just a hypothetical class. It does not exist in the Course Registration model.

45. 45 Class Design Steps  Create Initial Design Classes  Identify Persistent Classes  Define Operations  Define Attributes  …  Define Associations  Define Generalizations  Resolve Use-Case Collisions Purpose is to prevent concurrency conflicts caused when two or more use cases access may potentially access instances of the design class simultaneously, and in potentially inconsistent ways.  Handle Non-Functional Requirements in General  Checkpoints

46. 46 Resolve Use-Case Collisions  Multiple use cases may simultaneously access design objects – perhaps in conflicting ways.  Concurrency conflicts must be identified and resolved explicitly.  Options Use synchronous messaging => first-come first-serve order processing (blocks others…)  Good if message is same priority or where execution runs within same execution thread.

47. 47 Resolve Use-Case Collisions  Options (continued)  Where objects may be accessed concurrently by different threads of execution: Identify operations (or code) to protect from simultaneous access. Apply access control mechanisms to prevent conflicting simultaneous access.  Message queuing (serializes access)  Semaphores (or 'tokens') (allow access only to one thread at a time)  Other locking mechanism  Resolution is highly dependent on implementation environment – may vary with programming language and operating environment.

48. 48 Class Design Steps  Create Initial Design Classes  Identify Persistent Classes  Define Operations  Define Class Visibility  Define Methods  …  Resolve Use-Case Collisions  Handle Non-Functional Requirements in General Purpose: to make sure the design classes are refined to handle general, non-functional requirements (make sure that all mechanisms mapped to the class have been taken into account)  Checkpoints

49. 49 Handle Non-Functional Requirements in General Analysis ClassAnalysis Mechanism(s) Student Schedule CourseOffering Course RegistrationController Persistency, Security Persistency, Legacy Interface Distribution Persistency, Security AnalysisDesignImplementation Remote Method Invocation (RMI) Persistenc y Analysis Mechanism (Conceptual) Design Mechanism (Concrete) Implementation Mechanism (Actual) OODBMS RDBMS JDBC ObjectStore Java 1.2 from Sun Legac y Data New Data Distribution Persistenc y Design Guidelines Some Design Class Here, the designer should, for each design mechanism needed, qualify as many characteristics as possible, giving ranges where appropriate.

50. 50 Classes in non-functional requirements:  There can be several design guidelines and mechanisms that need to be taken into consideration when classes are designed: How to use existing products and components How to adapt to the programming language How to distribute objects How to achieve acceptable performance How to achieve certain security levels How to handle errors, … and more.

51. 51 Class Design Steps  ….  Define Dependencies  Define Associations  Define Generalizations  Resolve Use-Case Collisions  Handle Non-Functional Requirements in General  Checkpoints Here we verify that the design model fulfills the requirements on the system, is consistent with respect to the general design guidelines, and that it serves as a good basis for its implementation. We need to check the design model carefully to verify that all work is headed in the right direction. Consider the check points ahead…

52. 52 Checkpoints: Classes  Does the name of each class clearly reflect the role it plays? The class should only define attributes, responsibilities or operations that are functionally coupled to the other attributes, responsibilities, or operations defined by that class.  Does the class represent a single well-defined abstraction?  Are all attributes and responsibilities functionally coupled?  Are there any class attributes, operations or relationships that should be generalized, that is, moved to an ancestor?  Are all specific requirements on the class addressed?  Are the demands on the class consistent with any statecharts which model the behavior of the class and its instances?  Is the complete life cycle of an instance of the class described?  Does the class offer the required behavior?  If the class does not represent a well-defined abstraction, you should consider splitting it.  The complete lifecycle of an instance of the class should be described.  Each object should be created, used, and removed by one or more use-case realizations.  The classes should offer the behavior the use-case realizations and other classes require.

53. 53 Checkpoints: Operations  Are the operations understandable?  Is the state description of the class and its objects' behavior correct? Names of ops should be descriptive and the operations should be understandable to those who want to use them.  Does the class offer the behavior required of it?  Have you defined the parameters correctly Ensure there are not too many parameters for an operation.  Have you assigned operations for the messages of each object completely?  Are the implementation specifications (if any) for an operation correct?  Do the operation signatures conform to the standards of the target programming language?

54. 54 Checkpoints: Attributes  Does each attribute represent a single conceptual thing?  Are the names of the attributes descriptive?  Are all the attributes needed by the use-case realizations?  (Remove any attributes that are redundant and not needed by the use-case realizations.  Be sure to identify and define any applicable default attribute values.

55. 55 Checkpoints: Relationships  Are the role names descriptive?  Are the multiplicities of the relationships correct?  The role names of the aggregations and associations should describe the relationship between the associated class to the relating class.

56. 56 Review: Class Design  What is the purpose of Class Design?  In what ways are classes refined?  Are statecharts created for every class?  What are the major components of a statechart? Provide a brief description of each.  What kind of relationship refinements occur?  What is the difference between an association and a dependency?  What is done with operations and attributes ?