1. Object-Oriented Extensions to the 4GL Pat Bonser Product Readiness PUG Norway Lillehammer March 16th & 17th

2. © 2006 Progress Software Corporation2 March 2006, PUG Norway Introducing OO in 10.1A OpenEdge ® 10.1 introduces formal object- oriented programming through language extensions that support user-defined classes. User-defined classes allow you to define objects, with methods and data, and interfaces for building business applications.

3. © 2006 Progress Software Corporation3 March 2006, PUG Norway Object-orientation Benefits  Let’s you organize applications the way you think: around objects  Increase application robustness (strong typing)  More development productivity with encapsulation, inheritance, and polymorphism  Promotes reusability  Helps you build OERA. More closely support SOA Modular. Components. Composite applications. Service contracts = Interfaces  Ease application maintenance  Natural integration with: Modeling tools Other OO platforms  Ease hire new developers

4. © 2006 Progress Software Corporation4 March 2006, PUG Norway Object-orientation and the 4GL  OO Extensions to the 4GL Not a replacement for existing code constructs  Not a migration requirement  Can co-exist/integrate with procedural 4GL  You do not need to use OO if you do not want to  Use for natural benefits Strong typing SOA Interface Goals of the OO Extensions to the 4GL Phased Release: OpenEdge 10.1A is the first release for OO

5. © 2006 Progress Software Corporation5 March 2006, PUG Norway  OO terminology for familiar concepts Classes, types, data members, methods & objects  Encapsulation Grouping data & behavior together  Inheritance Re-using and extending code  Delegation Letting contained objects do their own work  Interfaces Implementing a standard set of methods  Polymorphism Generic code for objects with common data & behavior Object-Oriented Concepts Overview What do you need to understand before you use OO?

6. © 2006 Progress Software Corporation6 March 2006, PUG Norway Object-oriented Terminology  A class is a structure that consists of: A set of data definitions (data members) A set of operations that maintain that data (methods) Similar to definitions + procedures within a.p  A class’ data is stored in data members Each data member is defined by name & type  A method is an operation within a class To invoke a method, you send a message to an object Similar to calling a subroutine or procedure within a.p  An object is an instance of a class Created at runtime Contains values within the data members What are classes, data members, methods & objects?

7. © 2006 Progress Software Corporation7 March 2006, PUG Norway Object-oriented Programming  How to start? You need a model –White-board models are okay! Best NOT to start with the presentation layer Best NOT to start with the data management layer  START inside-out Model the required functionality Identify potential functional units candidates for classes

8. © 2006 Progress Software Corporation8 March 2006, PUG Norway Object-oriented Programming  Logical model - Abstraction Identify Classes. Data members. Methods. Identify inheritance “chains” Identify interfaces you need to conform to Identify where you’ll need delegation, polymorphism, etc. Refine: Too coarse? Too fine grained? Reusable?  Implementation model Define each of above Refine as needed  Start programming

9. © 2006 Progress Software Corporation9 March 2006, PUG Norway The Logical Model Business Processing Presentation Layer Integration Data Access

10. © 2006 Progress Software Corporation10 March 2006, PUG Norway Business Abstraction  What is an Order?  Business Operations Approve Ship Check Inventory  Data Operations Create Read Update Delete Order

11. © 2006 Progress Software Corporation11 March 2006, PUG Norway Higher Level Abstraction  What is a Business Entity? Tracks my business  What do I do with a Business Entity? Business Operation –Security –Auditing Delegate CRUD to Data Access in subclasses –Create –Read –Update –Delete Business Entity

12. © 2006 Progress Software Corporation12 March 2006, PUG Norway Encapsulation - Overview  A class encapsulates Data members The methods that maintain them  Encapsulation of a class enforced via different access levels: QualifierCan access.. - privateonly from within the class itself # protectedonly from within the class hierarchy + publicfrom inside or outside the class hierarchy Data & behavior are grouped together within a class

