Definition of Reference Architectures based on Existing ...€¦ · Definition of Reference...

Definition of Reference Architectures based on Existing Systems

WP 2.2, Platforms and Components

Authors: Joachim Bayer Dharmalingam Ganesan Jean-François Girard Jens Knodel Ronny Kolb Klaus Schmid Eureka Σ! 2023 Programme, ITEA project ip00004

IESE-Report No. 085.03/E Version 1.0 September 2003

A publication by Fraunhofer IESE

Fraunhofer IESE is an institute of the Fraun-hofer Gesellschaft. The institute transfers innovative software development techniques, methods and tools into industrial practice, assists compa-nies in building software competencies customized to their needs, and helps them to establish a competitive market position. Fraunhofer IESE is directed by Prof. Dr. Dieter Rombach Sauerwiesen 6 67661 Kaiserslautern

Abstract

The success of a product family depends greatly on the quality of its reference architecture. To achieve high-quality reference architectures, it is important to leverage the experience embodied in successful systems from the same set of domains. However, the literature provides limited guidance on how to mine prior related systems for this specific purpose. This report addresses this issue by introducing an approach, which defines the views needed to express the architectures of a specific product family, recovers and analyzes these views, and provides a sys-tematic process to define the reference architecture integrating the experience of past systems. This first version of this document focuses on architectural views: how they can be recovered, and how architectures can be analyzed and compared among themselves. The second version will emphasize the selection of reuse candidates and the development of the reference architecture for the product family.

Copyright © Fraunhofer IESE 2003 v

Table of Contents

1 Introduction 1 1.1 Practical and Scientific Motivations 1 1.2 Concept of the Approach 1

2 Combining Design and Recovery 4 2.1 Typical Cases 4 2.1.1 Case 1: Single System to Product Family 4 2.1.2 Case 2: Multiple Systems to Product Family 5 2.1.3 Case 3 Product Family to a new Product Family 5 2.2 Software Architecture as Interface 6 2.3 Architecture Descriptions 7 2.4 Tailoring Architecture Descriptions 11 2.5 Typical Views 13 2.5.1 Conceptual Architecture View 13 2.5.2 Module Architecture View 14 2.5.3 Execution Architecture View 15 2.5.4 Code Architecture View 16 2.6 Mapping the Meta-Model to Recovered Information 17 2.7 Process Description 18

3 Architecture Recovery Techniques 21 3.1 Code Architecture View 21 3.1.1 Introduction to the Code Architecture View 21 3.1.2 Elements of the Code Architecture View 22 3.1.3 Conclusion 26 3.2 Module Views 27 3.2.1 Layers 35 3.3 Execution Views 39 3.3.1 Deployment Views 44 3.4 Integrating Views 47

4 Analysis and Comparison of related prior Systems 48 4.1 The Comparison Process 50 4.2 Connecting the Business Cases to the Comparison Process 52

5 Design of Reference Architectures 54 5.1 Introduction 54 5.2 Overview 55 5.2.1 Select Scenarios and Plan Next Iteration 57

Copyright © Fraunhofer IESE 2003 vii

5.2.2 Define Evaluation Criteria 58 5.2.3 Choose Means and Patterns 58 5.2.4 Instantiate Patterns 59 5.2.5 Document Architecture using Views 59 5.2.6 Evaluate Architecture 59 5.2.7 Analyze Problem 60 5.3 Outlook 60 5.4 Summary 61

6 Conclusion 62 6.1 Future work 63

References 64

Copyright © Fraunhofer IESE 2003 viii

Introduction

1 Introduction

1.1 Practical and Scientific Motivations

Software development only rarely happens on a green field. More often than not, software does already exist that must be taken into account: a predecessor system that must be exploited while developing the next generation based on new technology, some systems might have been built independently and now should be combined into a single product family, and so on. In all of these situations, existing documentation is usually found to be insufficient as a basis for further development. At this point, reverse engineering techniques come in: they provide the ability to identify the necessary architectural information from the existing systems. This task is not a simple one as currently the required technology in terms of architecture recovery is still under research and no prac-ticable approaches for the non-expert practitioner exist. Coming closer to the vision of supporting people in exploiting their existing software optimally in the development of new product families is at the heart of this deliverable. This is both a formidable research task, as well as one of high practical relevancy.

The overall task of providing the practitioner with a systematic approach to the construction of new systems on the basis of existing ones has proven a rather difficult one. We thus had to decompose it in several steps (and hence deliver-ables). Here, we present our answer to the first step: how to systematically identify the information that needs to be captured from existing systems.

1.2 Concept of the Approach

The approach we describe in this deliverable integrates architecture develop-ment with the analysis of existing systems in order to obtain a reference archi-tecture that takes optimal advantage of existing systems.

The basic concept of our approach along with the focus of the existing deliver-able is shown in Figure 1.This figure shows the respective foci of the deliverable versions 1.0 and 2.0. The bullets show activities on which we will focus in our deliverable.

We start with the understanding of the business goals for the new architecture, as this will together with scope of the product family determine the architec-tural views that will be required in order to represent the new architecture. The information needed to construct these views is the basis for reverse engineering activities. Based on this information, we will describe specific reverse engineer-ing techniques that will enable us to gain the particular information. This in-

Copyright © Fraunhofer IESE 2003 1

Introduction

formation-driven selection of reverse engineering techniques is a key contribu-tion of this deliverable. The various techniques will also be described in detail.

The views produced with these techniques represent the support for capturing the rationales for different architectural choices and the advantages of using one strategy over another. Analyzing and comparing related systems through the various views produces the rationales and advantages. This information constitutes a precious input for designing a reference architecture. The method to analyze and compare related systems through these views constitute another key contribution of this deliverable.

However, often learning from prior system domain sets is not the main motiva-tor for analyzing them. The main motivation is the hope to reap the rewards of reusing mature time-tested components. For this reason, the next step of this approach consists in selecting the best reuse candidates based on the recovered information, the business goals, and the scope. The reuse candidates and the experience from related successful systems, together with the business goals, and the scope of the product family constitute the basis for developing a new architecture.

Scoping

A1

ElicitBusiness andQuality Goals

A2

DetermineArchitectural

Views

A5

Select BestReuse

Candidates

A6

Developnew

ArchitectureArchitecture

Reverseengineering

A0

DetermineScope

Scope of Deliverable Version 1.0Scope of Deliverable Version 2.0

A3

Recoverrequired

architecturaldescription

A4

Analyze andcompare

architectures

Work Foci

Legend

Figure 1 Deliverable Overview

To explain this approach, the document is structured along mainly along its steps: After providing exemplary scenarios where the approach is relevant, Chapter 2 describes the method to derive context-specific views and the Sie-mens’ view set as a typical starting point for constructing customized views.


Introduction

Chapter 2 explains the techniques used to reconstruct these views from prior related systems. Chapter 3 describes how the reverse architect and expert ana-lyze and compare related systems to provide key information to the product family architect designing the reference architecture. Chapter 5 portrays PuLSE-DSSA – our method for designing a reference architecture. Chapters 6 summa-rizes the contribution of the deliverable and depicts the work that will take place to produce the second version of this deliverable.


Combining Design and Recovery

2 Combining Design and Recovery

The combination of design and recovery is at the heart of developing new ref-erence architectures based on existing systems. In order to discuss this combi-nation, we will now first describe how these two fundamental activities interact in various specific product family development scenarios. In the following sec-tion, we will discuss the software architecture in its role as an interface be-tween architecture design and reengineering. We will then discuss various ar-chitectural views and the information contained in them, as well as how this can be used as a basis for driving the information recovery process.

2.1 Typical Cases

Product families are rarely developed independent of any predecessor system. More often than not, they are based on some pre-existing systems and need to take some information on these systems into account. We will now describe three typical cases in order to illustrate how our approach can help in integrat-ing reengineering and architecture design:

2.1.1 Case 1: Single System to Product Family

In a typical example for reengineering-based product family development, a sys-tem already exists which has evolved over years. While it is still possible to evolve this system over time, it is inappropriate as a basis for a product family. The reasons for this may be one of these:

• Only little documentation on the existing system is available.

• Although the existing architecture fits the original system’s needs, it does not support new, originally unforeseen, market requirements. As a conse-quence, its functionality should be systematically repackaged.

• The software development technologies that are used do not have the flexi-bility required by the new product family (e.g., if core functionality of the ex-isting system is implemented in FORTRAN).

In this case, a thorough analysis of the functionality of the existing system and the mapping of the functionality to code must be performed. This can be used as a basis for designing a reference architecture, which repackages the func-tionality in a systematic manner. Therefore the architecture will be appropriate to support the required variability.



2.1.2 Case 2: Multiple Systems to Product Family

A similar, but more complex situation, exists if a number of different systems al-ready exist that were so far developed individually, but should now be inte-grated into a single product family. This case is more complex than the previous one as information from a number of different sources needs to be integrated. The development of a common platform will usually proceed through the iden-tification of components in different products and their subsequent integra-tion.1 As the identified components will be directly integrated into the plat-form, the necessary information on these components for all relevant views must be made available. A special case of this business case occurs if there are not just a number of individual exists, but a number of existing product fami-lies. The different product families have then to be integrated into one resulting family.

2.1.3 Case 3 Product Family to a new Product Family

An extreme case is when an already existing product family that is not well enough documented cannot be adapted to a change from its environment and a new product family should be develop encompassing the scope of the current family and the new needs. The following example illustrates three types of change:

• The existing product family has to fulfill new business goals, functional re-quirements or quality attributes for which its reference architecture is not suitable.

• The domains covered by the product family are extended or have been modified (e.g., new laws have come in force and affect the domain) and this domain extension cannot be well integrated in the current reference archi-tecture.

• The product family should exploit different technologies that are not com-patible with the existing infrastructure.

To leverage the experience of the existing product family in the development of the new one, the existing product family architecture has to be analyzed and documented. The analysis should elicit the strategies of existing architecture that address the new requirements and identify component candidates for re-use in the new family. The documentation should stress include the rationales and trade-off of still relevant strategies and the key success factors of the first product family. With the help of this information, the architect of the new fam-

1 In some cases, however, the integration effort will be regarded to high. In this case, first a single system will

be chosen as the basis for the product family infrastructure, and then this will be mapped to the first case.



ily should construct a reference architecture meeting the new requirements, while reusing as much of the old family’s component as possible.

These three typical cases illustrate, each from its context, the need for reverse engineering one or more prior related systems to gather experience, to analyze commonalities and variabilities at the architecture level, to characterize success-ful solution patterns, and to identify reusable candidates. All of these activities provide an input for the design of a reference architecture. For each of them, the architecture represents the medium to convey experience and success from the past to the product family architect. In other words, the architecture consti-tutes the interface between reverse engineering and design activities.

2.2 Software Architecture as Interface

Software architectures have been defined as “the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution” [BCK98]. The architecture of a software-intensive system is concerned with the high-level organization and the structure of the system and is generally the first artifact that describes a software system from a solution-oriented point of view. As such, it facilitates communication about a system in an early phase of system development and enables discussions about alternative solutions. The architec-ture is a fundamental artifact in a software development project and whatever is wrong in the architecture multiplies through the complete product life cycle. As it is generally accepted that the earlier design decisions are made, the harder they are to change in later phases and the more far-reaching effects they have, it is crucial to make decisions in the architecture phase carefully and to be aware of their impact. Software architectures not only cover functional re-quirements but also quality and business goals and hence have determinant impact on the quality attributes of the resulting systems. Thus, it is important to make sure to have the best possible architecture.

The characteristics of software architectures just mentioned make them a cru-cial asset in the development of software. Furthermore, these characteristics make architectures the ideal interface for combining recovery from existing sys-tems and the development of a product family based on the recovered informa-tion. The architecture of a software system is at a sufficiently abstract level to overview the overall organization of a software system, yet it describes the solu-tion offered by the software system at a level of detail that enables the com-parison among different architectures in the same application domain or their combination in a product family or reference architecture. Therefore, it can be used to exchange and reconcile information recovered from existing architec-tures that is used as input to design new architectures.



The architecture of a software system is its fundamental organization. To use an architecture as interface between recovery and design activities, it must be documented properly. This is done in architecture descriptions. Figure 2 shows the interaction between recovery and design activities as an IDEF0 diagram. The output of architecture recovery is a number of architecture descriptions from the different existing systems that are to be used as a basis for a product family architecture. The scope of the product family, as well as the requirements on the product family are determined and documented during product family scoping and modeling. The recovered architecture descriptions are used as starting point to the design of the product family architecture.

ArchitectureRecoveryExisting Systems

ExpertKnowledge

Product andDomain Information

Product FamilyArchitecture

Design

Architecture Descriptions

Product FamilyArchitectureDescription

ExpertKnowledge


Product FamilyScoping and

Modeling


Figure 2 Combining Design and Recovery

An architecture description is a document that usually contains a number of ar-chitectural views that describe the software architecture from different perspec-tives. It is essential that the description techniques for the different architec-tures (i.e., the recovered architectures, as well as the product family architec-ture) match or that, at least, the differences in the descriptions are docu-mented. Otherwise, misunderstandings are likely to happen leading to un-wanted results or unnecessary effort.

2.3 Architecture Descriptions

