Rendering Patterns for Adaptive Object-Models

León Welicki Joseph W. Yoder Rebecca Wirfs-Brock

ONO (Cableuropa S.A.) The Refactory, Inc. Wirfs-Brock Associates
Basauri, 7-9 7 Florida Drive 24003 S.W. Baker Road
28023, Madrid, Spain Urbana, Illinois USA 61801 Sherwood, Oregon USA
+34 637 879 258 1-217-344-4847 1-503-625-9529
lwelicki@[Link] joe@[Link] rebecca@[Link]

ABSTRACT using the PROPERTY pattern [5]. The TYPE OBJECT pattern is
An Adaptive Object-Model is an instance-based software system used again to define the legal types of attributes, called
that represents domain-specific classes, attributes, relationships, PropertyTypes. Thus Entity, EntityType, Property, and
and behavior using metadata.. This paper presents three patterns PropertyType are the core set of constructs used to represent
for visually presenting and manipulating AOM domain entity Adaptive Object-Models [13].
objects. An Adaptive Object-Model expresses relationships between
entities using metadata. Any rules and constraints governing these
Categories and Subject Descriptors relationships can also be described with metadata. In contrast,
D.1.5 [Programming Techniques]: Object-oriented with traditional object-oriented programs, relationships between
Programming; D.2.2 [Design Tools and Techniques]: Object- domain entity objects are implemented via a direct reference or an
oriented design methods, User Interfaces; D.2.11 [Software appropriate structuring object (e.g. hash table or a collection).
Architectures]: Patterns Constraints on relationships are implemented by methods in
related classes.
General Terms
Design In an Adaptive Object-Model, the STRATEGY pattern [6] can be
used to define the behavior of EntityTypes. If behavior is
Keywords complex, instead of using Strategies, an interpreted rule-based
Visual Rendering, Adaptive Object-Models, Patterns language can be defined. In contrast, with a typical object-
oriented programming language implementation of an entity,
1. INTRODUCTION simple behavior is typically implemented in class methods.
An Adaptive Object-Model is an instance-based software system
that represents domain-specific classes, attributes, relationships, The above core AOM patterns have been described previously.
and behavior using metadata [19, 20]. Typically in an Adaptive One area that has not been described are how to implement the
Object-Model, metadata descriptions are stored in a database and user interface in an AOM system. Since an AOM is instance
interpreted at runtime. This is similar to a UML Virtual Machine based rather than class based and has metadata which drives
described by [12]. The object model is adaptable and tools are domain entity behavior, interpretation of the entities needs to be
often provided with AOM systems that allow end users or domain considered when constructing a user interface. This paper
experts to edit and change these metadata descriptions. So when describes patterns for dynamically building the GUI layer which
changing requirements cause the domain model to be updated, end supports the modification and visualization of AOM domain
users edit metadata. These changes can immediately be reflected objects.
in the running system without any software program changes.
2. TOWARDS AN ADAPTIVE OBJECT-
In contrast, in a typical object-oriented program, classes are MODEL PATTERN LANGUAGE
designed to represent domain entities and their attributes. A Adaptive Object-Model architectures are usually made up of
change in requirements that results in changes to the domain several smaller patterns. In the existing literature they are
model causes developers to modify and/or add new classes, documented by the patterns TYPE OBJECT, ATTRIBUTES,
leading to a new application version. PROPERTY LIST, TYPE SQUARE, ACCOUNTABILITY
Adaptive Object-Model architectures are typically made up of (Entity-Relationship), STRATEGY, RULE OBJECTS,
several interrelated patterns. TYPE OBJECT [8] is used to define COMPOSITE, BUILDER, and INTERPRETER.
a domain entity. An entity has attributes, which are represented
Besides these patterns, less widely-known patterns are often used
Permission to make digital or hard copies of all or part of this work for in AOM systems. In the AOM current literature descriptions of
personal or classroom use is granted without fee provided that copies are these other patterns are scattered among a number of different
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
PLoP'07, September 5-8, Monticello, IL, U.S.A..
Copyright 2007 Hillside Group.
Figure 1 - AOM Pattern Language Map
patterns papers with different templates and styles. Additionally, Entity View: describes the coordination of several property
not all these papers work through similar examples. Some patterns renderers to produce more complex UI fragments for an entity
have not been updated to reflect implementation trends, new (rendered from descriptive data from the type objects).
programming language environments or development platforms. Entity-Group View: given a set of entities, renders UI code
We ultimately see the patterns described in this paper as part of a (including layout issues). Several different views can exist for the
more complete pattern language for building Adaptive Object- same set of entities and they can be linked dynamically at run-
Models. Patterns in this pattern language are organized into these time (useful to present a set of entities).
categories:
The patterns presented in this paper are interrelated. While they
Core: patterns that represent the basic implementation of can be used individually, more commonly they are used in
AOM entities, their behavior and relationships. They are the
ones that govern this architectural style.
Process: patterns that describe how to create and evolve Property Renderer coordinates several… Entity View
AOM systems. They establish guidelines and advice on when
and where the use of meta-description based approaches is
warranted.
can use… can use…

