Software architectures shift the focus of developers from lines-of-code to coarser-grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architecture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, the distinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation and programming languages on the other. This paper attempts to provide an answer to these questions. It motivates and presents a definition and a classification framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations. The framework is used to classify and compare several existing ADLs, enabling us, in the process, to identify key properties of ADLs. The comparison highlights areas where existing ADLs provide extensive support and those in which they are deficient, suggesting a research agenda for the future.

/pdf/a-classification-and-comparison-framework-for-software-3so7xapmcq.pdf

A classification and comparison framework for software architecture description languages

This pczper investigcztes irzterrelationslzi~~s of product design, orgcznization design, processes for leartlirzg and managing knowledge, arzd competitive strategy. This paper uses the principles of nearly decotnposable systems to investigate the ability of strind(irdized interfcices between components in cz product design to embed coordination of product development processes. Embedded coordination creates 'hierczrchical coordination' without the need to continually exercise authority-erzcrblirlg effective coordination of processes without the tight coupling of orgcznizationczl structures. We develop concepts of modularity in product and organization designs based orz smndcirdized component and organization interjczces. Modular product architec- tures create information structures that provide the 'glue' that holds together the loosely coupled parts of a modular orgatzizatiorz design. By fczcilitriting loose coupling, modularity can czlso reduce the cost and dyficulty of adaptive coordination, thereby incrensing the strategic flexibility of firms to respond to erzvironmentnl change. Modularity in product and organizcztion designs therefore etznbles cz new strcitegic approach to the management of knowledge based on cztz irztentionczl, carefully mcznaged loose coupling of (I firm's learning processes czt architec- tural cznd comporzent levels of product crecztiorz processes.

Modularity, flexibility, and knowledge management in product and organization design

This paper is a review of research in product development, which we define as the transformation of a market opportunity into a product available for sale. Our review is broad, encompassing work in the academic fields of marketing, operations management, and engineering design. The value of this breadth is in conveying the shape of the entire research landscape. We focus on product development projects within a single firm. We also devote our attention to the development of physical goods, although much of the work we describe applies to products of all kinds. We look inside the "black box" of product development at the fundamentaldecisions that are made by intention or default. In doing so, we adopt the perspective of product development as a deliberate business process involving hundreds of decisions, many of which can be usefully supported by knowledge and tools. We contrast this approach to prior reviews of the literature, which tend to examine the importance of environmental and contextual variables, such as market growth rate, the competitive environment, or the level of top-management support.

/pdf/product-development-decisions-a-review-of-the-literature-1jhatri7bn.pdf

Product Development Decisions: A Review of the Literature

Software reuse is the process of creating software systems from existing software rather than building software systems from scratch. This simple yet powerful vision was introduced in 1968. Software reuse has, however, failed to become a standard software engineering practice. In an attempt to understand why, researchers have renewed their interest in software reuse and in the obstacles to implementing it.This paper surveys the different approaches to software reuse found in the research literature. It uses a taxonomy to describe and compare the different approaches and make generalizations about the field of software reuse. The taxonomy characterizes each reuse approach in terms of its reusable artifacts and the way these artifacts are abstracted, selected, specialized, and integrated.Abstraction plays a central role in software reuse. Concise and expressive abstractions are essential if software artifacts are to be effectively reused. The effectiveness of a reuse technique can be evaluated in terms of cognitive distance—an intuitive gauge of the intellectual effort required to use the technique. Cognitive distance is reduced in two ways: (1) Higher level abstractions in a reuse technique reduce the effort required to go from the initial concept of a software system to representations in the reuse technique, and (2) automation reduces the effort required to go from abstractions in a reuse technique to an executable implementation.This survey will help answer the following questions: What is software reuse? Why reuse software? What are the different approaches to reusing software? How effective are the different approaches? What is required to implement a software reuse technology? Why is software reuse difficult? What are the open areas for research in software reuse?

Software reuse

The World Wide Web has succeeded in large part because its software architecture has been designed to meet the needs of an Internet-scale distributed hypermedia application. The modern Web architecture emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. In this article we introduce the Representational State Transfer (REST) architectural style, developed as an abstract model of the Web architecture and used to guide our redesign and definition of the Hypertext Transfer Protocol and Uniform Resource Identifiers. We describe the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, contrasting them to the constraints of other architectural styles. We then compare the abstract model to the currently deployed Web architecture in order to elicit mismatches between the existing protocols and the applications they are intended to support.

Principled design of the modern Web architecture

From the Book:

Our goals for the first edition were threefold. First, we wanted to show through authentic case studies actual examples of software architectures solving real-world problems. Second, we wanted to establish and show the strong connection between an architecture and an organization's business goals. And third, we wanted to explain the importance of software architecture in achieving the quality goals for a system. 

Our goals for this second edition are the same, but the passage of time since the writing of the first edition has brought new developments in the field and new understanding of the important underpinnings of software architecture. We reflect the new developments with new case studies and the new understanding both through new chapters and through additions to and elaboration of the existing chapters.

Architecture analysis, design, reconstruction, and documentation have all had major developments since the first edition. Architecture analysis has developed into a mature field with industrial-strength methods. This is reflected by a new chapter about the architecture tradeoff analysis method (ATAM). The ATAM has been adopted by industrial organizations as a technique for evaluating their software architectures.

Architecture design has also had major developments since the first edition. The capturing of quality requirements, the achievement of those requirements through small-scale and large-scale architectural approaches (tactics and patterns, respectively), and a design method that reflects knowledge of how to achieve qualities are all captured in various chapters. Three new chapters treat understanding quality requirements, achieving qualities, and theattribute driven design (ADD) method, respectively.

Architecture reconstruction or reverse engineering is an essential activity for capturing undocumented architectures. It can be used as a portion of a design project, an analysis project, or to provide input into a decision process to determine what to use as a basis for reconstructing an existing system. In the first edition, we briefly mentioned a tool set (Dali) and its uses in the re-engineering context; in in this edition the topic merits its own chapter.

Documenting software architectures is another topic that has matured considerably in the recent past. When the first edition was published, the Unified Modeling Language (UML) was just arriving on the scene. Now it is firmly entrenched, a reality reflected by all-new diagrams. But more important, an understanding of what kind of information to capture about an architecture, beyond what notation to use, has emerged. A new chapter covers architecture documentation.

The understanding of the application of software architecture to enable organizations to efficiently produce a variety of systems based on a single architecture is summarized in a totally rewritten chapter on software product lines. The chapter reinforces the link between architecture and an organization's business goals, as product lines, based around a software architecture, can enable order-of-magnitude improvements in cost, quality, and time to market. 

In addition to the architectural developments, the technology for constructing distributed and Web-based systems has become prominent in today's economy. We reflect this trend by updating the World Wide Web chapter, by using Web-based examples for the ATAM chapter and the chapter on building systems from components, by replacing the CORBA case study with one on Enterprise JavaBeans (EJB), and by introducing a case study on a wireless EJB system designed to support wearable computers for maintenance technicians.

Finally, we have added a chapter that looks more closely at the financial aspects of architectures. There we introduce a method--the CBAM--for basing architectural decisions on economic criteria, in addition to the technical criteria that we had focused on previously.

As in the first edition, we use the architecture business cycle as a unifying motif and all of the case studies are described in terms of the quality goals that motivated the system design and how the architecture for the system achieves those quality goals.

In this edition, as in the first, we were very aware that our primary audience is practitioners, so we focus on presenting material that has been found useful in many industrial applications, as well as what we expect practice to be in the near future.

We hope that you enjoy reading it at least as much as we enjoyed writing it.


0321154959P12162002

/pdf/software-architecture-in-practice-1msttzulix.pdf

Software Architecture in Practice

Foreword. Preface. Acknowledgements. Dedication. Reader's Guide. I. SOFTWARE PRODUCT LINE FUNDAMENTALS. 1. Basic Ideas and Terms. What Is a Software Product Line? What Software Product Lines Are Not. Fortuitous Small-Grained Reuse. Single-System Development with Reuse. Just Component-Based Development. Just a Reconfigurable Architecture. Releases and Versions of Single Products. Just a Set of Technical Standards. A Note on Terminology. For Further Reading. Discussion Questions. 2. Benefits. Organizational Benefits. Individual Benefits. Benefits versus Costs. For Further Reading. Discussion Questions. 3. The Three Essential Activities. What Are the Essential Activities? Core Asset Development. Product Development. Management. All Three Together. For Further Reading. Discussion Questions. II. SOFTWARE PRODUCT LINE PRACTICE AREAS. Describing the Practice Areas. Starting versus Running a Product Line. Organizing the Practice Areas. 4. Software Engineering Practice Areas. Architecture Definition. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Architecture Evaluation. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Component Development. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. COTS Utilization. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Mining Existing Assets. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Requirements Engineering. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Software System Integration. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Testing. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Understanding Relevant Domains. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. 5. Technical Management Practice Areas. Configuration Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Data Collection, Metrics, and Tracking. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Make/Buy/Mine/Commission Analysis. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Process Definition. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Scoping. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Technical Planning. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Technical Risk Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Tool Support. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. 6. Organizational Management Practice Areas. Building a Business Case. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Customer Interface Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Developing an Acquisition Strategy. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Funding. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Launching and Institutionalizing. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Market Analysis. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Operations. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Organizational Planning. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Organizational Risk Management. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Structuring the Organization. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. Discussion Questions. Technology Forecasting. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. Training. Aspects Peculiar to Product Lines. Application to Core Asset Development. Application to Product Development. Specific Practices. Practice Risks. For Further Reading. Discussion Questions. III. PUTTING THE PRACTICE AREAS INTO ACTION. 7. Software Product Line Practice Patterns. The Value of Patterns. Software Product Line Practice Pattern Descriptions. The Curriculum Pattern. The Essentials Coverage Pattern. Each Asset Pattern. What to Build Pattern. Product Parts Pattern. Assembly Line Pattern. Monitor Pattern. Product Builder Pattern. Cold Start Pattern. In Motion Pattern. Process Pattern. Factory Pattern. Other Patterns. Practice Area Coverage. Discussion Questions. 8. Product Line Technical Probe. What Is the Product Line Technical Probe? Probe Interview Questions. Probe Participants. Probe Process. Using the Probe Results. Conducting a Mini Self-Probe. Discussion Questions. 9. Cummins Engine Company: Embracing the Future. Prologue. Company History. A Product Line of Engine Software. Getting off the Ground. An Organization Structured for Cooperation. Running the Product Line. Results. Lessons Learned. Epilogue. Practice Area Compendium. For Further Reading. Discussion Questions. 10. Control Channel Toolkit: A Software Product Line that Controls Satellites. Contextual Background. Organizational Profiles. Project History. Control Channels. Launching CCT. Developing a Business Case for CCT. Developing the Acquisition Strategy and Funding CCT. Structuring the CCT Organization. Organizational and Technical Planning. Operations. Engineering the CCT Core Assets. Domain Analysis. Architecture. Component Engineering. Testing: Application and Test Engineering. Sustainment Engineering: Product Line Evolution. Documentation. Managing the CCT Effort. Early Benefits from CCT. First CCT Product. Benefits beyond CCT Products. Lessons and Issues. Tool Support Is Inadequate. Domain Analysis Documentation Is Important. An Early Architecture Focus Is Best. Product Builders Need More Support. CCT Users Need Reuse Metrics. It Pays to Be Flexible, and Cross-Unit Teams Work. A Real Product Is a Benefit. Summary. For Further Reading. Discussion Questions. 11. Successful Software product Line Development in Small Organization. Introduction. The Early Years. The MERGER Software Product Line. Market Maker Software Product Line Practices. Architecture Definition. Component Development. Structuring (and Staffing) the Organization. Testing. Data Collection and Metrics. Launching and Institutionalizing the Product Line. Understanding the Market. Technology Forecasting. A Few Observations. Effects of Company Culture. Cost Issues. The Customer Paradox. Tool Support. Lessons Learned. Drawbacks. Conclusions: Software Product Lines in Small Organizations. For Further Reading. Discussion Questions. 12. Conclusions: Practices, Patterns and Payoffs. The Practices. The Patterns. The Success Factors. The Payoff. Finale. Glossary. Bibliography. Index.

Software Product Lines: Practices and Patterns

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.

Documenting Software Architectures: Views and Beyond

List of Figures. List of Tables. Preface. Acknowledgments. Reader's Guide. 1. What Is Software Architecture? Architecture as a Vehicle for Communication among Stakeholders. Architecture and Its Effects on Stakeholders. Architectural Views. Architecture Description Languages. Architecture as the Manifestation of the Earliest Design Decisions. Architectural Styles. Architecture as a Reusable, Transferable Abstraction of a System. Summary. For Further Reading. Discussion Questions. 2. Evaluating a Software Architecture. Why Evaluate an Architecture? When Can an Architecture Be Evaluated? Who's Involved? What Result Does an Architecture Evaluation Produce? For What Qualities Can We Evaluate an Architecture? Why Are Quality Attributes Too Vague for Analysis? What Are the Outputs of an Architecture Evaluation? Outputs from the ATAM, the SAAM, and ARID. Outputs Only from the ATAM. What Are the Benefits and Costs of Performing an Architecture Evaluation? For Further Reading. Discussion Questions. 3. The ATAM-A Method for Architecture Evaluation. Summary of the ATAM Steps. Detailed Description of the ATAM Steps. Step 1: Present the ATAM. Step 2: Present the Business Drivers. Step 3: Present the Architecture. Step 4: Identify the Architectural Approaches. Step 5: Generate the Quality Attribute Utility Tree. Step 6: Analyze the Architectural Approaches. Step 7: Brainstorm and Prioritize Scenarios. Step 8: Analyze the Architectural Approaches. Step 9: Present the Results. The Phases of the ATAM. Phase 0 Activities. Phase 1 Activities. Phase 2 Activities. Phase 3 Activities. For Further Reading. Discussion Questions. 4. The Battlefield Control System-The First Case Study in Applying the ATAM. Preparation. Phase 1. Step 1: Present the ATAM. Step 2: Present the Business Drivers. Step 3: Present the Architecture. Step 4: Identify the Architectural Approaches. Step 5: Generate the Quality Attribute Utility Tree. Step 6: Analyze the Architectural Approaches. Phase 2. Step 7: Brainstorm and Prioritize Scenarios. Step 8: Analyze the Architectural Approaches. Step 9: Present the Results. Results of the BCS Evaluation. Documentation. Requirements. Sensitivities and Tradeoffs. Architectural Risks. Summary. Discussion Questions. 5. Understanding Quality Attributes. Quality Attribute Characterizations. Performance. Availability. Modifiability. Characterizations Inspire Questions. Using Quality Attribute Characterizations in the ATAM. Attribute-Based Architectural Styles. Summary. For Further Reading. Discussion Questions. 6. A Case Study in Applying the ATAM. Background. Phase 0: Partnership and Preparation. Phase 0, Step 1: Present the ATAM. Phase 0, Step 2: Describe Candidate System. Phase 0, Step 3: Make a Go/No-Go Decision. Phase 0, Step 4: Negotiate the Statement of Work. Phase 0, Step 5: Form the Core Evaluation Team. Phase 0, Step 6: Hold Evaluation Team Kick-off Meeting. Phase 0, Step 7: Prepare for Phase 1. Phase 0, Step 8: Review the Architecture. Phase 1: Initial Evaluation. Phase 1, Step 1: Present the ATAM. Phase 1, Step 2: Present Business Drivers. Phase 1, Step 3: Present the Architecture. Phase 1, Step 4: Identify Architectural Approaches. Phase 1, Step 5: Generate Quality Attribute Utility Tree. Phase 1, Step 6: Analyze the Architectural Approaches. Hiatus between Phase 1 and Phase 2. Phase 2: Complete Evaluation. Phase 2, Step 0: Prepare for Phase 2. Phase 2, Steps 1-6. Phase 2, Step 7: Brainstorm and Prioritize Scenarios. Phase 2, Step 8: Analyze Architectural Approaches. Phase 2, Step 9: Present Results. Phase 3: Follow-Up. Phase 3, Step 1: Produce the Final Report. Phase 3, Step 2: Hold the Postmortem Meeting. Phase 3, Step 3: Build Portfolio and Update Artifact Repositories. For Further Reading. Discussion Questions. 7. Using the SAAM to Evaluate an Example Architecture. Overview of the SAAM. Inputs to a SAAM Evaluation. Outputs from a SAAM Evaluation. Steps of a SAAM Evaluation. Step 1: Develop Scenarios. Step 2: Describe the Architecture(s). Step 3: Classify and Prioritize the Scenarios. Step 4: Individually Evaluate Indirect Scenarios. Step 5: Assess Scenario Interactions. Step 6: Create the Overall Evaluation. A Sample SAAM Agenda. A SAAM Case Study. ATAT System Overview. Step 1: Develop Scenarios, First Iteration. Step 2: Describe the Architecture(s), First Iteration. Step 1: Develop Scenarios, Second Iteration. Step 2: Describe the Architecture(s), Second Iteration. Step 3: Classify and Prioritize the Scenarios. Step 4: Individually Evaluate Indirect Scenarios. Step 5: Assess Scenario Interactions. Step 6: Create the Overall Evaluation-Results and Recommendations. Summary. For Further Reading. Discussion Questions. 8. ARID-An Evaluation Method for Partial Architectures. Active Design Reviews. ARID: An ADR/ATAM Hybrid. The Steps of ARID. Phase 1: Rehearsal. Phase 2: Review. A Case Study in Applying ARID. Carrying Out the Steps. Results of the Exercise. Summary. For Further Reading. Discussion Questions. 9. Comparing Software Architecture Evaluation Methods. Questioning Techniques. Questionnaires and Checklists. Scenarios and Scenario-Based Methods. Measuring Techniques. Metrics. Simulations, Prototypes, and Experiments. Rate-Monotonic Analysis. Automated Tools and Architecture Description Languages. Hybrid Techniques. Software Performance Engineering. The ATAM. Summary. For Further Reading. Discussion Questions. 10. Growing an Architecture Evaluation Capability in Your Organization. Building Organizational Buy-in. Growing a Pool of Evaluators. Establishing a Corporate Memory. Cost and Benefit Data. Method Guidance. Reusable Artifacts. Summary. Discussion Questions. 11. Conclusions. You Are Now Ready! What Methods Have You Seen? Why Evaluate Architectures? Why Does the ATAM Work? A Parting Message. Appendix A: An Example Attribute-Based Architectural Style. Problem Description. Stimulus/Response. Architectural Style. Analysis. Reasoning. Priority Assignment. Priority Inversion. Blocking Time. For Further Reading. References. Index. 020170482XT10082001

Paul Clements

Papers

Software Architecture in Practice

Software Product Lines: Practices and Patterns

Documenting Software Architectures: Views and Beyond

Evaluating Software Architectures: Methods and Case Studies

Software Architecture in Practice: Addison-Wesley