Software architectures encompass structural and behavioral properties of soft-ware systems and their relation to their environments. To completely describe an architecture, several perspectives towards it should be taken. This results in architecture descriptions that consist of multiple architectural views. Each archi-tectural view is an abstraction of the software system, but different architec-tural views abstract from different details of the system. Architectural views prescribe the types of components and the types of relationships to be used to describe the software system (i.e., the connectors), as well as properties of these component and connector types. Consequently, each architectural view



presents different information, is used by different stakeholders, and addresses different concerns.

The most influential input to view-based documentation of software architec-tures was made by Philippe Kruchten [Kruc95]. He proposed a system of four interrelated views (logical, process, development, and physical view) augmented with a fifth redundant view (scenarios) that abstracts from certain requirements and shows how the four views work together to satisfy the requirements on an architecture.

Davis and Williams also propose a set of four views (domain, component, plat-form, and interface view) augmented with a fifth view, the context view that describes the dynamic behavior and quality characteristics of the resulting soft-ware system [DaWi97].

Hofmeister, Nord, and Soni elicited their views by investigating what descrip-tions are actually used to describe architectures in industrial software projects [HNS00]. The result was a set of four interrelated views (code, module, execu-tion, and conceptual view).

These view sets have in common that they focus on functional aspects of an ar-chitecture. However, non-functional or quality aspects should also be reflected in an architecture description. Quality attributes can be the basis for defining additional views that highlight how quality requirements are satisfied in the ar-chitecture. A quality attribute is a general characteristic of a software system (e.g., performance). A quality requirement is a concrete requirement related to a quality attribute (e.g., the method x should have a response time of y). The use of quality attributes as a basis for additional views on software architectures has a number of effects. It supports a clear separation of concerns, since one architectural view concentrates on a certain functional or non-functional aspect and only contains elements that depict how that aspect is covered by the archi-tecture. Such a separation of concerns leads to reduced complexity in the de-scription of the individual aspects that, in turn, increases the comprehensibility of the individual views and, consequently, of the overall system. The increased comprehensibility also supports the evolution and maintenance of the architec-ture, enables traceability and facilitates reuse. Views for certain quality attrib-utes enable a clear separation of concerns during architecture development. The architects can concentrate on one important aspect of the architecture at a time. The concentration on one aspect per view increases the comprehensibility of the software architecture description. The effect of the mentioned benefits is that the quality of the documentation (i.e., of the architecture description) is in-creased. This, in turn, supports the creation, as well as the maintenance and evolution of the architecture description.

However, there are also challenges that have to be mastered when using views for quality attributes, the first is selecting the views to be used in a way that



they form an optimal set that is neither too big nor too small. Once the views have been selected, the consistency among them must be ensured and they must be maintained properly.

The view-based description of software architectures is accepted practice. There are two principal possibilities for doing this in a given project:

• Using a proposed, general-purpose view set, like one of the view sets men-tioned above

• Setting up a customized view set

As described above the general-purpose view-sets do not take into account quality-related views. Therefore, a customized set of views must be created when quality attributes are to be reflected in the architecture description. The problem is that there are no methods that support the creation of an integrated set of views or to augment an existing set of views with quality-related views. However, there is an IEEE Recommended Standard for Architecture Description that can be used as a basis for doing that [IEEE1471]. It defines a meta-model that allows the description of an architecture from different viewpoint using ar-chitectural views. This meta-model defines the concepts associated with archi-tecture descriptions and relates them to each other. It can, therefore, be used to create customized view sets by specializing the standard’s meta-model. The resulting view sets are compatible with each other, which fosters the reuse of views and view sets in numerous projects. However, recommended standard does not provide concrete views or any process support for defining, creating, and using view-based software architectures.

Another important aspect when dealing with view-based product family archi-tectures is that each view potentially contains variability. Therefore, each view must support the description of variability and a decision model must support the consistent management of the different variabilities in the different views.

The meta-model for architecture descriptions as proposed by the IEEE Recom-mended Standard for Architecture Description is shown in Figure 3. A system is the final product of software development. It fulfils a mission in its environment that, in turn, influences the system.

A system has a number of stakeholders. Stakeholders include customers of the system, persons involved in the development of the system, or other systems collaborating with the system at hand. Each stakeholder has a number of con-cerns on the system under consideration. Concerns are any matter of vested in-terest a stakeholder has in a software system.

The architecture of a system is documented in the respective architecture de-scription. The architecture description is organized by a number of views that conform to viewpoints. A viewpoint is a perspective taken by a stakeholder on



the system. A viewpoint is used to cover one or more concerns. It does this by determining the models used to represent the concern(s), processes to create them, and applicable analyses.

Mission

SystemEnvironment Architecture

Stakeholder ArchitecturalDescription Rationale

LibraryViewpoint

ViewViewpointConcern

ModelModel

/influences/influences

/fulfils/fulfils

/described by/described by

/inhabits/inhabits /has an/has an

/provides/provides

/is addressed to/is addressed to

/aggregates/aggregates

/has source/has source

/participates in/participates in

/establishes methods for/establishes methods for

/conforms to/conforms to

/indentifies/indentifies/selects/selects/has/has

/is important to/is important to/identifies/identifies

/has/has

/organized by/organized by

/used to cover/used to cover

Figure 3 Conceptual Model of Architecture Description (taken from [IEEE1471])

A view is the description of a software system from a certain viewpoint. A view is associated to one viewpoint, which it must conform to. Views consist of col-laborating models and can be composed. The view must conform to the nota-tion determined by a viewpoint and is created using associated processes. To enable the reuse of viewpoints the concept of a library viewpoint is introduced. A library viewpoint can be used in different architecture descriptions.



2.4 Tailoring Architecture Descriptions

As described above, there are cases in which the views in a pre-defined view set are not fitting to the respective context. Unfortunately, approaches for view-based description of software architectures do not provide systematic means for extending their view sets. Therefore, we developed an approach for extend-ing existing view sets that elicits and defines the views necessary in a given con-text.

The goal of the view elicitation and definition activity is to define an optimal set of architectural views that are used to document the architectures of the planned products. There are cases in which an existing view set can be used without adaptation. However, often the proposed views are not sufficient to describe all relevant architectural aspects. Then, a new view set must be de-fined.

Business GoalElicitation

Quality GoalElicitation

ExpertKnowledge

BusinessStrategy

Constraints

ExpertKnowledge

ExpertKnowledge

BusinessStrategyBusinessStrategy

ConstraintsConstraints

Business Goals

ExpertKnowledge

ExpertKnowledge

ProductRequirementsProductRequirements

ViewElicitation

Quality Model

Existing View Sets

View Set

ViewConsolidation

ConsolidatedViews Set

ViewDefinition

Customized ViewSet

ProductRequirements

IncompleteView Set

Figure 4. Customizing Architecture Views

The process for customizing architecture views is shown in Figure 4. To prepare the view set definition, business and quality goals are elicited and documented. These are then, together with an existing view set that is to be extended, the input to the actual view elicitation and definition activities. The single activities are described in more detail in the following.

Business goals are the starting point for view set definition. Business goals are taken into account to enable the documentation of the impact of an organiza-tions’ business strategy on the products the organization builds. Certain busi-ness goals influence a products’ software architecture. These influences can be documented by providing views that show how the respective business goals



are realized in the architecture. In this initial step, the business goals of the or-ganization developing the product family are elicited and documented. In a moderated brainstorming session the business goals influencing the product family are collected and consolidated from the domain and application experts. If a documented business strategy exists, it is taken into account as well. Con-straints on the product family are also taken as an input in this step.

A quality model is a description of the quality goals that apply to a product family and of how these quality goals influence each other. The (non-functional) requirements on the different products are investigated with the domain and application experts to set-up a quality model. To do this, the qual-ity goals are collected, consolidated, and documented. The result is a quality model that captures the quality attributes relevant to the product family, as well as concrete quality requirements on the product family architecture in the form of scenarios.

The quality goal elicitation concludes the preparation phase that is followed by the actual view elicitation and definition. As described above existing view sets can be used as a starting point to add project-specific views. It is also possible to start from scratch. As a first step, an initial set of views is created. In moder-ated brainstorming sessions, views that highlight important aspects of the sys-tem being developed and its architecture are collected. The goal is to elicit all concerns and aspects that should be explicitly modeled and to find views that enable the modeling of these in the architecture description. Sources for views are the quality model, as well as existing view sets as a framework to integrate the specific views into in case there is one. The result is a list of views that should be used. Typically, the number of views is too large. Therefore, the view set is analyzed in a second step called view consolidation. The initial set of views is analyzed to find the optimal set (in terms of number of views and which views to select). If certain important aspects of the product family archi-tectures cannot be covered with the initial views, view elicitation is revisited based on the incomplete view set.

Once the view set is consolidated, this final set of views is defined. The result is a metamodel that defines the element types and the relationships that can be used in the different models, as well as relations among the different views. Additionally, the notations used to document the views are defined. We found three principal possibilities for representing architecture views when augment-ing an existing set of views:

• New view: a new view representation, that is new representations for the elements and relationships defined in the meta-model are created.

• Filtered or highlighted view: elements in an existing view are filtered out (in case they are not important for the new view) or highlighted (in case they are the focus of attention). As an example, the structure and behavior of employed patterns can be shown by means of filtered logical and process



views. An example for highlighting is a structural architecture view in which the elements that are being made persistent are marked for a persistence view.

• Augmented Views: new elements are added to an existing view, for ex-ample annotations for performance data in dynamic views.

2.5 Typical Views

A view set as the ones proposed in literature can be used directly or as a start-ing point for defining a customized view set that is tailored to the respective project context. The customization process has been presented in the preceding section. Its result is a customized meta-model that defines the views to be used to describe an architecture. The notations that are used to model the views ac-company the meta-model. We use the following template to define the view-point a view conforms to. As defined in the IEEE recommended Standard 1471 for Architecture Description, a viewpoint establishes the conventions by which a view is created, depicted, and analyzed [IEEE1471].

Viewpoint Name of the viewpoint

Concerns The concerns the viewpoint addresses

Metamodel Pointer to the meta-model defining the view

Representation The notation used to depict the view

Process Pointer to the process description that captures how the view is created

Analyses Pointer to the applicable analyses

Table 1. Viewpoint Template

In the following, the view set proposed by Hofmeister, Nord, and Soni is mod-eled using the viewpoint template [HNS00]. It can then play the role of an exist-ing view set in the view customization process (cf. Figure 4). The view set is comprised of four views, conceptual architecture view, module architecture view, execution architecture view, and code architecture view that will be pre-sented in more detail in the following subsections.

2.5.1 Conceptual Architecture View

The conceptual architecture view captures the application domain by mapping the functionality of the system to conceptual components. Conceptual connec-tors are used to coordinate the conceptual components and to exchange data among them. The interplay and relationships among conceptual components and the conceptual connectors is captured in the conceptual configuration.



The conceptual view depicts a system from an application domain viewpoint that is independent of solution aspects, like software or hardware techniques.

Viewpoint Conceptual Architecture ViewpointConcerns • Functional Requirements

• COTS Integration • Legacy System incorporation • Domain-specific hardware/software integration • Partitioning into product releases

Metamodel

Representation • Structural Models for decomposition of functional require-ments in conceptual components (e.g., UML class diagrams with appropriate stereotypes)

• Behavioral Models for modeling the conceptual connectors (e.g., UML sequence diagram)

Process cf. Design Activities for the Conceptual Architecture View Analyses -

ConceptualComponentConceptualComponent

ConceptualConnector

ConceptualConnector

ConceptualConfigurationConceptual

Configuration

1 1

******

0..10..10..10..1

Table 2. Conceptual Architecture Viewpoint

The metamodel is a slightly simplified version of the metamodel in the originally published view set. We removed the conceptual ports and roles, as well as the protocols, because we usually describe the conceptual architecture at a level of detail that does not go into such detail that the mentioned concepts are neces-sary. The process for creating a conceptual architecture view is not replicated from the original reference because the focus in this deliverable is on the views playing the role of an interface between recovery and design activities. Hof-meister, Soni, and Nord do not provide analyses for the views. Again, since the focus is not on that aspect of viewpoints, we do not provide analyses.

2.5.2 Module Architecture View

The module architecture view maps the components and connectors from the conceptual architecture view to subsystems and modules. The conceptual solu-tion provided in the conceptual architecture view is addressed with available software platforms and technologies.



The modules are the places where computation takes place. Modules require and provide interfaces to other modules. Interfaces have no associated imple-mentation. Modules are organized in two orthogonal structures: decomposition and layers. A software system is decomposed into a number of hierarchical sub-systems and modules. A module is also assigned to a layer, which then con-strains a module’s dependencies on other modules.

Viewpoint Module Architecture Viewpoint Concerns • Mapping of the solution to a software platform

• Support and services required • Testing support • Dependencies among modules • Reuse of modules/subsystems

Metamodel

Representation • Structural Model for decomposition of the system into subsystems, layers, modules and interfaces (e.g., UML class diagram with appropriate stereotypes and packages for subsystem and layers)

Process cf. Design Activities for the Module Architecture View Analyses -

*

*

*0..1

0..1ModuleModule

SubsystemSubsystem

*

*

0..1

0..1

containcontain

containcontain

use

InterfaceInterfaceInterface

LayerLayerLayerassigned toassigned to* *

*

use

requirerequire

provideprovide

requirerequire

provideprovide*

*

*

*

*

*

**

containcontain

*

Table 3. Conceptual Architecture Viewpoint

