Conference PaperPDF Available

Building up and Exploiting Architectural Knowledge

Authors:
Philippe Kruchten at University of British Columbia
Philippe Kruchten
Patricia Lago at Vrije Universiteit Amsterdam, Amsterdam, Netherlands
Patricia Lago
  • Vrije Universiteit Amsterdam, Amsterdam, Netherlands
Hans Van Vliet at Vrije Universiteit Amsterdam
Hans Van Vliet
Timo Wolf at Siemens
Timo Wolf
Download full-text PDF
Read full-text
Download citation

Abstract

Architectural knowledge consists of architecture design as well as the design decisions, assumptions, context, and other factors that together determine why a particular solution is the way it is. Except for the architecture design part, most of the architectural knowledge usually remains hidden, tacit in the heads of the architects. We conjecture that an explicit representation of architectural knowledge is helpful for building and evolving systems. If we had a repository of architectural knowledge for a system, what would it ideally contain, how would we build it, and exploit it in practice? In this paper we describe a use case model for an architectural knowledge system.
Content uploaded by Patricia Lago
Author content
All content in this area was uploaded by Patricia Lago
Content may be subject to copyright.
Building up and Exploiting Architectural Knowledge
Philippe Kruchten
University of British Columbia
Vancouver, B.C., Canada
pbk@ece.ubc.ca
Patricia Lago Hans van Vliet
Vrije Universiteit
Amsterdam, NL
{patricia, hans}@cs.vu.nl
Timo Wolf
Technische Universität
München, Germany
wolft@in.tum.de
Abstract
Architectural knowledge consists of architecture
design as well as the design decisions, assumptions,
context, and other factors that together determine why
a particular solution is the way it is. Except for the
architecture design part, most of the architectural
knowledge usually remains hidden, tacit in the heads of
the architects. We conjecture that an explicit represen-
tation of architectural knowledge is helpful for building
and evolving systems. If we had a repository of archi-
tectural knowledge for a system, what would it ideally
contain, how would we build it, and exploit it in prac-
tice? In this paper we describe a use case model for an
architectural knowledge system.
1. Introduction
Architectural design, even well documented ac-
cording to all the good recipes is only one small part
of the Architectural Knowledge that is required to de-
sign a system, or that can be exploited out of a system
to build the next one, or that is required to successfully
evolve a system. Bosch and others have pointed that
design decisions, the tight set of interdependencies
between them, and their mapping to both the require-
ments, needs, constraints upstream, or the design and
implementation downstream are also a key component
of architectural knowledge [1,6,7,10].
The reasoning behind a design decision, and other
forces that drive those decisions (such as, company
policies, standards that have to be used, earlier experi-
ences of the architect, etc.), usually are not explicitly
captured. They are tacit knowledge, essential for the
solution chosen, but not documented. At a later stage, it
then becomes difficult to trace the reasons of certain
design decisions. In particular, during the evolution one
may stumble upon these design decisions, try to undo
them or work around them, and get into trouble when
this turns out to be very costly if not impossible. The
future evolutionary capabilities of a system can be bet-
ter assessed if this type of knowledge would be ex-
plicit.
Capturing design rationale has been a key research
topic for many years, leading to interesting models,
tools and methods [2, 3], but it has failed to transfer to
practice [8]. Why? This is mostly because the burden
to capture assumptions and decisions outweighs largely
the immediate benefits that the architect may draw.
These benefits would be felt much later, or by others. If
we are not careful to address the key problem: how to
move this knowledge out of the tacit level into at least
the documented level and then the formalized level, all
what we may do with architectural knowledge could
follow the same route as design rationale has done over
the years: nice ideas, but not practical. One way is to
automate the collection of rationale (or of decisions, or
both). Assuming for a while that we have solved the
problem, and that we have defined a repository of ar-
chitectural knowledge in the form of all design deci-
sions, how would we use it? Who would use it, to do
what?
2. Use Cases for Architectural Knowledge
Here is an initial set of use cases:
Incremental architectural review: what pieces of
Architectural Knowledge have been added or modi-
fied since the last review? Extract and visualize
these elements; browse and explore dependencies or
traces.
Review for a specific concern: from a given perspec-
tive (such as security, safety, reuse, etc.) what are
the knowledge elements involved? This consists in
building in some sense a “view” of Architectural
Knowledge restricted to that concern.
Evaluate impact: if we want to do a change in an
element, what are the elements impacted (decisions,
and elements of design). This may branch out to
various kinds of changes: change of an assumption,
change of a design decision.
Get a rationale: given an element in the design,
trace back to the decisions it is related to.
Study the chronology: over a time line, find what the
sequence of design decisions has been.
Add a decision: manually or via some tool; then in-
tegrate the decision to other elements of AK. (Simi-
larly for other AK elements).
Cleanup the system: make sure that all consequences
of a removed decision have been removed.
Spot the subversive stakeholder: identify who are the
stakeholders whose changes of mind are doing the
most damage to the system.
Similar but different, Spot the critical stakeholder:
the stakeholder who seems to have the most
“weight” on the decisions, and who therefore maybe
the one that could be most affected by the future
evolution of the system.
Clone AK: produce a consistent subset of AK to
prime the pump for a new system (reuse AK)
Integration: you want to integrate multiple systems
and decide whether they fit. The tool would help an-
swering questions about integration strategies.
Detection and interpretation of patterns: are there
patterns in the graphs that can be interpreted in a
useful fashion, and lead to guidelines for the archi-
tects. For example: decisions being hubs (“God” de-
cisions), circularity, decisions that gain weight over
time and are more difficult to change or remove.
Assuming we have captured architectural knowl-
edge as discussed above in some graph-like form,
where the vertices represent design decisions, and the
edges represent relationships between decisions, the
different use cases correspond to certain operations on
this graph. Some of these operations are relatively
straightforward. They correspond to a subset operation
(Clone AK, Review for a specific concern) or closure
operation (Evaluate impact, Cleanup the system).
A more interesting operation has to do with the de-
tection or matching of patterns or, rather, antipatterns.
Some of these can be cast as graph operations. E.g.,
detection of a “God” decision boils down to selecting
nodes with a high fan-in/fan-out. The identification and
operationalization of time-related patterns still is an
open issue.
One of the most interesting unsolved issues is how
to visualize architectural knowledge. The amount of
information is overwhelming, so we have to abstract
away from a lot of details. Developments in the area of
information visualization are relevant here [4]. Most of
these visualizations abstract away from details in the
graph representation, and present the result in terms of
tree maps, radial or conical representations, and the
like. In our opinion, though, this is not enough. The
visualizations have to direct our attention to the very
issue we want to convey [9], such as the subversive or
critical stakeholder.
Finally, if we can link our ontology of design deci-
sions to some thesaurus that describes the contents of
actual design documents, we may exploit thesaurus-
based browsers [5] to explore these resources. This is a
kind of data mining operation on documents containing
architectural knowledge, with a targeted visualization.
3. Conclusions
In this paper we discuss the notion of architectural
knowledge. If we had a repository of architectural
knowledge for a system, what would it ideally contain,
how would we build it, and exploit it in practice? We
describe a use case model for an architectural knowl-
edge system, together with an indication of the type of
operations needed to realize the uses cases
Acknowledgements
This research has partially been sponsored by the Dutch
Joint Academic and Commercial Quality Research & Devel-
opment (Jacquard) program on Software Engineering Re-
search via contract 638.001.406 GRIFFIN: a GRId For in-
FormatIoN about architectural knowledge; and by an Eclipse
Innovation grant from IBM.
References
[1] J. Bosch, "Software Architecture: the Next Step,"
in Proceedings of First European Workshop on
Software Architecture (EWSA 2004), St Andrews,
Scotland, 2004, Springer-Verlag, pp. 194-199.
[2] J.E. Burge and D.C. Brown, "Reasoning with de-
sign rationale," in J. S. Gero, ed., Artificial Intelli-
gence in Design '00, Netherlands: Kluwer, 2000, pp.
611-629.
[3] J. Conklin and M.L. Begeman, "gIBIS: A tool for
all reasons," Journal of the American Society for In-
formation Science, vol. 40, 1989.
[4] J.-D. Fekete, "The InfoVis Toolkit," in Proceed-
ings of IEEE Symposium on Information Visualiza-
tion 2004 (INFOVIS'04), 2004, pp. 167-174.
[5] C. Fluit, M. Sabou, and F. van Harmelen, "Ontol-
ogy-based information visualisation," in V. Gero-
imenko and C. Chen, ed., Visualising the Semantic
Web, Springer-Verlag, 2005.
[6] P. Kruchten, "An Ontology of Architectural De-
sign Decisions," in Proceedings of 2nd Groningen
Workshop on Software Variability Management,
Groningen, NL, 2004, Rijksuniversiteit Groningen.
[7] P. Lago and H. van Vliet, "Explicit Assumptions
Enrich Architectural Models," in Proceedings of
ICSE 2005, St. Louis, MO, USA, 2005, ACM, pp.
206-214.
[8] J. Lee, "Design Rationale Systems: Understanding
the Issues," IEEE Expert, 12 (3), 1997, pp.78-85.
[9] E.R. Tufte, Visual explanations: images and quan-
tities, evidence and narrative, Cheshire, CO: Graph-
ics Press LLC, 1997.
[10] J. Tyree and A. Ackerman, "Architecture Deci-
sions: Demystifying Architecture," IEEE Software,
vol. 22, no. 2, 2005, pp. 19-27.
... The organization and management of architectural knowledge (AK) have become an important aspect of software architecture at management and technical levels alike [1]. In particular, the timely discovery, sharing and integration of AK [2] is critical for enabling software architects and developers to make conceptual and technical design decisions and tradeoffs [3]. ...
... In the following paragraphs we describe the individual stages in more detail. 1 http://qse.ifs.tuwien.ac.at/proj/caki/ (last visited 2017-02-28) ...
Continuous Architectural Knowledge Integration: Making Heterogeneous Architectural Knowledge Available in Large-Scale Organizations
Conference Paper
Full-text available
  • Apr 2017
The timely discovery, sharing and integration of architectural knowledge (AK) have become critical aspects in enabling the software architects to make meaningful conceptual and technical design decisions and trade-offs. In large-scale organizations particular obstacles in making AK available to architects are a heterogeneous pool of internal and external knowledge sources, poor interoperability between AK management tools and limited support of computational AK reasoning. Therefore we introduce the Continuous Architectural Knowledge Integration (CAKI) approach that combines the continuous integration of internal and external AK sources together with enhanced semantic reasoning and personalization capabilities dedicated to large organizations. Preliminary evaluation results show that CAKI potentially reduces AK search effort by concurrently yielding more diverse and relevant results. Index Terms—Architectural knowledge management, continuous software architecture, semantic integration.
View
... Since the 1990s, a great number of studies on architectural learning stemming from the field of design studies have been accompanied by research aiming at identifying systematic design methods in order to establish teaching models (for a review, see Demirbas¸ and Demirkan 2003). While only some of the existing studies identify architectural knowledge directly as tacit knowledge (Kruchten et al. 2005;Uluoglu 2000), a great number identify the tacit dimension of the knowledge mobilised in architectural design, although they do not refer to it in this term, preferring notions such as intention, intuition, implicit reasoning or empiric method. To the knowledge of the authors, none of these studies assessed the development of tacit knowledge in an architectural teaching environment, despite the fact that diverse models are employed in existing studies to assess various aspects of the mobilised knowledge and methods in architectural training. ...
Prototaxites stellaviatori: a Fungal Growth Simulation Model for Mycelium-Based Composites Education in Applied Arts
Conference Paper
Full-text available
  • Jul 2022
The increasing experimental investigations of Mycelium-Based Composites (MBC) in design and architecture necessitate efforts from pedagogues to find ways to transmit knowledge and support regarding the guiding principles of mycology so as to empower students in their investigations and study. The adoption of MBC craft in arts and applied arts offers much potential in extending the space of material semiotics as it is often accompanied by several theoretical and systemic interests, such as the urge to adopt alternative ontologies of nature or implementing thoroughly sustainability in the economy. To support these critical reflections and exploring novel formal expressions we have developed a stochastic simulation model of fungal colonisation for design education and research in MBC. In this paper we present the conceptual and technical framework guiding the model's development with specific focus on its role as a pedagogical instrument. We report on its pedagogical impact based on a students survey and their productions.
View
... The specification task defines various information needs that the designer has to take into account. Designers need to understand the architectural compliance with requirements, the system context and associated forces and implications of design decisions (Kruchten et al. 2005). Its desired outcome is a docu- mentation of design elements and their connections, along with an explication of architectural knowledge including design intentions and their underlying rationale (e.g., with reference to patterns) (Capilla et al. 2016). ...
Cognitive Diagram Understanding and Task Performance in Systems Analysis and Design
Article
  • Dec 2021
Models play an important role in systems analysis and design (SAD). A diagrammatic model is defined as a mapping from a domain to a visual representation in such a way that relevant information is preserved to meet a specific goal. So far, cognitive research on diagram criteria in relation to task performance has been fragmented. The aim of this paper is to (1) consolidate research on the cognitive processing steps involved during understanding and task performance with diagrams, (2) consolidate corresponding criteria for such diagrams to best support cognitive processing, and (3) demonstrate the support effective diagrams provide for performing SAD tasks. Addressing the first aim, we develop a theoretical cognitive framework of task performance with diagrams called CogniDia. It integrates different cognitive theories from research on diagrams in software engineering and information systems. Regarding the second aim, we review the literature to organize criteria for effective cognitive processing of diagrams. We identify research gaps on verbal and task processing. Regarding the third aim, we use the theoretical cognitive framework to investigate how diagrams support the SAD process effectively.
View
... Con el surgimiento del concepto de decisión arquitectónica, aparecieron las primeras ideas en el empleo de ontologías aplicadas al diseño de arquitecturas de software. (Kruchten et al., 2005) propusieron una ontología para describir decisiones arquitectónicas y relaciones entre ellas, incluyendo aspectos de razonamiento. Para explotar el conocimiento de la ontología propusieron además una herramienta para preservar los grafos de decisiones de diseño y todas sus interdependencias con el fin de brindar soporte a la evolución y mantenimiento de los sistemas. ...
Uso de ontologías y tecnologías de la web semántica para la integración, recuperación e intercambio de conocimiento de arquitecturas de software
Article
Full-text available
  • Oct 2020
A medida que los sistemas de software evolucionan, sus arquitecturas de software se vuelven más complejas, y crece la cantidad de datos generados durante los procesos de desarrollo, los cuales contienen alguna forma de conocimiento arquitectónico. Si bien muchas organizaciones han adoptado algunas estrategias y herramientas para brindar soporte a los productores de estos datos, existen aún dificultades para la extracción y/o formalización del conocimiento intrínsicamente embebido en esta información, así como su uso y distribución en proyectos de software posteriores. La importancia del estudio, captura y representación del conocimiento sobre arquitecturas de software (CAS) y su gestión ha dado lugar a numerosos trabajos de investigación, algunos de ellos haciendo uso de ontologías aplicadas como herramienta de soporte al conocimiento. Con el surgimiento del concepto de decisión arquitectónica, aparecieron las primeras ideas en el empleo de ontologías aplicadas al diseño de arquitecturas de software, por ejemplo, para describir decisiones arquitectónicas y relaciones entre ellas, para registrar decisiones arquitectónicas, artefactos de software, hojas de ruta e intereses arquitectónicos. El objetivo general de la investigación abordada es la definición de metodologías, herramientas y mecanismos para explotar el conocimiento de arquitecturas de software que se encuentra codificado en fuentes diversas y heterogéneas, haciendo uso de ontologías, tecnologías de la web semántica y algoritmos de aprendizaje automático; para facilitar el acceso, integración, recuperación, y aplicación en nuevos proyectos de diseño, así como también para inferir nuevo conocimiento a partir del existente.
View
... [14] also suggests that the soft-skills and external influences are important in the socialization of decisions. Kruchten et al. argued that since the effort in capturing decisions outweighs the immediate benefits, we should automate the collection of decisions and their rationale [15]. ...
The Evolution of Architectural Decision Making as a Key Focus Area of Software Architecture Research: A Semi-Systematic Literature Study
Conference Paper
  • Mar 2020
Literature review studies are essential and form the foundation for any type of research. They serve as the point of departure for those seeking to understand a research topic, as well as, helps research communities to reflect on the ideas, fundamentals, and approaches that have emerged, been acknowledged, and formed the state-of-the-art. In this paper, we present a semi-systematic literature review of 218 papers published over the last four decades that have contributed to a better understanding of architectural design decisions (ADDs). These publications cover various related topics including tool support for managing ADDs, human aspects in architectural decision making (ADM), and group decision making. The results of this paper should be treated as a getting-started guide for researchers who are entering the investigation phase of research on ADM. In this paper, the readers will find a brief description of the contributions made by the established research community over the years. Based on those insights, we recommend our readers to explore the publications and the topics in depth.
View
... Even though the semi-systematic literature review was performed during the later phase of the dissertation to provide a holistic view of ADM, the comparative tool study conducted by Tang et al. [75], an extensive literature review by Capilla et al. [1], the use cases from Liang and Avgeriou [76], and the experiences from Kruchten et al. [77] provided us the comprehensive list of requirements that should be supported by tools for AKM and ADM. These requirements were validated and prioritized by the architects in the earlier mentioned ADM department and are summarized in this chapter. ...
Tool support for architectural decision making in large software intensive projects
Thesis
Full-text available
  • May 2020
https://mediatum.ub.tum.de/?id=1521926 ---------------------------------------------------------------------- Over the last decade, there has been a paradigm shift in the way researchers and practitioners view software architectures. Today, a software architecture is not only seen as a blueprint but instead is considered as a set of design decisions that leads to the blueprint of the underlying software system. Architects and developers regularly make design decisions, for instance, concerning the selection of an architectural style, design pattern, and also the underlying IT infrastructure. Documenting such decisions especially in large projects is beneficial to answer questions such as “What design decisions have already been made?”, “Which architectural elements and quality attributes are affected by a decision?”, “Who should be involved in making a new decision?”, “Which similar decisions have been made in the past?”, and “What are the alternatives to consider while making a design decision?”. Even though many of the architectural knowledge management (AKM) tools provide means to capture design decisions, we observe that, in practice, those decisions are rarely documented. The reasons for not explicitly capturing design decisions are manifold. These include, but not limited to, the lack of integration of AKM tools in software engineering practice. Second, these AKM tools are considered intrusive since they require architects to manually document decisions which can be tedious and expensive. Contrary to the traditional AKM tools that follow a top-down approach, we propose a bottom-up approach for AK curation and reuse thereof. In the bottom-up approach, design decisions are automatically retrieved from various systems as well as annotated with publicly available knowledge sources. Specifically for understanding design decisions made in the past and for supporting architects in making future decisions, we present the realization of a framework called Amelie - Decision eXplorer (ADeX). The components within the framework first retrieve project-related information from disparate systems and then, automatically identify design decisions within project’s data using machine-learning techniques. Next, by using natural language processing, ADeX annotates architectural elements and quality attributes affected by the extracted decisions. Using the annotations from the previous step, ADeX quantifies the architectural expertise of individuals to recommend experts for addressing new design concerns. And finally, using an ontology-based approach, ADeX suggests alternatives that can be considered during architectural decision-making (ADM). Based on the results of these steps, various viewpoints are generated to support architects answer the aforementioned questions during the ADM process. The qualitative evaluation of ADeX shows that it reduces the effort required for maintaining AK and provides stakeholders with a retrospective view of design decisions in large software projects. Furthermore, the components within the framework have been quantitatively evaluated using datasets both from open-source and industrial projects. Based on those datasets, we found that decisions can be automatically extracted from issues with an accuracy of 91%, architectural elements can be annotated with an accuracy of 84%, and with an accuracy of 79% experts can be recommended to address new design concerns. Finally, ADeX, which has been realized over the last four years is currently being used by our industry partner to highlight its benefits to the business units under an initiative called AI4AM. Such a setup provides us the necessary platform to further investigate related challenges of ADM including the aspects of biases and uncertainties in decision making.
View
... Other authors [1], [10], [13], [18] proposed ontologies to support the design of software architectures and the representation of architectural decisions along with rationale. However, these ontologies are not related to other supporting tools for architects, which constitute the sources of knowledge to feed such ontologies. ...
An Ontology-based Approach for Sharing, Integrating, and Retrieving Architectural Knowledge
Article
  • Jul 2018
  • Electron Notes Theor Comput Sci
The Architectural knowledge (AK) generated during software architecture projects is a valuable asset for software organizations. Although many organizations have adopted supporting tools to capture the produced AK, still there exist some difficulties in making it available to be retrieved by the consumers. Moreover, the boundaries of knowledge of an organization can be expanded to AK repositories that are shared or made public by other organizations. Thus, organizations have to deal with heterogeneity in knowledge representation, which makes complex the integration of knowledge from several sources. There is a need of an approach for sharing, integrating, and retrieving AK from various sources, which enables organizations to revisit and retrieve both their own and others' past decisions, as a basis for upcoming decisions. This paper describes an ontology-based approach for sharing, integrating, and retrieving knowledge from different AK sources, which is based on ISO/IEC/IEEE 42010. A proof of concept was developed to apply the approach on an AK management tool, and a scenario of knowledge retrieving was carried out.
View
... Other authors [17], [18], [19], [20] proposed ontologies to support the design of SA and decisions representation along with rationale, but they not related to tools for accompanying architects in the course of the design process, which provides the sources of knowledge to feed the ontology. Other ontologies have been proposed to provide semantic to file-based software architecture documents, and improve the retrieval of knowledge [11], [12]. ...
An Ontology-based Approach for Sharing, Integrating, and Retrieving Architectural Knowledge
Conference Paper
  • Sep 2017
The Architectural knowledge (AK) generated during software architecture projects is a valuable asset for software organizations. Although many organizations have adopted supporting tools to capture the produced AK, still there exist some difficulties in making it available to be retrieved by the consumers. Moreover, the boundaries of knowledge of an organization can be expanded to AK repositories that are shared or made public by other organizations. Thus, organizations have to deal with heterogeneity in knowledge representation, which makes complex the integration of knowledge from several sources. There is a need of an approach for sharing, integrating, and retrieving AK from various sources, which enables organizations to revisit and retrieve both their own and others’ past decisions, as a basis for upcoming decisions. This paper describes an ontology-based approach for sharing, integrating, and retrieving knowledge from different AK sources, which is based on ISO/IEC/IEEE 42010. A proof of concept was developed to apply the approach on an AK management tool, and a scenario of knowledge retrieving was carried out.
View
Supporting Architectural Decision-Making with Data Retrieved from Online Communities
Chapter
  • May 2021
The focal question of this paper is how to support architecture decision-making by utilising data stored in internet services such as Git Hub, Stack Overflow or Wiki Data. Our proposition is to query such internet services in order to identify alternative architectural solutions to a given architectural problem, and to estimate their properties. This would provide assistance to the decision-making architect. The above idea resulted in the implementation of an Architecture Decision Support System (ADSS) prototype. This enabled the validation of the proposed approach in terms of technical feasibility, as well as its usefulness, for software engineers during practical experimental use.
View
Architectural Decision-making as a Financial Investment: An Industrial Case Study
Article
  • Jan 2021
  • INFORM SOFTWARE TECH
Context Making architectural decisions is a crucial task but also very difficult, considering the scope of the decisions and their impact on quality attributes. To make matters worse, architectural decisions need to combine both technical and business factors, which are very dissimilar by nature. Objectives We provide a cost-benefit approach and supporting tooling that treats architectural decisions as financial investments by: (a) combining both technical and business factors; and (b) transforming the involved factors into currency, allowing their uniform aggregation. Apart from illustrating the method, we validate both the proposed approach and the tool, in terms of fitness for purpose, usability, and potential limitations. Method To validate the approach, we have performed a case study in a software development company, in the domain of low-energy embedded systems. We employed triangulation in the data collection phase of the case study, by performing interviews, focus groups, an observational session, and questionnaires. Results The results of the study suggested that the proposed approach: (a) provides a structured process for systematizing decision-making; (b) enables the involvement of multiple stakeholders, distributing the decision-making responsibility to more knowledgeable people; (c) uses monetized representations that are important for assessing decisions in a unified manner; and (d) enables decision reuse and documentation. Conclusions The results of the study suggest that architectural decision-making can benefit from treating this activity as a financial investment. The various benefits that have been identified from mixing financial and technological aspects are well-accepted from industrial stakeholders.
View
Ontology-Based Information Visualisation.
Conference Paper
Full-text available
  • Jan 2001
The main contribution is to show how visual representations of information can be based on ontological classifications of that information. We first discuss the central role of ontologies on the Semantic Web. We subsequently outline our general approach to the construction of ontology-based visualisations of data. This is followed by a set of examples of ontology-based visualisations which all differ in interesting respects. We conclude with a brief discussion of related work
View
Software Architecture: The Next Step
Conference Paper
Full-text available
  • May 2004
  • Lect Notes Comput Sci
This position paper makes the following claims that, in our opinion, are worthwhile to discuss at the workshop. 1) The first phase of software architecture research, where the key concepts are components and connectors, has matured the technology to a level where industry adoption is wide-spread and few fundamental issues remain. 2) The traditional view on software architecture suffers from a number of key problems that cannot be solved without changing our perspective on the notion of software architecture. These problems include the lack of first-class representation of design decisions, the fact that these design decisions are cross-cutting and intertwined, that these problems lead to high maintenance cost, because of which design rules and constraints are easily violated and obsolete design decisions are not removed. 3) As a community, we need to take the next step and adopt the perspective that a software architecture is, fundamentally, a composition of architectural design decisions. These design decisions should be represented as first-class entities in the software architecture and it should, at least before system deployment, be possible to add, remove and change architectural design decisions against limited effort.
View
Explicit assumptions enrich architectural models
Conference Paper
Full-text available
  • Jun 2005