Presentation: patterns which describe how to visually Entity-Group View

represent and manipulate objects representing domain

entities, their attributes and relationships to other objects in
an AOM.
Figure 2 - Rendering Patterns Map
Creational: patterns for creating instances of AOMs
combination. Figure 2 shows the relationships between these
Behavioral: patterns for dynamically adding, removing or rendering patterns. The most fine-grained pattern is PROPERTY
modifying AOM system behavior. RENDERER, which renders individual property instances. It is
connected with all the other patterns: an ENTITY VIEW
Miscellaneous: patterns for instrumentation, usage, and
coordinates several PROPERTY RENDERERS to generate a
version control of AOMs. These patterns also provide
fragment of a UI for an entity, and the ENTITY-GROUP VIEW
mechanisms which support non-functional requirements such
uses these elements to render a set of entities. The ENTITY-
as performance or auditing.
GROUP VIEW is coarser-grained, since it generates a coherent
Figure 1 from [19] is a map of our AOM pattern language as UI for related entities. To implement its behavior it can either use
presented at the OOPSLA 2007 Poster Session. the other patterns or be hand coded.
Patterns presented in this paper discuss presentation concerns
2.1 THE AOM VISUALIZATION LAYER which arise when working with AOMs. Therefore, any developer
In the existing literature [5, 14, 20, 21, 22], the core architecture working with this kind of systems (mainly TYPE OBJECT,
of AOMs is represented by two different levels: PROPERTIES [8], and TYPE-SQUARE [20] or DYNAMIC
Knowledge Level: which defines the general rules that OBJECT MODEL [13] based architectures) can benefit from
govern the behavior [4] and the structure of domain using these patterns to visually represent and manipulate AOMs.
entities (TypeObjects, PropertyTypes). These rendering patterns may apply also to other rendering
Operational Level: which contains instances of the scenarios, but our main focus is on AOM-based architectures. We
domain (in our case, instances of entities and properties describe these patterns in that context. Use of these patterns in
for representing values) whose behavior is governed by other contexts is outside the scope of this paper.
associated objects in the knowledge level [4] If you are unfamiliar with Adaptive Object-Model based systems,
Because of the way objects are represented in the operational you will need to become familiar with the core AOM patterns
level, a specialized rendering layer is almost always needed. It before you can appreciate the rendering patterns described in this
consists of “ instructions” for how to construct the UI which paper. An appendix at the end of this paper briefly explains the
presents AOM domain objects for viewing and modification. This core concepts and patterns of AOM systems. We invite the reader
visualization behavior is embodied in rendering components visit to [Link] for additional publications
which can be composed at runtime (from configuration that offer more comprehensive discussions and examples.
information) and combined dynamically (and adaptively) to 3.1 Shared Pattern Context
generate complex views of AOM domain objects. Separating this All the patterns in this paper share the same basic context
behavior into a rendering layer allows us to abstract and scenario: You are creating an application using an Adaptive
encapsulate presentation issues [17]. Object-Model. This model relies on a variant of TYPE SQUARE and
therefore you are using a combination of TYPE OBJECT and
3. AOM RENDERING PATTERNS PROPERTIES patterns. Each pattern then adds its own issues and
This paper contains the following patterns: forces to this general context and presents a problem accompanied
Property Renderer: describes how to render the UI code for with its respective solution.
instances of specific properties using their data.
3.2 Property Renderer You want to encapsulate the rendering code.
3.2.1 Context You want to avoid rendering code duplication.
You want to render the entities in your model using a standardized You want rendering aspects to be composable into more
approach. You want to minimize code redundancy and present a complex visual representations.
GUI with a consistent look and feel.
You want your UI code to evolve independently of entities.
3.2.2 Example
Imagine youʼ ve created a Content Management System (CMS) You want to vary the way a property is rendered according to
using AOM patterns. New content types can be created by end its rendering context (e.g., target device, state of the
users. A tool allows them to compose several pre-defined property application, client options, etc.).
types. For example, an instance of a content of type Document
You donʼ t want to bloat rendering code with conditional
may be composed of a property called “ name” that is of type
statements to handle each rendering context.
“ string property” , a property called “ description” also of type
“ string property” , and another property called “ binaryElement” 3.2.5 Solution
that is of type “ binary property” . Your system is implemented Create rendering objects that have the responsibility for
using common variant of TYPE SQUARE pattern. rendering the UI for a certain type of property within a given
You have several applications that rely on this Document entity. context. Each rendering object will encapsulate the way an
Application create instances of entities based on the “ Document” instance of a property of a concrete type (when TYPE OBJECT
type object and present them to users in a UI. Each time you want pattern is applied) is visualized in a certain context. We call these
to render a property, you have to write very similar rendering objects “Property Renderers” .
code. Your code for rendering each type of property may in the A PROPERTY RENDERER contains code that generates the UI for an
best case be duplicated in all your applications. In the worst case, instance of a property in a particular context. This renderer is
it may be duplicated in each visualization layer as well as coupled both with the property type (it knows how to handle it)
additional application code (for example, when rendering the and the target context (it knows how to generate appropriate UI
name and description properties of the document two different code for it).
pieces of very similar code may be invoked).
To start, provide a default PROPERTY RENDERER implementation
This redundancy leads to a higher degree of maintenance and that generally knows how to interpret all properties and to
potential inconsistency in your UIs. Slightly different approaches generate minimal UI code targeted to a prototypical context. This
may exist in each application for rendering the same type of default implementation may not accurately render the property or
properties (for example, each application may render differently generate nice UI code, but allows you to marginally render any
the “ binary” properties). property in any context. While this default implementation is
3.2.3 Problem likely not suitable for production code, it can be useful when
How can you encapsulate how the properties of different types are prototyping or evolving an adaptive system.
rendered? Then, define individual PROPERTY RENDERERS as needed.
3.2.4 Forces Each PROPERTY RENDERER will be responsible for rendering a
concrete visualization of some specific property type, and may be
An entity may have several properties of different types and specialized for a concrete context (it may be included in a Web
the properties can be attached to and detached from entities Form, an e-Mail, a report, etc.). Since individual property
at any time. renderers are specific and “ fine-grained” they can be combined to
You want to ensure UI consistency across applications. create complex UI visualizations (see ENTITY VIEW and ENTITY-

Figure 3 - Property Renderer Structure

GROUP VIEW). Since properties are fine-grained elements with specific
PROPERTY RENDERERS enforce a strong separation between the responsibilities they can be easily combined to create more
domain entities and their visualization, isolating all presentation complex visual representations.
related code into distinct objects. The base PropertyRenderer class provides a generic
Figure 3 shows the UML class diagram of the solution. implementation that allows for rendering any entity,
PropertyRenderer is the base class for all the renderers and facilitating prototyping and evolving adaptive systems.
provided default implementations for behaviors that each concrete A PropertyRenderer is strongly coupled with its
renderer must redefine. As shown, PropertyRenderer has respective PropertyType.
two methods: one for rendering a property, render(), and other
for receiving sets of parameters setParameters() (parameters A PropertyRenderer is coupled to its rendering context.
can be any arbitrary piece of data to be used in the rendering The indirection found in this solution can lead to lower
process). Subclasses of PropertyRenderer can either be performance than in a non-AOM system.
primitive (stand-alone renderers of strings, numbers, dates, etc.) or
composite (combining several renderers to create more complex
output). Instances of PROPERTY RENDERERs are created using a
factory (PropertyRendererFactory). Finally, the Client
uses the PROPERTY RENDERERs to compose the UI.
3.2.6 Example Resolved
Thus you can create a PropertyRenderer class for each type
of Property and use it in all applications. In our example, two
renderers may be created: one for the StringProperty and
other for the BinaryProperty. These renderers may be used
in all applications, giving consistency to their UIs and simplifying
maintenance (the property rendering code is in a single well-
known location).
Figure 4 - Example Property Renderers for
In Figure 4 four property instances are shown (the name of the
Generating Data Entry HTML UI Widgets
property is in bold and the property type is in italic below the
name). In this example, some property renderers are applied to 3.2.8 Related Patterns
instances of properties to render data entry UI widgets in a web PROPERTY RENDERERS are a special type of STRATEGY concerned
application. All the properties shown (Title, Description, with the generation of UI code for instances of properties of a
BinaryElement and DateCreated) belong to the Document entity given property type.
type. The PropertyRenderers create the appropriate UI PROPERTY RENDERERS instances can be created using a FACTORY.
elements for the properties. Note that in the example: 1) the UI
elements have a standardized look and feel and behavior which PROPERTY RENDERERS instances can be created using a PRODUCT
provides a consistent user experience; and 2) the property TRADER. If so, the rules for selecting one renderer or another are
renderers could also contain additional logic which analyzes not hardcoded in the factory but determined at run-time using
certain characteristics of the properties used when producing the Specification objects [3].
appropriate UI elements (for example, a string property renderer PROPERTY RENDERERS have code for rendering the PROPERTY
might analyze the length of the input text and produce an TYPES of the PROPERTIES instances when using TYPE SQUARE.
appropriately sized single text box or a text area for data entry).
ENTITY VIEW organizes the way several PROPERTY RENDERERS are
3.2.7 Resulting Context combined to generate a UI code fragment.
Responsibility for rendering instances of properties of PROPERTY RENDERER performance can be improved using
concrete types is assigned to fine-grained rendering objects. CACHING [11].
UI code is separated from entities and encapsulated in PROPERTY RENDERER can be combined with FLYWEIGHT [6] to
specialized property renderers. improve performance and resource utilization of pre-allocated
UI code can evolve independently from the model consisting rendering instances.
of entities, properties and relationships between them. ANYTHING [15] have a similar abstraction called Renderers, but
New PropertyRenderers can be created, allowing for with a more broad scope. If you want to use this pattern to render
dynamic change in how instances of property of a specific ANYTHING instances, the PROPERTY RENDERER can be seen as
type are rendered. specialized instance of such renderers.
PropertyRenderers can contain context-related (target 3.3 Entity View
device, purpose, state, etc.) presentation code, eliminating
complex conditional code in the UI (e.g. a different
3.3.1 Context
To encapsulate and abstract the presentation you are using
PropertyRenderer might exist for each kind of target
PROPERTY RENDERER. You have several property renderers and
device).
want to coordinate them and produce a more complex output. This
output may be a fragment of the UI or a complete screen.
 Figure 5 - Entity View Structure
