Reflection and the adaptive object model architecture
Download
1 / 49

Reflection and the Adaptive Object Model Architecture - PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Reflection and the Adaptive Object Model Architecture' - shelly


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


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 for each kind of policy.

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 for each kind of policy.

  • 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


Composite for each kind of policy.

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 for each kind of policy.

  • 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 for each kind of 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 for each kind of policy.

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 for each kind of policy.

  • 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 for each kind of policy.

  • Automate user interface

  • Automate database interface

  • Enable users to extend system

  • Automate other aspects of system

    • History

    • Workflow


Insurance framework summary
Insurance Framework Summary for each kind of policy.

  • 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 for each kind of policy.

  • 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 for each kind of policy.

  • 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 for each kind of policy.

  • Database

    • customers

    • charges

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

    • billing plans

    • bills


Telecommunications billing1
Telecommunications Billing for each kind of policy.

Rating - converting network events into charges to customer

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


Rating
Rating for each kind of policy.

  • 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 for each kind of policy.

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 for each kind of policy.

  • 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.


Type Object for each kind of policy.

type

Type

name

Entity

Properties

Property

name

value

NetworkEvent

NetworkEventType

BusinessEventType

BusinessEvent

Interpreter

Charge

+

*

PropertyRef


Similarities between systems
Similarities Between Systems for each kind of policy.

  • 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 for each kind of policy.

  • 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 for each kind of policy.

  • 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 for each kind of policy.

  • 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 for each kind of policy.

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 for each kind of policy.

  • 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 for each kind of policy.

  • 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 for each kind of policy.

  • 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 for each kind of policy.

“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 for each kind of policy.

  • 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 for each kind of policy.

  • 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?


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


ad