Krzysztof Czarnecki
Daimler-Benz AG
Research and Development
Wilhelm-Runge-Str., 89081 Ulm, Germany
Tel: (x49) 731 505 4008
Fax: (x49) 731 505 4210
Email:
czarnecki@dbag.ulm.DaimlerBenz.com
Object-orientated frameworks, software architectures, generators, and domain analysis are all technologies that claim to make reuse possible. In this position paper, we argue that in order to achieve a higher level of reuse, all these technologies should be combined into a single development framework using the concept of domain-specific software architectures. We will examine the elements of a domain-specific architecture and show how they incorporate the above-mentioned technologies.
Keywords: domain-specific software architecture, object-orientation, frameworks, generators, domain analysis, formal specification
Workshop Goals: Learning; networking; to discuss the opportunities and benefits of integrating OO frameworks and generators within domain-specific software architectures.
Working Groups: Object Technology, Architectures, and Domain Analysis: What's the connection? Is there a connection?; Software System Generators.
Software has a substantial impact on success in business today. For example, in the telecommunication market, new services are often entirely expressed in software. Time to market for new services is a crucial criterion for survival and prospering in a highly competitive market. The same situation can be observed in various other domains. In order to cut development time and cost, the vision of configuring applications out of pre-fabricated software components has to be pursued.
I am currently involved in the OSVA research project, the goal of which is to leverage reuse in distributed environments using object-oriented architectures. One of the target domains of our work is image recognition for postal automation. We believe that domain-specific software architectures are currently the only feasible way to achieve ``plug-and-play'' component reuse. A domain-specific software architecture provides a common framework for component interoperability within a domain.
Our position is that domain-specific software architecture is the connection between object technology, architectures, and domain analysis. Our view on domain-specific software architectures is based on on the results of the DSSA project (see [1]), according to which a domain-specific software architecture (DSSA) consists of a domain model, reference requirements, and a reference architecture. A DSSA forms the basis for devising a domain-specific development environment (DSDE) which supports the configuration of reusable components.
In our view, the DSSA approach provides the unique opportunity of combining a number of different technologies and research areas, such as domain analysis, OOA, OOD, OOP, generators and transformers, software architecture, and formal methods, into a single software development framework. A formally specified software architecture can be used as a basis for the automatic generation of applications. In addition to the DSSA project, work on combining generation and object-oriented approaches includes Don Batory's GenVoca [2] (for some newer work see [3]) and Stephen Mellor's ``Translation Approach'' [4]. The latter has been commercialized by Project Technologies, Inc. and validated in industrial projects.
In the rest of this position paper, I will explain the elements of a DSSA and show their connection to domain analysis, object technology, architectures, and generators. I will use the Telecommunications Information Networking Architecture (TINA) as an example of a DSSA. TINA is an emerging standard architecture for telecommunications. The TINA documents are available publicly on the Internet [5] and provide an excellent case study of DSSA.
A domain model is meant to define the concepts and principles of a domain. In particular, it defines the basic vocabulary of the domain and a taxonomy of its main concepts (i.e. domain abstractions). A domain model is obtained in the process of domain analysis. Domain analysis also has to identify the stable and the variable parts of the domain. Object-oriented analysis methods represent possible domain analysis approaches and the UML, for example, is a general purpose object-oriented domain modeling notation. The main requirement for a particular set of techniques used to describe a domain is that it has to capture all its relevant information at an adequate level of abstraction. If, for example, data-flow diagrams adequately described some part of the domain, one would obviously use them.
The TINA architecture overview document [6] is a good example of an informal domain model definition. It defines the terminology, concepts and principles of the standard. Examples of important TINA concepts are service, session, and connection graph. It seems that as a domain model matures, it gradually moves from being an informal domain model towards a more formal domain theory.
Mathematical theories are very good examples of mature domain models. For example, in the course of advances in the area of image recognition, many sophisticated low-level image recognition and processing algorithms have been developed and implemented. At some later point, the attempt was made to formulate a mathematical theory called image algebra that is based on abstract algebra and defines the objects (different types of images) and operations (image operations) of the domain. The purpose of image algebra is to provide a unifying framework for the formulation and analysis of image processing algorithms. To date, most of the standard image processing algorithms have already been defined in terms of image algebra, and a C++ library of these algorithms has also been developed [7]. As noted in [7] image algebra - as any other mathematical theory - will never become a finished product. However, a mathematical theory seems to be an even longer-lasting artifact than any other type of standard. In this context, one should note that algebraic specification methods provide an important connection between object-orientation and mathematical methods [8].
Each domain has its own set of typical requirements that an application in this domain has to satisfy. A domain model provides the vocabulary to formulate the reference requirements. Reference requirements are differentiated into functional and non-functional requirements. The latter will constrain the architecture and the implementation. Most importantly, the required variabilities in the domain have to be explicitly specified. Rapid prototyping can be used to test an architecture against the reference requirements.
The TINA standard has a separate document [9] defining all the reference requirements. An interesting feature of TINA is its architectural viewpoints. The architectural viewpoints divide the requirements into the following classes: computation, engineering, enterprise, information, and technology. These viewpoints result in different subset architectures, with their own components and configuration views.
An architecture is a reusable design and a reference architecture is a reusable design for a family of systems in a particular domain. In our view, a reference architecture should consist of the following elements:
The application component model needs to be formalized to enable analysis of the application architecture. For example, checking for cycles in a connection graph of pipes and filters prevents deadlocks. A model for expressing architectural constraints, rationale, and a model for describing components (e.g. name, keywords, interface, behavior, etc.) also have to be provided.
Choosing the appropriate application component model (i.e. architectural style) can be tricky. And coming up with concrete reference components is much more difficult. The issues that have to be addressed are the granularity of the components, packaging of the functionality, and, in some cases, the parameterization of the architectural style of a component. Some guidance can be expressed using architectural patterns [11], [12] and analysis patterns [13]. Also, the evolution of object-oriented frameworks represents a possible approach to architecture development (see [14]). One advantage in using this approach is that incomplete frameworks can be utilized and improved upon while in use. On the other hand, evolving a domain specific language in order to improve its modeling power is much more difficult. A stable framework design is an excellent basis for the development of a reference architecture and a domain-specific language.
As a general rule, components need to be adaptable and extensible. Adaptability and extensibility are mainly achieved through parameterization. For example, object-oriented frameworks use parameter classes having compatible interfaces to provide variability in so-called ``hot spots''. The highest level of parameterization can be reached using transformational techniques. Such techniques make the parameterization of any design or implementation decision possible (e.g. intentional programming [15]).
In TINA, architectural components are called computational objects. A computational object can have multiple procedural interfaces as well as stream interfaces (used for fast data transfer in streaming applications) [6]. This is an example of an architectural style that combines the object style with the pipes-and-filters style. In a critique of the TINA definition, one could point out that there is no clear separation between the problem space (domain model) and the solution space (reference architecture).
A domain-specific development environment (DSDE) supports the application development based on a DSSA. A DSDE has its own architecture that usually has three levels:
An example of a DSDE for TINA based on the principles mentioned above is ACE [19].
The process of developing and implementing a DSSA is called domain engineering. Its counterpart, i.e. the process of developing an application based on a DSSA, is called application engineering. The TINA-based application engineering, for example, is called service development methodology. The phases of this process include defining business objectives, defining requirements, configuration of an application and development of new components, and application deployment. The application engineering processes could be implemented using workflow and a distributed component repository and is a subject to metrics-based improvements.
One of the goals of the OSVA project is the development of a distributed DSSA for image recognition. The DSDE for this DSSA will be based on CORBA and consist of a number of C++ support frameworks, pre-defined standard components, and will use generative and transformational techniques for customizing and optimizing components (performance is critical).
At the current stage we are examining two existing image recognition systems in order to come up with a domain model and a reference architecture.
Krzysztof Czarnecki received the B.S. and M.S. degrees in computing science from the Technical University of Ilmenau, Germany, in 1991 and in 1995, respectively. He also received a M.S. degree in computer science from the California State University, Sacramento, in 1994. He currently holds a research position at the Daimler-Benz Research Center, Ulm, Germany, and is a Ph.D. student at the Technical University of Ilmenau. His research interests include formal methods, object-orientation, software architecture, software reuse, and transformation systems. He also writes the Smalltalk column for OBJEKTspektrum, a German magazine on object-oriented technology.