In the context of software architecture recovery, visual representations can allow architects or developers to perceive and comprehend the recovered information faster. Many visualizations address various facets of the complex information space, but there are no systematic approaches for the architect to efficiently evaluate candidate visualizations for suitability, or to explore ways to extend them. The resultant ad-hoc selection from available generic visualizations leads to ineffective comprehension and analysis. We propose a viewpoint-driven approach towards tackling this problem. From a comparison of the conceptual models of architectural viewpoints and information visualization, we observe that focusing on the concerns framed by a viewpoint can guide the suitable selection of visualization tasks. The viewpoint description also serves a source for the definition of the visualization dataset. Starting from a seed visualization, a simple measure called the task/concern coverage allows the architecture visualization designer to decide if the resulting visualization can express all the desired concerns. This approach is illustrated with an example of the Polyptychon hierarchical dependencies visualization.

Some organizations consider software architects as advanced software engineers with a high-technology bias. From their perspective, architects do not require expertise in business and strategy. Even software architects themselves tend to believe they are only responsible for technology and design decisions but not for economic aspects. This attitude leads to solutions that are technically sound but fail to deliver the expected return on investment. If software architects do not understand economics and the business, they cannot come up with economic solutions that support the business case and business strategy. This is why mission-critical projects often do not achieve their business goals, thus incurring high additional costs. Although this holds for other engineering disciplines as well, the high flexibility expectations regarding software and its creation increase the economic risks.

System Quality and Software Architecture collects state-of-the-art knowledge on how to intertwine software quality requirements with software architecture and how quality attributes are exhibited by the architecture of the system. Contributions from leading researchers and industry evangelists detail the techniques required to achieve quality management in software architecting, and the best way to apply these techniques effectively in various application domains (especially in cloud, mobile and ultra-large-scale/internet-scale architecture) Taken together, these approaches show how to assess the value of total quality management in a software development process, with an emphasis on architecture. The book explains how to improve system quality with focus on attributes such as usability, maintainability, flexibility, reliability, reusability, agility, interoperability, performance, and more. It discusses the importance of clear requirements, describes patterns and tradeoffs that can influence quality, and metrics for quality assessment and overall system analysis. The last section of the book leverages practical experience and evidence to look ahead at the challenges faced by organizations in capturing and realizing quality requirements, and explores the basis of future work in this area.Explains how design decisions and method selection influence overall system quality, and lessons learned from theories and frameworks on architectural qualityShows how to align enterprise, system, and software architecture for total qualityIncludes case studies, experiments, empirical validation, and systematic comparisons with other approaches already in practice.

Architects and developers are often tasked with evaluating or maintaining unfamiliar software systems. Reverse engineering tools help extract relationships between the system parts as they exist instead of as documented. Though node-link diagrams have a straightforward correspondence with the graph-represent able data generated, the scale and complexity of real-world data sets prevent efficient comprehension. This paper presents Polyptychon, an interactive node-link visualization designed for incremental exploration of dependency information. Given a hierarchical information space of software artifacts, Polyptychon constrains the visible dependencies to be related to the child nodes of a specified artifact node, called a view root. It then classifies these siblings as levelized, tangled and independent. It also includes context nodes, which are a filtered set of nodes elsewhere in the hierarchy that are related to the siblings. The context nodes are further grouped based on a project-specific partition function. The hierarchical constraints and partition function provide means to control the number of nodes displayed, while the dependency classification allows users to form a qualitative impression of the dependency structure. We demonstrate with examples from the Netty open source project. We conclude with areas of future work, in particular, as a basis of evolutionary dependency analysis.

This chapter describes how to systematically prevent software architecture erosion by applying refactoring techniques. Software architecture modifications are common rather than the exception in software development. Modifications come in different flavors, such as redefining or adding requirements, changing infrastructure and technology, or causing changes by bugs and incorrect decisions. But no matter where these changes originate, they need special attention from software architects. Otherwise, if software architects merely focus on adding new features—(changes or extensions that by themselves might not be adequate), design erosion will be the final result. In a systematic approach, software architects evaluate the existing software design before adding new artifacts or changing existing ones. Whenever they identify architecture problems, they immediately resolve architectural issues, thus assuring high quality and sustainability. Software architecture refactoring enables such iterative architecture improvement. It consists of indentifying problems, applying the right refactorings, and testing the results. Architecture refactoring is often combined with code refactoring activities to add the best value. Refactoring patterns offer proven solutions for recurring architectural problems, hence providing a toolset to software engineers.

Software architecture is the foundation of software system development, encompassing a system's architects' and stakeholders' strategic decisions. A special issue of IEEE Software is intended to raise awareness of architecture sustainability issues and increase interest and work in the area. The first Web extra at http://youtu.be/wUGHvocfix0 is an audio interview in which Davide Falessi speaks with guest editors Paris Avgeriou and Rich Hilliard about the importance of architecture sustainability including the three types of approaches they distinguish for handling change systematically, listed in an order of increasing severity: refactoring, renovating, and rearchitecting. The second Web extra at http://youtu.be/T-neSlUhAv0 is an audio interview in which Brian Brannon speaks with guest editor Michael Stal about his experiences with architecture sustainability as a principal engineer at Siemens AG's Corporate Research and Technology division.

