ADTs. An ADT module is a module that exports a type, along with the operations needed to access and manipulate objects of that type.

Transcription

1 ADTs An ADT module is a module that exports a type, along with the operations needed to access and manipulate objects of that type. An ADT hides the representation of the type and the algorithms used in the operations. The details of the type is dealt with in the implementation of the ADT. Correspond to Java and C++ classes Concept may also be implemented by Ada private types and Modula-2 opaque types May add notational details to specify if certain built-in operations are available by default on instance objects of the ADT e.g., type A_TYPE:? (:=, =) indicates that assignment and equality check are available SFWR ENG 3KO4 Slide 1

2 Abstract data types (ADTs) A stack ADT: allows to have more than one instance of a stack module Define a type and its objects module STACK_HANDLER exports type STACK =?; indicates that details of the data structure are hidden to clients This is an abstract data -type module; the data structure is a secret hidden in the implementation part. procedure PUSH (S: in out STACK ; VAL: in integer); procedure POP (S: in out STACK ; VAL: out integer); function EMPTY (S: in STACK) : BOOLEAN;... end STACK_HANDLER SFWR ENG 3KO4 Slide 2

3 An example: simulation of a gas station module FIFO_CARS uses CARS exports type QUEUE :?; procedure ENQUEUE (Q: in out QUEUE ; C: in CARS); procedure DEQUEUE (Q: in out QUEUE ; C: out CARS); function IS_EMPTY (Q: in QUEUE) : BOOLEAN; function LENGTH (Q: in QUEUE) : NATURAL; procedure MERGE (Q1, Q2 : in QUEUE ; Q : out QUEUE); This is an abstract data-type module representing queues of cars, handled in a strict FIFO way; queues are not assignable or checkable for equality, since := and = are not exported. end FIFO_CARS Moduel Gas_Station uses FIFO_CARS gasoline_1, gasoline_2, gasoline_3: QUEUE car_wash: QUEUE; that_car: CARS; ENQUEUE (car_wash, that_car); MERGE (gasoline_1, gasoline_2, gasoline_3); end Gas_Station SFWR ENG 3KO4 Slide 3

4 Object-oriented design One kind of module ADT, called class A class exports operations (procedures) to manipulate instance objects often called methods Instance objects accessible via references SFWR ENG 3KO4 Slide 4

5 Syntactic changes in TDN No need to export opaque types; class name used to declare objects Instead of using the notation type X =? in the interface of some module Y to introduce the type s name, we let the client module to use the class name directly. In OO we write a:x to say object a is of class X and a is a reference to an instance object of the abstract data type implemented by class X. If a is a reference to an object of class X: a.op (parameters): means invocation of the operation op provided by the instance a of class X; SFWR ENG 3KO4 Slide 5

6 A further relation: inheritance ADTs may be organized in a hierarchy Class B may specialize class A B inherits from A Conversely, A generalizes B A is a superclass of B B is a subclass of A SFWR ENG 3KO4 Slide 6

7 An example class EMPLOYEE exports function FIRST_NAME(): string_of_char; function LAST_NAME(): string_of_char; function AGE(): natural; function WHERE(): SITE; function SALARY(): MONEY; procedure HIRE (FIRST_N: string_of_char; LAST_N: string_of_char; INIT_SALARY: MONEY); Initializes a new EMPLOYEE, assigning a new identifier. procedure FIRE(); procedure ASSIGN (S: SITE); An employee cannot be assigned to a SITE if already assigned to it (i.e., WHERE must be different from S). It is the clientʼs responsibility to ensure this. The effect is to delete the employee from those in WHERE, add the employee to those in S, generate a new id card with security code to access the site overnight, and update WHERE. end EMPLOYEE SFWR ENG 3KO4 Slide 7

8 class ADMINISTRATIVE_STAFF inherits EMPLOYEE exports procedure DO_THIS (F: FOLDER); This is an additional operation that is specific to administrators; other operations may also be added. end ADMINISTRATIVE_STAFF class TECHNICAL_STAFF inherits EMPLOYEE exports function GET_SKILL(): SKILL; procedure DEF_SKILL (SK: SKILL); These are additional operations that are specific to technicians; other operations may also be added. end TECHNICAL_STAFF SFWR ENG 3KO4 Slide 8