As in the conceptual architecture view, the process for creating a module archi-tecture view is not replicated from the original reference because the focus in the deliverable is on the views playing the role of an interface between recovery and design activities.

2.5.3 Execution Architecture View

The execution architecture view captures how modules from the module archi-tecture view are mapped to the elements provided by the respective runtime platform and how these are mapped to the hardware architecture.



The modules identified in the module architecture view are assigned to runtime entities. Two or more runtime entities communicate via a communication path. The type of available runtime entities and communication paths is dependent on the software platform that provides platform elements and communication mechanisms. The software platform also determines the available platform re-sources that can be assigned to appropriate hardware resources.

Viewpoint Execution Architecture Viewpoint Concerns • Performance

• Recovery • Reconfiguration • Resource Utilization • Concurrency • Replication • Distribution

Metamodel

Representation • Deployment diagrams that show the mapping of software onto hardware (e.g., UML deployment diagrams)

Process cf. Design Activities for the Execution Architecture View Analyses -

SoftwarePlatform

2..*

use mechanism

consume

*contain

CommunicationMechanism

PlatformElement Platform

ResourceHardwareResource

CommunicationPath

RuntimeEntity

ModuleView::Module

*

*

*

*assigned to

* 1

*consume

* *

assigned to**

*

1

*

1

communicate over*

is a

SoftwarePlatform

2..*

use mechanismuse mechanism

consumeconsume

*containcontain

CommunicationMechanism

PlatformElement Platform

ResourceHardwareResource

CommunicationPath

RuntimeEntity

ModuleView::Module

*

*

*

*assigned toassigned to

* 1

*consumeconsume

* *

assigned toassigned to**

*

1

*

1

communicate overcommunicate over*

is ais a

Table 4. Execution Architecture Viewpoint

2.5.4 Code Architecture View

The code architecture view captures how the runtime entities from the execu-tion view are mapped to deployment components, how modules from the module view are mapped to source components and how deployment compo-nents are produced from source components.



The code architecture view captures how the implementation of the system de-scribed in the other views is organized. The source components, intermediate components (e.g., object files or static libraries), and deployment components (e.g., executable or dynamic libraries) are related to the elements from the module view (i.e., subsystem, layer, module, and interface) and from the execu-tion view (i.e., runtime entity).

Viewpoint Code Architecture Viewpoint Concerns • Version and release management

• Build time reduction • Tools for development environments • Integration • Testing

Metamodel

Representation • Process cf. Design Activities for the Code Architecture View Analyses -

*

used at run time

trace

1

ModuleView::Subsystem

ModuleView::Layer

ModuleView::Module

ModuleView::Interface

Code Group

SourceComponent

BinaryComponent Library Executable Configuration

Description

trace

0..1

0..1

*

*

*

trace

trace

0..1

0..1

*

ExecutionView::RuntimeEntity

1

*

instantiate

link

link

**

link

compilecompile

******* 1generate import

**

**

*

used at run timeused at run time

tracetrace

1

ModuleView::Subsystem

ModuleView::Layer

ModuleView::Module

ModuleView::Interface

Code Group

SourceComponent

BinaryComponent Library Executable Configuration

Description

tracetrace

0..1

0..1

*

*

*

tracetrace

tracetrace

0..1

0..1

*

ExecutionView::RuntimeEntity

1

*

instantiateinstantiate

linklink

linklink

**

linklink

compilecompilecompilecompile

******* 1generategenerate importimport

**

**

Table 5. Code Architecture Viewpoint

2.6 Mapping the Meta-Model to Recovered Information

As described above, software architectures can be used as an interface between design and recovery activities. A common meta-model for describing the archi-tectures that are recovered and the product family architecture that is designed based on the recovered architectures is a pre-requisite for doing this. The last section presented a view set that consists of four architectural views as an ex-ample for such a common meta-model. This view set can be directly used to document a designed architecture. However, as a goal description for recov-ered information it is insufficient. This is caused by the abstraction gap that ex-ists between concepts at architectural level and concepts expressed using pro-gramming language constructs: even though the architecture of a system is definitely existing in its implementation, it is not expressed directly in the source



code. Therefore, a mapping is necessary that relates programming language constructs and combinations thereof with elements of the architecture descrip-tion meta-model. This mapping is depending on the programming language used, project characteristics, and the legacy systems used as a starting point for a product family architecture and their implementations. For instance, in the module architecture view of a C system, a module is mapped to an implemen-tation file and it optional header file (i.e., fileA.c & fileA.h) while for a Java sys-tem it would be mapped to packages or classes, depending on the organization of the system and the stakeholder’s persective on the system. An example for a mapping based on the legacy systems is that depending on underlying the op-erating system, the used platform and hardware resources differ.

Chapter 3 will describe the mappings in more detail for the views presented above, by connecting the meta-model entities to the recovered artifacts.

2.7 Process Description

Figure 5

Figure 5 Combining Design and Recovery - Process Overview

depicts the process of combining recovery and design. The single steps are described briefly in the following overview, then in details in the next sec-tions.

A0

Determinearchitectural

Views

A1

Recover requiredarchitecturaldescription

A2

Analyze andcompare

architecture

A4

Develop newreference

architecture

A3

Select bestreuse

candidates

scope

businessgoal

selectedviews

recovered views

referencearchitecture

fragment

scope

softwaresystem

product anddomain

information

product anddomain

information

Determine architectural views: This step decides which views should be recovered. Each view focuses only on certain properties of a software architecture, so a set of complementary archi-tectural views such as described by Hofmeister et al. [HNS00] and Kruchten [Kruc95] is used to describe a software system as a whole. For instance, these views may be:

• Conceptual view to show conceptual components and connectors.



• Development view to show the source code organization and include de-pendencies.

• Module view to show the subsystems, modules, and layers.

• Code view to show the organization of the software system on file-system level.

• Deployment view to show how a system is mapped to hardware.

• Dynamic view to show how a system interacts when performing usage sce-narios

• Feature view to show the implementation of a set of features at the compo-nent level.

• Data structure view to show the data-driven information.

Architecture recovery: In terms of our architecture recovery approach we particularly focus on the ex-traction of the view set proposed by Hofmeister. The architecture of each re-lated prior individual software system has to be recovered first. The software system usually consists of source code files, or it is represented in a fact base with relevant information extracted out of the system. The architecture recovery step is strongly influenced by product and domain information, e.g. domain expert input, requirements specification, user manuals, (mostly outdated) de-sign documentation, etc. Architecture recovery delivers different aspects of the architecture. One category concerns the architectural concepts. Every software system is built according to some particular architectural style. The style defines the types of building blocks that can be used to compose the system (e.g. com-ponents, classes, applications) and the communication infrastructure that en-ables the components to interact at runtime (e.g. software busses, remote pro-cedure calls, function calls). Those concepts represent the way developers think of a system, and they are first class entities, the terminology, of the reconstruc-tion.

Analyze and compare architecture: This task involves producing useful design information by comparing the archi-tecture descriptions of prior products. Product and domain information are used to answer questions when comparing the architecture of different systems and extracting plausible rationales. Existing architecture descriptions are rarely up-to-date or rarely contain all the needed views. However, they offer an an-chor point from which the reverse architect produces a description closer to the expert mental model of the system. Explicitly recording the concepts, features and functionality expected in the system can guide the reverse architect and help the production of a description expressed in the terms used by experts. The analysis phase annotates the architecture descriptions with rationales. When comparing the prior systems’ architecture, the reverse architect may re-quest more detailed information or additional views. This has to be fulfilled by



another iteration of architecture recovery. The architecture descriptions are complemented by newly gained information, so that we have individual de-scriptions annotated with rationales and information referring to multiple sys-tems (e.g., trade-offs involved in the choices of multiple system, integration strategies). The infrastructure and the architecture style present in the individual systems constitute key inputs to the design of the reference architecture. In addition they offer a good point to anchor initial comparisons. This step analyzes the re-covered architectures of different systems to find out how and why they ad-dress the requirements in the way they do. It also documents the implementa-tion strategies employed by each system to address a given concern and evalu-ates their success in their respective context and compares the strategies with respect to criteria relevant to the product family. It captures the conjectured ra-tionales and trade-offs involved in selecting the strategies used in a system (similar to Parnas’ idea of a “rational development process and why we should fake it” [PaCl93]).

Select best reuse candidates: Reuse candidates offer a great potential in the design process. The conse-quences when reusing those parts those fragments are already visible in the prior software systems. So the risks for integration and application of those parts are known, and therefore, the risks can be mitigated if necessary.

Develop new reference architecture: PuLSE-DSSA [AB+00] is an iterative and scenario-based method for the design of reference architectures. The basic ideas of PuLSE-DSSA are to develop a ref-erence architecture incrementally by applying generic scenarios in decreasing order of architectural significance and to integrate evaluation into architecture creation. The quality of the architecture is monitored and assured in each de-velopment iteration. The input to design a reference architecture is information obtained through architecture recovery as well as a prioritized list of business goals, functional requirements, and quality requirements. The design might re-quest to deepen the analysis and comparison of the architecture of prior sys-tem, or to refine views or to produce other specialized views. The knowledge gained in the analysis of the recovered architectures is inte-grated into the design process of the reference architecture. The construction of the reference architecture provides feedback on what is important for the design process, and which views should be presented in more details.


Architecture Recovery Techniques

3 Architecture Recovery Techniques

In the main process of this deliverable, after the architect has defined the views that should be used to express the concerns of the product family, the reverse architect reconstruct these views from the prior related systems. This chapter describes the techniques used to reconstruct the required views and their inter-action with the example of the Siemens’ view set (Hofmeister et al. [HNS00]). As described in the last chapter, this view set contains the code view, the mod-ule view, the conceptual view, and the execution view.

Reconstructing these views constitutes a good illustration of the broad scope of the possible recovery techniques and their mutual support. Reconstructing these views exercises dynamic and static analysis, top-down and bottom-up technique, and expert-driven and automatic recovery. One reconstructed view supports the construction of the others: For example the execution view can il-lustrate the dynamic interaction amongst the components recovered in the module or the conceptual view. Similarly, by describing the code view the ex-pert can provide useful inputs for the module or the conceptual view. Because of the way these views build on each other, this chapter presents the views re-construction techniques in the following order: code, module, and module view, then the execution view.

These views constitute the canvas on which the expert and the reverse architect will paint the design rationales, the successful means to meet requirement, to-gether with the commonalities and variabilities among the various prior sys-tems. This creation will take place is the architecture analysis and comparison method described in the next chapter. The product family architect, who will design the new reference architecture, can enrich the views by these analyses.

3.1 Code Architecture View

3.1.1 Introduction to the Code Architecture View

Code architecture views isolate the construction and development aspects of a software system, and organize them in a separate view according to the or-ganization’s particular development environment. The implementation lan-guage, development tools, development environment and the development process have a strong influence on this view during forward engineering, thus, they will affect again when recovering the architecture of software systems.



The code architecture view is grounded on information found in the source code, in configuration files, or other information sources directly connected to development environment. The main goal of the code architecture view is to give an overview about how the different elements are organized in the devel-opment environment of an organization.

According to Hofmeister et al. the code architecture view is built of several dif-ferent code groups. Each code group can again contain other code groups. A code groups consists of the following elements:

• Source components

• Binary components

• Libraries

• Executables

• Configuration description

The code architecture view shows a static view on the software system, i.e. in-formation that can be gathered without executing the system. Fact extractors perform (several) static analyses to collect data and information out of the de-velopment environment.

3.1.2 Elements of the Code Architecture View

In the following sections, it will be discussed how the different elements can be recovered from existing systems as well as what are available techniques for the tasks and which problems might occur in their usage.

Source components

Source components are artifacts, which are produced by software developers in the implementation phase. They can be programmed manually or with the help of source code generators. Information about source components can be col-lected with fact extractors. A fact extractor analyzes the complete source code and extracts low-level information. Based on this low-level information, we can build at least two hierarchical perspectives on the software system:

• Physical containment: the physical containment perspective of a software system reflects the file system structure in the development environment. It shows the location of directories and files related to the software system. This perspective is language independent, i.e. every software system has of these two elements (in the worst case, it is one file in a flat directory struc-ture).

• Structural containment: the structural containment perspective shows logical abstraction structure of the source code entities. It is obvious that this is a



highly language dependent perspective on the software system. Therefore we have to choose an appropriate fact extractor with respect to the lan-guage of the source code. If the developers used different programming languages or dialects within a system, several fact extractors are needed, or the fact extractor has to be adapted in some way.

An example of a structural containment is an object-oriented software system programmed in Java. In Java, we have the following structural hierarchy: at the top-level are the Java packages, which contain one or more classes. Each class may consist of several attributes, methods, and inner classes. The same counts for inner classes again. Attributes can be class variables or instances of other classes; methods operate with local variables, members and invoke methods of other classes. A fact extractor can provide this structural information and the relations between the entities.

In contrast to a Java system, a procedural system programmed in C has a dif-ferent structure. It consist of functions and procedures, which may call each other, pass variables and parameters between each other and they may set and use global data structures.

When recovering a software system, it is most important to have the right fact extractor(s) because of these language dependent differences.

Fact extractors store the information in a fact base. Several fact extractors may contribute to one and the same fact base, in order to capture some product specific information not provided by a single fact extractor. There are different types of fact extractors:

• Parsers: a parser is a program that receives input in the form of source code instructions and breaks them up into parts (for example, the nouns (objects), verbs (methods), and their attributes or options) that can then be put into a fact base or can be processed by other tools.

