Anssi Karhinen

Configuring designs for reuse

The main problem in developing software product families is how to share effort and reuse parts of design and implementation while providing variation of features and capabilities in the products. We discuss the mechanisms that are commonly used to achieve reuse and sharing in product families, and the kind of variance each is best suited for. Our analysis motivates a need for a new mechanism to deal with ad hoc variation of features found in different members of a family. We argue that higher level abstraction and parametrization techniques are not well suited for this task. We propose an alternative approach that enables sufficiently detailed designs for every variant and at the same time achieves a level of design reuse without making designs unnecessarily complex or implementations inefficient.

Mobile service oriented architectures (MOSOA)

Mobile services hold a promise of utilizing the phone also for other purposes than purely communication. However, repeated attempts at realizing mobile services in the market place have been met with limited success. This article (1) defines the architectural drivers that drive success or failure of mobile services, (2) analyzes three different architectural styles of realizing such a mobile service using the example of a movie ticket selling service and (3) presents the results of this analysis. The main result of the analysis is that a serious conflict exists between usability and essentially all the other architectural drivers included in our analysis, i.e. portability, deployability and scalability. This is due to the fact that, because of the restricted state of the art technology, only native client applications offer satisfactory usability, but these do not satisfy the other drivers.

Structuring Design Decisions for Evolution

Software system has to face many changes during its life cycle. Some of these changes can be anticipated some come as surprises. Software systems can be designed to be flexible in terms of anticipated changes. Flexibility is achieved by structuring the system utilizing abstraction, indirection, late binding or some other variance mechanism. Surprising changes are still a problem. Partially this problem can be alleviated by proper management of design knowledge. We propose a mechanism to organize design decision so that this organization can be used to analyze change requests and determine their impact on system architecture. We demonstrate this using an industrial example.

An approach to manage variance in legacy systems

Different market areas set different requirements on software-intensive products. A careful domain analysis yields the predictable variance that can be managed at the architectural and design levels, but the unpredictable variance that is detected only during the maintenance phase is usually managed at the implementation level, due to the high costs of the system re-design or re-architecting. Thus, most legacy systems contain a lot of unpredictable variance in the source code, e.g. in the form of cluttering it with pre-processor directives. The weak overlay technique is a promising reverse engineering approach to abstracting, comprehending, maintaining and re-designing legacy software containing various types of variance.

Matching Service Requirements to Empirical Capability Models in Service-Oriented Architectures

The importance of reliably achieving quality of service (QoS) requirements in service-oriented architectures is constantly increasing. This trend has changed the characteristics that are needed from the service architectures, hosting environments and to the methods to create new services. To enable hosting services with strict QoS requirements, abilities to model service requirements, identify the capabilities of the hosting environment, and effectively match those for the wanted service configuration are needed. Many current methods build theoretical models of service requirements and capabilities of the hosting infrastructure. Based on our experience, using these in commercial systems is hard. In this paper, we highlight the key requirements for commercial service oriented architectures with strict latency requirements. We also propose using empirical models of the service infrastructure to provide accurate and reliable service configuration that will match the service requirements.

Orthogonal type extensions and reductions

In this paper we present a generalization of Oberons record type extensions. Our extension mechanism is orthogonally applicable to all the conventional data types found in Pascal-like languages. In order to balance the type system, we present an inverse concept, type reductions, that also can be applied to all the programmer-defined data types. These concepts provide flexible and powerful means for expressing universal subtyping and supertyping in a statically-typed programming language, as well as many possibilities for reuse of data types via a sound mathematical characterization of assignment statements. The presented ideas are under implementation in Alberich, a programming language that can be considered as a natural descendant of Oberon.

An architectural style decoupling coordination, computation and data

In distributed applications, several processes are involved in serving a request. The state of the request is encoded in the states of their processes. This can lead to unnecessary complexity and hard-to-detect errors. This paper presents an architectural style, token architectures, that decouples data, control and synchronization. Tokens encapsulate the state of a computation. Service points manipulate the tokens and perform services for them. The tokens use maps to move between service stations. We show in an example how this style simplifies the design of a telecommunications application and what difficulties traditional designs must solve.

Software Architecture Helpdesk

Software architecture has been identified as a main tool for high quality system development. Software architecture provides the basis for the reuse in a software product line. Unfortunately the potential benefits of a well designed software architecture can be lost if the software architecture is not followed in the design of the products. We suggest that a software architecture help desk could play an important role in enabling the dissemination of software architecture and in improving the communication between designers and architects.