1 / 48

Software Design Methodologies: UML in Action

Learn about object-oriented design heuristics in UML, including classes, attributes, behaviors, and common traps to avoid. Taught by Dr. Mohamed Fayad.

asowers
Download Presentation

Software Design Methodologies: UML in Action

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 ISISTAN Research Institute – Tandil, Argentina

  2. Lesson 7: Object-Oriented Design Heuristics - 2 2 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  3. Lesson Objectives • 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 3 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  4. Modeling Notation Notation Again ! 4 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  5. Objects & Classes (1) • 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 5 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  6. Objects & Classes (2) Example ObjectsClassesAttributes A computer screen Screen Resolution, # of colors A window Window Size, location IBM Company Name, location, total revenue Joe Harris Employee Name, department, salary 6 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  7. 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 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

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

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

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

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

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

  13. 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 <<metaclass>> Classes in UML (6) - Metaclasses 13 <<metaclass>> CustomerClass ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  14. 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. Classes in UML (7) - Metaclasses <<metaclass>> PersonClass Person <<instance of>> numInstance: Integer name: String birthDate: Date new(name) age(): Integer numInstance: Integer new(name) 14 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  15. 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. Classes in UML (8) - Parameterized Classes 15 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

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

  17. 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. Classes in UML (9) - Abstract Classes 17 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  18. 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 Classes in UML (9) - Abstract Classes Class {abstract} Class Class {abstract} attributes Operations() attributes Operations() 18 Class ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  19. Example Classes in UML (9) - Abstract Classes GeomFigure Abstract Class Concrete Class Triangle Circle Rectangle 19 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  20. Utility classes are collections of global variables and functions which are combined into a class. The stereotype <<utility>> 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. Classes in UML (9) - Utility Classes <<utility>> MathFun sin(angle): Real cos(angle): Real tan(angle): Real cot(angle): Real 20 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. 21 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  22. 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. A Useful Analogy From Telephony (2) 22 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  23. 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. A Useful Analogy From Telephony (3) 23 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  24. Comparison of Macho Class & Overly Distributed Topologies Overly Distributed System Macho Class 24 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  25. A Behavior Macho Class A Data Structure Macho Class The Macho Class Problem 25 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  26. 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. A Behavior Macho Class set_result() get_x() class5 class1 Macho class get_y() get_z() get_q() 26 class2 class3 class4 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  27. 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 A Data Structure Macho Class set_result() get_x() controller class5 controller class1 Macho class get_y() get_z() get_q() 27 controller class3 controller class4 controller class2 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  28. 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 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  29. 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. The Accessor Method Debate (1) 29 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  30. 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. The Accessor Method Debate (2) The Point Class get_x() get_x() get_y() set_y() int x; int y; 30 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  31. 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. The Accessor Method Debate (3) 31 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  32. 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. The Accessor Method Debate (4) 32 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  33. 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 A Topology Which Needs Accessor Methods OO Model User Interface get/set messages 33 The Model-Interface Application Topology ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  34. 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. The Common Traps of Controller Classes (1) 34 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  35. 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. The Common Traps of Controller Classes (2) CallProcessingBlock A Legacy Call Processing System data1 data2 data3 Func1() Func7() Func3() Func5() Func6() Func2() Func4() 35 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  36. 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. Controller Classes & the Migration of Legacy Systems (1) 36 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

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

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

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

  40. 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. Controller Classes & Hiding Portions of Public Interface (1) 40 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  41. 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? Controller Classes & Hiding Portions of Public Interface (2) 41 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

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

  43. 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. Controller Classes & Hiding Portions of Public Interface (4) A Better Design for The Composition Class The Composition Entity Class P, Q, R, X, Y, Z Only uses X, Y, and Z Only uses P, Q, and R 43 The Editing Application The Player Application ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  44. 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. Controller Classes & Hiding Portions of Public Interface (5) 44 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  45. 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. Heuristics for Avoiding Macho Classes (1) 45 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  46. 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. Heuristics for Avoiding Macho Classes (2) 46 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

  47. 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 Discussion Questions 47 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad

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

More Related