Classifying Architectural Elements as a Foundation for Mechanism Matching

Source: CiteSeer


: Building a system at the architectural level can be thought of as decomposition into components followed by a series of exercises in matching. Components must be composed with each other via matching mechanisms; matching signatures within those mechanisms ensure that data and control will flow through the system; and matching semantics among the components ensures that the system will meet its behavioral requirements. Although efforts in signature and semantic matching enjoy formal bases from which to proceed, mechanism matching starts from no such foundation. The standard concepts of software architecture (components, connectors, styles) have been widely used with little more than intuitive understanding of their meaning. Mechanism matching is currently an ad hoc exercise that relies on the peculiarities of programming language facilities. This paper presents a set of well known but informally described software architectural elements used in system composition, and taxon...

Download full-text


Available from: Len Bass, Oct 31, 2012
  • Source
    • "These tables list the possible features of architectural elements (both components and connectors), and are divided into information that can be derived from a temporal perspective and information that can be derived from a static perspective of an architectural element. These features are described in greater detail in [8]. Table 1 summarizes the features derived from the static view, and the possible values for each. "
    [Show abstract] [Hide abstract]
    ABSTRACT: Software architecture, as a vehicle for communication and reasoning about software systems and their quality, is becoming an area of focus in both the forward- and reverse-engineering communities. In the past, we have attempted to unify these areas via a semantic model of reengineering called CORUM II. In this paper we present a concrete example of an architecturally-motivated reengineering task. In executing this task, we perform architecture reconstruction, reason about the reconstructed architecture, motivate an architectural transformation with new architectural quality requirements, and realize this architectural transformation via an automated code transformation
    Reverse Engineering, 1999. Proceedings. Sixth Working Conference on; 01/1999
  • Source
    • "In our proposal for CORUM II, we will use the taxonomy of architectural elements introduced in [14] and show how this provides a set of features that can be reasoned about in architecture-based design, analysis, and reengineering. "
    [Show abstract] [Hide abstract]
    ABSTRACT: This paper discusses the requirements and a generic framework for the integration of architectural and code- based reengineering tools. This framework is needed because there is a large number of stand-alone reengineering tools that operate at different levels of abstraction ranging from "code-level" to software architecture. For the purposes of reengineering a complete system however, these tools need to be able to share information so that not only can the code be updated or corrected, but also so the system's soft- ware architecture can be simultaneously rationalized or mod- ernized. To this end, we have built upon the CORUM model of reengineering tool interoperation to include software architecture concepts and tools. This extended framework— called CORUM II—is organized around the metaphor of a "horseshoe", where the left-hand side of the horseshoe con- sists of fact extraction from an existing system, the right hand side consists of development activities, and the bridge between the sides consists of a set of transformations from the old to the new.
    Reverse Engineering, 1998. Proceedings. Fifth Working Conference on; 01/1998
  • Source
    • "Since it was not part of their focus, they did not address compositional issues. On another recent work [8], Kazman and his colleagues try to support system composition in a manner very similar to the one proposed here. They use behavioral characteristics which they call features to classify architectural elements (components and connectors), not architectural styles nor systems. "
    [Show abstract] [Hide abstract]
    ABSTRACT: Megaprogramming [3], the practice of software construction in a component-oriented fashion heavily based on software components' reuse, has long been recognized as an important solution for the software crisis [11]. It is a powerful means of not only reducing software development costs in the long run, but also reducing the risk of project failure, improving software quality, shortening development time, and greatly increasing the productivity of the individual software developer. The existence of architectural mismatches among various parts may seriously hinder a megaprogramming effort [7]. We use architectural styles and their intrinsic characteristics to motivate an architectural feature set that is relevant to reuse. Subsequently, we discuss how these underlying architectural features can be used for potential mismatch detection, which in turn is a powerful tool towards early risk assessment.
Show more