WICSA 2009 WS1 -- Architecture Knowledge 1 -- Patterns and Constraints

From WICSA Conference Wiki

Jump to: navigation, search

Session Chairs: Hans van Vliet and John Klein

Tuesday, 15th September, 13:30 - 15:30

Contents

Participants (Tentative)

Please sign your name here if you are thinking of attending this working session. (Click the signature button in the editor). Tell us something about your background. Add a few sentences about the working session topic such as your position, questions you would like to see discussed, etc.
  • Rafael Capilla, Universidad Rey Juan Carlos (Madrid).
  • Eltjo Poort, Logica. Patterns are a popular way of capturing re-usable knowledge, but their main drawback is that they are basically solutions looking for a problem. Real-life architects should focus on understanding the problem rather than pushing their favourite solution - how can we improve the pattern paradigm to address this?
  • Sorana Cimpan, Université de Savoie (France).
  • Nelis Boucke DistriNet, KULeuven (Belgium) I was particularly drawn by the mentioning of "constrains" in the working session title. How can we use constraints in the context of patterns and with respect to multiple models/views/viewpoints?
  • Paulo Pires University of Rio Grande do Norte Brazil.
  • Flavia Delicato University of Rio Grande do Norte Brazil.
  • Daniel Vincen EADS Innovation Works UK (The European Aeronautic Defence and Space Company). Innovation Works is EADS' research unit.
  • Peng Liang, University of Groningen.
  • David Emery D&S Consulting (DSCI). Consulting architect on some US Army projects.
  • Jennifer Pérez, Technical University of Madrid.
  • Elena Navarro, University of Castilla-La Mancha. I'm especially interested on exploitation of traceability relationships for Architectural Knowledge.
  • Carlos E. Cuesta, Rey Juan Carlos University at Madrid, Spain.

Papers

  • "Weaving Antipatterns in a Network of Architectural Knowledge", by Elena Navarro, Carlos E. Cuesta, and Dewayne E. Perry
    Recent research in software architecture has reasserted an emphasis on keeping track of design decisions and their rationales during the development process, that is, on maintaining architectural knowledge (AK). This knowledge takes the form of explicit assets, interrelated in decision networks. We argue that the relationships structuring these networks contain valuable information, specially those describing negative semantics. For this reason, we have extended an architecture-centric, model-driven development process, ATRIUM, which already provides support for AK, with new AK relationships to define AK as a network of knowledge.
  • "On the Need of Architectural Patterns in AOSD for Software Evolution", by Monica Pinto, Lidia Fuentes, Juan A. Valenzuela, Paulo F. Pires, Flavia C. Delicato, and Eberton Marinho
    One promising approach to tackle software evolution in AOSD is model-based pointcuts, where pointcuts are defined in terms of elements of a conceptual model, which are less susceptible to evolution than elements of the base model. We propose the definition of model-based pointcuts at the architectural level and identify three layers in the definition of our conceptual model: the system, the domain-specific and the application-specific layer. An MDD process drives the definition of conceptual and aspect models, their instantiation and composition. AO-ADL is used to implement it.
  • "Exploring Ontologies to support the establishment of Reference Architecture: An example on Software Testing", by Elisa Yumi Nakagawa, Ellen Francine Barbosa, and José Carlos Maldonado
    Software architectures have played a significant role in determining the success of software systems. In particular, reference architectures have emerged, achieving well-recognized understanding in a specific domain, promoting reuse of design expertise and facilitating the development of systems. In another perspective, ontologies have been widely investigated aiming at representing, communicating and reusing knowledge. In spite of their relevance on directly dealing with domain knowledge, reference architectures and ontologies have been separately treated. In this paper we investigate the impact in using ontologies to the establishment of reference architectures. We illustrate our idea using an ontology of software testing to build a reference architecture for the testing domain. Preliminary results indicate that ontologies are an important and viable mechanism aiming at building reference architectures.
  • "Modeling Constraints Improves Software Architecture Design Reasoning", by Antony Tang and Hans van Vliet
    Requirements and project-related factors influence architectural design in intricate and multivariate ways. We are only beginning to understand some of the tacit but fundamental mechanisms involved in reasoning about design decisions, and one of them concerns the role of design constraints. This paper examines design constraints and how they shape design solutions. We introduce a design constraint model and an architectural design reasoning process for specifying design constraints and checking for design conflicts. We experiment with using logic for constraint verification with the Alloy tool.

Contributions

If you have relevant materials or references, please add here:

Working Session Details

The working session on Architecture Knowledge: patterns and constraints was attended by 22 people. After the presentation of the four short papers, a lively discussion ensued regarding the nature of constraints. We came up with the following definitions of "constraint":

  1. a requirement whose non-fulfillment has unacceptable consequences
  2. a rule that scopes the design space
  3. an attribute on one or more named component or connector
  4. a requirement whose fulfillment can be checked automatically
  5. a requirement not on the system, but on the organisation/process delivering that system
  6. a relationship between two requirements or decisions - one decision constrains another one

The following uses of constraints were mentioned:

  1. to (automatically) check the feasability of a design
  2. to prune the design space [Is this not a rephrased version of rule 2 above?]
  3. to identify and increase awareness of the consequences of decisions
Retrieved from "http://wwwp.dnsalias.org/wiki/WICSA_2009_WS1_--_Architecture_Knowledge_1_--_Patterns_and_Constraints"
Personal tools