Software architecture is the foundation of software system development, encompassing a system's architects' and stakeholders' strategic decisions. A special issue of IEEE Software is intended to raise awareness of architecture sustainability issues and increase interest and work in the area. The first Web extra at http://youtu.be/wUGHvocfix0 is an audio interview in which Davide Falessi speaks with guest editors Paris Avgeriou and Rich Hilliard about the importance of architecture sustainability including the three types of approaches they distinguish for handling change systematically, listed in an order of increasing severity: refactoring, renovating, and rearchitecting. The second Web extra at http://youtu.be/T-neSlUhAv0 is an audio interview in which Brian Brannon speaks with guest editor Michael Stal about his experiences with architecture sustainability as a principal engineer at Siemens AG's Corporate Research and Technology division.

Computing systems are increasingly designed as a collection of interacting services that constitute a set of functionality offered by a service provider or server to its clients. Many service-oriented computing systems have constraints on the resources they allocate and manage. In these systems, certain types of services should consume resources only when they are accessed by clients, and clients should be shielded from where services are located, how they are deployed, and how their lifecycle is managed. The activator pattern provides an effective means to efficiently and transparently automate scalable on-demand activation and deactivation of services accessed by many clients. This paper motivates the need for the activator pattern, describes the structure and dynamics of canonical implementations of the pattern, and examines the benefits and liabilities of applying this pattern to services in resource-constrained computing systems. Copyright (c) 2011 John Wiley & Sons, Ltd.

Software engineering has an increasing impact on the diverse products, services, and solutions offered by technology-oriented industries. For example, within SIEMENS AG over 60% of revenues depend on software. Consequently, failures in software development projects lead to significant costs. If software is so important, we need sustainable software architectures designed by well-educated and skilled software architects as backbone of high quality software systems. However, due to the complexity of problem and solution domains and the increased desiderata of customers, software systems cannot be created in a big bang approach. Instead, software architectures must be systematically designed and then implemented using piecemeal growth which implies that software architects need to incrementally and iteratively refine, assess, and improve a software system. Otherwise, wrong or inefficient design decisions will be hard and costly to detect and eliminate inevitably causing design erosion to creep in. Thus, Software Architecture Evaluation and Improvement play an important role in the development of sustainable software systems. But how can we seamlessly integrate Software Architecture and Improvement into the architecture design process? A systematic process for creating software architecture comprises among many other ingredients the (stepwise) clarification and prioritization of requirements, the incremental and iterative evolution of the software architecture driven by requirements and risks, Continuous quality assessment for assuring that the software system meets its internal and external qualities as well as its functional expectations. For continuous quality assessment Test-Driven Development and Design for Testability denote approaches that are applicable when the implementation is available. In order to assess the architecture itself, even in absence of a (full) implementation, qualitative and quantitative architecture assessment methods are available. For example, the experience-based industry review method applies a SWOT analysis to identify potential threats and weaknesses as well as potential means to resolve these issues. Architecture Analysis tools support software architects in this endeavor. But how can software architects improve the internal or external quality of the software system after they detected some architecture smells? It is essential to get rid of these issues by continuous software architecture improvement which exactly is the place where architecture refactoring, reengineering, and rewriting come in.

Although Software Architecture appears to be a widely discovered field, in fact it represents a rather young and still maturing discipline. One of its essential topics which still need special consideration is systematic software architecture design. This chapter illustrates a set of proven practices as well as a conceptual method that help software engineers classify and prioritize requirements which then serve as drivers for architecture design. All design activities follow the approach of piecemeal growth.

State-of-the-art middleware such as CORBA, RMI or .NET Remoting represents a stack of interoperability layers to connect different islands of code. While all these existing solutions are widely used for the development of commercial and industrial software, they still lack essential features: First of all, there is no accepted middleware standard to connect different technology platforms with each other. And second, standard middleware promotes a tight coupling between peers. SOA principles introduce loose coupling which is important when even small parts of a distributed system are not under control of the developers. One implementation of these principles, XML Web services, are capable of bridging heterogeneous languages, platforms, and middleware. On the other hand, complain about immature, missing or even competing standards for XML Web services. And it still seems unclear how component-based technologies and services fit together. The keynote tries to illustrate how the upcoming universe of middleware, services and components could look like. Not only from a functional perspective but also keeping quality of service issues in mind.

Seeking a better solution to the application integration problem.

Seeking a better solution to the application integration problem.

Today, many Web-based products and software systems must continuously evolve in ETime. Nonetheless, they must be easily changeable, extensible, and reveal many other non-functional properties. The question arises how software systems can be prepared to cope with these requirements? Conventional applications are driven by a specific set of requirements that is stable during development, at least in theory. Applications may be extended after their rollout, but their usage context is mostly unchanged. This approach doesn't work anymore for a Web-based world. Here, new applications must be developed with change and integration in mind. This requires a more framework-like approach where the same applications may participate in different contexts. To support this kind of flexibility, we need to increase entropy. That means, applications shouldn't make too many assumptions a priori where they run and how they interact. Everything should be loosely coupled. Meta-information should be decentralized. For this purpose, applications need to resort to standards and minimize dependencies on other applications. This does not only hold for inter-application interaction, but also for intra-application boundaries. Thus, we should partition applications into decoupled services we can compose to completely new applications previously not anticipated. In other words: we need agile software technologies for an agile world. What we finally get is a world of services that interoperate and interact with each other using Web-based standards. Finally, we have reached the universe of Web Services and Web-based middleware.