• Lexical pattern matchers: a lexical pattern matcher evaluates the source code based on regular expressions, i.e. it scans the code for a search string matches the criteria (or several criteria for more complex patterns) and puts the hits into the fact base.

In general, (most) fact extractors are able to collect at least the following rela-tions between source code components:

• Imports: this is a dependency between files, one file needs information that is part of another file.

• Call: calls are function or procedure calls in a procedural software system, or if we have an object-oriented system, method invocations are extracted here



• Inheritance: inheritance can occur between classes, that means one class in-herits the attributes and/or methods of another class

• Set: an attributes can be set by a method, or a variable can be set by a func-tion or procedure

• Use: the same applies for the use relation

• Of-type: the of-type relation indicates the different types; variables, fields or objects used in the signature of a method, function or procedure.

These relations can be lifted to various levels of abstraction, even to higher-level views. Depending on the questions the reverse architect wants to answer, he may neglect some relations or even some source components.

Static analysis with the help of fact extractor cannot resolve all relations be-tween source code entities, since some decision can only be drawn at a later time, i.e. at the compile time, or run time of the system. Therefore the code ar-chitecture view should be completed by the execution architecture view, where the interaction of the different source code entities is modeled.

Binary Components

When compiled, the statements of source components are translated machine code. A source component is transformed into at least one binary component. Binary components are then linked together to libraries and executables, which then enable the user to run the program.

Libraries

Libraries often contain general support or special purpose functionality like mathematical computation, file handling, or graphical user interface stencils. When analyzing an existing system, the reverse architect wants to set a certain focus, e.g. he only wants to learn about the software system itself (i.e. without any libraries) or the connections between the software system and a specific group of libraries. For this reason, recovery techniques should be able to filter the information, which will be put into the fact base. We have to differentiate between two types of libraries:

• Third-party libraries: third-party libraries are often part of the development environment and located in other directories than the software system itself. The libraries are linked to the binary components during the build process. Filter have to be applied to certain standard include directories, and to user-defined directories passed via switches to the linker.

• In-house libraries across programs: a software system can consist out of other software systems, which play the role of libraries. In this case, the li-braries serve a lot of systems and have to be handled very carefully because



of their high importance in to the organization. A concrete specification whether the binary components are part of the libraries or part of the soft-ware system under examination is needed.

• In-house libraries within a single program: These libraries are a normal part of the software development environment. The source components are packaged into libraries in order to obtain to have a more

The separation of libraries and the software system is a filtering problem. The reverse architect has to leave out certain parts contributing to the software sys-tem, but disregard in the recovery process.

Executables

The result of the transformation process of source components into binary components through compiling and linking are executables. Executable are mostly machine and operating system dependent, i.e. the translation process introduces various dependencies to the source components.

Configuration Descriptions

The configuration description of a software system has a very strong influence on the other elements of the code architecture view. The configuration descrip-tion decides among others can be divided into mechanisms and results of the software system. Mechanisms care about:

• Preprocessing conditions

• Compiler switches

• Include paths for libraries

• Make-files generation and execution

Results directly connected to the configuration might be among others:

• Which parts are included in one particular instance of a software system, and which are not

• Initial values for variables and constants

• Distribution to client and server

• Etc.

The configuration description is a very crucial part in the analysis of existing software systems because of its deep impact on source and binary components, libraries and executables. The more a software system is configurable, the more complex is the situation for the reverse architect. Instead of analyzing all possi-ble instances at the same time, the focus is set onto one concrete instance first



(often the most common one). Later, other instances can be analyzed and the differences can be modeled in the view.

Special Cases

This section names two possibilities how to construct the code architecture when the source code itself got lost (e.g. after a hard disk crash).

• Binary Components: For the analysis of binary components, there is one type of fact extractor. A decompiler converts object code back into the code of a higher-level language. A major problem of this technique is that some of the naming conventions present in the original source code will be replaced with insignificant terms in the decompiled version.

• Libraries: libraries can be analyzed with the help of disassemblers. A disas-sembler converts a program in its ready-to-run form (sometimes called ob-ject code) into a representation in some form of assembler language so that it is readable by a human. A program used to accomplish this performs the inverse of the task that an assembler does.

• Executables: A disassembler can also be applied to executables.

The understandability and readability of the code, and therefore of the emerg-ing code architecture view as well, will be decreased when working only with decompilers. As well as with decompilers, the value of the extracted informa-tion by disassemblers lacks of incomplete information.

3.1.3 Conclusion

Due to the large variety of possible combinations of source code languages, configurations, tools, make-files properties, not every case is addressed in the above description. Therefore the above description gives a general overview about recovery techniques for the code architecture view. The elements of the code architecture view will be transformed from one into another, starting from the source code, finally ending with libraries and executables. The translation process of source components of the software systems has to be documented in order to support the organization of concurrent development, compilation and build processes. Different development teams need a clear decomposition of the source components, so that the integration process of the whole soft-ware system is smoothed as well as the management of different version of the source components is possible.

Abstractions, aggregations and groupings of the code architecture view ele-ments build the higher-level view (i.e., first the module view, then the concep-tual view). The higher level or abstracted entities and relations can be mapped to a concrete ones at the code level. During architecture recovery activities,



code architecture view and the execution architecture views produce a lot of facts about the software system. The facts are then the foundation for the two other views. In case of an ambiguity in the higher views, the reverse architect can step at every time into the details, and inspect his assumptions.

For a large-scale software system, both views will contain a lot of elements (up to several millions), which can be hardly managed by humans. For this reason, the foundation has to be shifted to a wieldy level (i.e., the module and the con-ceptual architecture views).

Having all four views, analysis of the system is possible in a top-down (guidance from the higher levels) and a bottom-up (from details to abstractions) manner (or both combined).

3.2 Module Views

In the Siemens view set [HNS00], the module view organizes modules into two orthogonal structures: decomposition and layers. The decomposition of a sys-tem captures the way a system is decomposed into a hierarchy of subsystems and modules. A module is also assigned to a layer, which constrains its de-pendencies on other modules, based on the layer where they are found. The following subsection address these structure in turns: decomposition into sub-systems and modules, then the layers.

3.2.1 Subsystems and Modules

The focus of this subsection is on recovering efficiently this decomposition, when it is not available or up-to-date. It describes a semi-automatic technique to produce this decomposition of a system based on its source code and expert inputs.

Before considering how to efficiently recover this decomposition, it is helpful to consider why we recover it and how it will be used. The main goal of this re-covery is to help the design a reference architecture by focusing the architects’ and experts’ attention on the specific subsystems and modules implementing a needed feature in different prior systems. This allows them to identify, analyze and compare the strategies and solutions of prior systems and used them as in-put to specific design questions.

We exploit the system decomposition of the module view for two main pur-poses. First it serves as a good anchor point to interact with developers or de-signers of the system. For them, this view is more abstract than the code view, but still close to daily understanding, so that they can easily use it as reference point, when answering questions about strategies and solution employed to



implement features or fulfill quality attributes. Second, the decomposition serves as input for the execution and conceptual view. The dynamic part of execution view analyses the dynamic interaction among the subsystems and modules defined here. The conceptual view combines the decomposition with top down information obtained from expert and other sources.

Coming back to the efficient recovery of the decomposition of the module view. Reconstructing this decomposition manually requires often too much ef-fort to be practical, due to the high of number of files and the fact that other sources (e.g., the code view and the conventions) often reflect only a small part of the module structure. For this reason, automatic or semi-automatic solutions can be very useful, when they provide a good approximation of this decomposi-tion with limited expert effort.

A semi-automatic solution must meet a key challenge to be successful: It has to find the right combination of limited expert input and focused review to achieve a decomposition that the expert accepts with few modifications.

There exist different automatic [MM+98, HuBa85] or semi-automatic [ScHa94, MüUh90] techniques, which decompose a system into a hierarchy of subsys-tems and modules (see [BGS02] for a summary of these techniques). This sub-section describes SARA (Semi-automatic Architecture Recovery Approach), be-cause it is more flexible and efficient in handling expert inputs and reviews, and in many cases, it is more successful [Gira03].

3.2.1.1 SARA Overview

SARA decomposes a system into its subsystems through a series of automatic steps, which exploit the optional inputs and feedbacks the expert provides. SARA exploits them by calibrating its automatic steps automatically. It proceeds through successive approximations of the complete decomposition. Usually, the more inputs and intermediate feedbacks the expert provides, the fewer itera-tions are needed until SARA reaches a decomposition he accepts. In the best case, there are as few as 1 or 2 iterations.

SARA’s Input

SARA has a single mandatory input to automatically produce a subsystem de-composition. All others are optional, but their use leads to faster convergence toward a decomposition that the expert accepts. This compulsory input is a graph. Its nodes are the smallest relevant units (e.g., a file, a class, or a pack-age). Its edges are the relations among these units (e.g., includes, calls, data usages, inheritance, distributed connectors). The exact kinds of nodes and edges used depend on the available information extracted from the system by



the static fact extractors and the expected usage. Given this mandatory input, the question is how to obtain the key optional input with limited effort.

Usually the expert has an idealized module view of the system and he can de-scribe it with limited effort. This view is not perfect: Often it is incomplete and out-of-date. The expert can only map parts of it to the actual code. Despite these drawbacks, it is parts of his understanding of the system. For this reason, producing a subsystem decomposition, which is inspired by this idealized view, has a major advantage: the expert has access to his intuitive knowledge of the system when analyzing this decomposition.

The description neither has to be complete nor to require important effort to be useful. For example, it is enough if the expert performs some of the following activities (in decreasing order of importance):

• He names the main subsystems.

• He designates a few representative units (usually 1-10) for the most impor-tant subsystems.

• He associates units following a naming convention to the specific subsystem to which they belong.

• He identifies directories that for him belong to a specific module or subsys-tem.

• He estimates the relative size of the subsystems.

• He characterizes subsystems playing a particular role in the system (e.g., support/library, main drivers, client, server).

When the expert partially describes his idealized module view of the system in this way, SARA exploits these partial descriptions of the subsystems to select among alternatives, prioritize results for review, and calibrate its automated techniques. Once calibrated, the techniques produce intermediate results (e.g., small components) and a complete decomposition, which are closer to the ex-pert idealized view.



1S111

Collapse molecularcomponents

2S112

Partition andClustersystem graph

# of components# representativesrelative sizerole of components

C1C1

3

Integration

expert rev iew

optional expert rev iew

naming conventions

Optional input

Legend

optional

normal f low

Figure 6 S1-Top-Level Semi-Automatic Recovery

SARA’s Three Phases

To extend the expert’s partial description and to exploit it well, SARA’s auto-matic steps are grouped into the three phases depicted in Figure 6. Phase one helps the expert in extending a partial description of his idealized view by iden-tifying naming conventions candidates and functionality candidates. After an optional review, these candidates are collapsed into molecular components used by the other two phases. The heuristics used to produce these candidates and support the expert are described in section 3.2.1.2. Phase two contains techniques that are automatically calibrated to exploit the expert partial descrip-tion. It produces a list of units serving as drivers or support and a hierarchical decomposition of the system by applying partition and cluster techniques. This phase is the core of the automatic recovery. It is described in Section 3.2.1.3. Phase three refines the decomposition of phase two at the molecular compo-nents and integrates drivers and support. This phase is described in 3.2.1.4. These three phases offer to the expert the opportunity to reduce the number of iterations needed to obtain by reviewing intermediate results and providing feedbacks.

Expert Review and Feedbacks

Usually the key expert of the system has very little time available to review re-sults and to provide feedbacks on them. Therefore it is important to obtain as much information as possible during this limited time. SARA minimizes expert effort to review on all intermediate result by prioritizing the elements to be re-viewed and requiring short and simple feedback on the proposed components. For each of these components, the review consists in going over their units and classifying each one as: correctly assigned to the component, incorrectly as-



signed or unknown. In addition, SARA uses different strategies to optimize the review and feedback session with the experts for specific steps. These strategies are explained with the description of the steps.

3.2.1.2 Phase 1: Collapse Molecular Component

Figure 7

Figure 7 Phase 1 – Collapse of Molecular Components

illustrates the three automatic techniques used to collapse units into molecular components. They are applied in three steps.

2

namingconvention-based

componentsidentif ication

1

Services w ithunique entry point

identif ication

sy stem graph

rev iew

clusteringdata

C1: f eedback uniqueentry components

C2: f eedback namebased components

The first step is to identify groups of units, which contribute to a service offered through a unique entry point. SARA applies a technique called dominance analysis [CiVi95] on the call relations among the system’s units to identify these unique entry points and the set of units associated with them. Each set of units is associated to an entry point in that every call chain starting at the main driver of the system2 goes through its entry point before reaching the units of the set. We call the set of units together with its entry point a unique entry component.

The second step generates component candidates based on the naming con-ventions provided by the expert. For each naming pattern, a group of units is created. Units, which appear in multiple groups, are assigned to the group to which they have the strongest similarity.

2 The main driver is the first system specific routine called. For a C system, the main driver is the main routine.



The expert can optionally review the results of the two steps above. In all steps, he validates that all the units belong to a single subsystem. Then if he already has defined the main subsystems, he can assign the unique entry component one of the main subsystems.

After correcting the results according to expert feedbacks, the molecular com-ponents are passed to the following phases. The unique entry components and the validated named- based components are passed to phase two. In this phase, they considered as individual item for the partition and clustering. The support and drivers units are passed three (integration).