13. © 2006 Progress Software Corporation13 March 2006, PUG Norway Benefits of Encapsulation Why should I use encapsulation?  Objects are insulated from each other’s implementation detail & changes Code is easier to maintain & evolve  Allows you to “black-box” data and functionality Makes it easier to understand code Results in a more intuitive model Modular code

14. © 2006 Progress Software Corporation14 March 2006, PUG Norway Type –. Methods Data Members OOABL.BusinessEntity # daObject:IDataAccess + lcBEXMLDataSet:LONGCHAR + fetchWhere():VOID + saveChanges():VOID  Data Members daObject - Retrieve records lcBEXMLDataSet - Stores records in XML to pass  Methods fetchWhere - Select Records (Read) saveChanges - Saves Changes (Create, Update, Delete) What does a Business Entity need to do for the application? Note: This example does not contain Security or Auditing Super Class – Business Entity

15. © 2006 Progress Software Corporation15 March 2006, PUG Norway Type Overview  Each class represents a new data type Can be used as variables, parameters, return types  Allows for strong-typing Early binding - types determined at compile time Type-consistency enforced at compile time and runtime  Type-name is the. A type is a new data type definition

16. © 2006 Progress Software Corporation16 March 2006, PUG Norway Types – An Example  OOABL.BusinessEntity  OOABL.beOrder Subtype of OOABL. BusinessEntity  OOABL.beCustomer Subtype of OO4ABL.BusinessEntity A subtype can appear anywhere a super type is expected OOABL.BusinessEntity OOABL.beOrderOOABL.beCustomer is a

17. © 2006 Progress Software Corporation17 March 2006, PUG Norway Benefits of Types  Compile time checking for type consistency  Results in safer, bug-free code because all code paths checked at compile time Strong Typing myBEOrder = mybeExternalOrder.must be subtype myBEOrder:fetchWhere()validates signature MyBEOrder:lcBEXMLDataSet = “...” validates data type

18. © 2006 Progress Software Corporation18 March 2006, PUG Norway Inheritance Hierarchy Overview Re-using and extending code  Inheritance is used to abstract out common functionality & data amongst similar classes  Inheritance relationship means a subclass inherits all data members & methods from a super class  Resulting subclass may extend or change behavior by overriding methods of super class or add functionality by adding new methods to the subclass

19. © 2006 Progress Software Corporation19 March 2006, PUG Norway Inheritance - An Example OOABL.BusinessEntity # daObject: IDataAccess + lcBEXMLDataSet:LONGCHAR + fetchWhere():VOID + saveChanges():VOID Inherits super class subclass Additional Override OOABL.BEOrder # dsOrder: dataset + BEOrder () + fetchWhere():VOID + saveChanges():VOID +processOrder():VOID Additional

20. © 2006 Progress Software Corporation20 March 2006, PUG Norway Benefits of Inheritance Why should I use inheritance?  Code is more re-usable Common data members and methods abstracted out of similar object types into a super class  Code is more generic Operations that work on super classes will also work on subclasses Subclasses can extend or replace behavior of super class

21. © 2006 Progress Software Corporation21 March 2006, PUG Norway Delegation Overview Letting contained classes do their own work  Delegation may be used when an object is built from other objects The class hierarchy  Containing object forwards messages it can’t handle to a contained object, called its delegate  Containing object defines a “stub” for the message

22. © 2006 Progress Software Corporation22 March 2006, PUG Norway Delegation – An Example OOABL.BEOrder # dsOrder: dataset + BEOrder () + fetchWhere():VOID + saveChanges():VOID +processOrder():VOID OOABL.DAOrder - dsOrder: handle + convertToDS():VOID + convertToXML():VOID + setcWhere():VOID + getcWhere():CHAR + setDataSources():VOID + selectRecords():LONGCHAR + updateRecords():VOID + setCallbacks():VOID + postOlineFill():VOID + postDataSetFill():VOID Business entity object delegates the record retrieval to data access object delegates