9 UML representation of inheritance EMPLOYEE ADMINISTRATIVE_STAFF TECHNICAL_STAFF SFWR ENG 3KO4 Slide 9

10 UML associations Associations are relations that the implementation is required to support Can have multiplicity constraints TECHNICAL _STAFF * 1 project_member PROJECT MANAGER 1 manages 1..* SFWR ENG 3KO4 Slide 10

11 Aggregation Defines a PART_OF relation Differs from IS_COMPOSED_OF Here TRIANGLE has its own methods It implicitly uses POINT to define its data attributes TRIANGLE 1 3 POINT SFWR ENG 3KO4 Slide 11

12 Inheritance A way of building software incrementally A subclass defines a subtype subtype is substitutable for parent type Polymorphism a: A a := obj B a := obj C ADMINISTRATIVE_STAFF EMPLOYEE a variable of type A can refer to an object of type B if B is a subclass of A B op(x,y) A At run-time a.op(x,y) is either from B or C TECHNICAL_STAFF C op(x,y) Dynamic binding the method invoked through a reference depends on the type of the object associated with the reference at runtime SFWR ENG 3KO4 Slide 12

13 How can inheritance be represented? We start introducing the UML notation UML (Unified Modeling Language) is a widely adopted standard notation for representing OO designs We introduce the UML class diagram classes are described by boxes SFWR ENG 3KO4 Slide 13

14 UML Modeling SFWR ENG 3KO4 Slide 14

15 UML Models SFWR ENG 3KO4 Slide 15

16 Ticket Selling Booth Use Case View SFWR ENG 3KO4 Slide 16

17 Ticket Selling Booth Class Diagram SFWR ENG 3KO4 Slide 17

18 Sequence Diagram SFWR ENG 3KO4 Slide 18

19 Component Diagram SFWR ENG 3KO4 Slide 19

20 Statechart diagram State machine view Shows the history of a ticket to a performance SFWR ENG 3KO4 Slide 20

21 Design Patterns SFWR ENG 3KO4 Slide 21

22 Design Pattern Christopher Alexander (1977, buildings / towns): Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way. At high-level design: Architectural Styles At low-level design: Design Patterns Encourages design reuse (intended for OO) Used as a means for transferring knowledge from experienced designers to novice designers SFWR ENG 3KO4 Slide 22

23 Design pattern definition Describe the design of objects and classes (can be modules) in a diagram that communicate with each other and are customized to solve a general design problem in a particular context. A pattern has four essential elements: Name: a handle we can use to describe a design problem, its solution, and consequences in a word or two. Finding a good name is the hardest part. Problem: describes when to apply the pattern; can be a specific design problem or a set of conditions to exist. Solution: describes the elements that make up the design, their relationships, responsibilities, and collaborations. Consequences: are the results and trade-offs applying the pattern. Its impact on system s flexibility, extensibility, or portability SFWR ENG 3KO4 Slide 23

24 MVC Pattern in Smalltalk MVC (Model / View / Controller) consists of: Model: the application program (object) View: its screen presentation Controller: defines the way the user interface reacts to user input, i.e., the user interaction (controller is not shown below) Views Model A = 30% B = 20% C = 50% Protocol for model & view interaction is: Subscribe Notify model SFWR ENG 3KO4 Slide 24

25 MVC Views are subscribed for specific Model Model notifies the views when its value changes Views communicate with model to access new values The problem that MVC addresses: Decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others. Observer design pattern. MVC: a control panel of buttons, ie, nested view: A design pattern that let us treat a composite view just like we treat one of its components. Composite design pattern. MVC: possible to change a view s controller at run-time Lets you change the way a view responds to user input without changing its visual presentation. Strategy design pattern SFWR ENG 3KO4 Slide 25

26 Organizing the Catalog NOT IN EXAM Purpose Creational Structural Behavioral Class Factory Method Interpreter Template Method Scope Object Chain Command Iterator Mediator Memento Observer State Strategy Visitor SFWR ENG 3KO4 Slide 26