2

Partition

3

Cluster

C1: f eedback onselected smallcomponents

C2:rev iewofhierarchicalcomponents

selected small components

hierarchicalcomponents

1

Support & driverf iltering

support & driv er

graph withoutsupport&driv er

units

Figure 8 Phase 2 – The Partition and Clustering Phase

Figure 8

3.2.1.3 Phase 2: Partition and Clustering

depicts the central phase of SARA. In this phase molecular components and individual units not belonging to such components are grouped hierarchi-cally into a binary tree. This tree contains the core information needed by the integration phase to produce the subsystem decomposition. The phase is com-posed of two steps: filtering support and drivers, partition and clustering. After looking at the filtering step, we will consider the data representation used by the two following steps.



Filtering Support & Drivers

In the first step, SARA identifies support units and drivers. The support units are units, which do not call any other units. They usually play a role similar to librar-ies, offering services. The drivers are units that call a large number of units. SARA obtains better results by excluding support and driver units from the par-tition and clustering steps.

Data Representation

The partition and the clustering steps use essentially the same input: a matrix where the row corresponds to the entities and the column to their attributes. These attributes are divided in different groups.

• The first group captures different types of relations among the entities (e.g., call, inheritance, data usage, include, etc.). The value represents a measure of their context similarity: the proportion of shared elements reached through this relation over all the elements reached through this relation.

• The second group characterizes the position of the entities in the contain-ment hierarchies of the code view (e.g., directories, packages). Each level of the hierarchy that is not filtered out by the expert is represented as a column of this group.

• The third group characterizes entities in terms of the word they use in their file names and identifiers and comments within the file. The columns of this group the words that indicate a component-related convention used in the system according to the expert.

• The fourth group indicates if the entities belonging to one of the libraries developed in-house (i.e. a library specific to the system or reused across pro-jects) or domain specific ones.

• The fifth group contains a derived attribute for each component for which the expert provided representatives. Its value is the distance between the en-tity associated with a row and the centroid of the representatives for this component.

The first group is always present, the last one is present as soon as the expert can provide some representatives (either directly or by reviewing suggestions from SARA). All other groups are optional and depend on the system’s context. The reverse architect decides which relationships are relevant in the first group and which optional groups should be used.

Partition

The first step partitions the entities into many small components that the expert can quickly and easily review, but the results of this review strongly improve the



overall decomposition. SARA employs different techniques (refined recursive bi-section [JaDu88] and a min-k-cut approximation [KaKu98]) to produce a range of small component decompositions. These decompositions are ranked accord-ing to how well they match the representatives provided by the expert in com-bination with internal metrics. The expert reviews a few selected small compo-nents from the best decompositions. For each of them, he identifies the entities that do not belong to the components. These corrected components become an extended representative set from which SARA computes new centroids and produce new small components decompositions. The best decomposition is se-lected. The small components are inputs for the next step.

Clustering

The second step of this process clusters the small components into a binary tree based on their similarity. It uses a hierarchical agglomerative clustering optimiz-ing one of 9 criterion functions. These solutions are ranked according to how well they match the representatives provided by the expert in combination with internal metrics. SARA transforms binary tree of the best solutions into a sub-system decomposition using the expert estimate subsystem size and heuristics trying to achieve decomposition containing 5-10 subcomponent per compo-nents. The expert has the option to review the resulting best decompositions.

Expert Review & Feedback

SARA combines the following strategies to optimize the review of the compo-nents of the partition and clustering steps by the expert:

• SARA describes the key characteristics of each component it submits for re-view; so that the expert does not waste time figuring out how the units of this component are related. These characteristics include the representatives contained in a component, the columns of the matrix that descriptive and discriminate most the units inside the component, and the units that are most representative of the component.

• It focuses intermediate review on components that the expert is more likely to know and recognize quickly. The components with the highest cohesion and the ones containing the representative units at their core are example of components that SARA proposes as first candidates for review.

3.2.1.4 Phase 3: Refinement and Integration

The third phase performs two tasks: it decomposes or refines the molecular components hierarchically and integrates the support and drivers unit excluded from the partition and clustering phase. At the end of these two tasks, the sub-system decomposition contains all units of the system.



SARA decomposes the larger molecular components by applying the partition parameters, which provided the best results in the partition phase onto each molecular component. To obtain the right decomposition, it varies the desired number of component from five to ten and keeps the decomposition with the best internal value.

SARA assigns each of the drivers to the subsystem to which it has the highest similarity. It then decompose the support units based on the subsystem using them.

3.2.1.5 Conclusion

The reconstruction of the subsystem decomposition module view can be a tedi-ous task if it is performed manually. On the other had an automatic that does not reflect the expert understanding of the system has little value. For these reasons, we developed SARA, the semi-automatic approach, which integrates key anchor points from the expect understanding of the system and performs automatic reconstruction with optional review and feedback sessions. This inte-gration is flexible and can be adapted to different type of systems. The current customizations include object-oriented systems developed in Java and Delphi, and procedural systems written in C.

3.2.2 Layers

Layers organize modules into a partially ordered hierarchy. Modules can be as-signed to exactly one layer. Layers consist of further layers and can only use lay-ers that are on the same or a lower level in the hierarchy. A layer depends only on layers that are on the same or on a lower level. A strictly definition of a lay-ered architecture means that the used layers are at most one level below.

To establish layers within a software system, the expert has first to define them, and then to assign modules (and/or subsystem) to the different layers. Then the reverse architect could take advantage of the reflexion model technique in or-der to check if hypothesis of the relations between the assignments corre-sponds to the source code. The reflexion model technique validates the as-sumptions of the expert about the software system against the source code. Detailed information about the software reflexion model can be found at [MNS95], while [MuNo97] shows that the technique is applicable to a large-scale software system.

Two layers of the software system can have interactions with each other, in the context of the reflexion model called edge. Each edge has explicit one of three different types:



• Convergences are interactions drawn in the hypothesis that could be found in the source code.

• Divergences describe where the source code differs from the hypothesis model.

• Absences are interactions stated in the model, which do not correspond to any interactions in the source code, i.e. the model differs from the source code.

To compute a reflexion model, four things are needed as input: the language description file of the source components, the source code translated into the input format, the layer model and the mapping. The former two can be synthe-sized out of the fact base, while the other two require expert input. In order to reduce the expert effort, one can adopt the semi-automatic technique for pro-ducing a description of the software system (see above). Instead of subsystems and modules, layers are this time outcome.

The process of establishing the layers will run over several iterations, until the layers are stable. Every iterations the expert may reconsider his assignments. Once stable, the technique can be used to check the layer part of the module architecture view, and hence, one is able to track changes, and to detect bro-ken layers.

3.3 Conceptual views

The conceptual view is the view closest to the application domain. As such, it can be a key facilitator to interact with domain experts, who are not interested in the details of the software system, but what the system does in terms of domain concepts. When inputs from such domain experts are required by the reference architecture design process, it is important to reconstruct this view by using the subsystem decomposition of the module view.

The conceptual view differs from the module view in its components scope, its structure, and the concerns it addresses. Conceptual components are where the main functionality resides. In the module view, all the application function-ality, control functionality, adaptation and mediation must be mapped to mod-ules [HNS00]. The structure of the conceptual view is flat, as its role is to pro-vide an overview. The module view subsystem decomposition is hierarchical, as it is decomposed down to the individual module level. Example of the module view’s concerns can be expressed by the following questions (from the recon-struction perspective):

• How are the products mapped to the software platform?

• How are the dependencies among modules minimized?



• Which modules and subsystems could be reused?

• Which techniques are used to isolate change in COTS, OS, database, stan-dards, protocols, etc. and how successful are they?

Example of the conceptual view’s concerns can be expressed by the following questions:

• How is domain-specific hardware and software incorporated into the sys-tem?

• How does the system meet its requirements?

• How are COTS components integrated and how do they interact (at the functional level) with the rest of the system?

• How is the impact of changes in requirements or the domain minimized?

• How is the system is connected to it environment?

When developing the software architecture of a single system, Hofmeister’s process produces the conceptual view first [HNS00]. In the reconstruction con-text, our method requires that the module view is produced before, since in-formation from the concrete system help building the appropriate abstractions. This way the conceptual view can be clearly associated to the module view and can be used as a domain-oriented map of the module view.

1

elicit domainconcept &

functionality

2

Identify domainconcepts andfunctionality insubsystems

3

transformsubsystems into

conceptualcomponents

4

associate relevantinformation tocomponents

module viewdomain/systemexpert

systemexpert

systemexpert

expert

logical components

5

refine conceptualview through

logical connectors

moduleview

expert

conceptualview

reversearchitect

domain & systemdocumentation

domainexpert

reversearchitect

reversearchitect

reversearchitect

reversearchitect

namingconventions

criticalconnectors

conceptual connectorson the module view

domain concepts

Figure 9 Conceptual View Reconstruction

Figure 9 illustrates the process of the reconstruction method, which produces a conceptual view from the module views, by removing information not relevant at the conceptual level. It is composed of the following five steps:



1. In the first step, the reverse architect elicits the relevant domain concepts and main functionality from a domain or a system expert. They may consult documentation about the system and the domain as input. When multiple systems from the same domain are analyzed the concepts and functionality list from one system can be exploited for the next system. This list of feature can serve as input for producing a feature map.

2. In the second step, the expert indicates where the functionally identified a-bove is implemented in the main subsystems of the module view. He also indicates, which functionality is not present in the system. Then he describes any additional important functionality implemented in each of the main sub-systems.

3. In the third step, the reverse architect and the expert strip the top-level sub-system decomposition of subsystems that do not contain any domain functi-onality elicited in step 1 and 2.

4. In the fourth step, the expert maps the domain concepts identified before to the component implementing them. Then he associates relevant information to the components. The fact that a component relies on domain-specific software or hardware is an example of such relevant information. The implementation of a logical component by a COTS is another example.

5. In step five, the expert completes the conceptual view by adding connectors among the conceptual components and refines them through a process ba-sed on the reflexion model approach [Mu95]. This process consists of the following substeps: a) The expert defines the type of logical connectors that are mostly rele-

vant to the context of this specific conceptual view. b) He uses these connectors to express his knowledge of the relationship

among the conceptual components identified above. c) With the help of the reverse architect, he then identifies from the modu-

les view the concrete connectors that implement the logical connectors. These connectors can be identified as specific services offered interface of a component providing the conceptual functionality.

d) The reverse architect lifts the concrete connectors to the main subsystem level of the module view and presents a reflexion model indicating the absence or the unexpected presence of connectors among components.

e) The expert reviews the cause of unexpected connectors among main subsystems, by reviewing the concrete connectors causing them. In most cases, these will be due to the fact that a subsystem contains sub-systems not implementing any of the functionality selected in step 1 and 2, but implementing control, adaptation or mediation. In this case, the expert and the reverse architect look at the next level of decomposition of the components and remove the subsystems and modules not contri-buting to the logical functionality. They then repeat step d. In some ca-ses, the cause of the unexpected connectors will be in the mapping



between concrete and conceptual connectors. In this case, they go back to substep c and proceed from there on.

At the end of this process the expert has produced a conceptual view, which contains the actual connectors among conceptual components that are clearly associated with the subsystems of the module view and have been annotated with the domain concepts they implement. The exact meaning of the concep-tual connector is also clearly defined and can also be used to enrich the module view and derive new customized views.

3.4 Execution Views

The architecture execution view comprises two parts; the first addresses the dy-namic aspects of the software system, while the latter explains the deployment of the system, how the elements of the code, module, and conceptual view can be mapped to concrete external elements (i.e., operating system mechanisms and architecture) as well as to the hardware architecture.

3.4.1 Dynamic Views

3.4.1.1 Introduction

Throughout this section, we describe the run-time behavior of a system with the help of dynamic views. Furthermore, we extend the main focus to potential comparisons of the dynamic views of similar systems. Dynamic views report how a software system acts during the execution of scenarios. In the meta-model of the execution view as proposed by Hofmeister [HNS00], the basic elements of the execution view are:

• Runtime entities

• Communication Paths

• Communication Mechanisms

The basic elements are the runtime entities (for example, threads, process, ob-jects) and their relation to each other, expressed via communication paths.

A run-time entity represents a running instance of a module or a code group. Two run-time entities can interact with each other via communication paths. A communication path can be a method invocation, a procedure call, or anything that connects two run-time entities. Two run-time entities can influence the behavior of each other by passing messages, or changing the internal status. The implementation of a run-time entity specifies the limit and the range of the state and of the behavior.



3.4.1.2 Motivation

Dynamic views describe the run-time behavior of a software system by instru-mentation and executing it with appropriate execution scenarios. By comparing the dynamic views of two systems A and B, for example, one can say that in both systems, the architectural entities implementing the feature f are mapped to separate system process (commonality) but in system A, these processes communicate via RPC, and in system B, communication is by semaphores (vari-ability). Dynamic views need not just concentrate on the process, tasks and threads but it can also contain conceptual elements of the domain. For exam-ple, let us assume that we have two similar systems in the banking domain and both systems have the feature “Money transfer between accounts”. This is a commonality. But in one system, the money transfer will be done only after verifying two times the PIN and in other systems just only once. This is variabil-ity. Using the dynamic view, we will be able to identify commonalities and vari-ability in the behavior of the systems.