23. © 2006 Progress Software Corporation23 March 2006, PUG Norway Benefits of Delegation Why should I use delegation?  Simplifies Code More modular  Run-time flexibility since delegate could easily be changed on-the-fly Results in a sort of “dynamic” inheritance  Can provide a stable public API for less- stable or multiple APIs of delegate classes

24. © 2006 Progress Software Corporation24 March 2006, PUG Norway Interfaces Overview Implementing a standard set of methods  An interface specifies a set of methods which must be implemented by a class in order to claim support for the interface  Similar to inheritance, except no default data to inherit & no default implementation for the methods i.e., no clear common behavior or data can be represented  A class may implement zero or more interfaces

25. © 2006 Progress Software Corporation25 March 2006, PUG Norway Interface – An Example OOABL.dataObject # xmlDataSet: LONGCHAR # hDataSet:HANDLE # cWhere:CHARACTER # DataObject() + convertToDS():VOID + convertToXML():VOID + setcWhere():VOID + getcWhere():CHAR + setDataSource():VOID + selectRecords():LONGCHAR + updateRecords():VOID OOABL.IDataAccess + setcWhere():VOID + getcWhere():CHAR + setDataSource():VOID + selectRecords():LONGCHAR + updateRecords():VOID implements

26. © 2006 Progress Software Corporation26 March 2006, PUG Norway Benefits of Interfaces  Code is more generic Operations that work on interface classes will also work on classes that implement it Each subclass will have its own implementation of the methods within the interface resulting in polymorphism  Allows you to specify a standard, required interface Implementation of common methods required for a particular class type are enforced by the interface mechanism Why should I use interfaces?

27. © 2006 Progress Software Corporation27 March 2006, PUG Norway Polymorphism Overview Treating similar objects generically  Instances of classes derived from the same super class can be dealt with generically at runtime  A message in the super class is dispatched to the corresponding method in a subclass Polymorphism means each subclass may respond to the same message in a different manner

28. © 2006 Progress Software Corporation28 March 2006, PUG Norway Polymorphism – An Example OOABL.BEExternalOrder - InvoiceNum:INTEGER + processOrder():VOID - sendInvoiceInfo():VOID - startSession():VOID OOABL.BEInternalOrder -crossChargeDeptNum:INTEGER +processOrder():VOID - getCrossChargeDept():CHAR -setCrossChargeDept():VOID - crossCharge():VOID OOABL.BEOrder # dsOrder: dataset + BEOrder () + fetchWhere():VOID + saveChanges():VOID +processOrder():VOID

29. © 2006 Progress Software Corporation29 March 2006, PUG Norway Benefits of Private Methods OOABL.BEExternalOrder - InvoiceNum:INTEGER + processOrder():VOID - sendInvoiceInfo():VOID - startSession():VOID Hmm... I’d like to change the invoicing backend. I can make this change to private methods without effecting the public APIs.

30. © 2006 Progress Software Corporation30 March 2006, PUG Norway OO Concepts Overview Summary Now you are familiar with concepts needed for OOABL:  OO terminology for familiar concepts Classes, types, data members, methods & objects  Encapsulation Grouping data & behavior together  Inheritance Re-using and extending code  Delegation Letting contained objects do their own work  Interfaces Implementing a standard set of methods  Polymorphism Generic code for objects with common data & behavior

31. © 2006 Progress Software Corporation31 March 2006, PUG Norway OO in the 10.1A Features  CLASS definitions .cls files  Single inheritance hierarchies  Data members and methods  Interfaces  Polymorphism  Delegation  CAST function  VALID-OBJECT() method  Support with development tools

32. © 2006 Progress Software Corporation32 March 2006, PUG Norway Similarities between Classes and Procedures ClassesProcedures Class files (.cls)Procedure files (.p) Data membersDefine variables VOID methods Internal procedures Other methodsUser defined functions ConstructorCode in main block Inheritance Super-procedures.p.cls