An entity contains one or more properties that need to be rendered To simplify the coordination of compositions of renderers a
and might have different views. Domain Specific Language might be created.
3.3.2 Example The ENTITY VIEW is aware of its rendering context (target device,
Consider again the CMS example presented previously (see state, etc.) and therefore must contain instances of the suitable
Example section in PROPERTY RENDERER) and the Document property renderers for that context. It may also contain additional
entity. contextual information used when rendering.
You may want several ways to render the properties for a The ENTITY VIEW may have several constraints (such as
Document entity. For instance, you may want to render it as a validations, rules, etc) that are used while rendering an entity. You
form for editing purposes or as a set of text fields for can create new types of constraints, by creating a new
visualization. You have property renderers for each kind of specialization of the abstract class EntityViewConstraint,
property, but you will have to coordinate each screen to produce for use in an EntityView. When the constraints are applied, a
desired behavior. This could result in duplicate code within the variant of the WARNING MESSAGE ACCUMULATOR pattern [1] can
same application or lack of consistency across applications. be used and consequently a set of ConstraintResult
instances may be returned. It is important to stress that the
3.3.3 Problem constraints included are focused on UI concerns such as client
How can you coordinate several property renderers to render a side data validations. Any other business validation or rule
complex UI fragment for different views of an entity? enforcement should be delegated to the domain specific
3.3.4 Forces constraints associated with the core AOM instance being rendered
You want to combine several property renderers to and not be located in presentation-layer code.
produce a complex UI fragment for an entity. The ENTITY VIEW will primarily be used to generate fragments of
UI fragments should be easy to change. the UI for an entity, although it could also generate a full page.

