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. L7-S2Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 2 Lesson 7: Object-Oriented Design Heuristics - 2

3. L7-S3Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Lesson Objectives 3 Overview of Previous Lecture Understand Classes in UML Discuss the following: – Macho Class Problem – Interesting Design Problems – Topology Which Needs Accessor Methods – The Common Traps of Controller Classes

4. L7-S4Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Notation Again ! Modeling Notation 4

5. L7-S5Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Real-world systems can be decomposed into discrete entities called objects Objects represent things, concepts, or abstraction with definable boundaries and behaviors An object is specific instance of a class to which it belongs Classes have attributes and behaviors Individual objects have their own specific values for each attribute and share the same behaviors Objects & Classes (1) 5

6. L7-S6Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Example ObjectsClassesAttributes A computer screenScreenResolution, # of colors A windowWindowSize, location IBMCompanyName, location, total revenue Joe HarrisEmployeeName, department, salary Objects & Classes (2) 6

7. L7-S7Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Objects & Classes (3) Objects with the same attributes, behaviors, and relationships are grouped together into classes A class describes general attributes and behaviors for a group of objects An object is a single instance of its class (e.g., IBM is an instance of the Company class) A Class diagram is used to describe the attributes and behaviors of a class 7

8. L7-S8Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 8 Classes in UML (1) Class AbstractClass > UtilityClass attribute operation() > Package::Class {Constraints} Syntax for attributes and operations Attribute[Cardinality]:Package::Type = InitialValue {Constraints} Operation(ArgumentList):ReturnType {Constraints} > MetaClass > ActiveClass

9. L7-S9Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 9 Classes in UML (2) Parameterized Class Parameterized Class i:Element normalOperation() abstractOperation() /derivedOperation() classOperation() publicOperation() #protectedOperation() -privateOperation() Class normalAttribute /derivedAttribute classAttribute publicAttribute #protectedAttribute -privateAttribute Class

10. L7-S10Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Related Terms: Type Definition: Class = Attributes + Operations A class includes the definition of potential constraints, tagged values, and stereotypes. Notation: 10 Classes in UML (3) Class attribute1 attribute2 operation1() operation2() Class attribute1 attribute2 Class attribute1 attribute2 Class operation1() operation2() operation1() operation2() Class

11. L7-S11Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad > stereotype {.. } tagged values :: separate package and class names 11 Classes in UML (4) attribute: Type=InitialValue {Constraints} operation(Paramter) {Constraints} > Package::Class {PropertyValues}