33. © 2006 Progress Software Corporation33 March 2006, PUG Norway Positioning  When should you consider using Classes? For well defined and designed functional units Not too coarse. Not too granular. Useful (and easy) when called from at least three different modules of an application, or different appls Need to adhere to Interfaces  When are Procedures best? Tasks Processes Workflows Dynamic or late bound code (not strong typed) Disposable programs Differences between Classes and Procedures

34. © 2006 Progress Software Corporation34 March 2006, PUG Norway Interoperability – Classes and Procedures  Classes Can RUN a procedure Can invoke internal procedure / UDF using procedure handle  Procedures Can NEW a CLASS Can DELETE an object Invoke methods using object reference Can pass object reference as a parameter

35. © 2006 Progress Software Corporation35 March 2006, PUG Norway The Shortest Path To Using A Class  Defining a class Class construct –Data members –Constructor –Destructor –Methods  Using a class Defining a variable as a user defined type Instantiating an object Accessing class data members Invoking class methods Deleting an instance Just the basics

36. © 2006 Progress Software Corporation36 March 2006, PUG Norway CLASS Statement CLASS : END [ CLASS ]. Syntax type-name Example – OOABL/Example.cls CLASS OOABL.Example: END. Rules for type-name on next slide

37. © 2006 Progress Software Corporation37 March 2006, PUG Norway CLASS statement – Type Name  Type Name Specify a user-defined type name for a class, a super class, or an interface as a character string Package –A character string that specifies a period-separated list of components that, along with class-name, uniquely identify the –Each component maps to a directory level in the path and each forward or backward slash separator in the path is replaced with a period (.) –Any package specification must remain constant between compile time and run time Class-name –A character string that specifies a class –Must match the name of a class file (excluding its.cls or.r extension) that contains the definition for the defined class –Must be located in the relative path represented by package [package.]class-name Syntax Must be in the PROPATH

38. © 2006 Progress Software Corporation38 March 2006, PUG Norway Programming Conventions for Classes  All class names should use camel case For example –Example.cls  Keywords should not be used for class names, method names or data member names Some keywords are marked illegal by the compiler  Classes should be put into packages, possibly using your company name For example, built-in classes provided by Progress –Progress.Lang –In these examples OOABL is the package

39. © 2006 Progress Software Corporation39 March 2006, PUG Norway Class Members - Data Members CLASS type-name: [ data member …] [ constructor ] [ destructor ] [ method … ] END [ CLASS ]. Class members Syntax Example – OOABL/Example.cls DEFINE PUBLIC VARIABLE cPublic AS CHARACTER INITIAL "I'm PUBLIC" NO-UNDO. DEFINE PROTECTED VARIABLE cProtected AS CHARACTER INITIAL "I'm PROTECTED" NO-UNDO. DEFINE PRIVATE VARIABLE cPrivate AS CHARACTER INITIAL "I'm PRIVATE" NO-UNDO.

40. © 2006 Progress Software Corporation40 March 2006, PUG Norway Defining a Class: CONSTRUCTOR Rules  Name the same as class name Without the package  Default access level is PUBLIC Can’t be PRIVATE  Accepts parameters  Allows you to add custom code  Has no return type  Only one per class Special method used when instantiating the class

41. © 2006 Progress Software Corporation41 March 2006, PUG Norway Class Members - CONSTRUCTOR CONSTRUCTOR { PUBLIC | PROTECTED } class-name ( [param [,param] …] ): /* constructor body */ END [CONSTRUCTOR]. Can NOT be PRIVATE Syntax Example – OOABL/Example.cls CONSTRUCTOR PUBLIC Example (): MESSAGE "This is the constructor for Example.cls" VIEW-AS ALERT-BOX INFO BUTTONS OK. END CONSTRUCTOR. Must match class name