The resulting structure should be easy to change. Figure 5 presents the UML class diagram of the solution. The
abstract class EntityView defines the public interface and basic
You donʼ t want redundant UI code. behavior of all entity views. It also maintains a set of
PropertyRenderer instances (see the PROPERTY RENDERER
You may want to use different sets of fragments in
different contexts (for example, you may use different pattern in this paper) which are coordinated to generate UI code
renders for a mobile device than for a web browser). for an entity instance. The concrete EntityViews can be leafs
(stand-alone views) or composite (composing several entity views
3.3.5 Solution to generate the output). An EntityView receives context
Create view components which coordinate the presentation of information from its associated RenderingContext. Some
several property renderers of an entity to produce different constraints can be applied to the orchestration process (classes
complex UI fragments. Each property renderer is specialized to EntityViewConstraint, Validation and Rule). These
generate UI code for instances of a property type in a certain constraints can be composed to create dynamically complex
context. A view component will coordinate several fine-grained validation or composition rules.
renderers and produce more complex UI code for an entity.
3.3.6 Example Resolved
The sequence and composition of renderers could be specified
You can create two different kinds of EntityViews: ones for
using source code or with metadata stored in a database or a file.
editing and others for visualizing. These views may be used in all
 Figure 6 - Entity View Example

Figure 6 - Entity View Example