Design for change is a well-known adagium in software engineering. We separate concerns, employ well-designed interfaces, and the like to ease evolution of the systems we build. We model and build in changeability through parameterization and variability points (as in product lines). These all concern places where we explicitly consider variability in our systems. We conjecture that it is helpful to also think of and explicitly model invariability, things in our systems and their environment that we assume will not change. We give examples from the literature and our own experience to illustrate how evolution can be seriously hampered because of tacit assumptions made. In particular, we show how we can explicitly model assumptions in an existing product family. From this, we derive a metamodel to document assumptions. Finally, we show how this type of modeling adds to our understanding of the architecture and the decisions that led to it.
View
The Infovis Toolkit
Conference Paper
Full-text available
This article presents the InfoVis toolkit, designed to support the creation, extension and integration of advanced 2D information visualization components into interactive Java swing applications. The InfoVis toolkit provides specific data structures to achieve a fast action/feedback loop required by dynamic queries. It comes with a large set of components such as range sliders and tailored control panels required to control and configure the visualizations. These components are integrated into a coherent framework that simplifies the management of rich data structures and the design and extension of visualizations. Supported data structures currently include tables, trees and graphs. Supported visualizations include scatter plots, time series, parallel coordinates, treemaps, icicle trees, node-link diagrams for trees and graphs and adjacency matrices for graphs. All visualizations can use fisheye lenses and dynamic labeling. The InfoVis toolkit supports hardware acceleration when available through Agile2D, an implementation of the Java graphics API based on OpenGL, achieving speedups of 10 to 200 times. The article also shows how new visualizations can be added and extended to become components, enriching visualizations as well as general applications
View
gIBIS: a tool for all reasons
Article
  • May 1989
  • J Am Soc Inform Sci