42. © 2006 Progress Software Corporation42 March 2006, PUG Norway Defining a Class: DESTRUCTOR Overview  Never called directly DELETE OBJECT statement  Class instances are NOT automatically deleted Responsibility of the developer  Used to free resources when a class is deleted  Provided by OpenEdge unless explicitly defined  Always PUBLIC  Never has parameters or return-value  Same name as class name No package

43. © 2006 Progress Software Corporation43 March 2006, PUG Norway Class Members - DESTRUCTOR DESTRUCTOR PUBLIC class-name ( ): /* destructor-body */ END [DESTRUCTOR]. Syntax Example – OOABL/Example.cls DESTRUCTOR PUBLIC Example (): MESSAGE "This is the destructor for Example.cls" VIEW-AS ALERT-BOX INFO BUTTONS OK. END DESTRUCTOR. Must match class name

44. © 2006 Progress Software Corporation44 March 2006, PUG Norway Class Members - METHOD Overview  Define the behavior of a class  All behavior implemented within methods No logic outside of methods  Methods can be PUBLIC, PROTECTED or PRIVATE  Must have a return-type, or VOID  Can accept parameters Same syntax as UDFs  FINAL methods cannot be overidden

45. © 2006 Progress Software Corporation45 March 2006, PUG Norway Class Members - METHOD – Syntax/Example METHOD {method-modifiers} {VOID | return-type} method-name ( [param [, param] …] ): /* method body */ END [METHOD]. Syntax Example – OOABL/Example.cls METHOD PUBLIC CHARACTER getcPrivate(): MESSAGE "In getcPrivate" VIEW-AS ALERT-BOX INFO BUTTONS OK. RETURN cPrivate. END. METHOD PUBLIC VOID setcPrivate(INPUT cValue AS CHARACTER): MESSAGE "In setcPrivate" VIEW-AS ALERT-BOX INFO BUTTONS OK. ASSIGN cPrivate = cValue. END.

46. © 2006 Progress Software Corporation46 March 2006, PUG Norway Code Sample – Defining a Class CLASS OOABL.Example: DEFINE PUBLIC VARIABLE cPublic AS CHARACTER INITIAL "I'm PUBLIC" NO-UNDO. DEFINE PROTECTED VARIABLE cProtected AS CHARACTER INITIAL "I'm PROTECTED" NO-UNDO. DEFINE PRIVATE VARIABLE cPrivate AS CHARACTER INITIAL "I'm PRIVATE" NO-UNDO. CONSTRUCTOR PUBLIC Example (): MESSAGE "This is the constructor for Example.cls" VIEW-AS ALERT-BOX INFO BUTTONS OK. END CONSTRUCTOR. METHOD PUBLIC CHARACTER getcPrivate(): MESSAGE "In getcPrivate" VIEW-AS ALERT-BOX INFO BUTTONS OK. RETURN cPrivate. END. METHOD PUBLIC VOID setcPrivate(INPUT cValue AS CHARACTER): MESSAGE "In setcPrivate" VIEW-AS ALERT-BOX INFO BUTTONS OK. ASSIGN cPrivate = cValue. END. DESTRUCTOR PUBLIC Example(): MESSAGE "This is the destructor for Example.cls" VIEW-AS ALERT-BOX INFO BUTTONS OK. END DESTRUCTOR. END CLASS.

47. © 2006 Progress Software Corporation47 March 2006, PUG Norway Class Hierarchies  Classes provide single inheritance Allows extending of super classes Inherit non-private data members and methods  Hierarchy is any number of levels  Top level is root class Implicitly inherits only from Progress.Lang.Object

48. © 2006 Progress Software Corporation48 March 2006, PUG Norway Defining a Class INHERITS Option Understanding INHERITS  Identifies a super class that this class extends Provides access to non-private data members and methods of the super class  Super-type-name Identifies the super class Must be locatable

49. © 2006 Progress Software Corporation49 March 2006, PUG Norway Example: OOABLExample.cls & Example2.cls CLASS OOABL.Example: END CLASS. CLASS OOABL.Example2 INHERITS OOABL.Example: END CLASS. is a CLASS [INHERITS super-type-name ]: [ …] END [ CLASS ]. Syntax Defining a Class INHERITS Option