applications, giving consistency to their UIs (the same group of The indirection interpretation of metadata found in this
elements is rendered in a consistent way in all applications) and solution can lead to lower performance than in a non-AOM
simplifying maintenance (the property renderer coordination code system.
is in a single, well-known location).
In Figure 6, two EntityViews are shown: the first, called 3.3.8 Variants
EditableEntityView, allows for editing an instance of an Form Entity View: orchestrates several property renderers to
entity (in this case to create a new Document entity representing create a form for data input. It may also contain constraints which
the paper “ Dynamic Object Model” [13]). Notice how all the establish input validations, and rules for showing or hiding groups
editing UI widgets shown are the same as those shown previously of renderers, etc.
in Figure 4 for the PROPERTY RENDERER pattern. The second Table Row Entity View: orchestrates several property renderers
EntityView, called ReadOnlyEntityView, in the lower to create a table showing an each entity in a row of a grid. To
section of the figure renders a read-only representation of the show a full grid this Entity View must be applied to a set of
Document entity. In this view no Document entity properties entities in an ENTITY-GROUP VIEW.
can be edited. Note that this EntityView shows additional Selection of Fields Entity View: in this case the view selects a set
Document properties. of the fields of an entity type (or a discrete set of property
3.3.7 Resulting Context instances) and generates the output. For example, you can have
UI composition of rendering entities can be abstracted, several views for a type of entity where each view shows a
encapsulated and easily modified. different subset of entity properties. For example, in case of an
entity type “ Patient” you could have an entity renderer that only
The rules for showing an instance of an AOM entity can be shows its contact info and another one that shows only the ID, the
modified dynamically at runtime. name and the birth date.
The rules for showing an instance of an AOM entity can be Full Display Entity View: this view displays all the fields in the
modified declaratively (when rules are stored as metadata). entity type or the provided set of property instances.
The rules for showing an entity are explicitly stated. Rule Based Entity View: this more complex entity view selects
It is easy to change the way entities are shown. the property renderers to be used by applying rules. For example,
you may have an entity view that shows or hides fields according
Better adaptability to new visualization requirements.
to profile of the target user.
More flexibility in constructing different visualizations than
with hand-coded solutions. 3.3.9 Related Patterns
An ENTITY VIEW coordinates several PROPERTY RENDERERS.
This introduces more complexity in the form of additional
ENTITY VIEW can be seen as a typed COMPOSITE of PROPERTY
classes and interpretation of metadata.
RENDERERS for displaying entities.
ENTITY VIEW generates output using PROPERTY RENDERERS; rendering algorithm that could be applied to different contexts.
ENTITY-GROUP VIEWS display a set of related entities. Additionally, if you want to reuse the UI generation code for
RENDERING ORCHESTRATOR performance can be dramatically another application you wonʼ t be able to, since it would be
enhanced using CACHING [11]. contained in a page and therefore could not be reusable artifact in
another application (in the best case, you might copy the page, but
ANYTHING [15] has a similar abstraction called Renderer, but with if you want to change a single feature of that “ common page” , you
a broader scope. To use this pattern to render ANYTHING would need to modify all instances of that page in all client
instances, you can construe ENTITY VIEW to be a specialized applications).
instance of such renderers.
3.4.3 Problem
3.4 Entity-Group View How can you abstract the visualization (including the complex
3.4.1 Context layout) of a set of dynamic entities from an AOM so as to
You want to generate UI code for several entities but you donʼ t decouple this visualization from the model?
want to have any kind of coupling or to reference the UI in your 3.4.4 Forces
model. Additionally you may want to attach or detach views to You want to be able to attach and detach views
models, allowing for different views of the same entity to be dynamically to sets of entities.
selected dynamically. You want several views applied to the same
model and you want to have the possibility of selecting any of You want to abstract layout details.
them according to arbitrary decisions. You want to render several entities in the same
presentation.
3.4.2 Example
You are developing a Web-based Content Management You want to reuse that rendering code in different
application (the one quoted in the Property Renderer pattern). You contexts.
built a Document Management module on top of the CMS engine. You donʼ t want redundant UI code.
This content management module has entities Document and
You want to have control of all the generated UI code.
Link that are contained in Categories (a special kind of
entity which contains other entities). Categories simulate You may not be using PROPERTY RENDERERS or ENTITY
Folders in the document management module. VIEWS.
When using PROPERTY RENDERERS or ENTITY VIEWS
Whenever a user selects one Folder, its contents (the contained you may want to add additional UI code (layout code,
entities) should be displayed in one of several ways depending on glue code to give consistency and context to the
the specific context. You want to be able to attach and detach renderer properties, or perhaps code unrelated to
views to the folders. For example, a thumbnails view might only entities).
be applied to folders which contain images. Views should be
easily linked to and unlinked from categories, allowing users to 3.4.5 Solution
specify how they want to view folder contents according to their Abstract the UI code generation into a view component that
preferences. processes a set of entities to produce UI code. The
EntityGroupView is a component specialized in generating
Having the UI generation code static on a web page is not a very
UI code for a set of one or more entities. It will produce the
good idea because it would complicate your abstraction of a
appropriate UI code according to the purpose of the view. As in
cd Attachable View s

EntityGroupView

+ Render(Entity[]) : object
+ SetParameters(Hashtable) : void

ConcreteEntityGroupView A ConcreteEntityGroupView B ConcreteEntityGroupView C

- propertyRenderers: ProperyRenderer[] - orchestrator: EntityView

PropertyRenderer
EntityView
- id: string
+ Render(Entity, RenderingContext) : object
1..* + SetParameters(Hashtable) : void
+ Render(Property) : object
+ SetParameters(Hashtable) : void + ApplyConstraints() : ConstraintResult[]

