Reflection and the adaptive object model architecture
This presentation is the property of its rightful owner.
Sponsored Links
1 / 49

Reflection and the Adaptive Object Model Architecture PowerPoint PPT Presentation


  • 68 Views
  • Uploaded on
  • Presentation posted in: General

Reflection and the Adaptive Object Model Architecture. Ralph Johnson University of Illinois at Urbana-Champaign [email protected] 217-244-0093 http://st-www.cs.uiuc.edu/users/johnson. Reflection. Is hard Is important

Download Presentation

Reflection and the Adaptive Object Model Architecture

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Reflection and the adaptive object model architecture

Reflection and the Adaptive Object Model Architecture

Ralph Johnson

University of Illinois at Urbana-Champaign

[email protected]

217-244-0093

http://st-www.cs.uiuc.edu/users/johnson


Reflection

Reflection

  • Is hard

  • Is important

  • The ability of a program to reason about and change its own implementation.


Reflection1

Reflection

Base level (the application)

Paycheck

Employee

Report

Printer

Meta level (the virtual machine)

Class

Method

Module


Patterns and architecture

Patterns and Architecture

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


Kinds of architectures

Kinds of Architectures

Client-server

Purpose: access shared data, distribute computation

Result: bottlenecks usually database or network, not CPU


Kinds of architectures1

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


Adaptive object model

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


Adaptive object model1

Adaptive Object Model

  • Made up of design patterns

    • Composite, Strategy, Interpreter

    • Type Object

    • Properties

  • Examples:

    • Rating insurance policies

    • Rating telephone calls

    • Maintaining database


Type object

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.


Examples

Examples

  • Airline scheduling system

    • airplane and airplane type

  • Medical information system

    • observation and observation type

  • Manufacturing

    • item and item type


Type object1

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


Insurance policies

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


Component class hierarchy

Component Class Hierarchy

One solution is to make a class for each kind of component.

PolicyComponent

Policy

Car

House

HouseFire

HouseLiability

CarFire

CarLiability


Component characteristics

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


Eliminating subclasses

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.


Property

Property

Problem: object has arbitrary or huge number of attributes

Solution: represent attributes with a dictionary

properties

Subject

Property

name

value


Composite type object with properties and strategies

Composite Type Object with Properties and Strategies

children

type

ComponentType

name

Component

properties

type

Property

value

PropertyType

name

type

Strategy


Composite type object with properties and strategies1

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


Reflection and the adaptive object model architecture

Problem: Strategy leads to a big class hierarchy, one class for each kind of policy.

Solution: Make Composite Strategies.

=> Interpreter pattern


Interpreter pattern

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


Small language for insurance

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


Reflection and the adaptive object model architecture

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


Products

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


Editing a policy

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


Creating new component

Creating New Component

Component

ComponentType

name =‘Policy’

Component

ComponentType

name =‘House’

Component

ComponentType

name =‘Auto’

Component

ComponentType

name =‘Liability’

ComponentType

name =‘Liability’


Creating new component1

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


Advantages of aom

Advantages of AOM

  • Automate user interface

  • Automate database interface

  • Enable users to extend system

  • Automate other aspects of system

    • History

    • Workflow


Insurance framework summary

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.


Adaptive object model2

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


Aom and reflection

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”


Telecommunications billing

Telecommunications Billing

  • Database

    • customers

    • charges

    • network events (call, directory assistance, voice-mail)

    • billing plans

    • bills


Telecommunications billing1

Telecommunications Billing

Rating - converting network events into charges to customer

Billing - computing discounts, finance charges, etc - printing bills


Rating

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


Rating1

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’


Rating algorithm

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.


Reflection and the adaptive object model architecture

Type Object

type

Type

name

Entity

Properties

Property

name

value

NetworkEvent

NetworkEventType

BusinessEventType

BusinessEvent

Interpreter

Charge

+

*

PropertyRef


Similarities between systems

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.


Differences between systems

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


Global data

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.


History

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


Global data editor

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


Result

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


Adaptive object models

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.


Disadvantages of aom

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?


The poetry of the language

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”


Summary

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.


Summary1

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?


Reflection and the adaptive object model architecture

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


  • Login