Reflection and the Adaptive Object Model Architecture

1. Reflection and the Adaptive Object Model Architecture Ralph Johnson University of Illinois at Urbana-Champaign johnson@cs.uiuc.edu 217-244-0093 http://st-www.cs.uiuc.edu/users/johnson

2. Reflection • Is hard • Is important • The ability of a program to reason about and change its own implementation.

3. Reflection Base level (the application) Paycheck Employee Report Printer Meta level (the virtual machine) Class Method Module

4. Patterns and Architecture Problem with Pattern-Oriented Software Architecture is that the “architectural patterns” are really pattern languages, not patterns.

5. Kinds of Architectures Client-server Purpose: access shared data, distribute computation Result: bottlenecks usually database or network, not CPU

6. Kinds of Architectures Layered system Purpose: reuse lower layers limit effects of change make system easier to understand Result: can be inefficient fix bottlenecks by “punching hole” thru layers

7. Adaptive Object Model • Pattern of business software • Used to model information • Valuable where information structure is complex and changes rapidly • Can be inefficient and hard to understand

8. Adaptive Object Model • Made up of design patterns • Composite, Strategy, Interpreter • Type Object • Properties • Examples: • Rating insurance policies • Rating telephone calls • Maintaining database

9. Type Object • Problem: Have to subclass, and subclasses require code. Want to customize system without programming. • Solution: • For each kind of object, make two classes, an Instance and a Type. • Try not to make a subclass - make a new object of the Type.

10. Examples • Airline scheduling system • airplane and airplane type • Medical information system • observation and observation type • Manufacturing • item and item type

11. Type Object • “type” describes what a group of objects have in common • often “type” creates “instances” • often used with Strategy, Interpreter, and Property Instance Type type name strategies properties name values

12. Insurance Policies Policy owner, address Instead of using multiple inheritance to model policies, model a policy as a tree of components. House address, value, size, style Car value, mileage, age, drivers Fire limit, deductable Liability limit, deductable Collision limit, deductable Liability limit, deductable

13. Component Class Hierarchy One solution is to make a class for each kind of component. PolicyComponent Policy Car House HouseFire HouseLiability CarFire CarLiability

14. Component Characteristics Insurance policies have only a few operations • Edit - create new policy or change old one • Rate - compute amount to charge for policy • Print - convert into paper Different components have different attributes

15. Eliminating Subclasses • Policy made up of Components and ComponentTypes. • Each ComponentType defines a set of Strategies (to represent operations) • Component has a set of Properties (to represent attributes). • One Component class and one ComponentType class.

16. Property Problem: object has arbitrary or huge number of attributes Solution: represent attributes with a dictionary properties Subject Property name value

17. Composite Type Object with Properties and Strategies children type ComponentType name Component properties type Property value PropertyType name type Strategy

18. Composite Type Object with Properties and Strategies Component ComponentType name =‘Policy’ Strategy Property value =‘John Doe’ PropertyType name =‘owner’ Property value = ‘1 Main Street, Big City’ PropertyType name =‘address’ Component ComponentType name =‘House’ Auto

19. Problem: Strategy leads to a big class hierarchy, one class for each kind of policy. Solution: Make Composite Strategies. => Interpreter pattern

20. Interpreter Pattern Problem: Need a small language Solution: • Make class hierarchy that models the grammar • Each class defines a value() function with the context as the argument • Program is a tree of objects

21. Small Language for Insurance • Attributes - value() function for an Attribute Type will return value of an attribute with that type in the context. • Arithmetic expressions (+,-,*,/) • Table lookup • Assignment to attribute

22. Composite Type Object Composite type ComponentType name Component children children properties Property Strategy type Property value Rule Type Object Interpreter PropertyType name type Table Expression

23. Products • A product is a type of policy. • Framework makes it easy to create new kind of product. • Framework makes composite types. • Instance vs. type • Operational vs. knowlege

24. Editing a Policy • One editor can edit any policy. • Policy is a sequence of components. • Policy editor is a sequence of component editors. • Component editor has a field for each attribute in the component. • Number field • date field

