April 29 to May 3, 2013
The second SEI Software Architecture Technology User Network Workshop (SATURN 2006) was held on April 25-26, 2006 at Sheraton Station Square in Pittsburgh, Pennsylvania. It was open to anyone who had taken some of the courses in the Software Architecture Curriculum or read some of the SEI publications about architectural methods and techniques and had an interest in applying them in their organization.
Topics discussed included:
Nord, Robert L. Proceedings of the Second Software Architecture Technology User Network (SATURN) Workshop (CMU/SEI-2006-TR-010).
Architecture Analysis Overview and Observations
Don O'Connell, Boeing Company
This presentation lists some of the key software/system architectural analysis that we use on our products. Then, the presentation focuses on the application of ATAM and QAW to a variety of products over the last 3+ years. Only publicly releasable information is described. Overview of our ATAM process adjustments and focuses are described. Keys to success are highlighted. Overview of ATAM/QAW results and risk mitigation activities are described.
Raytheon's Architecture Journey
Rolf Siegers, Raytheon Intelligence & Information Systems
Raytheon began an "architecture journey" several years ago to institutionalize architecture as a formal practice throughout the company. Corporate Engineering's senior leadership defined a vision to address a set of software, systems, and enterprise architecture needs across Raytheon's multiple business areas.
Since then, Raytheon has enhanced its architecture competencies through a variety of corporate initiatives including:
A Comparison of Requirements Specification Methods from a Software Architecture Perspective
Quality attribute requirements have a significant influence on the software architecture of a system. They guide the decisions about patterns, tactics and approaches that will contribute to the formation of the architecture. It has been our observation that quality attribute requirements are not routinely specified in a manner that makes them useful to an architect. In order to assess how well different requirement specification methods serve an architect's goals and needs for choosing architectural approaches we have examined natural language requirements using "shall" and "will", use case analysis, quality attribute workshop, global analysis, and an approach due to Fergus O'Brien that we call "O'Brien's approach". We have selected these methods either due to their widespread use, and/or their emphasis on the capture of quality attributes requirements in particular. In this talk, I will first present the evaluation criteria under which we have examined these methods. Then, I will introduce each method with a descriptive example and evaluate it under the criteria. I will conclude by comparing the methods against each other based on our examination.
Architectural Design of an Industrial AGV Transportation System with a Multiagent System Approach
Egemin N.V. is a Belgian manufacturer of Automatic Guided Vehicles (AGVs) and control software for automating logistics services in warehouses and manufactories using AGVs. In a joint R&D project, Egemin and the DistriNet research group have developed an innovative version of the AGVs control system aimed to cope with new and future system requirements such as flexibility and openness. In this project, a multiagent system approach is applied for modeling and implementing a decentralized control system. Instead of a centralistic approach, where one computer system is in charge of numerous complex and time-consuming tasks such as routing, collision avoidance, or deadlock avoidance, in this project the AGVs are provided with a considerable amount of autonomy. This allows obtaining a system that is far more flexible than the current software. The AGVs adapt themselves to the current situation in their direct vicinity, order assignment is dynamic, the system can cope with AGVs leaving the system (e.g. for maintenance) or adding new AGVs, and so on. To develop the AGV application, we used the evolutionary delivering life cycle. This life cycle model situates architectural design in the middle of the development activities.
To describe the functionality of the software system, we defined scenarios together with the main stakeholders of the system. Some scenarios are initiated by an external actor, e.g. a scenario that describes the life-cycle of a task that enters the system; other scenarios describe interactions among parts in the system, e.g. a scenario that describes collision avoidance of automatic vehicles on crossroads. For the expression of quality requirements we used quality attribute scenarios. In particular, to elicit quality attribute scenarios, we organized a quality attribute workshop with the main stakeholders involved in the project. During this two-day workshop we generated a utility tree to define and prioritize the relevant quality requirements precisely. Particular experiences here came from the specification of quality attributes such as flexibility and openness that were important quality goals of the project.
For architectural design, we used techniques from the Attribute Driven Design (ADD) method. The ADD method is a recursive decomposition method that is based on understanding how to achieve quality goals through proven architectural approaches. At each stage of the decomposition we selected architectural drivers together with appropriate architectural approaches to satisfy the drivers. We extensively used a reference architecture for situated multiagent systems as an asset base for selecting architectural solutions. This reference architecture is developed at DistriNet Labs and incarnates our expertise with architectural design of various situated multiagent system applications. The software architecture of the AGV application is documented by different views, each view belonging to a viewtype. We used views from the standard viewtypes: the module viewtype, the component-and-connector viewtype, and the deployment viewtype.
For the evaluation of the software architecture we used the Architecture Tradeoff Analysis Method (ATAM). The main goal of the ATAM is to examine whether the software architecture satisfies system requirements, in particular the quality requirements. We applied the ATAM for one concrete application, in casu a tobacco warehouse transportation system that was used as a test case in the project. The ATAM that took one day was a valuable experience. For the first time, the complete group of stakeholders discussed the architecture in depth. Participants agreed that their insights were improved on: (1) the importance of software architecture in software engineering; (2) the importance of business drivers for architectural design; (3) the importance of explicitly listing and prioritizing quality attributes with the stakeholders; (4) the strengths and weaknesses of the architecture and architectural approaches. One interesting discussion arose from the tradeoff between flexibility and performance. Various decisions in the software architecture aim to improve flexibility in the system, yet the decentralized nature of the multiagent system implies an increase of bandwidth occupation. Field tests after the ATAM proved that the communication cost remains under control even in worst-case scenarios.
A number of critical reflections about the ATAM were made as well: (1) a thorough and complete architectural evaluation using the ATAM of a realistic industrial application is not manageable in a single day; (2) coming up with a quality attribute tree proved to be difficult, time consuming, and at times tedious. A lack of experience and clear guidelines of how to build up such a tree hindered and slowed down the discussion; (3) while the general AGV software architecture was developed with several automation projects in mind, the ATAM evaluated it within the scope of a single automation project. Clearly, the ATAM is devised to evaluate a single architecture in a single project. However, this difference in scope hindered the discussions because some architectural decisions were motivated by the product line nature of the architecture; (4) we experienced a lack of good tool support to document architectures. Currently, drawing architectural diagrams and building up the architectural documentation incurs much overhead. Especially changing the documentation and keeping everything up-to-date (e.g. cross references and relations between different parts of the documentation) turned out to be hard and time consuming. Good tool support would be helpful.
Developing the AGV application with a multiagent system approach was a valuable experience for both partners in this project. Egemin learned a lot about the potential as well as the possible implications of applying multiagent system technology in AGV systems. For us at DistriNet, this real-world application showed that multiagent systems can make a difference when qualities such as flexibility and openness are important goals for a system. Finally, we gained a better insight in the relationship between multiagent systems and software architecture.
Our long-term goal is to provide an effective, integrated, widely applicable, and tailorable set of life-cycle architectural practices and tools to help an architect keep a software architecture in line with its goals as the system evolves. One challenge is to understand where we are - that is, readily determine the current state of the architectural design and be able to evolve from that position since it is not always the case that the architect is working in a Greenfield environment. Another challenge is to be able to find the appropriate practice or tool that can take us where we need to go - this may involve the need to flexibly tailor and integrate practices with each other and to understand the appropriate fit with other architectural processes and technologies.
Participants are asked to think about the following questions:
Architecture Centric Development Method
Anthony J. Lattanze
Functionality is a measure of how well a system does the work it was intended to do, but functionality is not all that matters in software development. Properties like interoperability, modifiability, and portability also matter as much as functionality does. These properties are determined primarily by the software structure - or the software architecture. While many structures can satisfy functionality, few can satisfy the required functionally and the quality attribute properties needed in a system. Achieving quality attributes in a predicable way can only be accomplished by deliberately selecting the appropriate structures early in the development process. This is a radical departure from high speed, lightweight programming methodologies (e.g., XP) that focus on functionality and prescribe writing software until a product emerges - architectures also emerge in this paradigm. Emergent architectural structures may or may not meet the expectations of the broader stakeholder community. Unfortunately, architectural shortfalls are not recognized until it is too late and repair is difficult and costly. On the opposite end of the spectrum are methods espouse high ceremony processes and heavy emphasis on document production. While mature processes are certainly beneficial, there is no correlation that high maturity organizations consistently produce high quality architectures - again, architectural shortfalls are often discovered late in the development lifecycle. The Architecture Centric Development Method (ACDM) can be differentiated from these extremes in that ACDM places the software architecture at the center of a development effort rather than software processes or code artifacts. Like architectures in the building and construction industries, ACDM prescribes using the architecture design to drive, not only the technical aspects of the project, but also the process and programmatic issues of a development effort as well. ACDM weaves together product, technology, process, and people into a cohesive lightweight, scaleable development method. During this presentation I will present an overview of ACDM, briefly discuss the experiences thus far in using the method, and the planned next steps for maturing the method.
Architecture Risk Reduction Activities
This working session will focus on:
We will draw on participants experience with SEI software architecture technology but not be restricted to these. We are interested in learning of other activities that address risk reduction. For example, some might use requirements validation techniques or cost modeling techniques, or COTS evaluation techniques that could address architectural risks.
ATAM and Collaboration at the Enterprise Level
This presentation will cover the use of the ATAM within a blackboard collaboration toolset. The demo will show the ATAM and its interaction with enterprise level concepts that will allow for a more streamlined enterprise understanding, traceability and architecture. The tool itself is a standards and methodology agnostic tool and allows users to build any framework, standard or methodology into it and then capture the relevant information into that environment.
Bridging System and Software Architecture
Michael J. Gagliardi
William G. Wood
There is currently a gap between engineering practices of system architecture and software architecture, and this can and does cause many problems in the development and acquisition of large-scale software-intensive systems in the DoD. Systems-of-systems (SoS) are particularly susceptible to major disconnects between system and software architectures. The SoS depends on the system architecture to guide the development of the individual systems and the concept of operations (CONOPS), and is also dependent on the software architecture allowing interoperation between nodes, and the sharing of critical timely information. All programs must find a way of matching the system architecture to the software architecture, handling the inevitable development parallelism, and ensuring that the system architects, software architects, and CONOPS developers interact appropriately to get the best possible system. This working session will be a facilitated forum to begin to capture the current state of practice for integrating system and software architectures. We also want to begin to identify the architecture integration gaps and technical obstacles.
Definition and Evaluation of Geographic Information System Architecture Using ADD and ATAM
Don O'Connell, Boeing Company
The presentation provides an overview of and key findings from the application of the SEI's architectural methods in the definition and assessment of an architecture for a Geographic Information System (GIS). This application resulted in the documentation of twenty-two quality attribute scenarios covering performance, availability, modifiability, security, testability and usability. Three design iterations were then performed, in accordance with the Attribute-Driven Design (ADD), producing an architecture, documented in two architectural views (Module and Component-and-Connector (C&C)). Thirty-eight distinct architectural design decisions were made; each contributed to the achievement of one or more quality attribute scenario. Finally, the GIS architecture was evaluated using the Architecture Trade-Off Analysis Method (ATAM), resulting in the identification of sixteen sensitivity points, ten tradeoff points, and thirteen risks, summarised in four risk themes. Lessons learnt from applying the SEI's architectural methods revealed that addressing GIS quality attributes systematically at the architectural stage facilitated an unambiguous record of the rationale, assumptions and dependencies of the critical technical decisions involved in achieving key quality drivers. This in turn improved the flexibility, adaptability and analysability of the architecture. Additionally, the GIS architectural process proved to be useful for teaching purposes. It is currently used as part of a postgraduate course in software architecture as an example of a systematically-defined architecture.
Global Software Development
The trend towards global software development has gathered pace in recent years. More and more software intensive systems are being developed using teams that are geographically distributed. Developing software in this way poses unique challenges, however. Not only do cultural issues, differences in background, and organizational boundaries come into play, but communication and coordination in general is much more difficult and less effective. The system architecture is a central artifact in these efforts. This working session aims to bring together people who are concerned with architecting systems for global development. During this working session we will bring our collective experience together to identify the architectural issues that are unique to global software development and provide a forum for sharing our experience in dealing with those issues.
Participants should think about the following questions:
SEI Future Directions in SEI Software Architecture Technology (SAT) Initiative
Mark H. Klein
The Software Architecture Technology (SAT) Initiative at the Software Engineering Institute creates, harnesses, and applies innovations that are then codified as effective software architecture practices and are used throughout the development life cycle. Our work is guided by the responding to real-world needs, maximizing impact and basing techniques and methods on theoretically sound foundations. This talk briefly reviews the "state of the SAT initiative" and then outlines our future research directions.
The Best of Three Worlds: Combining QAW, MDRE, and GA
Bob Schwanke, Siemens Corporate Research
The GEAR process integrates three approaches to architectural requirements engineering: model-driven requirements engineering, quality attribute scenarios, and global analysis, within an iterative, incremental analysis process. In so doing, it shows where these methods overlap and where they complement each other. It also adds insight into the differences between product requirements and architecture requirements. GEAR incorporates experience from over a dozen diverse industrial software architecture projects.
Building a Software Architecture Community
The Software Architecture Technology User Network (SATURN) Workshop is an effort to foster an exchange of best practices in developing and acquiring software architectures. During this working session we will discuss experiences with building a software architecture community of practice both within an organization and ideas for growing SATURN beyond a yearly workshop and into a network available to members throughout the year.
Participants should think about the following questions:
A presentation from the SEI Software Architecture Technology User Network (SATURN) Workshop April 25-26, 2006.
Risk Themes from ATAM Data: Preliminary Results
William G. Wood
ATAM is a method for evaluating a software architecture against business goals. The architecture identifies a number of risks that the architecture will not meet its goals and these risks are rolled up into a collection of "risk themes". This talk presents a preliminary analysis of the results of a collection of ATAMs. The articulated business goals are categorized as are the risk themes. The risk themes are compared to the business goals articulated and some patterns are identified.
April 29 – May 3, 2013
Get the latest SATURN news, important dates, and announcements on the SATURN Network blog, sign up for our email updates, follow us on Twitter (@SATURN_News, #SATURN2013), and join the SATURN LinkedIn Group.
Phone: +1 412-268-5800
Toll Free (within the USA): +1 888-201-4479
FAX: +1 412-268-6257
Please tell us what you
think with this short
(< 5 minute) survey.