1 Generalizations Multiple Inheritance (finishing up Class Design) Class Design – Another Look – Part 11

2 Class Design Steps  Create Initial Design Classes  Identify Persistent Classes  …  Define Dependencies  Define Associations  Define Generalizations In analysis, inheritance 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.  Checkpoints

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.  Discuss: What does ‘structure’ mean to you?  Discuss: What does ‘behavior’ mean to you?  Makes ‘change’ and ‘maintenance’ easier: Generalization extracts common properties into classes of their own

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

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 derived / child class ‘is a kind of’ parent class  Can us terms ‘ancestor’ and ‘descendent’ instead of super-class and subclass.  In analysis, generalization is used sparingly to model shared behavioral semantics only. (generalization must pass ‘is a’ test).  Generalization cited in  analysis is used to support reuse in Design. Account balance name number Withdraw() CreateStatement() Checking Savings GetInterest() Superclass (parent) Subclasses Generalization Relationship descendents ancestor

6 Generalization in Analysis and in Design  In Analysis, the generalization should be used to reflect shared definitions/semantics and promote “brevity of expression”  (The use of generalization makes the definitions of the abstractions easier to document and understand).  Think boundary classes for interfacing….  May be used in the Domain Model (Business Object Model)  A common super-class is created when generalization is found.  Super class contains common attributes, associations and aggregations, and behaviors.  Subclasses have unique, individual attributes/behaviors not common to all subclasses of a super class.  We can draw a generalization relationship from the sub-class to the super-class as we saw in the preceding slide. (solid line, open triangle)

7 Lion talk () Tiger talk () Animal {abstract} talk () {abstract} There can be 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 in UML. Meaning: no implementation exists for the operation in the class where it is specified. (A class that contains at least one abstract operation must be an abstract class.) A discriminator can be used to indicate on what basis the generalization or the specialization occurred.

8 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. Potential implementation problems.  Not all languages support it. We don’t care in design!! Why?  May need adjustment in design and implementation.

9 Name clashes on inherited 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 (see above). If a class inherits from several classes, you must check how relationships, operations, and attributes are named in the ancestors.

10 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 - often confused Generalization represents an “is-a” or “kind-of” relationship; one object. Aggregation represents a “part-of” relationship  Relates multiple objects;

11 Scrollbar Window WindowWithScrollbar 11 Window WindowWithScrollbar Scrollbar Consider: Which of these is/are true? A WindowWithScrollbar “is a” Window A WindowWithScrollbar “contains a” Scrollbar Or A WindowWithScrollbar “has a” Scrollbar Generalization vs. Aggregation Notice: specialization and the aggregation

12 Generalization Uses Share Common Properties and Behaviors This is the first use of generalization that we have been talking about to this point.

13 List insertTop (Item) insertBottom (Item) removeTop () removeBottom () insert (Item, position) Stack Animal talk () LionTiger talk () 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. ???

14 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 the descendent ‘is-a’ type of the ancestor and can fill in for all its ancestors in any situation. True? Converse?

15 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.

16 Generalization Uses 1. Share Common Properties and Behavior 2. Share Implementation This use of generalization is where there are some services or structure provided by a class you want to leverage in the implementation of another class. Several different ‘kinds’ of sharing implementations!  Side note: What is wrong grammatically with the sentence starred?

17 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 Can see we inherit insertTop() and removeTop() from SequentialContainer; Add those additional behaviors unique to List

18 Checkpoints: Classes (look these over)  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? Why?  Are all specific requirements on the class addressed?  Are the demands on the class consistent with any state-charts 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 not, why have it??  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.

19 Checkpoints: Operations  Are the operations understandable?  Is the state description of the class and its objects' behavior correct? Names of operations 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 (call by reference, call by value, others….) Ensure there are not too many parameters for an operation.  Are the implementation specifications (if any) for an operation correct? (Got those from??)  Do the operation signatures conform to the standards of the target programming language?

20 Checkpoints: Attributes  Does each attribute represent a single conceptual thing (noun, noun clause)?  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.) Remember, any thing you have may cause problems later in quality control, testing, configuration management, versioning, future maintenance, ….  Be sure to identify and define any applicable default attribute values.

21 Checkpoints: Relationships  Are the role names descriptive? Define roles?? Remember?  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.

22 Review: Class Design  What is the purpose of Class Design?  In what ways are classes refined?  What is the difference between an association and a dependency?  What is done with operations and attributes ?