25. Creating New Component Component ComponentType name =‘Policy’ Component ComponentType name =‘House’ Component ComponentType name =‘Auto’ Component ComponentType name =‘Liability’ ComponentType name =‘Liability’

26. Creating New Component • When editing component of type T, you can create a component of any type that is a child of T. • Types act like a grammar, while components are an abstract syntax tree

27. Advantages of AOM • Automate user interface • Automate database interface • Enable users to extend system • Automate other aspects of system • History • Workflow

28. Insurance Framework Summary • Policy is a tree of components • Component type is a composite object • System has tools for editing policies, and tools for editing component types • Domain specific object model is in the database, not the CASE tool.

29. Adaptive Object Model • Many systems store object model in a database and interpret it • results in user extensible systems • flexible, easy to maintain • kernel is small, abstract, complex • performance is an issue

30. AOM and Reflection • Similarities • Base level and meta level • Developers have to know both levels • Differences • Base level doesn’t necessarily invoke meta level • No “reflective tower”

31. Telecommunications Billing • Database • customers • charges • network events (call, directory assistance, voice-mail) • billing plans • bills

32. Telecommunications Billing Rating - converting network events into charges to customer Billing - computing discounts, finance charges, etc - printing bills

33. Rating • Many kind of network events • Billing policy determines how to rate network events • Billing policies continually changing • Network event has a set of properties

34. Rating Account Billing Policy Network Event name = ‘phone call’ BusinessEvent name = ‘phone call’ Property name = ‘caller’ value = ‘217-345-1111’ Charge value = ‘air time * .05’ Charge value = ‘roaming * .25’ Property name = ‘air time’ value = ‘25’ BusinessEvent name = ‘information’

35. Rating Algorithm • Given a Network Event, find the Account, then the Billing Policy. • Find the Business Event with the same name as the Network Event. • Compute the total of the Charges for the Business Event by evaluating them in the context of the Business Event.

36. Type Object type Type name Entity Properties Property name value NetworkEvent NetworkEventType BusinessEventType BusinessEvent Interpreter Charge + * PropertyRef

37. Similarities Between Systems • Automate GUIs • Automate database access • Provide full history on all objects • Provide GUIs for editing types and rules. • Planned for customers to edit types, but they don’t.

38. Differences Between Systems • Phone billing system makes lots of subclasses of Entity and Type • Phone billing system has more complex algorithms • Insurance system has more powerful rules

39. Global Data • Database for factory locations, product types, accounting codes, conversion rates, etc. • Originally 10 tables, now 100. • Keeps complete history of data • Global Data Division in charge of schemas and data editing programs, their users are in charge of the data.

41. History • Effective date - data at which record is valid • Obsolete date - date at which record is invalid • Record is never deleted, its obsolete date is just set to yesterday. • Referential integrity

42. Global Data Editor Type Object Type Object Table name Window Description Window Record Properties Type Object Type Object Widget Description Field name value Attribute name type Widget value Strategy FieldValidator RecordValidator

43. Result • Instead of 200 COBOL programs, there are two Java programs (client and server) • We use XML for metadata (window specs and table specs) • Generate documentation from XML • Programs make type objects from XML • New validation rules are in Java

44. Adaptive Object Models • It is common to see combinations of Type Object, Composite, Property, Strategy, and Interpreter. • Object model stored in the database. • Editors / database interface driven by object model. • Enables system to be customized easily.

45. Disadvantages of AOM • Abstract - can be hard to learn • An interpreter - can be slow • A language - are you ready to write a debugger, a test harness, a configuration control system, documentation aids, etc?

46. The Poetry of the Language “It is possible to put patterns together in such a way that many many patterns overlap in the same physical space: the building is very dense; it has many meanings captured in a small space; and through this density, it becomes profound.” Christopher Alexander “A Pattern Language”

47. Summary • Interesting applications use many patterns • Many interesting patterns are not in Design Patterns • Particular combinations of patterns are architectures, and interesting in their own right.

48. Summary • Document architectures • Patterns are a good model for documentation • architecture is a pattern? • architecture is a set of patterns? • architecture is an application of a set of patterns?

49. For more information on adaptive object models and other architectures for business software, see http://st-www.cs.uiuc.edu/users/johnson /bus-obj.html