50. © 2006 Progress Software Corporation50 March 2006, PUG Norway Inheritance – Complete Class Hierarchy OOABL.BusinessEntity # daObject: IDataAccess + lcBEXMLDataSet:LONGCHAR + fetchWhere():VOID + saveChanges():VOID Inherits super class subclass Additional Override OOABL.BEOrder # dsOrder: dataset + LabBEOrder () CONSTRUCTOR + LabBEOrder () DESTRUCTOR + fetchWhere():VOID + saveChanges():VOID +processOrder():VOID Additional

51. © 2006 Progress Software Corporation51 March 2006, PUG Norway The Shortest Path To Using A Class  Defining a class Class –Data members –Constructor –Destructor –Methods  Using a class Defining a variable as a user defined type Instantiating an object Accessing class data members Invoking class methods Deleting an instance Just the basics

52. © 2006 Progress Software Corporation52 March 2006, PUG Norway Defining a Variable as a User Defined Type  Supports strong typing of class references  A data type for classes and interfaces  Similar to a HANDLE variable  Cannot be used in an array or database Syntax DEFINE [access-mode] VARIABLE object-reference AS [ CLASS ] type-name. Example – OOABL/Basic.p DEFINE VARIABLE myExampleObject AS CLASS OOABL.Example NO-UNDO.

53. © 2006 Progress Software Corporation53 March 2006, PUG Norway Defining a Variable as a User Defined Type  Methods, procedures and UDF’s support classes as parameters  Always passed by reference Only object reference is copied Limitations Note with OpenEdge 10.1A cannot be passed across AppServer boundaries

54. © 2006 Progress Software Corporation54 March 2006, PUG Norway Instantiating an Object Using NEW Syntax obj-reference = NEW type-name ([ [, … ]]) [ NO-ERROR ]. Example – OO4GLExt/Basics.p /* Instantiating an object using NEW statement */ myExampleObject = NEW OOABL.Example().

55. © 2006 Progress Software Corporation55 March 2006, PUG Norway Instantiating an Object Using NEW  From a class or procedure  Locates the named class Uses package and class name  Creates a new instance of the class An “object” or “class instance”  Invokes the constructors in the class hierarchy  Must be accessible at compile time The NEW statement – instantiates a class

56. © 2006 Progress Software Corporation56 March 2006, PUG Norway Using a Class: CONSTRUCTOR Rules  Using Invoking the class runs the constructor Constructors invoke other constructors in the class hierarchy Cannot be directly called from a method Special method used when instantiating the class

57. © 2006 Progress Software Corporation57 March 2006, PUG Norway  Use an object reference Accessing PUBLIC Data Members Example– OOABL/Basic.p Syntax obj-reference:data-member-name MESSAGE "Access a PUBLIC variable. The value is … " myExampleObject:cPUBLIC VIEW-AS ALERT-BOX INFO BUTTONS OK.

58. © 2006 Progress Software Corporation58 March 2006, PUG Norway Invoking PUBLIC Methods  Use PUBLIC get or set methods to access Accessing PRIVATE & PROTECTED Data Members cVar = myExampleObject:getcPrivate(). Example – OOABL/Basic.p Syntax [ = ] obj-reference:method-name ( [ [, ] … ] )

59. © 2006 Progress Software Corporation59 March 2006, PUG Norway Deleting an Instance  Invokes the class instance destructors From bottom of hierarchy upwards  Frees all memory allocated to an object  Otherwise Resources stay allocated Destructor NEVER run  May not be deleted immediately If class instance still on execution call stack The DELETE OBJECT statement

60. © 2006 Progress Software Corporation60 March 2006, PUG Norway Deleting a Class Instance DELETE OBJECT object-reference [NO-ERROR]. Syntax Example– Basic.p DELETE OBJECT myExampleObject. ASSIGN myExampleObject = ?. /* prevents accidental use later */ A DESTRUCTOR will not be invoked if you do not explicitly DELETE OBJECT