12. L7-S12Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 12 Classes in UML (5) Circle Class name Attribute names Attribute type Operations Class Example Constraint Initial value Parameters (name: type = initial value) radius {radius>0} centerpoint: Point = (10, 10) display(0 remove() setPosition(pos: Point) setRadius(newRadius) Graphics::Circle Package name

13. L7-S13Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad In Smalltalk and CLOS, classes are simply objects, that is, classes can be sent messages, and they can include (class) attributes. In C++, class attributes and operations can be emulated by declaring them as static. However, in C++ classes cannot be treated like objects. An example for a class message or a class operation is new, which is used to create a new instance of a class. In Smalltalk for example: newObject := Class new; anEmployee := Employee new; Classes of class objects are called metaclasses and similarly to a normal class, noted with a stereotype > 13 Classes in UML (6) - Metaclasses > CustomerClass

14. L7-S14Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad In UML, metaclass is a class describing itself or other classes. In UML, class operations need not be noted within the metaclass; they may also be contained in the class itself, where they are underlined in order to distinguish them from normal operations. 14 Classes in UML (7) - Metaclasses numInstance: Integer name: String birthDate: Date new(name) age(): Integer Person numInstance: Integer new(name) > PersonClass >

15. L7-S15Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Definition: A parameterized class is a template equipped with generic formal parameters, which can be used to generate common (non- parameterized) classes. The generic parameters serve as placeholders for the actual parameters which represent classes or simple data types. Description: In a parameterized class, no concrete class is defined, but only a template for generation of classes. These templates are usually a type of macro technique which has no special function, apart from a text replacement. In statically typed languages, parameterized classes are an important means for writing re-usable code. C++ and Eiffel support parameterized classes. 15 Classes in UML (8) - Parameterized Classes

16. L7-S16Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad A class generated with the aid of a parameterized class is called a bound element. Notation 16 Classes in UML (9) - Parameterized Classes i:Element WaitingQueue add() remove() TrafficJam WaitingRoom > (Car) > (Patient) WaitingQueue

17. L7-S17Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Related Terms: virtual class Definition: –An Abstract class is never used to generate object instances. –It is intentionally incomplete and thus forms the basis for further subclasses which can have instances. Description: Abstract classes often represent a general term, a generic term for a set of concrete terms. Thus a vehicle can be an abstract generic term for bicycle, car, truck, train, and airplane. Vehicle in this case is merely an abstraction, a generalization. 17 Classes in UML (9) - Abstract Classes

18. L7-S18Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad An abstract class is always a superclass. An abstract class that has no subclasses makes no sense. Either it is superfluous, or it lacks a concrete class as subclass. Notation 18 Classes in UML (9) - Abstract Classes Class {abstract} attributes Operations() Class attributes Operations() Class {abstract}

19. L7-S19Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Example 19 Classes in UML (9) - Abstract Classes GeomFigure TriangleCircleRectangle Abstract Class Concrete Class

20. L7-S20Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Utility classes are collections of global variables and functions which are combined into a class. The stereotype > marks a class as a utility class Utility classes are not true classes, but collection of global variables and functions which are, however, noted in the form of a class. In OO, they are usually not needed. 20 Classes in UML (9) - Utility Classes sin(angle): Real cos(angle): Real tan(angle): Real cot(angle): Real > MathFun

21. L7-S21Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 21 A Useful Analogy From Telephony (1) When designing a telephone system for the United States we might suggest putting one big switch in Chicago and connecting every phone to it. (assume wire is free). The obvious problem is that if anything happens to Chicago, the entire phone system is down. We want to “distribute the system intelligence” for fault tolerance.

22. L7-S22Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Since we want to distribute the system intelligence let us propose a new phone system. We will connect each phone to every other phone in each of other houses. The obvious problem here is the complexity of the system is so great it prohibits us from adding a new phone. 22 A Useful Analogy From Telephony (2)

23. L7-S23Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad We clearly want to distribute the system intelligence for fault tolerance, but not too much because it will add too much complexity. The same is true in OO design. Fortunately for telephony system there is the useful number of call density to determine how the distribution should take place. In this case, there is analogy in the domain of OO design. This leads us to two largest problems plaguing OO designers: the “Macho Class” Problem and the “Proliferation of Classes” Problem. 23 A Useful Analogy From Telephony (3)

24. L7-S24Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 24 Comparison of Macho Class & Overly Distributed Topologies Macho Class Overly Distributed System

25. L7-S25Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad A Behavior Macho Class A Data Structure Macho Class 25 The Macho Class Problem

26. L7-S26Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad The problem Occurs when a designer misses the centralized control mechanism of action-oriented paradigm and attempts to capture it in a class. The result is a central brain class talking via accessor methods (i, e. gets and sets) to a number of uninteresting data structures. 26 A Behavior Macho Class Macho class class5 class1 class2class3class4 set_result() get_z() get_x() get_y() get_q()

27. L7-S27Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad The problem Occurs when designers are migrating a legacy system to an OO application. The legacy system has a global data block being access by many of the system’s functions. The designers wrap the data structure in a class with an interface of accessor methods and then collect the functions into groups within controller classes 27 A Data Structure Macho Class Macho classcontroller class1 set_result() get_z() get_x() get_y() get_q() controller class2 controller class3 controller class4 controller class5

28. L7-S28Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Legacy Systems: A Definition Legacy Software is any preexisting software that must be replaced by, incorporated into, or interfaced with software that is currently being developed. Legacy software is typically not OO and the use of legacy software on projects developing OO software can cause problems due to the impedance mismatch between different structures of the software. 28

29. L7-S29Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad An accessor method is any relatively standard small and simple method that is used to either get or set the value of an instance attribute Synonyms: Accessing Method, Accessing Operation, Accessor Operation. Contrast with: Accessor Message or Accessing Message Accessor Message is any message used to get or set the value of instance attribute. 29 The Accessor Method Debate (1)

30. L7-S30Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Examples from patterns discussion (e-mail) group A message stated that the following class is dangerous since it gives away implementation details. Another messages agreed with this premise but argued that they are useful, necessary, and therefore valid. 30 The Accessor Method Debate (2) int x; int y; The Point Class get_x() get_y() set_y()

31. L7-S31Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad The point of this example is that the Point class does not give a way implementation details. By definition a method hides the details. All this Point class is stating is that it possess the abstraction notion of a rectangular coordinate system. The actual implementation might be an integer radius and a real number theta (polar coordinates). The get_x() method simply multiplies radius and the cosine of theta. 31 The Accessor Method Debate (3)

32. L7-S32Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad The real questions are: –Who is getting x and y? Beware of people who state that it is often useful to pull an object X from an object Y so that object Z can use it directly. We ask an ATM machine to withdraw $100.00 for us, we don’t ask it for its cash dispenser and then use the dispenser directly. 32 The Accessor Method Debate (4)

33. L7-S33Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad OO models & User Interfaces Make OO independent of its user interface. The result is use of accessor methods defined on the model classes by the user interface classes. The topology does not advocate accessor method calls between the classes of the model, only those between the model and its user interface 33 A Topology Which Needs Accessor Methods OO ModelUser Interface get/set messages The Model-Interface Application Topology

34. L7-S34Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad There are several places in design where controller classes seem to provide us with solution to a difficult problem. These include the migration of legacy systems and the need to hide portions of a class’s public interface. Consider the following legacy system for handling call processing. 34 The Common Traps of Controller Classes (1)

35. L7-S35Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad A collection of global data with separate global functions taking direct access. To migrate this system to OO, controller classes seem to ease the job. 35 The Common Traps of Controller Classes (2) data1 data2 data3 Func2() Func1() Func3() Func4() Func5() Func6() Func7() A Legacy Call Processing System CallProcessingBlock

36. L7-S36Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 36 Controller Classes & the Migration of Legacy Systems (1) The functions can be grouped into controller classes and the global data can be encapsulated into a class with accessor methods. The problem with this design is that we have lost the ability to ask, “I have changed the CallProcessing class, who need to be told?” This is a violation of encapsulation.

37. L7-S37Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 37 Controller Classes & the Migration of Legacy Systems (2) get_data1() set_data1() get_data2() set_data2() get_data3() set_data3() data1 data2 data3 CallProcessingBlock Func2() Func1() Func3() Func4() Func5() Func6() Func7() ContollerClass1 ContollerClass2 ContollerClass3 The CallProcessing Class Poor Migration

38. L7-S38Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 38 Controller Classes & the Migration of Legacy Systems (3) CallProcessingBlock Func2() Func1() Func3() Func4() Func5() Func6() Func7() TelephonyClass1 TelephonyClass2 TelephonyClass3 A Better Migration

39. L7-S39Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 39 Controller Classes & the Migration of Legacy Systems (4) A more difficult But more correct solution Solution is to break up the data structure, encapsulating each part with its related behavior.

40. L7-S40Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Another mistaken use of controller classes occurs when designers of reusable frameworks need to address public interface issues of two or more product groups. Consider the following design produced by multimedia company. This company had two product groups which built there products based on a single framework. The framework captured the fact that all of the company’s products were based on the abstract notion of a composition. 40 Controller Classes & Hiding Portions of Public Interface (1)

41. L7-S41Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad A composition was a bunch of tracks (many derived classes of track), each track was a bunch of clips (many derived classes of clip), and each clip was associated with some piece of media. The play application needed operations P, Q, and R while the editor application needed operations X, Y, and Z. How do I prevent each application from seeing the other classes portion of the interface? 41 Controller Classes & Hiding Portions of Public Interface (2)

42. L7-S42Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 42 Controller Classes & Hiding Portions of Public Interface (3) The Composition Entity Class The Player Controller P, Q, R The Player Application The Editing Controller X, Y, Z The Editing Application gets/sets for the support of P, Q, R, X, Y, Z Reuse of Entity Classes Via Controller Classes

43. L7-S43Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad The problem with the controller class design is that we have now given up encapsulation in order to minimize access to the public interface of composition. The following design maintains this encapsulation. 43 Controller Classes & Hiding Portions of Public Interface (4) The Composition Entity Class The Player Application The Editing Application Only uses P, Q, and R Only uses X, Y, and Z P, Q, R, X, Y, Z A Better Design for The Composition Class

44. L7-S44Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad If minimizing access to public interface of composition is very important, then it is possible to encapsulate the Composition class in an EditComp and PlayComp classes. This creates two new encapsulated classes which only exist to minimize public interface access. 44 Controller Classes & Hiding Portions of Public Interface (5)

45. L7-S45Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Heuristic #1: Distribute horizontal system intelligence as uniformly as possible, i.e. the top level classes in a design should share the work uniformly. Heuristic #2: Beware of classes that have many accessor methods defined in their public interfaces. Heuristic #3: Spin off non-related information into another class, i.e. non-communicating behavior. 45 Heuristics for Avoiding Macho Classes (1)

46. L7-S46Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Heuristic #4: Most of the methods of a class should use most of the data most of the time. Heuristic #5: Keep related data and behavior in one place. Heuristic #6: Be suspicious of any class in your system whose name contains the substrings driver, system, subsystem, or manager. 46 Heuristics for Avoiding Macho Classes (2)

47. L7-S47Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad T/F statements 1. Abstract classes are used to generate object instances 2. Legacy Software is any preexisting software that must be replaced by, incorporated into, or interfaced with software that is currently being developed 3. Utility class contains global variables and functions. 4. Design patterns identify, name, and describe common and recurring designs appearing frequently in object-oriented systems. Define in UML: Abstract Classes, Objects, Metaclasses, Parameterized Classes, Utility Classes, and Notes 47 Discussion Questions

48. L7-S48Design Heuristics - 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Define: –Objects –Notes –Attributes –Operations –Design patterns –The relationships between classes and objects. 48 Questions for the Next Lecture