From the meta-model of execution architecture view as described in [HNS00], we can infer that dynamic views should address the following questions?

• How are architectural entities from other views connected to the run-time entities like processes, threads and tasks? Every static architectural entity has a dynamic counterpart, but the assign-ment is not always trivial. Hence, we have to enrich the static information with dynamic aspects in order to answer this question.

• How do run-time entities interact or what are the conceptual messages (messages in the domain terminology) that are exchanged between the run-time entities, and how can they be mapped to architectural entities form other views? Run-time entities interact during the execution of a program using the communication mechanisms like RPC (remote process communication), IPC (inter process communication) and shared memory. In a big system, it is not obvious, which runtime entities interact and what kind of conceptual mes-sages they exchange for a given scenario/feature. Hence, this information has to be recovered.

• How many objects/threads that are created/destroyed by various modules implementing a feature?

The complexity behind the implementation of a feature should also be exposed in the dynamic view. With complexity, we mean:

• Number of methods that are executed among various modules in the mod-ule view

• Number of threads/process that are created by each module in the module view



• Number of objects created/destroyed by each module in the module view, if it is object-oriented system

However, the meta-model of execution architecture doesn’t include this infor-mation. The reason behind choosing most of these questions centered with features is that we are interested to identify commonalities and variability in the run-time behavior of the similar systems and similar systems implements similar features and also that the activity of creating reference architecture is mainly driven by features. Answer to the questions (1-2) will help us to understand the implementation of a feature in a system while the answer to question (3) will expose the complexity behind the implementation of a feature.

3.4.1.3 Techniques

Various techniques recover dynamic information from current systems, each fol-lowing the same principle:

• Instrumentation

• Execution

• Abstraction

First of all, the source code of the software system has to be instrumented in order that some kind of output is created whenever certain parts of the system are executed. For instance, whenever a routine is entered, is left, or a special action is performed by a routine, then new output is produced containing that information. Another example are components that communicate by sending messages via a standard primitive (for example, send (destination, message), where “destination” receives message), then we must trace these primitives to visualize that kind of information in a dynamic view.

In the next step the software system carries out a set of execution scenarios, and traces are collected for each execution scenario. The information of all sce-narios is then aggregated within one or more dynamic views on the system.

The volume of the extracted information is usually huge and the level of detail is fine-grained (on routine-level). In order to improve the usefulness of the ex-tracted information is lifted to higher level using the domain-knowledge and other architectural views. For instance, the dynamic information is lifted to di-rectories coming from the code architecture view in order to show runtime de-pendencies between specific directories, or the run-time information obtained in extraction phase is lifted to the module level, showing the relations of archi-tectural concepts to each other, during the execution of specific scenarios.

There are some techniques following the general principle introduced above:



• Riva’s Approach: This technique proposed by Riva in [RiRo02] recovers architectural views of a system by combining a static view containing a hierarchical decomposition and dynamic information showing interactions between the static entities. The extracted runtime messages are lifted from the routine-level to the level of architectural entities. Further abstractions can be obtained by horizontally (regard two or more entities as one) and vertically (regard two or more mes-sages as one) grouping of the entities. This approach is using message se-quence charts for visualization and manipulating the dynamic view.

• Jerding’s Approach: Jerding introduces a technique to extract components and connectors using a Solaris tool called ISVis as described in [JeRu97]. Components have to be assigned manually by the reverse architect to abstract the collected dynamic information. This approach is able to detect interaction patterns, i.e. a recur-ring ordered list of interactions, and to match all instance of such a pattern.

• Wong’s Approach: In [WGH00] Wong proposes a technique to quantify the closeness between components (e.g. files) and features (abstract functionality, e.g. “phonebook in a mobile”). After the carrying out an execution scenarios for a specific feature three different metrics are computed to get information about how a component has contributed to a feature or is dedicated to it: The distance DISTcf measures how close a feature f is to a program compo-nent c. 0<= DIST cf <= 1. If DISTcf is “closer” to 1 then we can conclude that only few blocks of the component c is needed for the feature f. If DISTcf is “closer” to 0 then we can conclude that many blocks of the component c is needed for the feature f The concentration CONCfc measures how much a feature f is concentrated in a program component c. 0 <= CONCfc <= 1. CONCfc equals 1 if and only if all the blocks used to implement f are in c, whereas CONCfc equals 0 if and only if none of these blocks is in c. The dedication indicates DEDIcf how much a program component c is dedi-cated to a feature f. 0 <= DEDIcf <= 1. DEDIcf equals 1 if and only if all the blocks in c are important, whereas DEDIfc equals 0 if and only if none of these blocks has anything to with f. All three metrics are computed for one single feature. If we have set of re-lated features, the interpretation of the metrics is unclear. The application of these metrics to architectural entities and features can make statements about the reuse potential of a certain feature.

• Murphy’s Approach: Murphy introduces a technique for visualizing the operation of an object-oriented system at an architectural level in [WMF+98]. Trace information (e.g. created/destroyed objects) is collected while carrying out the execution scenarios. The reverse architect maps then the trace information to architec-tural entities, which is the most crucial non-trivial step of this approach. De-



pendencies between the architectural entities as well as numbers about creation and destruction of objects are then visualized. This performance-related information makes statements about the complexity the systems.

The techniques vary in their inputs, outputs, and their degree of abstraction. compares the techniques with respect to the following points: Table 6

Table 6

• User inputs to the approach

• Extracted artifacts/information of the approach

• Scalability of the approach with respect to complexity and numbers of the scenario

Jerding’s approach automatically identifies interaction patterns, which can guide the reverse architect to compress MSC produced by Riva’s approach. Since static view is also recovered in Riva’s approach, this can be used in Wong’s approach to visualize various metrics at different levels of abstraction. That is, we visualize those metrics from the file level to higher level of abstrac-tion. In order to use Murphy’s approach, one need to define a mapping be-tween dynamic information and abstract entities, static view constructed from Riva’s approach can be used to define mapping and then visualize the complex-ity or performance related information extracted by this approach. In every ap-proach, the abstraction to a higher level is crucial in order to cope with com-plexity and the amount of run-time information. Since we are also able to re-cover modules, subsystems, and other architectural entities of existing systems, we can combine this information together with those provided by the tech-niques described above.

Riva Jerding Wong Murphy

User Inputs Scenarios, compo-nents (hierarchical decomposition)

Scenarios Scenarios, compo-nents (files), features

Scenarios, compo-nents, mapping

Extracted Artifacts

Component-level run-time interactions

Component-level run-time interactions, interaction patterns

Metrics: distance, dedication and concentration of a feature and a com-ponent

Component-level run-time interactions, performance related numbers and infor-mation

Major Weak-ness

No automatic map-ping between run-time and architec-tural entities




Output Forma

Message sequence charts (MSC), Rigi views

ISVis views Text Dotty graphs, text

Scalability ? ? No sets of features possible

?



3.4.1.4 Conclusion

In this section, we discussed the role of dynamic views, a part of the execution architecture view and showed why it is necessary to work with dynamic infor-mation when recovering a software system. We introduced briefly various exist-ing techniques that provide dynamic views. The code execution architecture is strongly connected to the other views. Information collected during the carry out of the execution scenarios can be combined with the static information of the other views. The execution architecture view rounds up the other perspec-tives on the software system, since it shows how a system behave during run-time and what physical resources are used during the execution.

3.4.2 Deployment Views

This subsection describes how the analysis of configuration files can produce an assignment of subsystems to a set of machines.

3.4.2.1 Introduction

The deployment view provides information about how runtime entities are mapped onto the hardware architecture of the machines executing a program. Deployment views are a good means to illustrate the connection of the various hardware elements on the hand, and the distribution of the system onto differ-ent machines on the other hand. The easiest case, as it is often the case for small systems, is that every runtime entity is operating on the same machine in the same process, accessing only one shared memory area. But as most soft-ware systems are complex, communicating over networks, radio, or the Inter-net, it is crucial to know about which parts run on which hardware.

The deployment part of the execution view is in charge for the following ele-ments, specified in the meta-model of Hofmeister et al.:

• Communication mechanism

• Platform element

• Platform resource

As described above, the other elements (what runtime entities are present, and which communication paths two runtime entities can use) of the architecture execution view can be recovered with the help of dynamic view.

The deployment influences the module and the conceptual view on the soft-ware architecture. When recovering the deployment, it will make a great differ-ence, if the reverse engineer bothers with a system running on a multi-processor hardware platform, or if it is a web application distributed on several



servers, using some kind of middleware to access an underlying database man-agement system.

3.4.2.2 Elements

Communication Mechanism

Two runtime entities communicate over a communication path, using a communication mechanism. There are a lot of different possible mecha-nisms, so the following list contains only some important ones:

• TCP/IP: This protocol realizes the communication via the Internet.

• RPC: Remote procedure calls are used to forward requests and responses in local area network.

• DCOM: This technology is responsible for establishing the communication of distributed components.

• CORBA: Another technology used for communication purposes.

• Etc.

Source components are responsible for the implementation of these mecha-nisms. The code architecture view can provide information about the corre-spondent parts of a communication path, i.e. which source components are sending requests, and which are replying with a response. For instance, in Java systems, the so-called stubs can be localized and be connected to the commu-nication path. Dynamic information then can report about the usage of the specific paths.

Platform element

Each runtime entity contributes to a platform element. Platform elements are operating system dependent container, where runtime entities run in or share data. A runtime entity can be:

• Process

• Thread

• Queue

• Shared memory

• Socket

• Shared Library

• File handle

• Etc.



A platform element is composed of at least one run time entity. To figure out, which platform elements are in use, instantiated or working together, the re-verse architects can monitor the software system and the operating system. The evaluation of the data will show for instance, if there were new processes cre-ated because of the software system, or if some memory was allocated by sys-tem. Furthermore, the runtime entities responsible for those actions can be identified when combing the deployment view with dynamic aspects. The code view indicates as well the usage of platform elements. For example, Java threads can only be instantiated in distinct, predefined ways. If the reverse ar-chitect is able to find those neuralgic spots, he can reveal the connection be-tween the platform element and a source component.

Platform element

Platform resources consume platform elements, i.e. every element needs at least one resource for its mode of operation, but it may be also split over sev-eral resources. Among others, the following items are considered as platform resources:

• CPU

• Memory

• Timer

• Address Space

• Semaphore

Platform resources are directly linked to the hardware of the machine, where the software system is running on. To encounter different hardware combina-tions, configuration files often specify system properties.

3.4.2.3 Conclusion

Deployment views show how a software system is connected to the hardware of the machine where it is running on. Different hardware combinations can lead to different deployment views, when the software system is configured in a way that considers hardware properties. Otherwise the system may be im-plemented in a way that the hardware influence is minimized. For instance, if a software system runs just in a process, it will do so in any case, whether the underlying machine is a multi-processor system or not. The dynamic parts of the execution architecture view and the code architecture view can help to dis-close the source components related to the deployment view elements since some of the elements are always implemented in a certain, consistent manner.



3.5 Integrating Views

The four views (i.e. the code, the module, the conceptual and the execution ar-chitecture view) complement each other. Each view contributes by revealing certain aspects of the software system not captured by another view. Each module of the module architecture view comprises a defined set of source components, i.e. it is a container of parts of the source code. Relations ex-tracted in the code architecture view, or dynamic information (which corre-sponds to source components as well) gathered through the execution of usage scenarios can be combined, and then lifted to the module (or subsystem) level. The gained level of abstraction described makes it easier to visualize and to re-flect consequences of code changes on the architectural level. Furthermore, it is possible to verify layers with the help of the combined views. The conceptual view puts the conceptual components and connectors in context with external systems. The components and connectors can be relocated in the module view, although there is not a one to one mapping.

In summary, only a sound set of views, which complement each other, can ful-fill the requirements we have towards an architectural description. Therefore, architecture recovery activities put emphasis on reconstructing the complete view set, i.e. the four views, as described above.


Analysis and Comparison of related prior Systems

4 Analysis and Comparison of related prior Systems

Once having architectural descriptions of prior systems (or at least partially de-scriptions containing most relevant information), we can start the architecture comparison. The goal of a comparison is to learn about different solutions ap-plied in the same domain, to identify advantages and drawbacks of the solu-tions, to rate the solutions with respect to scenarios. By achieving these goals, architecture comparisons contribute to the fulfillment of the quality goals of the design process of reference architectures.

Request

DSSA Request Analysis Request

Comparison

1

*

1

*

Prior System

Characteristic

Means

* has

* uses

1* fulfills

Results

*

Strategy Infrastructure Pattern

Scenario

Stimulus

Response

Figure 10 Architecture Comparison Meta-Model

A comparison of multiple systems is possible and reasonable, because all prior systems are related to each other:



• They implement the similar features to a certain degree

• They operate in the same set of domains

• They provide similar functionality

• Most of the time, they were developed within the same organization

Figure 10 depicts the meta-model underlying the comparison process described later in this chapter. A comparison is triggered by a request. Such a request can come from the design process for the reference architecture (e.g., PuLSE-DSSA) or can be started through insights gained during the analysis of individual soft-ware systems (the later phase of architecture recovery). Each request produces a result by use of a comparison, where the solution of the prior systems (at least one) is analyzed in detail. The information produced by the comparison is then communicated back to the originator.

When comparing two systems, we have to consider two different cases:

• Request about scenarios: We ask about how do prior systems fulfill scenarios. By analyzing individual systems and comparing different systems, we learn about sets of means as-sociated with a scenario for each system, and the background in which they are applied to fulfill it.