This article describes an application specific hypertext system designed to facilitate and capture policy and design discussions. It implements a specific method, called Issue Based Information Systems (IBIS), which was developed for use on large, complex design problems. The hypertext system described here, gIBIS (for graphical IBIS), makes use of color and a high speed relational database server to facilitate building and browsing typed IBIS networks. Further, gIBIS is designed to support the collaborative construction of these networks by any number of cooperating team members spread across a local area network. Early experiments suggest that the gIBIS tool is still incomplete, but that it is already a useful tool for thinking and communication. © 1989 John Wiley & Sons, Inc.
View
View
View
Visual Explanations: Images and Quantities, Evidence and Narrative
Article
  • Aug 1997
As an extension of his observations described in his earlier book, "Envisioning Information", Tuftes third installment of the trilogy turns the discussion to the display of dynamic information. Again, Tufte draws from numerous examples throughout history to illustrate his points. The chapter on Visual and Statistical Thinking contains some of the most poignant arguments in the book, including an engaging visual narrative of the 1854 Cholera Epidemic and a study on the Challenger space-shuttle tragedy. This book may not for everyone, however. It does not contain ready-to-use concepts nor does it present a comprehensive solution for displaying dynamic information. What it does contain, are keen observations and commentary on past attempts at dynamic information display. The relation of each chapter to the next is not readily apparent and is quite precarious in fact. What results, is a book that reads better if each chapter is taken independently. In short, this book will be more rewarding to those willing to spend time to ponder over Tuftes observations. Conversely, the book will appear to have a lack of focus to those in a rush to find solutions.
View
Design Rationale Systems: Understanding the Issues
Article
  • Jun 1997
Most current design rationale systems fail to consider practical concerns, such as cost-effective use and smooth integration. The author identifies seven technical and business issues and describes their implications
View
Architecture Decisions: Demystifying Architecture
Article
  • Apr 2005
We believe that a key to demystifying architecture products lies in the architecture decisions concept. We can make the architecture more transparent and clarify its rationale for all stakeholders by explicitly documenting major architecture decisions.
View