1. May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department of Computer Science & Engineering University of Nebraska, Lincoln Ferguson Hall, P.O. Box 880115 Lincoln, NE 68588-0115 http://www.cse.unl.edu/~fayad

2. L10-S2OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 2 Lesson 10: Object-Oriented Concepts -1

3. L10-S3OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Lesson Objectives 3 Overview of Previous Lecture Understand some OO Concepts Discuss Advanced Issues about Attributes Understand UML- Inheritance Explore Multiple Inheritance The Uses & Containment Relationships

4. L10-S4OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 4 Modeling Concepts  Logical Forms  Structure  Abstraction  Concepts  Objects  Classes  Roles  Actors

5. L10-S5OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 5 Logical Forms  The same substance often take several forms.  ice, steam, water, snow, frost, fog are different forms of H 2 O  Some substances can be transformed from one form to another.  Not all of our studies are of material substances.  Speech, Writing, Geometry, Physics, etc.  But each area of human study acknowledges the existence of “good form”.  “Form” is thus equated with the existence of a pattern/order/consistency/regularity

6. L10-S6OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 6 Structure  “Structure” is the way a thing/construct/form us built up from its parts.  Changing the structure’s content can lead to new forms.  Musical notes, part of a house, etc.  A given content may exist in several different forms.  But each area of human study acknowledges the existence of “good form”.  Conversely, a form may also appear in several different contents  In fashion, dresses can be made from different materials.

7. L10-S7OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 7 Abstraction  “Abstraction” is the consideration of a form apart from its contents. Examples:  “roundness” is a property of a golf ball, a snow ball, a baseball, etc.  “hardness’ is a property of diamond, wood, steel, etc.  Abstraction can be improved upon by practice and study.  Abstract forms are discovered, and named, in the investigation of analogous forms.  A song ==> piano, guitar, etc.  A sphere ==> gold, steel, etc.  We teach abstraction by presenting a set of different things (physical or conceptual) and pointing out the common features that called formal properties.  formal properties are those properties that allow us to express the form of a thing.

