No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Using an Architecture Reasoning Tool to Teach Software Architecture
Abstract
The Architecture Expert (ArchE) is a software architecture design assistant under development at the Software Engineering Institute (SEI). It embodies knowledge of quality attributes and the relation between the achievement of quality attribute requirements and architecture design. In this paper, we describe the use of ArchE in a graduate level software architecture class at Clemson University. The discussion combines aspects of using ArchE as a tool to produce architectures and using ArchE to teach about architecting. The students were positive about the use of ArchE although critical of ArchE's immaturity. The instructor was also positive about the use of ArchE.
... In this context, so-called software architecture design assistants (e.g., [18,17,16,13]) provide architects with a toolbased, (semi-)automated support in their engineering tasks. Compared to manual engineering, the main promise of such a support is that architects can create high-quality architectural designs more e ciently. ...
... Such studies are especially suitable to (a) show the general applicability of a design assistant and (b) identify potential influence factors on eciency (or other attributes of interest). For example, Smith et al. [20], Brosig et al. [4], Huber et al. [11], McGregor et al. [16], as well as Lehrig and Zolynski [14] all conducted case studies in the context of architecture-level performance analyses; each revealing di↵erent influence factors that architects should consider in architecture-level performance models. ...
Software architects use so-called software architecture design assistants to get tool-based, (semi-)automated support in engineering software systems. Compared to manual engineering, the main promise of such a support is that architects can create high-quality architectural designs more efficiently. Yet, current practice in evaluating whether this promise is kept is based on case studies conducted by the original authors of respective design assistants. The downside of such evaluations is that they are neither generalizable to third-party software architects nor can be used for quantitative efficiency comparisons between competing design assistants. To tackle this problem, we investigate how researchers can apply controlled experiments for evaluating the impact of software architecture design assistants on the efficiency of architects. For our investigation, we survey related controlled experiments. Based on this survey, we derive lessons learned in terms of best practices and challenges for such experiments.
... Connectors are also found in the architectures that are derived to analyze various quality attribute requirements of a system. Figure 6.1, shows a fragment of a dependency graph found in the Clemson Travel Assistance System (CTAS) architecture [69]. The circles in the figure represent responsibilities and the lines represent connectors. ...
... We will illustrate our technique using the Clemson Travel Assistance System (CTAS) [24][23] . It is an itinerary planning system that plans routes and modes of transportation from one place to another. ...
Architects use a variety of techniques to evaluate designs for the desired levels of specific quality attributes. Reasoning frameworks are used to guide architecture definition by determining the extent to which a software architecture satisfies its quality requirements. There is much work on reasoning about quality attributes such as performance and modifiability but there has been little work on defining a reasoning framework for safety. We present a safety reasoning framework that is based on the observation that safety hazards lead to accidents when certain other quality requirements of the system are not satisfied. This naturally leads to the use of reasoning frameworks for these other attributes as a means to indi-rectly reason about safety. We present our technique for using standard safety engineering activities to provide the data needed for the safety reasoning framework. A risk-based qualitative reasoning technique is used to combine the results from the set of reasoning frameworks and make a judgment on satisfaction of safety requirements by the architecture.
... The PREViA approach gives a richer, more detailed representation, and allows navigation between different levels of abstraction, including grouping of diagram packages. The ArchE tool [24] works as an assistant to the software architect. Like PREViA, both students (who interact from suggestions made by the tool as the architectural design is created) and teachers (for teaching software architecture) can use it. ...
Creation, interpretation, and evolution of models and diagrams are activities commonly performed in software projects, and the teaching of such activities is fundamental for software engineering education. However, it is difficult to see the changes made in model corrections, evolutions, or maintenance done by the student, as well as by the teacher, comparing templates and different solutions. In this regard, this paper presents the use of the PREViA approach, which aims at visualizing software architecture models. This work focuses on supporting teaching and learning in the modeling education context. A feasibility study was conducted and its results provided positive evidences of the use of the approach in the correction of diagrams.
... A design assistant can be seen as an agent that supports the architect in decision-making, either by making suggestions on possible courses of action or by performing some computations autonomously on her behalf. For several years, the Software Engineering Institute (SEI) has been developing an assistant for architecture design called ArchE 1 [1, 2, 16]. In a nutshell, this prototype performs a semi-automated search of the design space, using the outputs of reasoning frameworks to direct the search towards solutions with known quality properties. ...
Techniques,and,tools for specific quality-attribute issues are becoming,a mainstream,in architecture design. This approach,is practical for evaluating the architecture in early stages but also for planning improvements for it. Thus, we believe that one challenge is the integration of the individual capabilities of quality-attribute techniques. This paper presents our research work on a design assistant called ArchE that, based on reasoning framework technology, provides an infrastructure for third-party researchers to integrate their own quality-attribute models. This infrastructure aims at facilitating the experimentation,and sharing of quality-attribute knowledge,in both research and educational contexts. Keywords: architecture-based analysis & design, quality attributes, design
Software design decisions are usually made at early stages but have far-reaching effects regarding system organization, quality, and cost. When doing design, developers apply their technical knowledge to decide among multiple solutions, seeking a reasonable balance between functional and quality-attribute requirements. Due to the complexity of this exploration, the resulting solutions are often more a matter of developer’s experience than of systematic reasoning. It is argued that AI-based tools can assist developers to search the design space more effectively. In this chapter, the authors take a software design approach driven by quality attributes, and then present two tools that have been specifically developed to support that approach. The first tool is an assistant for exploring architectural models, while the second tool is an assistant for the refinement of architectural models into object-oriented models. Furthermore, the authors show an example of how these design assistants are combined in a tool chain, in order to ensure that the main quality attributes are preserved across the design process.
This paper aims to present an approach entitled VisAr3D to support software architecture teaching by means of virtual and augmented reality. Thus, it intends to define a D visualization environment which includes exploration, interaction and simulation resources to establish a practical and attractive learning, focusing on large scale systems.
From the Book:For all but the most trivial software systems, you cannot hope to succeed without paying careful attention to its architecture: the way the system is decomposed into constituent parts and the ways those parts interact with each other. Without an architecture that is appropriate for the problem being solved the project will fail. Even with a superb architecture, if it is not well understood and well communicated—in other words, well documented—the project will fail. Not may fail. Will fail.Accordingly, software architecture is at the center of a frenzy of attention these days. A new book about it seems to pop out monthly. In response to industrial need, universities are adding software architecture to their software engineering curricula. It's now common for "software architect" to be a defined position in organizations, and professional practice groups for software architects are emerging. It has been the subject of major international conferences and workshops. The purveyors of the Unified Modeling Language promote their product by calling it "the standard notation for software architecture" (a claim that may say at least as much about the pervasiveness of architecture as about UML). The Software Engineering Institute maintains a bibliography of journal and conference papers about software architecture and its population is approaching 1000.Rather surprisingly, there is a dearth of practical guidance available that is independent of language or notation for how to capture an architecture. To be sure, piles of books exist about how to use a particular language—again, UML comes to mind—but what an architect really needs is guidancein which architecture is a first-class citizen and language is relegated more appropriately to a supporting role.First, let's agree on some basic context. The field has not anointed a single definition of software architecture, and so there are many, but we'll use this one: A software architecture for a system is the structure or structures of the system, which comprise elements, their externally-visible behavior, and the relationships among them. (Adapted from Bass 98.)Much of this book is about the meaning of elements and relationships, but for now we use this definition to emphasize the plurality of structures that exist in architectures. Each structure is characterized by different kinds of elements and relationships, and each structure provides a view of the architecture that imparts a particular kind of understanding.The architecture serves as the blueprint for both the system and the project developing it. It defines the work assignments that must be carried out by design and implementation teams. The architecture is the primary carrier of system qualities such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision. Architecture is an artifact for early analysis to make sure that the design approach will yield an acceptable system. And architecture holds the key to post-deployment system understand-ing, maintenance, and mining efforts. In short, architecture is the conceptual glue that holds every phase of the project together for all of its many stakeholders.And documenting the architecture is the crowning step to crafting it. The perfect architecture is useless if it has not been expressed understandably. If you go to the trouble of creating a strong architecture, you must go to the trouble of describing it in enough detail, without ambiguity, and organized so that others can quickly find needed information. Otherwise your effort will have been wasted, because the architecture will be unusable.The goal of this book is to help you decide what information about an architecture is important to capture and to provide guidelines and notations (and examples) for capturing it. We intend this book to be a practitioner- oriented guide to the different kinds of information that constitute an architecture. We wanted to give practical guidance for choosing what information should be documented, and show (with examples in various notations, including but not limited to UML) how to describe that information in writing so that others can use it to carry out their architecture-based work: implementation, analysis, recovery, etc. Therefore, we cover: Uses of software architecture documentation. How one documents depends on how one wishes to use the documentation. We lay out possible end goals for architecture documentation, and provide documentation strategies for each. Architectural views. We hold that documenting software architecture is primarily about documenting the relevant views, and then augmenting this information with relevant information that applies across views. The heart of the book is an introduction to the most relevant architectural views, grouped into three major families (which we call viewtypes) along with practical guidance about how to write them down. Examples are included for each. Packaging th information. Once the views have been understood, there is still the problem of choosing the relevant views, including information not contained in a view, and packaging all of the information as a coherent whole. has been created, We give practical advice for all of these facets.The audience for this book includes the people involved in the production and consumption of architectural documentation, which is to say the community of software developers. We believe strongly in the importance of architecture in building successful systems. But no architecture can achieve this if it is not effectively communicated, and documentation is the key to successful communication. We hope we have provided a useful handbook for practitioners in the field.PC—Austin, TexasFB, LB, DG, JI, RL, RN, JS—Pittsburgh, Pennsylvania
This lecture maps the concepts and templates explored in this tutorial with well-known architectural prescriptions, including the 4+1 approach of the Rational Unified Process, the Siemens Four Views approach, and the ANSI/IEEE-1471-2000 recommended best practice for documenting architectures for software-intensive systems. The lecture concludes by re-capping the highlights of the tutorial, and asking for feedback.