SUMMARY This paper presents an approach to construct execution views, which are views that describe what the software of a software‐intensive system does at runtime and how it does it. The approach represents an architecture reconstruction solution based on a metamodel, a set of viewpoints, and a dynamic analysis technique. The metamodel and viewpoints capture the conventions that can be used to describe the runtime of a system developed by a particular organization. The dynamic analysis technique is used to extract and abstract runtime information from a combination of system logging and runtime measurements in a top‐down fashion. The approach was developed and validated constructing execution views for a magnetic resonance imaging scanner developed by Philips Healthcare. Therefore, the approach represents a solution that can be applied at similar large and complex software‐intensive systems. Copyright © 2011 John Wiley & Sons, Ltd.

We compare five industrial software architecture design methods and we extract from their commonalities a general software architecture design approach. Using this general approach, we compare across the five methods the artifacts and activities they use or recommend, and we pinpoint similarities and differences. Once we get beyond the great variance in terminology and description, we find that the 5 approaches have a lot in common and match more or less the "ideal" pattern we introduced.

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

We present a quantitative method for scenario-driven value, risk, and cost analysis when proposing new system architectures for innovation projects. The method helps to articulate the relative benefits and/or disadvantages of the proposed set of scenarios in the early architecting phases of a new system. It provides the arguments on which to base an informed decision to select the final architectural scenarios for further consideration in the design. In this paper we present a case study in which we applied the proposed method.

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

The system architecture of successful systems typically enjoys a long life (ten years or more). From an architecting point of view, there are two major challenges. The first challenge is to establish the "right" initial architecture that satisfies the strategic intentions, the needs and the requirements of its stakeholders and intended users. The second challenge is to nurture the architecture and keep it architecture up to date (fit and slim) with respect to the changing requirements and technologies that will occur during its lifetime. Keeping the architecture so called "evergreen" (i.e. ongoing satisfying its stakeholders needs and requirements is a very challenging architecting). The second problem is addressed in a separate paper (America et al., 2003) where we describe a method to assess and improve the ease of accommodating new requirements by system architecture once it has been established. The first problem of how to establish the initial architecture satisfying the strategic plans and intentions of its stakeholders is addressed in this presentation.

Document-based management of requirements can be effective for single-site, narrowly-scoped projects. However, we firmly believe that it is essential to move to a database-centred way of managing requirements if platform-based product development and enterprise-wide requirements management is to be fully supported. This paper introduces an approach to the specification of system families that is database-centred. It outlines the experience of producing a database of requirements for a TV product. The schema was built using RTM (Requirements Management Tool) supplied by Integrated Chipware. It constitutes a practical example of the advantages that can be gained by changing from the conventional document-based requirements management process. It also shows the difficulties that need to be dealt with when mapping from a document-based to a database-centred product specification.

Abstract We develop a Hoare-style proof system for reasoning about the behaviour of processes that interact via a dynamically evolving communication structure.

Abstract We develop a denotational semantics for POOL, a parallel object-oriented programming language. The main contribution of this semantics is an accurate mathematical model of the most important concept in object-oriented programming: the object. This is achieved by structuring the semantics in layers working at three different levels: for statements, objects and programs. For each of these levels we define a specialized mathematical domain of processes, which we use to assign a meaning to each language construct. This is done in the mathematical framework of complete metric spaces. We also define operators that translate between these domains. At the program level we give a precise definition of the observable input/output behaviour of a particular program, which could be used at a later stage to decide the issue of full abstractness. We illustrate our semantic techniques by first applying them to a toy language similar to CSP.

Article Free Access Share on Formal techniques for OO software development Authors: Pierre America Philips Research Laboratories Philips Research LaboratoriesView Profile , Derek Coleman HP-Lab Bristol HP-Lab BristolView Profile , Roger Duke University of Queensland University of QueenslandView Profile , Doug Lea Syracuse University & SUNY-Oswego Syracuse University & SUNY-OswegoView Profile , Gary Leavens Iowa State University Iowa State UniversityView Profile Authors Info & Claims OOPSLA '91: Conference proceedings on Object-oriented programming systems, languages, and applicationsNovember 1991 Pages 166–170https://doi.org/10.1145/117954.117967Published:01 November 1991Publication History 2citation376DownloadsMetricsTotal Citations2Total Downloads376Last 12 Months13Last 6 weeks1 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

Abstract This paper discusses the considerations that have played a role in the design of the language POOL2. This language integrates the structuring techniques of object-oriented programming with mechanisms for expressing parallelism. We introduce the basic principles of object-oriented programming and its significance for program development methodologies. Several approaches for integrating objects and parallelism are compared and arguments for the choices made in POOL2 are presented. We also explain why inheritance is not yet included in POOL2. A brief overview of the research in formal aspects of POOL is given. Finally we indicate some directions for future developments.

The Centre for Mathematics and Computer