Definition of Reference Architectures based on Existing ... Definition of Reference Architectures...

download Definition of Reference Architectures based on Existing ... Definition of Reference Architectures based

If you can't read please download the document

  • date post

    26-Jun-2020
  • Category

    Documents

  • view

    0
  • download

    0

Embed Size (px)

Transcript of Definition of Reference Architectures based on Existing ... Definition of Reference Architectures...

  • 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

    Elicit Business and Quality Goals

    A2

    Determine Architectural

    Views

    A5

    Select Best Reuse

    Candidates

    A6

    Develop new

    ArchitectureArchitecture

    Reverse engineering

    A0

    Determine Scope

    Scope of Deliverable Version 1.0 Scope of Deliverable Version 2.0

    A3

    Recover required

    architectural description

    A4

    Analyze and compare

    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.

    Copyright © Fraunhofer IESE 2003 2

  • 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.

    Copyright © Fraunhofer IESE 2003 3

  • 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