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: 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.
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: Las arquitecturas de software posibilitan la toma de decisiones de diseño en etapas tempranas del proceso de desarrollo de software de manera de satisfacer tanto los requerimientos funcionales de un sistema como sus requerimientos de calidad. Como modelos conceptuales las arquitecturas de software admiten múltiples materializaciones orientadas a objetos que sirven como base para lograr la construcción del producto final de software. En particular, las distintas materializaciones manifiestan en mayor o en menor medida los requerimientos de calidad prescriptos pudiendo producirse potenciales incompatibilidades entre la arquitectura tal como fue diseñada y la arquitectura tal como fue implementada. Esto hace que el proceso de derivación de las contrapartes orientadas a objetos de las arquitecturas de software sea una tarea compleja requiriendo para su fin desarrolladores con amplios conocimientos y experiencia de diseño. En ese sentido, pensamos que la organización de un cuerpo de conocimiento de diseño reusable junto con la definición de procedimientos de razonamiento sistemáticos que posibiliten el desarrollo de herramientas semi-automáticas para asistir a los desarrolladores en el proceso de desarrollo de software es un aporte significativo hacia una solución al problema de la materialización de arquitecturas. Proponemos en este trabajo un nuevo enfoque basado en una metáfora de reutilización de experiencias de diseño en la cual decisiones de diseño exitosas tomadas para derivar materializaciones previas son reutilizadas para materializar nuevos modelos arquitectónicos. El enfoque propuesto representa un paso hacia un proceso de materialización sistemático integrando, a través de la codificación de experiencias de diseño, modelos de diseño arquitectónico y sus contrapartes orientadas a objetos.
  • [Show abstract] [Hide abstract]
    ABSTRACT: Component-based software engineering (CBSE) and software architecture (SA) are separate but related topics in software engineering research and practice. CBSE focuses on the realization of systems through integration of pre-existing components. This is a paradigm motivated by the decreasing lifetime of applications and the need for more rapid product development. SA is concerned with the high-level organization and structure of systems in general. The current high interest in the field is mainly motivated by the increasing complexity of modern software. One of the important issues studied in SA is that of recurring architectural patterns and idioms - or architectural style. CBSE and SA are clearly related, and the importance of architectural issues in CBSE is now widely recognized. However, since their motivations differ (and therefore their criteria for what should and should not be viewed as a component), the relationship between the two topics may not be straightforward

Full-text (2 Sources)

Available from
May 28, 2014