André Postma

A method for module architecture verification and its application on a large component-based system

Abstract A method for module architecture verification is described, which yields support for checking on an architectural level whether the implicit module architecture of the implementation of a system is consistent with its specified module architecture, and which facilitates achieving architecture conformance by relating architectural-level violations to the code-level entities that cause them, hence making it easier to resolve them. Module architecture conformance is needed to enable implementing and maintaining the system and reasoning about it. We describe our experience having applied the proposed method to check a representative part of the module architecture of a large industrial component-based software system.

Architectural support in industry: a reflection using C-POSH

Software architecture plays a vital role in the development (and hence maintenance) of large complex systems (containing millions of lines of code) with a long lifetime. It is therefore required that the software architecture is also maintained, i.e., sufficiently documented, clearly communicated, and explicitly controlled during its life-cycle. In our experience, these requirements cannot be met without appropriate support. Commercial-off-the-shelf support for architectural maintenance is still scarcely available, if at all, implying the need to develop appropriate proprietary means. In this paper, we reflect upon software architecture maintenance taken within three organizations within Philips that develop professional systems. We extensively describe the experience gained with introducing and embedding of architectural support in these three organizations. We focus on architectural support in the area of software architecture recovery, visualization, analysis, and verification. In our experience, the support must be carried by a number of pillars of software development, and all of these pillars have to go through a change process to ensure sustainable embedding. Managing these changes requires several key roles to be fulfilled in the organization: a champion, a company angel, a change agent, and a target. We call our reflection model C-POSH, which is an acronym for Change management of the four identified pillars of software development: Process, Organization, Software development environment, and Humans. Our experiences will be presented in terms of the C-POSH model. Copyright

Component replacement in a long-living architecture: the 3RDBA approach

In order to respond to changing requirements and advances in technology, system and software architectures must evolve during their lifetimes. Usually, in this evolution, several key components of the architecture are replaced. Achieving successful architecture evolution at a reasonable cost and effort is difficult. It requires many architectural and technological decisions. This paper describes an approach, called 3RDBA that facilitates replacing a key component in a long-living architecture. It is based on systematically gathering all information needed to make well-founded decisions regarding evolution of the architecture. The approach consists of an exploration, consolidation and migration cycle. Each cycle contains four steps: requirements, design, build and analyze. 3RDBA enables construction and evaluation of several alternative architecture realizations together with a migration path from the existing architecture towards the selected, new architecture. We describe how we have successfully applied this approach to support the evolution of a medical imaging system architecture.

Embedding architectural support in industry

Software architecture plays a vital role in the development (and hence maintenance) of large complex systems with a long lifetime. It is therefore required that the software architecture is also maintained, i.e. sufficiently documented, clearly communicated, and explicitly controlled. In our experience, these requirements cannot be met without appropriate support. Commercial-off-the-shelf support for architectural maintenance is still scarcely available, if at all, implying the need to develop appropriate proprietary means. In this paper, we briefly report upon an overall approach taken within three organizations within Philips that develop professional systems. We extensively describe the experience gained with the embedding of architectural support in these three organizations. We focus on architectural support in the area of software architecture recovery, visualization, analysis, and verification. In our experience, the support must be carried by a number of elements of software development, and all of these elements have to go through a change process to ensure sustainable embedding. We distinguish four of these elements, i.e. process, organization, software development environment, and humans, and present our experience in terms of those elements.

An architectural connectivity metric and its support for incremental re-architecting of large legacy systems

Architectural connectivity metrics are a means of supporting incremental re-architecting of large legacy systems. These metrics provide support by giving an indication of the degree of connectivity between or within architectural entities in the system. Ideally, a connectivity metric should provide useful information in as many situations as possible. However, the existing metrics of cohesion and coupling provide support only in a limited number of situations. In this paper, we present a new architectural connectivity metric, referred to as directed connectivity, together with an appropriate visualization. Directed connectivity is a measure of the relative number of connections from one architectural entity to another. The metric is applicable in a large number of situations, including ones where cohesion and coupling fall short. The metric is visualized by means of a tabular representation with browsing facilities. A description is given of initial experiences with directed connectivity and its visualization on a large industrial system.

Measuring Architecting Effort

The amount of architecting effort is a factor in a software development project’s efficiency. Before steps can be taken to optimize this factor, its current position must be know. We have measured the amount of architecting done in two industrial cases relating to the development of medical imaging systems.We discuss these cases and some of the problems that we encountered.