8. L10-S8OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 8 Concept  “A concept” is an abstract form or an abstraction.  There is a set corresponding to each concept.  “The dress is white” means the dress is a member of the set of white things.  These sets need not to be disjoint (i.e., the same member may appear in several sets.  The white dress is short and charming.  These set are called classes or categories.  Concepts are formal properties we use to describe things.  The primitive notions of a factual scientific theory are its concepts  Biology ==> cells, bacteria, virus, animal, plant, etc.  Adjectives & adverbs usually are the names of concepts in English

9. L10-S9OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 9 Roles  A “role” is the part of a person or thing plays in a specific situation, operation, etc..  Many different object can play the same role.  Many roles can be played by the same object.  The white dress is short and charming.  A description of a role involves descriptions of:  Activities to be performed  Sequences or processes  Commands to be given and received  Roles are, therefore, abstractions (i.e., abstract forms or concepts).  In fact, roles are abstract temporal forms (i.e., a certain behavior at relative points in time).

10. L10-S10OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 10 Actors  Roles are defined independently of the things used to play that role.  Conversely, Actors are classes that are capable of playing different roles.  They are often classes of physical things.  Man, Woman, Car, etc.  They are often capable of playing different roles in the same time  Woman ==> Doctor, Mother, Pilot  They often take-on and lose roles over time

11. L10-S11OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad  Attributes are simply the information associated with the object.  The data type used to hold the attributes is often a fundamental type, such as int or char.  Sometimes the attribute can be a non-fundamental type, such as String type and Address type.  Avoid using attributes which might be better implemented as an association to a new class. 25 Attribut es

12. L10-S12OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad x 12 More on Attributes TV String model String serialNum String manName For example: Why? Using an association to a Manufacturer class, the name and address of each manufacturer will be stored in one place rather than in each of the TV objects made by that manufacturer. TV String model String serialNum Manufacturer String name Address address productmanu- facturer Using Attributes Using Association

13. L10-S13OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 13 More on Attributes Employee String name float salary long clearanceNum If attributes only make sense in some instances of a given class but not in others. It will make sense to split the single class into two classes or more. Employee String name float salary ClearedEmployee long clearanceNum openVault() Split into two classes Not all employees have clearances inheritance

14. L10-S14OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad When a relationship exists between classes such that lower-level classes (called subclasses) share certain attributes and behaviors which can be defined once in a higher-level class (called superclasses). Subclasses inherit properties (attributes and behaviors) of its superclass and then adds its own unique properties and modifies any inherited properties. This is called Generalization or Inheritance. 14 Inheritance

15. L10-S15OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 15 More on Inheritance Window size icon paintWindow bitmaps textWindow contents

16. L10-S16OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Generalization, Specialization (1) Related terms: inheritance Definition: –Inheritance is a programming language concept; an implementation mechanism for the relationship between superclasses and subclasses by means of which attributes and operations of a superclass also become accessible to its subclasses. –Generalization (or specialization) is a taxonomic relationship between a general and a special element (or vice versa), where the special element adds properties to the general one and behaves in a way that is compatible with it. 16

17. L10-S17OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Generalization, Specialization (2) Notation: –The inheritance relation is represented by means of a large empty arrow pointing from the subclass to the superclass. Superclass Subclass 17

18. L10-S18OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Generalization, Specialization (3) Generalization relations can be provided with the following predefined constraints: –overlapping –disjoint –complete –incomplete 18 Superclass Subclass1Subclass2 {incomplete}

19. L10-S19OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Generalization, Specialization (4) Example: GeomFigure {abstract} x: Integer y: Integer visible: Boolean display() {abstract} Remove() {abstract} moveTo(pX, pY) Triangle a {c-b<a<b+c} b {a-c<b<a+c} c {a-b<c<a+b} setSides(pA,pB,pC) display() remove() Rectangle a {a>0} b {b>0} setSides(pA, pB) display() remove() Circle radius {radius >0) setRadius(pR) display() remove() 19

20. L10-S20OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Multiple Inheritance In multiple inheritance, a class can have more than one superclass. Animal Fish Aquatic Trout Mammal Dolphin Terrestrial Pig Habitat 20

21. L10-S21OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Multiple Inheritance Example: Vehicle name manufacuturer Windpowered Vehicle minWindForce maxWindForce Motor Vehicle fuelType power Water Vehicle draught displacement surfaceOfSails numOfSails SailingBoat KindOfPower{Overlapping} 21 LocomotionMedium

22. L10-S22OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Multiple Inheritance Overlapping Versus Disjoint overlappingSailingboat name manufacturer draught displacement surfaceOfSails numOfSails disjointSailingBoat waterVehicle:name windpoweredVehicle.name waterVehicle:manufacturer windpoweredVehicle.manufacturer draught displacement surfaceOfSails numOfSails 22

23. L10-S23OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad The uses relationship (object-based) The containment relationship (object-based) The inheritance relationship (class-based) The association relationship (object-based) The term “object-based vs. class-based” denotes whether or not all objects of a class have to obey the relationship. Each relationship has its own characteristics and can be dangerous when used in the wrong area of design. Each relationship has its own heuristics governing its correct use. 23 The Relationships between Classes & objects - Heuristics

24. L10-S24OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Most common Definition: if an object of one class sends a message to an object of another class, the first class is said to have a uses relationship with the second class. Example: 24 The Uses Relationship Name: Bob Jones Age: 30 Eyes: Blue Hair: Brown Height: 5’ 10” Weight: 170 APerson Hour: 6 Minute: 23 AlarmHour: 10 AlarmMinute: 30 AlarmStatus: On AnAlarmClock Set_time (“10:30”) A person using an alarm clock

25. L10-S25OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Heuristic 1: Minimize the number of classes with which another class collaborates. 25 Heuristics for the Uses Relationship Restaurant Patron Melon Steak Pie cost() Restaurant Patron Steak Melon Pie cost() Meal

26. L10-S26OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Heuristic 2: Minimize the number of messages send between a class and its collaborator. Heuristic 3: Minimize the amount of collaboration between a class and its collaborator, that is, the number of different messages sent. Heuristic 4: Minimize fanout in a class, that is, the product of the number of messages defined by the class and the messages they send. 26 Heuristics for the Uses Relationship

27. L10-S27OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Heuristic 1: If a class contains objects of another class, then the containing class should be sending messages to the contained objects, that is, the containment relationship should always imply a uses relationship. Heuristic 2: Most of the methods defined on a class should be using most of the data members most of the time. Heuristic 3: Classes should not contain more objects than a developer can fit in his or her short-term memory. A favorite value for this number is six. Heuristic 4: Distribute system intelligence vertically down narrow and deep containment hierarchies. (?) 27 Heuristics for the Containment Relationship

28. L10-S28OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Semantic constraint is an application-specific constraint imposed on an OO relationship restricting its scope or behavior, most often associated with the containment relationship. Heuristic 5: When implementing semantic constraints, it is best to implement them in terms of class definition. Often this will lead to a proliferation of classes, in which case the constraint must be implemented in the behavior of the class – usually, but not necessarily, in the constructor. 28 Semantic Constraints Between Classes (1)

29. L10-S29OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Heuristic 6: When implementing semantic constraints in the constructor of a class, place the constraint test in the constructor as far down a containment hierarchy as the domain allows. Heuristic 7: The semantic information on which a constraint is based is best placed in a central, third party object when that information is volatile. Heuristic 8: The semantic information on which a constraint is based is best decentralized among the classes involved in the constraint when that information is stable. 29 Semantic Constraints Between Classes (2)

30. L10-S30OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Heuristic 9: A class must know what is contains, but it should not know who contains it. Heuristic 10: Objects that share lexical scope – those contained in the same containing class – should not have uses relationships between them. 30 More Containment Heuristics

31. L10-S31OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 31 Objects Sharing Lexical Scope Problem (1) ATM CardReaderDisplay Keypad display_pin() get_pin() Example of objects sharing lexical scope and using each other

32. L10-S32OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 32 Objects Sharing Lexical Scope Problem (2) ATM CardReader Display Keypad display_pin() get_pin() A better solution to the objects sharing lexical scope problem have_a-card()

33. L10-S33OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Class-based relationship: an OO relationship between two classes in which all objects of the classes involved obey the relationship. Container class: a class whose main purpose is the storage of other objects. Often implemented as a homogeneous-looking list of heterogeneous objects, namely, a polymorphic list. Containment by value: A containment relationship in which the contained object is directly linked to the containing class, that is, the objects involved in the relationship are born and die together. Containment by reference: A containment relationship in which the contained object is indirectly linked to the containing class, usually via a pointer or referential attribute. 33 Summary

34. L10-S34OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Define uses and containment relationships What is semantic constraint? What do you think “multiple inheritance” means? Define Polymorphism with examples What do we mean by saying “Model/View/Controller”? 34 Discussion Questions

35. L10-S35OO Concepts -1 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Define: –Interactions vs. relationships –Inheritance vs. aggregation –Define: association, attributed association, recursive associations, –Explain: association constraints, qualified associations, composition –Discuss the inheritance relationship heuristics 35 Questions for the Next Lecture