AOM OOPSLA 2009

1
The Adaptive Object-Model Architecture Style – OOPSLA 2009 – October 2009, Orlando FL Copyright 2009, Joseph W. Yoder & The Refactory, Inc.
2
.melborp siht evlos ot euneva gnisimorp a si ti egnahc ot egdelwonk eht htiw elpoep eht
fo sdnah eht ni erawtfos egnahc ot ytiliba eht gnittup taht seveileb dna siht tuoba gnihtemos
od ot stnaw eH .egnahc ot drah oot llits si erawtfos skniht eoJ .stneilc rof segaugnaL cificepS
- niamoD gniyolped dna ,stnemnorivne TEN. dna avaJ eht htob ni gnikrow sedulcni krow tnecer
rehto siH .tnemnorivne TEN. eht gnisu erutcetihcra esirpretne no desab metsys tnemllifluf redro
na detcurtsnoc evah ohw srepoleved fo maet a seesrevo yltnerruc hpesoJ .stpecnoc eseht no
srepoleved srotnem dna sgnittes lairtsudni ni gnitseT dna ,gnirotcafeR ,ngiseD tcejbO ,snrettaP
ngiseD ,PX sa hcus sdohteM eligA sehcaet eH .sionillI ,anabrU ni sediser yltnerruc redoY hpesoJ
.erutcetihcra erawtfos ot hcaorppa eht ni seicallaf ynam detanimulli hcihw ,nrettap
duM fo llaB giB eht fo rohtua- oc si eH .POOCE dna ALSPOO , n o C Q ,OOAJ sa hcus secnerefnoc
ta sklat dna slairotut ynam nevig sa llew sa ,) PoLP( secnerefnoC gnimmargorP fo segaugnaL
nrettaP eht deriahc sah hpesoJ .tnempoleved erawtfos fo ytilauq eht gnivorpmi ot detacided
puorg a ,puorG edislliH ehT fo draob eht fo rahc eciv dna rebmem gnidnatsgnol a si redoY hpesoJ
.sn oitacilppa erawtfos fo sepyt ynam
no srepoleved derotnem sah eH .skrowemarF dna ,esueR ,gnirotcafeR ,smetsyS elbatpadA
,sdohteM eligA ,snrettaP ,klatllamS ,avaJ ,#C ,ngiseD dna sisylanA detneirO- tcejbO ni sezi
- laiceps hpesoJ .noitatnemelpmi dna ,ngised ,erutcetihcra erawtfos no rohtua
nrettap dna rekaeps lanoitanretni na si eoJ .tnempoleved erawtfos fo stecaf
lla fo gnirotnem dna gnitlusnoc ,noitatnemelpmi ,ngised ,erutcetihcra eraw
-t f o s n o d e s u c o f y n a p m o c a , . c n I ,y r o t c a f e R e h T f o e l p i c n i r p d n a r e d n u o f a s i
eH .tcapmi labolg htiw snoitazinagro dna seinapmoc ynam rof smetsys tsubor
depoleved sah dna ,s’0891 dim eht ni erawtfos htiw gnikrow nageb redoY hpesoJ
Short Instructor Bio
ACM 09/10.
OOPSLA'09, October 25–29, 2009, Orlando, FL, USA.
Copyright is held by the author/owner(s).
http://www.adaptiveobjectmodel.com
http://www.refactory.com
joe@refactory.com
The Refactory, Inc.
Joseph W. Yoder
their Business Models”
“Giving Users Control over
Architecture Style
Adaptive Object-Model
Object-

Table of Contents
Overview
Adaptive Object-Model Description
Core Architectural Elements of AOM
Some Examples of AOMs in Practice
Other Issues and Related Architectures
Advantages/Disadvantages
When to do and When not to do it
Summary
3

What are we doing?
Describing a “dynamic” architecture.
Not really “well-known”, known by a
few people. Has not been well
described. Becoming more popular.
Going to describe them with patterns.
Many Patterns work together to solve
the problem.

4

2

Context of the Style
Requirements change within
application’s domain.
Domain Experts know their domain best.
Business Rules are changing rapidly.
Applications have to quickly adapt to
new business requirements.
Changing the application is costly, it
generally includes code and data-storage.
There are cycles of: build-compile-release.
5

Forces – Shearing Layers

Who (Business Person, Analyst, Developer)
What (Business Rule, Persistence Layer,…)
When (How often, How fast)

There is a different rate of change
on the system.
Foote & Yoder - Ball of Mud PLoPD4
6

3

General Idea
Create an object design (meta-model) that
describes the domain objects which includes
attributes, relationships, and business rules as
instances rather than classes.
The domain objects are instantiated through a
description given by the user or domain expert.
Each new requirement is satisfied by creating a
new description and a new instantiation.
Separate what changes from what doesn’t.
Define Changes without Hand-Coding.
Focus on “What” Not “How”.
7

(Active|Dynamic Object-Model)

An ADAPTIVE OBJECT-MODEL is an object model
that provides “meta” information about the domain
so that it can be changed at runtime
e m i t- nur ta sterpretni ti taht ledom tcejbo ticilpxe
roivaheb sti segnahc metsys ,ledom tcejbo eht egnahc
ADAPTIVE OBJECT-MODELS usually arise from
domain-specific frameworks
Business rules are stored as descriptive (meta)
information in ADAPTIVE OBJECT-MODELS
Sometimes called a "reflective architecture“
or a "meta-architecture ".

8

4

Adaptive Object-Models
Represents classes, attributes, relationships,
and behavior as metadata.
Business knowledge is based on instances
rather than classes.
Users change the metadata (object model)
to reflect changes in the domain.
Stores its Object-Model in a database or in
files and interprets it (can be XML/XMI).
Consequently, the object model is adaptable, when you
change it, the system changes immediately.
9

Introduction of Metadata and
Adaptive (Active|Dynamic)
Object-Models
"Anything you can do, I can do Meta"
Metadata: If something is going to vary in
a predictable way, store the description
of the variation in a database so that it
is easy to change….Ralph Johnson
”Meta is Beta"
Code is Data, Data is Code – Everything is Data
10

5

Architectural Elements of
Adaptive Object Models

• Metadata • Entity-Relationship
• TypeObject • Strategy/RuleObjects
• Properties • Interpreters/Builders
• Type Square • Editors/GUIs

If you want something to change quickly,
you must push it into the data.
11

Type-Object
PLoPD3 - Johnson and Woolf

Before After
AirplaneM odel
-sharedAttributes
Airplane +typeOperations() : <unspecified>

1 -type

*
Boeing727 Boeing747 Boe ing757 Boeing767
... Airplane
-specificAttributes
+someOperations() : <unspecified>

12

6

Properties
Before After
Property
Car
Car 0..n
-name : String = color
- color : String = Any
attributes -type : String = String
- modelNumber : String = Any
- …. -value : String = Any

Example: A Store with Catalogue Entries
Sweaters (size, color, material)
Canoes (length, material)
Video Tapes (name, rating, category)

13

TypeSquare
Entity 0..n type EntityType

0..n properties
properties 0..n

PropertyType
Property

0..n type -name : String
-type : Type

Example: A Store with Catalogue Entries
)…,wolley,eulb,neerg,der(=roloc ,)LX,L,M,S(=ezis( sretaewS

)taolf=htdiw ,taolf=htgnel( seonaC
14

7

Entity-Relationship
supertype legal commissioner 1..n supertype

Accountability Type 0..n Party Type

legal responsible 1..n

0..n
1..n type type 1..n

0..n 0..n
commissioner 1..n

Accountability 0..n Party

responsible 1..n

0..n

Analysis Patterns - Fowler
15

An AOM Example

16

8

Newborn Screening

Doctor, HealthProf.
Hospital, Lab

Blood Specimen
Mother, Infant

17

Newborn Screening

Infants, Mothers and Doctors...
Person

+name : String
-address : String
-phone : String

Infant Mother Doctor LabTechnician

+gestetionalAge : Number

18

9

Newborn Screening

Hospital and Lab
Organization

+name : String
-address : String
-phone : String

Hospital Lab

19

Newborn Screening
Putting it all together
Organization
Person
+name : String
+name : String -address : String
-address : String -phone : String
-phone : String

Infant Mother LabTechnician Doctor Hospital Lab

+gestetionalAge : Number n

n
n 1..1 n n n 1..1

20

10

Refugee

VOLAG
Sponsor

Lab Tests
Medical Evaluations
21

Refugee
Person Organization
-name: String -name: String
-address: String -address: String
-phone: String -phone: String

Screening *
Results Refugee * Sponsor Volag

-testDate: aDate -originatingCountry
+refugees() +refugees()
+results() +familyMembers()
*
*

22

11

Entity-Relationship: Solution
supertype legal commissioner 1..n supertype

Accountability Type 0..n Party Type

legal responsible 1..n

0..n
1..n type type 1..n

0..n 0..n
commissioner 1..n

Accountability 0..n Party

responsible 1..n

0..n

Analysis Patterns - Fowler
23

Party and Accountability
Example

John Smith

Sue Smith

Sue is the mother of John
24

12

Party and Accountability
(instance diagram)

anAccountabilityType anAccountability
anAccountabilityType aParty aPartyType
<PARENT> <PARENT> name <Sue> <MOTHER>

aPartyType aParty anAccountability anAccountabilityType
<INFANT> name <John> <CHILD>

25

Dealing with Dynamic Behavior
Making methods that implement the different
algorithm for each Type or Property could
require a large case-statement and could be
impractical to maintain.
Instances for the similar types can have
different algorithm depending upon context.

• The model has to implements a defined set of
interchangeable algorithms that customize the
behavior of the system.
26

13

Strategies/Interpreters/RuleObjects
(Behavior/Methods)
SomeStrategy Entity
* 1
-sharedAttributes : someType -specificAttribues : type
+sharedInterface() * +someOperations()

...
Strategy1 Strategy2 StragegyN
t c ej b O e l u R
*
1

1

Strategy2.1 Strategy2.2 e l u R e vit i m i r P e l u R et i s o p m o C

n o iti d n o C D N A n oit i d n o C R O n o i ti d n o C T O N

Design Patterns - GOF95
Composite Strategies Interpreter
27

Composite Strategies

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

Solution: Make Composite
Strategies using Primitive
Operations.

=> Interpreter pattern
28

14

Adaptive Object Model
“Common Architecture”
htiw sessalC
dna setubirttA
spihsnoitaleR
roivaheB

lanoitarepO )atem( egdelwonK

29

Other Patterns
Composite – GOF
Interpreter – GOF
Builder – GOF
Mediator/Adaptor – GOF
Dynamic Hooks
History – Francis Anderson PLoPD4
Roles – Baumer, Riehle, Siberski, & Wulf
Fowler PLoP ‘97
RuleObject – Arsanjani PLoP2000
30

15

Interpreters / Builders
Application
Persistence
Mechanism

Database

Metadata Domain
Repository/Namespace Objects

XML Parser Interpreter/Builder

XML

31

Extending our Example

32

16

Medical Observation - First Model
Person * Observation

Measurement Trait
Quantity
traitValue
unit convertTo:
amount
expressOnUnit:
expressOnUnits:

PhysicalMeasure Blood
EyeColor HairColor Gender …

Height Weight FeedingType Hearing Vision
…

What happens when a new observation is required?
33

Observation Design

Person Observation
ObservationType
-recordedDate : Date
+address() -observedDate : Date -phenomenon : Symbol
+phone() -duration : TimePeriod
+name() +phenomenon()

Quantity
Measurement Trait
-unit : Unit
-amount : Number
+expressOnUnit(aUnit : Unit) +observationValue() +observationValue()
+expressOnUnits(unitCollection : Collection)

34

17

Observation Design
Example

Height: 3 feet

Eyes Color: Blue
Name: John Smith
Mother: Sue Smith
Father:
Address:
Phone:

35

Observation Design
(instance diagram)
aPerson
name <John Smith>
obsCollection

anObservationType
aMeasurement
#height
type
value

aQuantity
value <3>
unit <ft>

aTrait
type anObservationType
value <blue> #eyeColor

36

18

Composing Observations
Observations can be more complex
Cholesterol
Components: HDL, LDL
Blood Pressure
Components: Systolic, Diastolic
Vision
Components: Left Eye, Right Eye

37

Composite Observation Design
Person

+address()
+phone()
+name()

Observation
ObservationType
-recordedDate : Date
-phenomenon : Symbol -observedDate : Date 1..n
-duration : TimePeriod
+phenomenon()

Quantity
Measurement Trait CompositeObservation
-unit : Unit
-amount : Number -observations : Collection
+expressOnUnit(aUnit : Unit) +observationValue() +observationValue()
+expressOnUnits(unitCollection : Collection)

Composite Pattern (GOF)
38

19

Observation Design
Example

Height: 3 feet

Eyes Color: Blue
Name: John Smith
Mother: Sue Smith Blood Pressure:
Father: Systolic: 120 mmHg
Address: Diastolic: 80 mmHg
Phone:

39

Composite Observation Design
(instance diagram)
anObservType
<#BloodPressure>
aCompObs

aMeasurement anObserType
<120 mmHg> <#SYSTOLIC>

anotherMeasurement anObser-Type
<80 mmHg> <#DIASTOLIC>

40

20

Composite and Primitive
Observation Design
What we know about John?
aPerson
name <John Smith>
obsCollection

EyesColor: Blue Height: 3 feet BloodPressure: 120/80

Systolic: 120 mmHg

Diastolic: 80 mmHg

41

Validating Observations

Each Observation has its own set
of legal values.
Baby’s Weight: [0 30] pounds
HepatitisB: {positive, negative}
Left/Right Vision: {normal, abnormal}
GUI can enforce legal values
but we want business rules in domain
objects

42

21

Validating Observations Design
ObservationType
Validator

-phenomenon : Symbol
-validator : Validator

DiscreteValidator NullValidator RangedValidator

-descriptorSet : Collection -intervalSet : Collection
-validUnit : Unit

43

Overall Observation Design
Validator

DiscreteValidator RangedValidator NullValidator
Party descriptorSet intervalSet
validUnit

Observation
ObservationType recordedDate
type comments

Measurement Trait CompositeObservation
value value values
value value
value: value:
convertTo:

Quantity

Is everything an Observation?
How does the model specify the structure of the Composite?
What is the relationship between Trait and DiscreteValidator?

44

22

Observation Design
Validator
validatorName
ObservationType isValid: obsValue
phenomenonType
isValid: obsValue
descriptorSet intervalSet
validUnit
PrimitiveObservation CompositeObservation
Type Type Party

Observation
recordedDate
comments
isValid
Quantity
unit
CompositeObservation Primitive Observation quantity
observationValue convertTo:

DiscreteValues

Current Design

45

Observation Design
Validator
validatorName
ObservationType isValid: obsValue
phenomenonType
isValid: obsValue
validUnit
Type Type Party

Observation
recordedDate
comments
isValid
Quantity
unit

Operational level DiscreteValues

Current Design

46

23

Observation Design
Validator
validatorName
ObservationType Knowledge level isValid: obsValue
phenomenonType
isValid: obsValue
validUnit
Type Type Party

Observation
recordedDate
comments
isValid
Quantity
unit

DiscreteValues

Current Design

47

Observation Design
(instance diagram)

anObserv-Type
<#COMP-GAL>
aCompObs

aMeasurement anObser-Type aRangedValidator
<aQuantity> <#GAL>

anotherMeasurement anObser-Type anotherRangedValidator
<anotherQuantity> <#UDT>

48

24

Observation Design
(instance diagram)
anInfant
name aDiscreteValidator
anObservationType aRangedValidator
obsCollection
#GestationalAge
aMeasurement
type
value

aQuantity
value <36>
unit <weeks>
anObserv-Type
<#COMP-GAL>
aCompObs

aRangedValidator
aMeasurement anObser-Type
<aQuantity> <#GAL>

anotherRangedValidator
anotherMeasurement anObser-Type
<anotherQuantity> <#UDT>

49

Observations: TypeObject

ObservationType TypeObject
phenomenonType 1 descriptor 1..* Observation
isValid: obsValue instance recordedDate
1..* elements comments
elements 1..* isValid
Quantity
PrimitiveObservation CompositeObservation unit
Type Type value 1..* quantity
CompositeObservation Primitive Observation

Knowledge level DiscreteValues
dvalue 1..*
Operational level

50

25

Observations: Properties
Party

properties
1..*
1..* Observation
instance recordedDate
comments
Quantity
unit
value 1..* quantity
CompositeObservation Primitive Observation
Knowledge level
dvalue 1..* DiscreteValues
Operational level

51

Observations: TypeSquare
contDescr 1
ObservationType 1..* varType PartyType
phenomenonType 1 descriptor
isValid: obsValue 1 descriptor 1..*
1..* elements
Party

Type Type properties
1..*
1..* Observation
comments
Quantity
unit
value 1..*
Knowledge level

Operational level dvalue 1..* DiscreteValues

52

26

Observations: Strategy

1..* type
ObservationType Validator
phenomenonType guard 1
validatorName
isValid: obsValue isValid: obsValue
1..* elements

PrimitiveObservation CompositeObservation DiscreteValidator RangedValidator NullValidator
Type Type descriptorSet intervalSet
validUnit

Knowledge level
Operational level

53

Medical Observations Design
1..* type contDescr 1
Entities guard 1
Validator
validatorName
ObservationType 1..* varType PartyType isValid: obsValue
phenomenonType 1 descriptor
isValid: obsValue 1 descriptor 1..*
1..* elements
Party DiscreteValidator RangedValidator NullValidator
PrimitiveObservation CompositeObservation validUnit
Type Type properties
1..*
1..* Observation
Behavior
comments
Quantity
unit
value 1..*
Knowledge level

Operational level dvalue 1..* DiscreteValues

Attributes

54

27

What About Roles?
Problem: How do you deal with dynamic
behavior for an object? For example, a
person can be either a mother, child, or
doctor in our system.
Solution: Create a Role Object that
strategizes the behavior. A “role” is like
a pluggable strategy.

55

Roles
(an example)

Person 0..n PersonRole

+baseBehavior()

ChildRole DoctorRole MotherRole

+childBehavior() +doctorBehavior() +motherBehavior()

PLoP 97 - Fowler
PLoPD4 - Baumer, Riehle, Siberski, Wulf
56

28

Roles
(Parties, Accountabilities and Properties
is the Beginning of Roles)

In our system, there are different types
of parties, relationships between them,
properties on the parties which include
different observations about the parties.
The pluggable behavior (or different
roles) is defined for a given party by the
legal relationships it can have and the
set of properties they are allowed.

57

Roles
Babies
Have Mothers and Doctors
Gestational Age,
Hearing and Vision,
Weight, Race, Ethnicity, DOB, ...
Mothers
Have Babies and Doctors
Hepatitus present at Birth (y/n),
Languages, Race, Ethnicity, ...
58

29

Roles

aParty aPartyType
name <Sue> <MOTHER>

anAccountabilityType anAccountabilityType
<CHILD> <DOCTOR>

aParty aPartyType
name <John> <INFANT>

anAccountabilityType anAccountabilityType
<PARENT> <DOCTOR>

59

Other Issues
Persistence
Consistency (versions)
Dynamic GUIs
Managing Releases
Editors (Types and Rules)
Optimizers
…
60

30

Persisting AOM
The metadata is expressed with objects,
those objects can be mapped to relational
databases as well as object-oriented
databases
There is an increasing interest on persisting
metadata as XML/XMI files

61

Keeping consistency (versions)
It is important keeping consistency within the
metamodel while changing instances of
TypeObject or other object associated with
them.
Example: changing the legal range of a
Validator can make existing observations
invalid.
May have to keep version of the metadata
available and apply the rules based upon the
timeframe the rule applies.

62

31

Metamodel and GUI
The metadata can simplify building user
interfaces. Special GUI components can be
developed for using the metadata.
Example: The Observation model includes
widgets that display list of values from the
DiscreteValidators and also EntryBoxes that
use RangeValidator.
A Mediator and Adaptor layer was developed
for managing the interactions between the
domain objects and the GUIs.

63

Metamodel and GUI

64

32

PartyType: Metadata-Editors

65

Accountability: Metadata-Editors

66

33

Observation: Metadata-Editors

67


Primitive Observation
Type Editor

Composite Observation
Type Editor

68

34


69

Managing releases
The system has releases because of changes
in the metadata not only the code.
Changes in the metadata should be checked
by running test cases. Use of testing tools is
recommended.
Versions of the metadata has to be kept.
May have effective dates for the rules which
are represented by the metadata

70

35

36
72
Dynamic Views
kcorB-sfriW .R …can use …can use
, edoY.J
r
,ikcileW .L Renderer
…
several
Entity View coordinates Property
PLoP 2007 –
AOM Rendering Patterns
71
. ytilibatidua
dna ecnamrofrep sa hcus stnemeriuqer lanoitcnuf-non rof senilediug
edivorp ot pleh osla yehT .sMOA fo noitatnemurtsni dna ,lortnoc
,egasu eht tnemurtsni ot pleh taht snrettap sedulcni :suoenallecsiM
sMOA eht ot roivaheb gniyfidom
ro gnivomer ,gnidda yllacimanyd rof snrettap eht sedulcni :laroivaheB
sMOA fo secnatsni etaerc ot pleh taht snrettap eht sedulcni :lanoitaerC
.snoitacilppa ni sresu-
dne ot sMOA
tneserp ot woh htiw laed taht snrettap eht sedulcni : noitatneserP
.yrassecen naht dnoyeb raf slevel-atem eht ot pu gniog diova ot
seiradnuob dna skrowemarf gnivlove rof senilediug hsilbatse yehT .sMOA
gnitaerc fo ssecorp eht htiw laed taht snrettap eht sedulcni : ssecorP
.elyts larutcetihcra siht nrevog taht seno
eht era yeht dna snrettap cisab eht era esehT .sMOA fo noitatnemelpmi
cisab eht ni tneserp era taht snrettap eroc eht sedulcni :eroC
Part of a Larger Language

Other Production Examples:

Insurance
School Workflow
Many Many More …

73

User Defined Product
(insurance example)
-children * * -children
1 -rules *
Component -type ComponentType Rule

1 1
1 1 +valueUsing:()

1 1 -attributes

-attributes * *
* 1
*
Attribute AttributeType Constant CompositeRule
+name +value
-type +type 1 * 1
+valueUsing:()

*

TableLookup BinaryOperation

*

74

37

Argos Meta-Architecture
(document workflow example)

75

Argos Business Rule
(document workflow example)

76

38

Successfully Used For:
(some can be found in papers)
www.adaptiveobjectmodel.com
Representing Insurance Policies
Telephone Billing Systems
Workflow Systems
Medical Observations
Banking and Trading
Validate Equipment Configuration
Documents Management System
Gauge Calibration Systems
Simulation Software
77

Advantages of
Can more easily adapt to new
business requirements.
Smaller in terms of classes so
possibly easier to maintain by
experts.
Changes do not require recompiling
the system.
Business People can make changes.
Time to market can be reduced.
78

39

Disadvantages of
It demands having infrastructure for
storing, building, interpreting metadata.
Developing AOM can be expensive.
Can be hard to understand and
maintain.
It requires skilled human resources.
Can have poor performance.

79

Related Approaches
and Technologies
Generative Techniques
Black-box Frameworks
Metamodeling Techniques
Reflection Techniques
Domain Specific Languages
Table-driven Systems
UML Virtual Machine
Intentional Programming
Model Driven Architecture (OMG)
80

40

Black-box frameworks
These frameworks are instantiated by means
of parameterization and object creation.
They don’t need to have a meta-level.
They don’t need to have interpreters and
builders.
They both use very similar patterns (type-
objects, properties, strategies, …)

AOMs can be Black-box frameworks
but don’t have to be--and vice-versa
81

Code Generators
It provides infrastructure for transforming
descriptions of a system into code.
Descriptions are based on provided primitive
structures or elements.
Code generators produce either executable-
code or source-code.
Can use metadata and editors for describing
code to generate.

82

41

Metamodeling techniques
It focus on manipulating the model and meta-
model behind a system as well as supporting
valid transformations between different
model representations.
The attention is on the meta-model, or a
model or generating a model, rather than the
final application that will reflect the business
requirements.
This technique is used for describing the
domain-specific language.

83

Domain Specific Languages
DSLs can be a scripting language and work
by means of parameterization.
They don’t need to have a meta-level but
they often do.
They don’t need to have interpreters and
builders.
They both use solving similar patterns, they
just might do it in different ways.

AOMs can be a Domain Specific Language
but don’t have to be--and vice-versa
84

42

Table-driven Systems
Business rules can be parameterized and
stored in a database.
The running system can either interpret these
rules from a database table or the
appropriate function can be called with the
differing values from the database.
Sometimes these are implemented with
triggers and stored procedures.

85

Model Driven Architecture
MDA is highly related to AOMs

UML Virtual Machine is an AOM

UML Virtual Machine is an MDA approach

Focuses more on the modeling perspective

86

43

Object-
(Business Case)

Higher overall ROI
Higher flexibility to change
Cheaper to build applications
Foster business innovation
Incremental development and
prototyping

87

When AOM is the best solution?
Need for flexibility

High pace of business change

Need for experimentation

Need to empower user

88

44

Reasons for Failure of AOMs
Inadequate bridge between business and
technology level
Communication: different universe of
discourse
Unclear operations and deployment
structure
Takes too long to develop

89

Process for Developing AOMs
Developed Iteratively and Incrementally.
Be Agile, Scrum, XP, Retrospective
Get Customer Feedback early and often.
Add flexibility only when and where needed.
Provide Test Cases and Suites for both the
Object-Model and the Meta-Model.
Develop Support Tools and Editors for
manipulating the metadata.
Very similar to Evolving Frameworks
by Roberts and Johnson PLoPD3
90

45

Adaptive Object Model
“Common Architecture”
htiw sessalC
dna setubirttA
spihsnoitaleR
roivaheB

lanoitarepO )atem( egdelwonK

91

Dimensions of Abstraction
L3
language for
defining languages

L2 A language for defining domain specific software

L1 A specific software

L0 An execution of that software

Dimensions of abstraction in Adaptive Object-Models,
Reflection and OMG ’s metamodeling Architecture
Copyright by ECOOP’ 2000 workshop on Adaptive Object-Model. --- http://www.adaptiveobjectmodel.com/ECOOP2000/description.html
92

46

OOPSLA Poster Session

93

Summary
Adaptive Object-Models can take time to
develop -- but the payoff can be enormous!
Adaptive Object-Models work based upon
domain expert knowledge.
Adaptive Object-Model architectural style
exposes the elements of the domain and
business rules.
Applying well-known design principles (e.g.
TypeObject, Properties, Entity Relationship,
and Strategies/RuleObjects) works well for
developing systems that dynamically adapt
to a changing (business) environment.
94

47

AOM OOPSLA 2009

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a AOM OOPSLA 2009

Semelhante a AOM OOPSLA 2009 (20)

Último

Último (20)

AOM OOPSLA 2009