27 Describing Design Patterns Pattern name and classification Conveys the essence of the pattern (Creatinal, Structural, Behavioral) Intent: short statement to answer: What particular design issue it addresses? What is its rationale? Also known as: other name for the pattern Motivation: A scenario that illustrates a design problem Applicability: In what situations the pattern applies? Structure: Graphical representation of the classes in OMT notation SFWR ENG 3KO4 Slide 27

28 Describing Design Patterns. Participants: Classes and their responsibilities Collaborations: Collaboration among participants Consequences: How does the pattern support its objectives? Implementation: Pitfalls, hints, techniques to be aware of when implementing Sample code: Code in C++, Smalltalk, Java to implement pattern Known uses: Examples of the pattern found in real systems in other domains. Related patterns SFWR ENG 3KO4 Slide 28

29 The Catalog of Design Pattern SFWR ENG 3KO4 Slide 29

30 The Catalog of Design Pattern NOT IN EXAM SFWR ENG 3KO4 Slide 30

31 The Catalog of Design Pattern NOT IN EXAM SFWR ENG 3KO4 Slide 31

32 The Catalog of Design Pattern NOT IN EXAM SFWR ENG 3KO4 Slide 32

33 Abstract Factory Design Pattern Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes Motivation: A user-interface toolkit that supports multiple look-and-feel standards such as Motif and Open-window. A Kitchen-viewer software that allows the home owners to choose between two styles modern an antique for their wall and floor kitchencabinets and then view the kitchen. SFWR ENG 3KO4 Slide 33

34 Abstract Factory Pattern (Kitchen View Example) Wall cabinet Countertop Floor cabinet Provide an interface for creating families of related or dependent objects without specifying their concrete classes Example: a user-interface toolkit that supports multiple look-and-feel standards such as Motif and Open-window. Modern Classic Antique Modern Classic Antique SFWR ENG 3KO4 Slide 34

35 Kitchen viewer without Design Pattern Aggregation Kitchen contains a number of wall-cabinets and floor-cabinets Client renderkitchen() Implementation dependency Kitchen Specialization Wall cabinet can be ModernWallCabinet or AnticWallCabinet WallCabinet - Cabinet size, location - No. of knobs FloorCabinet ModernWallCabinet AnticWallCabinet ModernFloorCabinet AnticFloorCabinet - Style, color - Material: wood / metal SFWR ENG 3KO4 Slide 35

