Article

Classifying Architectural Elements as a Foundation for Mechanism Matching

08/1996;
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...

0 Bookmarks
 · 
47 Views
  • 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.
    01/1996;
  • 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.
  • 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).
    ARPN Journal of Systems and Software. 04/2011; 1(1):28-33.

Full-text (2 Sources)

Download
23 Downloads
Available from
May 28, 2014