Figure 7 - Entity-Group Views Structure

MVC, the view components present information to the user. Folder and views its contents, it is displayed on a container that
Different views can then present the information in the model in allows the user to select any of the views attached to the folder.
different ways. Whenever the user selects one of them it generates the appropriate
The EntityGroupView can contain complex layout logic. The UI code (delegated to the concrete View) as shown in Figure 8.
layout code may even allow dynamic set up and modification of In this example, a set of documents can be rendered in several
the layout (for example like the models in WinForms [9] or Swing ways (detailed list, big icons, and thumbnails).
[7]) or may represent in a fixed way a specific set of entities (the You could also define more views and attach them to any
layout is hard-coded in the view). category. For example, for a particular set of folders may need to
The views can generate all UI code from scratch or can use have some special rendering logic such as hiding documents older
PROPERTY RENDERERS and ENTITY VIEWS. than three weeks. To achieve this, you would create a new view
and attach it to the appropriate folders.
Several views may render the same set of entities. The views can
be linked to the entities (and entity types) dynamically, allowing 3.4.7 Resulting Context
easy run-time adaptation through the creation of multiple-view UI composition can be abstracted, encapsulated and easily
based interfaces. modified.
Figure 7 shows a UML class diagram of the solution. The abstract The rules for showing sets of entities can be modified
class EntityGroupView defines the public interface and dynamically at runtime.
default behavior of all EntityGroupViews. Concrete The rules for showing sets of entities can be modified
EntityGroupView subclasses can generate their output using declaratively (when they are stored in metadata).
several approaches: using Property Renderers
(ConcreteViewA), using Entity Views (ConcreteViewB) or The rules for showing sets of entities are explicitly stated.
generating all UI code themselves (ConcreteViewC). It is easy to change the way sets of entities are shown.
3.4.6 Example Resolved Better adaptability to new visualization requirements.
If the UI rendering code for an EntityGroupView is More flexibility.
represented as metadata, it can be stored in a views repository.
This can then be linked to existing entities in order to generate UI More complexity.
code for them. Lower performance.
In our example, several views are created (e.g. Details View, 3.4.8 Related Patterns
Icons View and Thumbnails View) and then linked to the ENTITY-GROUP VIEWS can use several PROPERTY RENDERERS.
categories that represent the folders. When the user selects a
ENTITY-GROUP VIEW can use several ENTITY VIEWS.

Figure 8 - Several views applied to the same entities.