Request Comparison Result

Scenario

Context Means Rating

Figure 11 Scenario-driven Comparison



• A means-driven request has the goal to uncover the context in which the means was applied. More precisely, what were the consequences of a spe-cific means, and why were the means selected as solution and applied to the systems. Therefore, the detailed analysis during the comparison activity has to reveal information about applied strategies and system characteristics of a specific solution, i.e. what are the success factors of a solution, what trade-off had to be accepted, what were the rationales for choosing a specific so-lution, and which technical bottle-necks had to be solved.

Request Comparison Result

RatingContext Means Consequence

Means

Figure 12 Means-driven Comparison

4.1 The Comparison Process

Figure 13 shows the five major steps of the comparison process in IDEF0 nota-tion:

• Analysis of Individual Systems The process starts with a analysis of all given individual systems (the later phase of architecture recovery). This is part of architecture recovery, but it goes beyond the techniques as described in Chapter 3. The goal of this step is to learn about the essential characteristics of each software system. There are two main categories:

Success factors: Success factors (SF) report about means, patterns, and strategies that worked well, i.e. with the help of these factors advantages were gained. Success factors of different solutions provide essential input to the design



process of the reference architecture. The software architect can learn about what worked out well, and why it was a success.

Critical aspects: Critical aspects (CA) are circumstance (e.g., a pattern, or infrastructure) that leaded to negative, sensitive consequences. For the design process of the reference architecture, it is necessary to handle those aspects with caution (or to avoid them at all if possible).

• Transform Success Factors and Critical Aspects into Requests: In the second step, the success factors and the critical aspects are trans-formed into scenarios, if possible. These scenarios extend the scenario list built when designing a reference architecture. A request can ask about sce-narios and means:

Scenarios: A scenario is the combination of a stimulus and a response. Critical aspects for instance should be transformed into a scenario, because the new refer-ence architecture has to fulfill the scenario as well.

Means: The reason for asking about architectural means is to learn about the con-sequences one (or the combination of several) means caused in prior sys-tems, and to integrate the experiences into the design process of the refer-ence architecture for the product family.

• Prioritize requests (based on DSSA priorities): This optional step orders the scenarios, so that potentially important ones are processed first.

• Comparison of different systems: For a comparison, three activities have to be performed one after another:

1. Select Systems: To start, the software systems to be compared against each other have to be selected. The elicitation of these comparison candidates is an acti-vity, which has to be performed carefully for two reasons. On the one hand, the effort for comparing a sound set of comparison candidates is significant lower than comparing all systems. On the other hand, choo-sing too few systems leads to more or less useless results in the context of a product family.

2. Detailed Analysis: In the second activity, the selected systems underlie a detailed analysis focusing on issues concerning the requests. For each system, it will be analyzed how it addresses the requirements reflected in the request. Se-veral questions will be answered after this activity: why was it done this



way, what were the trade-offs, and how does the solution fulfill the re-quirements.

3. Conditioning: Each system will contribute to the concluding results, but the more sys-tems are compared, the more data about the systems is produced. To reduce the amount of information, the results are conditioned so that the most important data and the essential gains in experience are retur-ned.

• Feedback: In the final step, feedback is integrated into the process. A new iteration may be started because of the feedback. Or the information gained in sev-eral feedbacks may lead to new insight about the product family context, so that more information about some solutions is required. Due to the learning effects during the detailed analysis, new scenarios and analyzed means re-fine the design process of the reference architecture.

1

Analysis ofIndividualSystem

2

Transform SF/CA into

Requests4

Comparison

5

Feedback

Sucess FactorsCritical Aspects

3

PrioritizeRequest

Requests

Request

D1

DesignReference

Architecture(DSSA)

Request

Figure 13 The Architecture Comparison Process

4.2 Connecting the Business Cases to the Comparison Process

In Chapter 2.1, we identified three typical cases, where it is beneficial to inte-grate information of prior systems into the product family development proc-ess. Furthermore, we claim that the resulting reference architecture will be of a



higher quality in these cases than when designing a new one from scratch. The three cases are:

• A legacy system with a long evolution, but inappropriate as a basis for a product family: The architecture of the individual system reveals information about success factors and critical aspects, and then the detailed analysis can react to re-quests such like why is the system inappropriate, what were the conse-quences of the application of one specific architectural means. The results are knowledge of essential characteristics and learning about side-effects of certain strategies.

• A number of systems (or product families) developed individually: In this case, the main goal is to synthesize architectural means and strategies out of a variety of systems, and to identify potential reuse candidates. The comparison process of the different system will produce a partial ranking of the individual solutions for requests. On basis of this ranking and because we will learn about consequences as well, we are able to derive a solution that will fit the requirements of the reference architecture of the design process. And we make statements about the impact of scenarios, patterns and strategies, if they have been applied in one of the prior systems.

• An existing product family to be put on another level: This case seeks to retain most of the existing, working product family. Due to outdated documentation it is vital to recover the existing reference archi-tecture and to learn about scenarios and means applied. For the transition of the means, patterns, and strategies, it is necessary to learn about their con-text and to reveal the means associated with scenarios.

In all three cases, exploiting the given systems is worthwhile, since it helps to understand success factors and critical aspects, it avoids bottlenecks, and it promotes the learning about applied solutions. The recovering of an architec-tural description and the following comparison with its detailed analysis are crucial in order to benefit from the existing systems, and to reuse implanted knowledge, as well as field-tested architectural means, (i.e. patterns, strategies and infrastructure).

Hence, we have a good foundation of common points among all systems so that we are able to compare two different systems and to draw conclusions about the solutions of the systems within their specific context and therefore to contribute to the design process of the reference architecture.


Design of Reference Architectures

5 Design of Reference Architectures

This chapter discusses the design of reference architectures based on architec-tural information recovered from existing systems. It presents PuLSE-DSSA, an integrated, iterative, and quality-centered method for the design and evaluation of product family, or reference, architectures. It is part of PuLSE™ (Product Line Software Engineering)3,a customizable method developed at Fraunhofer IESE for building software product lines that covers the whole product line develop-ment life cycle and that can be introduced incrementally. In this initial version of the document, the most recent version of PuLSE-DSSA will be briefly described. This version currently does not provide detailed guidance on how to exploit re-covered information during architectural design. Instead of that, we will provide an outlook on how PuLSE-DSSA will be extended to introduce information re-covered from existing systems into architectural design and where information recovered by architecture reconstruction techniques would be exploited. The fi-nal version of this document will then describe an improved version of PuLSE-DSSA that not only supports architects in the design of reference architectures, but also enables to systematically use recovered information.

5.1 Introduction

PuLSE-DSSA is an iterative and scenario-based method for the design of refer-ence architectures. The basic ideas of PuLSE-DSSA are to develop a reference architecture incrementally by applying generic scenarios in decreasing order of architectural significance and to integrate evaluation into architecture creation. The quality of the architecture is monitored and assured in each development iteration. The input to PuLSE-DSSA is a scope definition, which defines the business case for developing a product family, and a product family model, which describes commonalities and variabilities in the requirements of applica-tions in the product family. The output of PuLSE-DSSA is a product family archi-tecture, which consists of an architecture description and an architecture deci-sion model. The PuLSE-DSSA method is customizable to different application domains and application contexts. In particular, it is customizable with respect to a number of factors, including the supported architectural viewpoints and the processes and techniques used to integrate existing components.

3 PuLSE is a registered trademark of the Fraunhofer IESE.



5.2 Overview

This section presents an overview of the method for product family architecture design and analysis. The method guides software architects in systematically making design decisions based on identified and documented business and quality goals and in assessing whether the architecture under design really satis-fies the requirements. It makes use of information provided in quality models and patterns documented according to the meta-model described in Section 2.4 and depicted in Figure 16.

Figure 14

Figure 14 Inputs to and outputs of the Product Family Architecture Design Process

provides an overview of the inputs and outputs of the product family, or reference, architecture design process. As shown in the figure, the product family architecture design process takes as input a prioritized list of business goals, functional requirements, quality requirements, and optionally architec-ture recovery information and produces a reference architecture that satisfies the specified goals and requirements and that is documented using a number of previously selected or defined architectural views. The goal of the product family architecture design process is to define an architecture that fulfills the given quality and business goals.

Product FamilyArchitecture Design

ArchitectureRecovery Information

BusinessGoals

FunctionalRequirements

Reference ArchitectureDescription

QualityRequirements

Means andPatterns

During architecture design, functional and quality requirements that have an ef-fect on the architecture are selected. Functional and quality requirements are described using scenarios in the product family model. The product family model has either been defined using PuLSE-CDA, the domain analysis part of PuLSE, or any other domain analysis method. Scenarios are short descriptions specifying functional or quality requirements for the product family and its members. In case of functional requirements, the scenarios describe concrete series of actions that illustrate the desired system behavior. For quality require-ments, on the other hand, the scenarios are given by stimulus response pairs. A stimulus is an event that causes an architecture to respond or change, whereas the response is the activity undertaken or the property observable after the arri-



val of the stimulus. For example, for the requirement “The system shall be able to provide its services in the case of a hardware fault“, the scenario has the stimulus “Hardware Fault” and the response “Availability” and reads “High availability in the presence of hardware faults”. Once the scenarios have been defined and selected for the current iteration, the principal structure of the sys-tem is defined by selecting means and patterns that satisfy the selected re-quirements. The software architecture is documented using the defined archi-tectural views. After that, the existing architecture is iteratively refined. After each refinement step, the architecture is assessed concerning its non-functional properties.

1

Select Scenariosand Plan Next

Iteration2

Define EvaluationCriteriaScenarios

SelectedScenarios

Business Goals

QualityRequirements

3

Choose Meansand Patterns

Selected Scenarios,Business Goals,

Quality Requirements

Existing Meansand Patterns

Selected Means andPatterns

4

InstantiatePatterns

5

DocumentArchitecture using

Views6

EvaluateArchitecture

Evaluation PlanArchitecturalViews

IntermediateArchitectur

eDescription

Final ArchitectureDescription

7

Analyze Problem

Evaluation Planidentifiying

risks

IntermediateArchitectur

eDescription

RiskScenarios

Figure 15 Architecture Analysis and Design

As shown in Figure 15, the method for the design of product family architec-tures is comprised of seven activities that particularly deal with the identification of existing solutions that fulfill certain quality attributes, the documentation of the resulting architecture using the selected views, and the evaluation of the software architecture with respect to the quality requirements. In the following subsections, the various activities will be described. Note that the section num-bers correspond to the step numbers in Figure 15 (i.e., Section 5.2.4 corre-sponds to step 4).



MetricMetric

1*

MeansMeans

1

*

*

ScenarioScenario *

*

1

/influence/subcharacteristic

Quality ModelQuality Model

Quality AttributeQuality Attribute

1

**

1 1StimulusStimulus

ResponseResponse

1

*

RationaleRationaleProblemProblem SolutionSolution

/satisfies

/uses/specializes*

/conflicts

PatternPattern

*

/subgoal

Business GoalBusiness Goal

/effects

Figure 16 The metamodel

5.2.1 Select Scenarios and Plan Next Iteration

The purpose of this activity is to delineate the scope of the current iteration step by selecting a limited number of scenarios from the set of scenarios. The scenarios describe the functional and quality requirements of the product family the architecture is designed for. As the order in which scenarios are addressed is very important, those scenarios that are considered to have the highest sig-nificance for the architecture should be selected for the first iteration. In the next iteration, the second most important group is selected and so forth.

When the scenarios were created, they are prioritized and grouped to define the architecture creation plan, which contains a detailed plan for the next itera-tion and defines the order of processing the groups with respect to their prior-ity. Prioritizing scenarios should follow a simple, basic rule: the bigger the im-pact of a scenario on the architecture, the higher the scenario’s priority. How-



ever, simple in theory, evaluating the architectural impact of a scenario from its description is a difficult, non-trivial task that generally requires much experi-ence. Below, some criteria that can be used for prioritizing scenarios and con-structing the architecture creation plan are summarized. These criteria can be used as an indication of the expected architectural impact of scenarios.

• Economic Value. This is the value from an economic point of view that will be added to the product family in case a scenario will be realized. The prod-uct family scope can deliver this information. It is clear that a high economic value is a hint for high scenario priority.

• Typicality and Criticality. A scenario is of high typicality when it reflects routine operations whereas a critical scenario occurs in a rather sporadic manner and when the user does not expect them to occur. Typical scenarios should therefore implemented first.

• Future-proof. A scenario is future-proof when it considers possible evolu-tion points. Future-proof scenarios are likely to have a big impact on the ar-chitecture and therefore they should assigned high priorities.

• Effort. This is an estimation of the effort required for realizing a scenario. Since the architecture creation plan also assigns responsibilities to personnel, the effort estimation is surely helpful.

At the end of this process step, it has been defined which group of scenarios will be processed in the next iteration.

5.2.2 Define Evaluation Criteria

Based on the business and quality goals for the product family and its members and taking into account the constraints, the criteria to be met by the architec-ture are defined. These criteria are later used to evaluate the architecture. As an input for this activity, the architecture creation plan and the quality scenarios are used. The output is an architecture evaluation plan consisting of a number of evaluation criteria. Defining evaluation criteria before the actual design be-gins has a number of benefits, including a better understanding of the re-quirements and avoidance of specifying criteria that, due to a fixed perspective, merely support what has been developed.

