Classifying Architectural Elements as a Foundation for Mechanism Matching

Source: CiteSeer

ABSTRACT : 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...

  • Source
    [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.
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: As a communication vehicle among stakeholders, software architecture gives the entire view of the system’s major components, the behaviour of those components as visible to the rest of the system, and the ways in which these components interact and coordinate to achieve the system’s goal. The architecture determines the non-functional attributes of software systems that are built into quality models. In this paper we consider the performance attribute of a system. Most performance quality models have been developed and proved quantitatively. This paper approaches performance issues qualitatively using a proposed developed performance quality model called Software Architecture Scenario-Based Performance Quality Model (SASPUM). The validity of the model characterized into three categories: stimuli, architectural decisions, and responses, can be tested on any existing software architecture using the performance Assessment of Software Architecture (PASA) and the Architecture Trade-off Analysis Method (ATAM).
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: The needs of software architectural design and analysis have led to a desire to create CASE tools to support the processes. Such a tool should help: to document an architecture; to reuse architectural artifacts; to aid in exploring architectural alternatives; and to support architectural metrics. This position paper first presents a set of requirements that an ideal tool for architectural design and analysis, and then presents a tool—called SAAMtool—that meets most, but not all, of these requirements. SAAMtool embodies both SAAM (Software Architecture Analysis Method) and an architectural description framework which describes architectural elements according to their static and temporal features. The tool serves several purposes. It supports and documents the results of architectural design and analysis efforts at varying degrees of resolution, it acts as a repository of both designs and design rationales in the form of scenarios, it applies metrics to architectures, and it visualizes architectures with respect to architectural metrics.

Full-text (2 Sources)

Available from
May 28, 2014