61. © 2006 Progress Software Corporation61 March 2006, PUG Norway Considerations  PUBLIC only variables and PROTECTED data members scoped to enclosing class  If you forget to delete a class that has a temp- table it will cause a memory leak in the temp table db as well as the class itself Scoping

62. © 2006 Progress Software Corporation62 March 2006, PUG Norway Considerations  Two – pass compiler  Compile time validation of object reference  Validates Methods Parameters  Compiles all files in class hierarchy Compiler changes

63. © 2006 Progress Software Corporation63 March 2006, PUG Norway Current Class Limitations  Limited support for reflection  No dynamic run (call) support  No support for PUBLISH / SUBSCRIBE  Cannot expose a class as a Web service  Cannot ProxyGen a class  Limited native error handling support  Cannot NEW a class over an AppServer boundary Considerations

64. © 2006 Progress Software Corporation64 March 2006, PUG Norway Migrating from Procedures to Classes...  Remove AppBuilder generated code  Convert procedures and functions to methods  Move code from main block to constructor  Identify PUBLIC, PRIVATE, PROTECTED methods  Define interfaces  Change handles to object references  Convert super procedure stack to class hierarchy  Remove handle references, e.g. THIS-PROCEDURE, TARGET-PROCEDURE, SESSION:FIRST-PROCEDURE, etc. Considerations

65. © 2006 Progress Software Corporation65 March 2006, PUG Norway... Migrating from Procedures to Classes  Convert SHARED to PROTECTED  Change RUN to NEW  Change internal methods references to new colon syntax  Review error handling Remove RETURN and RETURN ERROR statements  Remove PUBLISH and SUBSCRIBE statements  Remove references to protected super class temp-tables from subclasses Considerations

66. © 2006 Progress Software Corporation66 March 2006, PUG Norway Object-Oriented Extensions to the 4GL Summary & Questions “… have been designed to complement the 4GL, and are meant to be combined and integrated with ‘traditional’ procedures, when it makes sense to do so. The object-oriented enhancements extend the core values of the 4GL, not replace them.”

67. © 2006 Progress Software Corporation67 March 2006, PUG Norway Example of More Detailed Logical Model Super Class Subclass Inheritance Delegation Polymorphism Interface Public Private Protected Data Members Methods Polymorphism

68. © 2006 Progress Software Corporation68 March 2006, PUG Norway CLASS OOABL.BusinessEntity: /* data members */ DEFINE PUBLIC VARIABLE lcBEXMLDataSet AS LONGCHAR NO-UNDO. /* methods */ METHOD PUBLIC LONGCHAR fetchWhere (INPUT cBEWhere AS CHAR): END. /* fetchWhere*/ METHOD PUBLIC VOID saveChanges (): END. /* saveChanges */ END CLASS. /*BusinessEntity Class*/ Super Class – Business Entity

69. © 2006 Progress Software Corporation69 March 2006, PUG Norway CLASS OOABL.BEOrder INHERITS OOABL.BusinessEntity: {ProDataSet/PrivateOrderTT.i} {ProDataSet/PrivateDSOrder.i} CONSTRUCTOR PUBLIC BEOrder (OUTPUT lSuccess AS LOGICAL): END CONSTRUCTOR. /* constructor BEOrder */ DESTRUCTOR PUBLIC BEOrder (): END DESTRUCTOR. /* destructor BEOrder */ METHOD PUBLIC OVERRIDE LONGCHAR fetchWhere (INPUT cBEWhere AS CHAR): END. /* fetchWhere*/ METHOD PUBLIC OVERRIDE VOID saveChanges(): END. /* saveChanges */ METHOD PUBLIC VOID processOrder(): END. /* processOrder */ END CLASS. /*BEOrder Class*/ Inheritance - An Example