ENTITY-GROUP VIEW instances should be created using a documents), ReadOnlyEditableEntityView (for viewing
FACTORY. instances of Document entities), and
ENTITY-GROUP VIEW can be seen as a special type of STRATEGY TableRowDocumentEntityView (for rendering a row for a
that is concerned with the generation of UI code for sets of table of entities). These kinds of Entity Views were addressed in
entities. the Variants section of the Entity View pattern.
An ENTITY-GROUP VIEW can be applied in MODEL VIEW These patterns work together to provide a consistent and reusable
CONTROLLER [10] scenarios. way for rendering AOM properties and entities. However,
rendering concrete properties or entities is not enough to create
ENTITY-GROUP VIEW performance can be dramatically enhanced
the UI for our example document management application. To
using CACHING [11].
address this final gap we need to use the ENTITY-GROUP VIEW
4. Putting It All Together pattern to create several coherent fragments of UI for entering and
This paper presented a set of patterns for dealing with dynamic retrieving Document entity instances. We thus create several
presentation of Adaptive Object-Models. Each pattern presented EntityGroupViews that use the PropertyRenderers and
in this paper address the rendering problem at a different level of EntityViews outlined in previous steps. These views can be
granularity as shown in Figure 9. dynamically linked to sets of Document entities to produce fully
We used as an example building an application on top of a CMS functioning and consistent UI fragments. The
system that is based on an AOM. In our CMS we created a EntityGroupViews have content layout code such as in the
Document entity type that contained several properties for case of the DocumentGridDynamicView which uses several
storing the title, description, binary element (e.g. word, pdf, excel, TableRowDocumentEntityViews for generating an HTML
etc.), creation date, and author of a document. These Document table of Document entities.
entity types are stored in Categories, which are abstractions There is a very important issue in the solution we present:
that gather several instances of entities (in our case Document performance and resource usage can be prohibitive, leading to a
entities). We wanted a consistent UI decoupled from the poor user experience and degradation of service scenarios
application logic that could be easily changed and reused (especially for web applications). To address these problems we
throughout this application or other systems. propose the careful use of CACHING [11, 15]. We propose several
levels of caching according to what we are trying to render: we
Coarse
grained
can have caches for a property type (applied to PROPERTY
Entity-Group View Sets of Entities RENDERER), for an entity (applied to ENTITY VIEW), or for set of
entities (applied to ENTITY-GROUP VIEW) [18]. The decision on
Entity View Single Entity how to apply caching should be carefully considered, keeping in
mind that caching, too, adds considerable complexity to an
application. Additionally, we might enhance the performance and
Property Renderer Single Property
resource usage of the application by applying other patterns (like
Fine
grained POOLING, LAZY ACQUISITION, etc. [11]).
There are also several other high level patterns for dynamic screen
Figure 9 - Granularity level of the patterns in the language. layout of the entities and properties which have not been
Since we wanted to render consistently all the properties of addressed in this paper. The authors intend on addressing these at
similar types, we determined to use the PROPERTY RENDERER a later date.
pattern to generate the UI widgets for each property type. The first
step was to create a PropertyRenderer for each
5. ACKNOWLEDGEMENTS
We would like to thank our shepherd Dirk Riehle for his great
PropertyType in Document: one for strings, another for help and advice for improving the contents of this paper. We
binaries and one for dates. Thinking more deeply, we quickly would also like to gratefully thank to the participants of the PLoP
realized that this is not enough: in some cases, we need two 2007 “ Sun Singer” Writers Workshop (Richard Gabriel, Ricardo
renderers for each property type, one for editing it and another for Lopez, Jason Yip, Christian Kohls, Scott Henninger, Avraham
visualizing it. Therefore, we created these six property renderers: Zilverman, and Vibhu Mohindra) and to the OOPSLA 2007 Mini-
StringInputPropertyRenderer PLoP writers workshop participants (Peter Sommerlad, Ademar
Aguiar, and Andre Santos).
FileInputPropertyRenderer
DateInputPropertyRenderer
StringPropertyRenderer 6. REFERENCES
[1] Ahluwalia, K. Warning Message Accumulator Pattern. 13th
FilePropertyRenderer Pattern Language of Programs Conference (PLoP 2005),
DatePropertyRenderer Monticello, Illinois, USA, 2005.
[2] Adaptive Object-Models.
After our renderers were created, we needed to establish how to
[Link]
present Document entities to end users. We used the ENTITY
VIEW pattern to generate the UI for the entities. We applied the [3] Bäumer, D ; D. Riehle. Product Trader. Pattern Languages
ENTITY VIEW pattern three times to create the following views: of Program Design 3. Edited by Robert Martin, Dirk Riehle,
FormDocumentEntityView (for creating and editing and Frank Buschmann. Addison-Wesley, 1998.
[4] Fowler, M. Analysis Patterns: Reusable Object Models. [15] Sommerlad, P.; M. Rüedi. Do-it-yourself Reflection.
Addison-Wesley, 1997. European Conference on Pattern Languages of Programs
[5] Foote B, J. Yoder. Metadata and Active Object Models. (EuroPLoP 98), Irsee, Germany, July 1998.
Proceedings of Plop98. Technical Report #wucs-98-25, Dept. [16] Welicki, L.. The Configuration Data Caching Pattern. 14th
of Computer Science, Washington University Department of Pattern Language of Programs Conference (PLoP 2006),
Computer Science, October 1998. Portland, Oregon, USA, 2006.
[6] Gamma, E.; R. Helm, R. Johnson, J. Vlissides. Design [17] Welicki, L; J. Cueva Lovelle; L. Joyanes Aguilar. Meta-
Patterns: Elements of Reusable Object Oriented Specification and Cataloging of Software Patterns with
Software. Addison-Wesley. 1995. Domain Specific Languages and Adaptive Object Models.
[7] Trail: Creating a GUI with JFC/Swing. European Conference on Pattern Languages of Programs
[Link] (EuroPLoP 2006), Irsee, Germany, July 2006.

[8] Johnson, R., R. Wolf. Type Object. Pattern Languages of [18] Welicki L; O. Sanjuan Martinez. Improving Performance and
Program Design 3. Addison-Wesley, 1998. Server Resource Usage with Page Fragment Caching in
Distributed Web Servers. International Conference on
[9] Microsoft .NET Framework. [Link] Parallel and Distributed Processing Techniques and
[10] Buschman, F. et al. Pattern Oriented Software Architecture, Applications (PDPTA 2007), Las Vegas, Nevada, June 2007.
Volume 1: A System of Patterns. Wiley & Sons. 1996 [19] Welicki L; J. Yoder; R. Wirfs-Brock; R. Johnson. Towards a
[11] Kircher, M.; P. Jain. Pattern Oriented Software Architecture, Pattern Language for Adaptive Object Models. Companion
Volume 3: Patterns for Resource Management. Wiley & of the ACM SIGPLAN Conference on Object Oriented
Sons, 2004. Programming, Systems, Languages and Applications
(OOPSLA 2007), Montreal, Quebec, Canada, 2007.
[12] Riehle, D., Fraleigh S., Bucka-Lassen D., Omorogbe N. The
Architecture of a UML Virtual Machine. Proceedings of the [20] Yoder, J.; F. Balaguer; R. Johnson. Architecture and Design
2001 Conference on Object-Oriented Program Systems, of Adaptive Object-Models. Proceedings of the ACM
Languages and Applications (OOPSLA ʼ 01), October 2001. SIGPLAN Conference on Object Oriented Programming,
Systems, Languages and Applications (OOPSLA 2001),
[13] Riehle D., M. Tilman, and R. Johnson. "Dynamic Object
Tampa, Florida, USA, 2001.
Model." In Pattern Languages of Program Design 5. Edited
by Dragos Manolescu, Markus Völter, James Noble. [21] Yoder, J.; R. Johnson. The Adaptive Object-Model
Reading, MA: Addison-Wesley, 2005. Architectural Style. IFIP 17th World Computer Congress -
TC2 Stream / 3rd IEEE/IFIP Conference on Software
[14] Revault, N, J. Yoder. Adaptive Object-Models and
Architecture: System Design, Development and Maintenance
Metamodeling Techniques Workshop Results. Proceedings
(WICSA 2002), Montréal, Québec, Canada, 2002
of the 15th European Conference on Object Oriented
Programming (ECOOP 2001). Budapest, Hungary. 2001. [22] Yoder, J.; R. Razavi. Metadata and Adaptive Object-Models.
ECOOP Workshops (ECOOP 2000), Cannes, France, 2000.
APPENDIX- A BRIEF SUMMARY OF THE dynamic tree like structure, the COMPOSITE pattern is applied.
BUILDERS and INTERPRETERS are commonly used for building the
ARCHITECTURAL STYLE OF AOMS structures from the meta-model or interpreting the results.
Important Notice: This section is a summary extracted from [21]
and [20] and has been included to help readers unfamiliar with But, these are just patterns; they are not a framework for building
the AOM architectural style. To get a more complete view we Adaptive Object-Models. Every Adaptive Object-Model is a
recommend the reader read the original papers found at framework of a sort but there is currently no generic framework
[Link]. for building them. A generic framework for building the
TypeObjects, Properties, and their respective relationships could
The design of Adaptive Object-Models differs from most object- probably be built, but these are fairly easy to define and the hard
oriented designs. Normally, object-oriented designs have classes work is generally associated with rules described by the business
which model the different types of business entities and associate language. These are usually very domain-specific and varied
attributes and methods with them. The classes model the from application to application.
business, so a change in the business causes a change to the code,
which leads to a new version of the application. An Adaptive Type Square
Object-Model does not model these business entities as classes. In most Adaptive Object Models, TYPE OBJECT is used twice:
Rather, they are modeled by descriptions (metadata) which are once before using the PROPERTY pattern, and once after it. TYPE
interpreted at run-time. Thus, whenever a business change is OBJECT divides the system into Entities and EntityTypes.
needed, these descriptions are changed, and can be immediately Entities have attributes that can be defined using
reflected in a running application. Properties. Each Property has a type, called
Adaptive Object-Model architectures are usually made up of PropertyType, and each EntityType can then specify the
several smaller patterns. TYPE OBJECT [8] provides a way to types of the properties for its entities. Figure 10 represents the
dynamically define new business entities for the system. TYPE resulting architecture after applying these two patterns, which we
OBJECT is used to separate an Entity from an call TYPE SQUARE [20].
EntityType. Entities have Attributes, which are
implemented using the PROPERTY pattern [5]. The TYPE OBJECT cd AOM

pattern is used a second time in order to define the legal types of

Entity EntityType
Attributes, called AttributeTypes. As is common in 0..* +type
Entity-Relationship modeling, an Adaptive Object-Model usually
separates attributes from relationships.
The STRATEGY pattern [6] can be used to define the behavior of
EntityTypes. These strategies can evolve, if needed into a
rule-based language that gets interpreted at runtime. Finally, there
is usually an interface for non-programmers which allows them to
define the new types of objects, attributes and behaviors needed
for the specified domain. +properties 0..* +properties 0..*

Therefore, we can say that the core patterns that may help to Property PropertyType
describe the AOM architectural style are: 0..* +type

TYPE OBJECT
PROPERTY Figure 10. The Type Square.
ENTITY-RELATIONSHIP / ACCOUNTABILITY TYPE SQUARE often keeps track of the name of the property and
STRATEGY / RULE OBJECT whether the value of the property is a number, a date, a string, etc.
INTERPRETER (of Metadata) The result is an object model similar to the following: Sometimes
objects differ only in having different properties. For example, a
Adaptive Object-Models are usually built from applying one or system that just reads and writes a database can use a Record with
more of the above patterns in conjunction with other design a set of Properties to represent a single record, and can use
patterns such as COMPOSITE, INTERPRETER, and BUILDER [6]. RecordType and PropertyType to represent a table.
COMPOSITE is used for building dynamic tree structure types or
rules. For example, if the entities need to be composed in a