Joseph W. Yoder

The Adaptive Object-Model Architectural Style

We have noticed a common architecture in many systems that emphasize flexibility and mn-time configuration. In these systems, business rules are stored externally to the program such as in a database or XML files. The object model that the user cares about is part of the database, and the object model of the code is just an interpreter of the users’ object model. We call these systems “Adaptive Object-Models”, because the users’ object model is interpreted at runtime and can be changed with immediate (but controlled) effects on the system interpreting it. The real power in Adaptive Object-Models is that the definition of a domain model and rules for its integrity can be configured by domain experts external to the execution of the program. These systems are important when flexibility and dynamic runtime configuration is needed, but their architectures have yet to be described in detail. This paper describes the Adaptive Object-Model architecture style along with its strengths and weaknesses. It illustrates the Adaptive Object-Model architectural style by outlining examples of production systems.

Metadata and active object-models

An object model is an abstract representation of a particular domain, using objects as the description. An active object-model is an object model whose object representation is interpreted or generated at run-time and can be changed with immediate (but controlled) effect on the system interpreting and running it. Metadata are data that describe other data. When data are accompanied by such descriptions, they can be integrated into new applications on-thefly. Indeed, when these descriptions are sufficiently rich and powerful, they can constitute a second-level language. This is distinct from the domain level in that it helps to specify the domain in such a way that it is dynamic and flexible. It makes it so that your domain objects can be reified. Neither metadata nor active object-models are new. Indeed, “meta is beta” was a mantra for database people during the ‘70s, and the designers of contemporary object-oriented systems build active object-models every day, without knowing they are doing anything special. This workshop brought together practitioners, language theorists, pattern mavens, architects, and academics to look for the patterns that underlie their disparate interests. By identifying the patterns and establishing a common vocabulary, we hope to relieve those who follow of the burden of reinventing these approaches yet again.

Metadata and Adaptive Object-Models

The unrelenting pace of change that confronts contemporary software developers compels them to make their applications more configurable, flexible, and adaptable. A way to meet such requirements is to use an Adaptive Object-Model (AOM). This paper describes common architectures for adaptive object-models and summarizes the results from our ECOOP 2000 workshop. Participants to this workshop focused on comparisons between the Adaptive Object-Models approach and those of Reflection and Metamodeling. It emerged that there are common themes present in all three approaches and that these approaches can compliment one another for assisting developers in designing and building systems that can more quickly adapt to new and changing business requirements.

Being Extreme in the Classroom: experiences Teaching XP

Agile Methods propose a new way of looking at software development that questions many of the beliefs of conventional Software Engineering. Agile methods such as Extreme Programming (XP) have been very effective in producing high-quality software in real-world projects with strict time constraints.Nevertheless, most university courses and industrial training programs are still based on old-style heavyweight methods. This article, based on our experiences teaching XP in academic and industrial environments, presents effective ways of teaching students and professionals on how to develop high-quality software following the principles of agile software development. We also discuss related work in the area, describe real-world cases, and discuss open problems not yet resolved.

Adaptive object-model builder

An Adaptive Object-Model system represents user-defined classes, attributes, relationships, and behavior as metadata. This paper presents the Adaptive Object-Model Builder pattern that is used to construct AOM entities. An AOM Builder reads an externally stored build description to construct a build process. This process is then executed to construct a properly initialized AOM entity. Since an AOM Builder is driven by metadata descriptions of entities and their build processes, a single generic AOM Builder implementation can construct different entity types.

The MEDIGATE Graphical User Interface for Entry of Physical Findings: Design Principles and Implementation

The solution to many of the problems of the computer-based recording of the medical record has been elusive, largely due to difficulties in the capture of those data elements that comprise the reco...The solution to many of the problems of the computer-based recording of the medical record has been elusive, largely due to difficulties in the capture of those data elements that comprise the records of the Present Illness and of the Physical Findings. Reliable input of data has proven to be more complex than originally envisioned by early work in the field. This has led to more research and development into better data collection protocols and easy to use human-computer interfaces as support tools. TheMedicalExaminationDirectIconic andGraphicAugmentedTextEntrySystem (MEDIGATE System) is a computer enhanced interactive graphic and textual record of the findings from physical examinations designed to provide ease of user input and to support organization and processing of the data characterizing these findings.(27,30)The primary design objective of the MEDIGATE System is to develop and evaluate different interface designs for recording observations from the physical examination in an attempt to overcome some of the deficiencies in this major component of the individual record of health and illness.

Language support for adaptive object-models using metaclasses

Adaptive object models (AOM) are a sophisticated way of building object-oriented systems that let non-programmers customize the behavior of the system and that are most useful for businesses that are rapidly changing. Although systems based on an AOM are often much smaller than competitors, they can be difficult to build and to learn. We believe that the problems with AOM are due in part to a mismatch between their design and the languages that are used to build them. This paper describes how to avoid this mismatch by using implicit and explicit metaclasses.

Dynamic hook points

When building dynamic systems, it is often the case that new behavior is needed which is not supported by the core architecture. One way to vary the behavior quickly is to provide well-defined variation points, called hook-points, in predefined places in the system where new behavior can be dynamically looked up and invoked at runtime when desired.

Adaptive object-models (poster session)

The unrelenting pace of change that confronts contemporary software developers compels them to make their applications more configurable, flexible, and adaptable. A possible way to meet such requirements is to use an Adaptive Object-Model (AOM). This poster describes common architectures for adaptive object-models and summarizes the results from our ECOOP 2000 workshop [9].

AOM metadata extension points

An Adaptive Object Model (AOM) is a common architectural style for systems in which classes, attributes, relationships and behaviors of applications are represented as metadata, allowing them to be changed at runtime not only by programmers, but also by end users. Frequently, behavior is added to AOM systems by increasingly adding expressiveness to the model. However, this approach can result in a full blown programming language, which is not desirable. This pattern describes a solution for adding behavior to AOM systems by using metadata to identify points in the application where behavior can be dynamically added. This solution may limit the expressive power of the model, but can also simplify it, since points of extension are well defined in the system.