My current research focuses on architecture-implementation mapping, including implementing software architecture (i.e. mapping architecture specification to code) and maintaining architecture-implementation conformance (i.e. mapping architecture development changes to code). Automatic architecture-implementation mapping is essential to architecture-centric software development, a promising software development paradigm where the focus is software architecture instead of source code. Examples include model-driven development, architecture-centric product line development, and architecture-based self-adaptation.
We have successfully developed an architecture-implementation mapping approach named 1.x-way mapping for single system development. We are currently working on another novel approach named 1.x-line mapping to support automatic mapping of product line architecture to source code in software product line development. They are both based on a code generation and separation pattern (i.e. 1.x) that we developed to implement software architecture in architecture-centric development: only the architecture ("1") and a separated portion of the code (".x") can be manually changed in software development and evolution. Other research approaches, tools, and demos that we have developed include ArchFeature and CREST Feed Reader. Each is specifically introduced below.
The 1.x-line approach is a research project that we are currently working on. It specifically addresses mapping variation points (e.g. an optional component interface accompanied with a presence condition) in the product line architecture to code. This is a challenge that fails to be addressed by existing architecture-implementation mapping and software variability implementation approaches. The following is a video demonstration of a prototype of 1.x-line that we recently developed and integrated in the ArchStudio architecture development environment. The demo highlights some initial capabilities of 1.x-line, such as tracing feature-related design and implementation. Our following work of 1.x-line will be focused on implementation and evolution of product line variability in implementation platforms, functions, and quality attributes.
ArchFeature is a modeling approach and tool that we developed primarily to reduce the overhead and effort involved in product line architecture modeling. It specifically addresses the difficulty of manually editing and updating guard conditions accompanied with variation points in the PLA (i.e. variability modeling), and the cognition overhead of identifying feature-related architecture elements. ArchFeature extends an existing XML-based architecture description language, xADL and integrates feature specification into the product line architecture model. It then provides tool support to fully automate operations such as variability modeling, development and maintenance of feature-architecture relationships, and derivation of architecture instances for a product of the product line.
ArchFeature allows us to easily create and maintain an product line architecture model, so that we can focus on the research on implementation and evolution of product line architectures. The following is a video demonstration of ArchFeature.
Architecture-implementation mapping is a process of converting architecture specifications to and from source code with the goal of maintaining their conformance. Depending on which artifacts can be manually changed, there are approaches of one-way mapping and two-way mapping. 1.x-way mapping is a new approach that only allows changes to be initiated in the architecture (“1”) and a separated portion of the code (“.x”).
Suppression of manual changes of architecture-prescribed code, automatic mapping of specific kinds of architecture changes to code in specific ways, and support for behavioral mappings are three most important features of 1.x-way mapping. They are illustrated below in a demo of a tool called xMapper that we built for 1.x-way mapping in the ArchStudio architecture development environment. More detailed introduction of 1.x-way mapping can be found in the paper that we published at ICSE 2012.
We currently maintain an extended version of ArchStudio based on the standard version that is originally developed and maintained at Institute for Software Research in University of California, Irvine. It includes some of the tools that we developed such as xMapper and ArchFeature, and provides extensive support for architecture-implementation mapping. We are using it in some classes at UMKC to provide students with hands-on experience of architecture-centric development.
Computational REST (CREST) is a new architecture style of the web that emphasizes computational exchange over the Internet. In this project, I collaborated with three of my colleagues (Justin Erenkrantz, Michael Gorlick, and Alegria Baquero) at UC Irvine, and built a CREST demo application - a dynamic feed reader. I was responsible for the development of the front end of the application (basically the portion that you can see in the demo video below). The technologies of Dojo and AJAX were extensively used in my development work. The demo was presented in Justin Erenkrantz's Ph.D. dissertation defense and my Ph.D. advisor, Professor Richard N. Taylor's keynote address at ESEC/FSE 2009.
The lunar lander video game was originally developed by a group of UC Irvine undergraduates as a class project. An architecture was also created at that time, but it did not match the code in many places. In this project, I refactored the game code based on the Myx architecture style, re-created the game's architecture that exactly matches the code, and finally established the connections between the architecture and the code. In particular, two different architectures were created: a flat architecture and a hierarchical architecture. The developed Myx-style lunar lander video game can be run in the ArchStudio architecture development environment from the game's architecture, instead of the code. The Myx-style lunar lander game now serves as a demonstration application of ArchStudio. It was also used in an undergraduate software architecture class of UC Irvine for students to work with.