5.2.3 Choose Means and Patterns

During this activity, mechanisms are elicited that support the satisfaction of the quality requirements collected in the last step. As an input for this step, a cata-log of means and patterns is used. The means and patterns are described ac-cording to the meta-model depicted in . In a first step, appropriate means are selected. The selection is done by comparing the scenarios associ-

Figure 16



ated with the means in a catalog with the scenarios describing the actual re-quirements. Let, for example, “The system must be available 24/7 even in the case of a hardware fault” be a quality requirement for the product or compo-nent under design. This requirement is covered by the scenario “High availabil-ity in the presence of hardware faults” with the stimulus “Hardware Fault” and the response “High Availability”. The scenario is for instance related to the ar-chitectural means “Redundancy” and therefore redundancy is chosen for the architecture. Once the means are selected, the patterns that specialize the re-spective means are selected. This is again done by comparing the scenarios re-lated to the patterns in a pattern catalog with the scenarios for the actual re-quirements. The patterns can be either taken from published pattern collections (e.g., [BM+96], [Doug99 and [GH+95]), have been identified and documented during earlier architecture creation projects, or have been discovered in prior systems during architecture recovery.

5.2.4 Instantiate Patterns

The selected patterns are instantiated in this activity in order to address the functional requirements. During the instantiation, the architect associates the elements of the pattern with concrete architectural elements.

5.2.5 Document Architecture using Views

Using the architectural views selected and defined using the process outlined in Section 2.4 and already used for documenting the results of the architecture recovery, the architecture resulting from the previous step is documented. In later iterations, this means that the architecture documentation is continuously refined.

5.2.6 Evaluate Architecture

The purpose of this activity is to evaluate the given product family architecture according to the evaluation criteria defined earlier in the architecture evaluation plan. If the evaluation is successful, that is all evaluation criteria are satisfied, the architecture creation either continues with the next iteration or is finished if all scenarios have been applied. If, however, at least some evaluation was un-successful, the process continues with the step “Analyze Problem”. In the evaluation of an architecture, the available quality models are used. The explicit relation between patterns, scenarios, and quality attributes and the rationale documented for a pattern helps in evaluating the given architecture. To mini-mize the effort involved in the evaluation, only the functionality newly added in the last iteration is evaluated in detail. Nevertheless, it is essential to ensure that all scenarios from previous iterations are still supported.



5.2.7 Analyze Problem

If the evaluation of the architecture showed that at least one of the defined evaluation criteria was not fulfilled, the underlying problem is examined during this activity in order to determine how the architecture creation process can continue. The analysis focuses on whether the current set of scenarios could be applied successfully to the architecture that resulted from the previous itera-tions and includes an in-depth reasoning about the chosen architectural ap-proaches and decisions. In the best case, changing just the last iteration may solve the problem. In the worst case, if a solution supporting all scenarios in all variants even exists it is necessary to track back to the first iteration. The input is the result from the architecture evaluation activity. Outputs of the activity are a problem analysis and an assignment of action items.

5.3 Outlook

In order to systematically make use of recovered information in the design of reference architectures, PuLSE-DSSA has to be extended. This section provides an outlook which steps of the method have to be extended, what additional inputs and outputs for the various steps have to be considered, and what addi-tional steps might be required.

The following activities of PuLSE-DSSA have to be extended to make use of the information recovered from prior systems:

• Choose Means and Patterns. As an additional input to this step, means and patterns used in existing systems and identified during the architecture recovery process have to be considered. However, the selection of means and patterns is expected to remain the same, whether they have been col-lected from literature, from prior architecture design projects, or recovered from existing systems.

• Instantiate Patterns. Similar to the previous step, information about pat-terns and their instantiation obtained during architecture recovery can be used as an input to this step. The process of instantiating a pattern, how-ever, is expected to remain the same.

• Evaluate Architecture. This step has to be extended to not only evaluate a given architecture with respect to functional and quality requirements and the achievement of business goals, but also to check its conformance to the meta-model described in Section 2.5 if the architecture is the result of a re-covery process. In the latter case, it also has to be checked if the recovered architecture has the right level of abstraction.

In addition to the steps already defined by PuLSE-DSSA, a new step “Check Comprehensiveness of Architecture” will be introduced. This step is concerned



with checking whether and to which degree the architecture recovered from one or more existing systems addresses the product family requirements. The result of this activity is a list of requirements already covered by the recovered architecture, as well as a list of requirements which still have to be addressed. This information is then used as an input to the first design iteration and the step “Select Scenarios and Plan Next Iteration”.

In case architecture recovery information exists as input for designing a refer-ence architecture, the architecture obtained during architecture recovery will be evaluated as a first step. To this end, only a subset of the steps of PuLSE-DSSA will be performed. In particular, the steps “Define Evaluation Criteria”, “Evalu-ate Architecture”, “Check Comprehensiveness of Architecture”, and optionally “Analyze Problem” will be performed.

5.4 Summary

This chapter has discussed the design of reference architectures. The presented method supports the integrated analysis and design of product family architec-tures and makes use of information provided in quality models and patterns. In the final version of this document, an extended version of PuLSE-DSSA will be described that exploits information recovered from existing systems in the de-sign of reference architectures.


Conclusion

6 Conclusion

Introducing a software product family in a development organization is a non-trivial task. Before most software organizations consider it, they have already produced multiple successful systems in the domain of their product family. The organization usually wants to exploit the experience gathered in developing these systems and even reuse some of their components. However, this lever-aging of previous success is rarely performed in an explicit and systematic fash-ion. This report introduced an approach to systematically leverage this experi-ence, which defines the views needed to express the architectures of a specific product family, recovers and analyzes these views, and provides a systematic process to define the reference architecture integrating the experience of past systems.

In the approach presented here, the architect of the product family derives the views needed to express the architectures of a specific product family from the business and quality goals. To define these views, he architect usually does not from scratch. Normally, he would use, more or less explicitly one of the typical view set. In this document we used the view set from Hofmeister et al [HSN00]. It contains the code, module, conceptual and execution views.

Then the report describes how a reverse architect uses different techniques to reconstruct these four views for each of the prior systems. These views consti-tute the canvas on which the expert and the reverse architect will paint the de-sign rationales, the successful means to meet requirement, together with the commonalities and variabilities among the various prior systems. This work takes place in the architecture analysis and comparison step of the approach. The information coming out of this step is the input the reference architecture design process.

To define a reference architecture with the various recovered information, we use PuLSE-DSSA. It is an iterative and scenario-based method for design of ref-erence architectures. The basic ideas of PuLSE-DSSA are to develop a reference architecture incrementally by applying generic scenarios in decreasing order of architectural significance and to integrate evaluation into architecture creation based on the scope definition, a product family model, and recovered informa-tion out of individual system (or existing product families).


Conclusion

6.1 Future work

Whereas, the current version of this document focuses on architectural views (i.e. how they can be recovered, and how architectures can be analyzed and compared among themselves) its second version will emphasize the selection of reuse candidates and the extension of PuLSE-DSSA to fully exploit the recovered information in the design of the reference architecture.

As a result of the emphasis of the second phase, we expect many benefices: First the interaction among candidate identification, design and recovery will be strengthened as the later steps mature. Second, we will extend our view recon-struction methods to produce specific views supporting the reuse candidate identification. Already, we have identified the need for additional data structure and feature views to support this task. Third, we will extend our analysis and comparison method to support the new needs arising from selection of reuse candidates and PuLSE-DSSA.

As we gain experience through case studies, we expect to be able to quantify the effort needed in applying the various techniques and to qualify their relative benefices. We will also consider the question of return on investment for the various step of the approach.


References

References

[AB+00] Anastasopoulos, M., Bayer, J., Flege, O., and Gacek, C., “A Process for Product Line Architecture Creation and Evaluation – PuLSE-DSSA Version 2.0”. Technical Report, No. 038.00/E, Fraunhofer IESE, June 2000.

[AnBa02] Anastasopoulos, M., and Bayer, J., “Product Family Specific Quality Attributes”, Consortium Wide Deliverable IESE-WP-2-2, June, 2002.

[BCK98] Len Bass, Paul Clements, and Rick Kazman. "Software Architecture in Practice", Addison Wesley, 1998.

[BF+99] Bayer, J., Flege, O., Knauber, P., Laqua, R., Muthig, D., Schmid, K., Widen, T., and DeBaud, J.-M. PuLSE: A Methodology to Develop Software Product Lines. In Proceedings of the Fifth ACM SIGSOFT Symposium on Software Reusability (SSR'99), Los Angeles, CA, USA, May 1999, 122–131.

[BFG00] Bayer, J., Flege, O., and Gacek, C. Creating Product Line Architec-tures. In Third International Workshop on Software Architectures for Product Families, March, 2000, 210–216.

[BGS02] J. Bayer, J. F. Girard, K. Schmid. Architecture Recovery of Existing Systems for Product Families, Technical Report 2002.

[BMW99] Bayer, J., Muthig, D., and Widen, T. Customizable Domain Analysis. In Proceedings of the First International Symposium on Generative and Component-Based Software Engineering (GCSE '99), Erfurt, Germany, September 1999.

[BM+96] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M. Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996.

[DaWi97] M. J. Davis and R. B. Williams. Software Architecture Characteriza-tion. In Proceedings of the 1997 Symposium on Software Reusability (SSR’97). Boston, Massachusetts, USA, 1997.

[Doug99] Douglas, B. P. Doing Hard Time: Developing Real-Time Systems with UML, Addison-Wesley, 1999.


References

[GH+95] Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns – Elements of Reusable Object-Oriented Software, Addison Wesley,1995.

[Gira03] J.-F. Girard. SARA: A Software Architecture Recovery Approach, Ph.D. Thesis, 2003.

[HuBa85] D. H. Hutchens and B. R. Basili. System Structure Analysis: Clustering with Data Binding. IEEE Transactions on Software Engineering, pages 749–757, Aug. 85.

[HNS00] Hofmeister, C., Nord, R., and Soni, D. Applied Software Architec-ture. Addison-Wesley, 2000.

[IEEE1471] IEEE Computer Society, IEEE Recommended Practice for Architectural Descriptions of Software-Intensive Systems, IEEE Std-1471-2000.

[JaDu88] A.K. Jain and R. C. Dubes. Algorithms for Clustering Data. Prentice Hall, 1988.

[JeRu97] Dean Jerding and Spencer Rugaber. Using Visualization for Architec-tural Localization and Extraction. In Fourth Working Conference on Reverse Engineering,1997.

[KaKu98] G. Karypis and V. Kumar. METIS 4.0: Unstructured graph partition-ing and sparse matrix ordering system. Technical report, Department of Computer Science, University of Minnesota, 1998.

[Kruc95] Kruchten, P. The 4+1 View Model of Architecture. IEEE Software, November 1995 12(6): 42–50.

[MM+98] S. Mancoridis, B.S. Mitchell, C. Rorres, Y. Chen, and E.R. Gansner. Using Automatic Clustering to Produce High-Level System Organiza-tions of Source Code. In International Workshop on Program Com-prehension,1998.

[MNS95] Gail C. Murphy, David Notkin, and Kevin Sullivan. Software Reflex-ion Models: Bridging the Gap Between Source and High-Level Mod-els. In the Proceedings of the Third ACM SIGSOFT Symposium on the Foundations of Software Engineering, ACM, pages 18-28, 1995.

[MuNo97] Gail C. Murphy and David Notkin. Reengineering with Reflexion Models: A Case Study. In IEEE Computer 30,8, pages 29-36, 1997.

[MüUh90] H. A. Müller and J. S. Uhl. Composing subsystem structures using


References

(k,2)-partite graphs. In International Conference on Software Main-tenance, pages 12–19. IEEE Computer Society Press, 1990.

[PaCl93] D.L. Parnas, P. C. Clements. A Rational Design Process: How and Why to Fake It, IEEE Transactions on Software Engineering, vol. 19, no. 2, pp. 251-257, February 1993.

[RiRo02] Claudio Riva and Jordi Vidal Rodriguez. Combining Static and Dy-namic Views for Architecture Reconstruction. In Sixth European Con-ference on Software Maintenance and Reengineering, 2002.

[ScHa94] Schwanke and Hanson. Using neural networks to modularize soft-ware. Machine Learning, 15:137–168, 1994.

[WGH00] W.Eric Wong, Swapna S.Gokhale and Joseph R. Horgan. Quantifying the Closeness between Program Components and Features. Applied Research, Telecodia Technologies, 2000.

[WMF+98] Robert J. Walker, Gail C. Murphy, Bjorn Freeman-Benson, Darin Wright, Darin Swanson, and Jeremy Issak. Visualizing Dynamic Soft-ware System Information through High-level Models. In Proceedings of the Conference on Object-Oriented Programming, Systems, and Applications, ACM SIGPLAN, Pages 271-283, 1998.


Document Information

Title: Definition of Reference Architectures based on Existing Systems

Date: September 2003 Report: IESE-085.03/E Status: Final Distribution: Public

Copyright 2003, Fraunhofer IESE. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means including, without limitation, photocopying, recording, or otherwise, without the prior written permission of the publisher. Written permission is not needed if this publication is distributed for non-commercial purposes.

Definition of Reference Architectures based on Existing ...€¦ · Definition of Reference...

Documents

Transcript of Definition of Reference Architectures based on Existing ...€¦ · Definition of Reference...