36 { { } // NO design pattern // Determine the style // Assume that the antique style was selected Rendering a Kitchen Without applying design pattern // Case statements to select antique or modern // Create the antique wall cabinet AntiqueWallCabinet antiquewallcabinet1 = new AntiqueWallCabinet () ; AntiqueWallCabinet antiquewallcabinet2 = new AntiqueWallCabinet ();.. //Create the antique floor cabinet AntiqueFloorcabinet antiquefloorcabinet1 = new AntiqueFloorCabinet (); //Create the kitchen object, assuming the existence of add() method Kitchen antiquekitchen = new Kitchen(); antiquekitchen.add ( antiquewallcabinet1, );. antiquekitchen.add ( antiquefloorcabinet1, );. // Render antiquekitchen //Create the modern wall cabinet Concrete class SFWR ENG 3KO4 Slide 36

37 Inheritance A way of building software incrementally A subclass defines a subtype subtype is substitutable for parent type Polymorphism a: A a := obj B a := obj C ADMINISTRATIVE_STAFF EMPLOYEE a variable of type A can refer to an object of type B if B is a subclass of A B op(x,y) A At run-time a.op(x,y) is either from B or C TECHNICAL_STAFF C op(x,y) Dynamic binding the method that is selected (invoked) through a referencevariable (e.g., a above) depends on the type (class) of the object associated with the reference at runtime SFWR ENG 3KO4 Slide 37

38 Abstract Factory Design Pattern idea Applied to KitchenView Different implementations for getfloorcabinet() KitchenStyle getwallcabinet() getfloorcabinet() WallCabinet FloorCabinet ModernKStyle WallCabinet getwallcabinet() FloorCabinet getfloorcabinet() AnticWallCabinet At RUN TIME: mystyle can be: ModernKStyle or AntiqueKStyle AntiqueKStyle WallCabinet getwallcabinet() FloorCabinet getfloorcabinet() AnticFloorCabinet SFWR ENG 3KO4 Slide 38

39 Abstract Factory Design Pattern Applied to KitchenView Client renderkitchen( KitchenStyle ) KitchenStyle getwallcabinet() getfloorcabinet() Kitchen getwallcabinet() getfloorcabinet() WallCabinet FloorCabinet ModernKStyle getwallcabinet() getfloorcabinet() AntiqueKStyle getwallcabinet() getfloorcabinet() ModernWallCabinet AnticWallCabinet ModernFloorCabinet AnticFloorCabinet SFWR ENG 3KO4 Slide 39

40 Code for method: renderkitchen(kitchenstyle mystyle) //Determine style by instantiating my Style of type KitchenStyle to be either // ModernKStyle or AnticKStyle (Polymorphism) IF: // Create the wall cabinets: Type determined by the calss of mystyle (dynamic bind) WallCabinet wallcabinet_1 = mystyle.getwallcabinet ();.. AnticWallCabinet ModernWallCabinet //Create the floor cabinet: Type determined by the class of mystyle FloorCabinet floorcabinet_1 = mystyle.getfloorcabinet ().. AnticFloorCabinet ModernFloorCabinet //Create the kitchen object (in the style required) Kitchen kitchen = new Kitchen (); //Antic/Modern WallCabinet is returned Kitchen.add ( wallcabinet_1,.); Kitchen.add ( wallcabinet_2,.);. //Antic/Modern FloorCabinet is returned Kitchen.add (floorcabinet_1, ); Kitchen.add (floorcabinet_2, ); AnticKStyle ModernKStyle chosen SFWR ENG 3KO4 Slide 40

41 Adapter Design Pattern Intent: Convert the interface of a class into another interface that the clients expect. Motivation: We want to use the functionality provided by a service application, e.g., an existing financial application. We want to modify our client application as little as possible We want to be able to easily switch to alternative implementations of the service application, to achieve: performance, efficiency, or reliability. Example: an existing financial application computes the principal and interest money obtained from investing a given amount of money for a given number of years in a special type of investment SFWR ENG 3KO4 Slide 41

42 Adapter Class Model AbstractClass clientnameforrequiredmethod() RequiredClass requiredmethod() Client adaptee Adapter clientnameforrequiredmethod() { adaptee.requiredmethod (); } :Client :AbstractClass clientnameforrequiredmethod() :Adapter requiredmethod() adaptee :RequiredClass Sequence Diagram for Adapter SFWR ENG 3KO4 Slide 42

43 Example of Adapter: Financial application New application: Legacy application: amount (float originalamount, float numyears, float intrate) computevalue (float years, float interest, float amount) Application Adaptation Legacy system Financial amount() Principal computevalue() Client FinancialAdapter amount() legacyadaptee { legacyadaptee.computevalue (); } SFWR ENG 3KO4 Slide 43

44 Implementation Class FinancialAdapter extends Financial { principal legacyadaptee = null; // Constructors go here... /** This method uses the legacy computevalue() method */ float amount ( float originalamount, float unmyears, float intrate) { return legacyadaptee. computevalue ( originalamount, numyears, intrate); }} The client could be written with a method parameterizing Financial such as: Void executefinancialapplicatioin ( Financial afinancial); It could then be executed with the following setup statement: executefinanceapplication ( new FinancialAdapter () ); All calls to the amount () method of Financial are passed to the legacy method computevalue(). SFWR ENG 3KO4 Slide 44

45 Adapter and Java API Java listeners as adapters: ActionListner Result of button press MyButton addactionlistener () MyClass mymethod () Adaptation MyListner acionperformed () SFWR ENG 3KO4 Slide 45

46 Comments on Adapter Instead of aggregating requiredclass in Slide 16 we could inherit from it, as long as the language supports multiple-inheritance Adapter is often used when we create an application using library classes, but where we want to retain the flexibility to select alternative library classes. SFWR ENG 3KO4 Slide 46