Abstract: 1. Software Architecture and Product Lines. I. THE DESIGNING OF SOFTWARE ARCHITECTURES. 2. Design of Software Architectures. 3. Software Architectural Design: Case Studies. 4. Functionality-Based Architectural Design. 5. Assessing Software Architectures. 6. Transformation of Software Architectures. II. SOFTWARE PRODUCT LINES. 7. Software Product Lines: An Introduction. 8. Software Product Lines: Case Studies. 9. Designing a Product-Line Architecture. 10. Developing Components: Traditional. 11. Developing Components: Object-Oriented Frameworks. 12. Family-Based System Development. 13. Evolving Product-Line Assets. 14. Organizing for Software Product Lines. 15. Industrial Experiences. References. Index.

Abstract: SUMMARY We describe a package of practical tools and libraries for manipulating graphs and their drawings. Our design, which aimed at facilitating the combination of the package components with other tools, includes stream and event interfaces for graph operations, high-quality static and dynamic layout algorithms, and the ability to handle sizable graphs. We conclude with a description of the applications of this package to a variety of software engineering tools. Copyright c 1999 John Wiley & Sons, Ltd.

Abstract: This book is a must-have for all IT professionals facing software development problems on a daily basis. If you are a systems analyst or requirements engineer it will provide an essential, practical guide from the task of identifying the problem to making the descriptions needed to resolve it.

Abstract: The software industry has practiced pair programming (two programmers working side by side at one computer on the same problem) with great success for years, but people who haven't tried it often reject the idea as a waste of resources. The authors demonstrate that using pair programming in the software development process yields better products in less time-and happier, more confident programmers.

Abstract: Most consumer electronics today contain embedded software. In the early days, developing CE software presented relatively minor challenges, but in the past several years three significant problems have arisen: size and complexity of the software in individual products; the increasing diversity of products and their software; and the need for decreased development time. The question of handling diversity and complexity in embedded software at an increasing production speed becomes an urgent one. The authors present their belief that the answer lies not in hiring more software engineers. They are not readily available, and even if they were, experience shows that larger projects induce larger lead times and often result in greater complexity. Instead, they believe that the answer lies in the use and reuse of software components that work within an explicit software architecture. The Koala model, a component-oriented approach detailed in this article, is their way of handling the diversity of software in consumer electronics. Used for embedded software in TV sets, it allows late binding of reusable components with no additional overhead.

Abstract: The production of new management approaches to evolution, leading to understanding of the relationships between technology and business. How can software be designed so that it can easily be evolved? More effective tools and methods for program comprehension for both code and data A better formalism and conceptualisation of 'maintainability'; how do we measure it? The development of a service-based model of software, to replace a product view. better

Abstract: Is there such a thing anymore as a software system that doesn’t need to be secure? Almost every softwarecontrolled system faces threats from potential adversaries, from Internet-aware client applications running on PCs, to complex telecommunications and power systems accessible over the Internet, to commodity software with copy protection mechanisms. Software engineers must be cognizant of these threats and engineer systems with credible defenses, while still delivering value to customers. In this paper, we present our perspectives on the research issues that arise in the interactions between software engineering and security.

Abstract: Testing is an important process that is performed to support quality assurance. Testing activities support quality assurance by gathering information about the nature of the software being studied. These activities consist of designing test cases, executing the software with those test cases, and examining the results produced by those executions. Studies indicate that more than fty percent of the cost of software development is devoted to testing, with the percentage for testing critical software being even higher. As software becomes more pervasive and is used more often to perform critical tasks, it will be required to be of higher quality. Unless we can nd ecient ways to perform eective testing, the percentage of development costs devoted to testing will increase signicantly. This report briefly assesses the state of the art in software testing, outlines some future directions in software testing, and gives some pointers to software testing resources.

Abstract: Software metrics as a subject area is over 30 years old, but it has barely penetrated into mainstream software engineering. A key reason for this is that most software metrics activities have not addressed their most important requirement: to provide information to support quantitative managerial decision-making during the software lifecycle. Good support for decision-making implies support for risk assessment and reduction. Yet traditional metrics approaches, often driven by regression-based models for cost estimation and defects prediction, provide little support for managers wishing to use measurement to analyse and minimise risk. The future for software metrics lies in using relatively simple existing metrics to build management decision-support tools that combine different aspects of software development and testing and enable managers to make many kinds of predictions, assessments and trade-offs during the software life-cycle. Our recommended approach is to handle the key factors largely missing from the usual metrics approaches, namely: causality, uncertainty, and combining different (often subjective) evidence. Thus the way forward for software metrics research lies in causal modelling (we propose using Bayesian nets), empirical software engineering, and multi-criteria decision aids.

Abstract: Since early 1980 an exponential blowup of cellular mobile systems has been observed, which has produced, all over the world, the definition of a plethora of analog and digital standards. In 2000 the industrial competition between Asia, Europe, and America promises a very difficult path toward the definition of a unique standard for future mobile systems, although market analyses underline the trading benefits of a common worldwide standard. It is therefore in this field that the software radio concept is emerging as a potential pragmatic solution: a software implementation of the user terminal able to dynamically adapt to the radio environment in which it is, time by time, located. In fact, the term software radio stands for radio functionalities defined by software, meaning the possibility to define by software the typical functionality of a radio interface, usually implemented in TX and RX equipment by dedicated hardware. The presence of the software defining the radio interface necessarily implies the use of DSPs to replace dedicated hardware, to execute, in real time, the necessary software. In this article objectives, advantages, problem areas, and technological challenges of software radio are addressed. In particular, SW radio transceiver architecture, possible SW implementation, and its download are analyzed.

Abstract: Computer simulations provide a framework for exploring the biomechanics of movement. The authors have developed a software system that lets users create computer graphics simulations of human and animal movement. This software provides a platform on which the biomechanics community can build a library of simulations that can be exchanged, tested and improved through multi-institutional collaboration.

Abstract: An approach to software performance testing is discussed. A case study describing the experience of using this approach for testing the performance of a system used as a gateway in a large industrial client/server transaction processing application is presented.

Abstract: The software clustering literature contains many different approaches that attempt to automatically decompose software systems. These approaches commonly utilize criteria or measures based on principles such as high cohesion and low coupling, information hiding etc. We present an algorithm that subscribes to a philosophy targeted towards program comprehension and based on subsystem patterns. We discuss the algorithm's implementation and describe experiments that demonstrate its usefulness.

Abstract: For the past 40 years, the techniques, processes and methods of software development have been dominated by supply-side issues, giving rise to a software industry oriented towards developers rather than users. To achieve the levels of functionality, flexibility and time-to-market required by users, a radical shift is required in the development of software, with a more demand-centric view, leading to software which will be delivered as a service within the framework of an open marketplace. Already, there are some signs that this approach is being adopted by industry, but in a very limited way. We summarise research and a research method which has resulted in a long-term strategic view of software engineering innovation. Based on this foundation, we describe more recent work, which has resulted in an innovative demand-side model for the future of software. We propose a service architecture in which components may be bound instantly, just at the time they are needed, and then the binding may be discarded. A major benefit of this approach is that it leads to highly flexible and agile software that should be able to meet rapidly changing business needs.

Abstract: This book is published as part of ACM Press Books a collaboration between the Association for Computing (ACM) and Addison Wesley Longman Limited. ACM is the oldest and largest educational and scientific society in the information technology field. Through its high-quality publications and services, ACM is a major force in advancing the skills and knowledge of IT professionals throughout the world. For further information about ACM, contact:

Abstract: vii 1 Nothing New Under the Sun? 1 2 Software Component Technology 3 Summary of Key Points 5 3 Vision Statement 7 Summary of Key Points 8 4 Components 9 Summary of Key Points 10 5 Interfaces 11 5.1 Interface Abstraction and Application Programming Interfaces 11 5.2 Extending APIs to Extra-Functional Properties 12 5.2.1 Specifying Behavior 12 5.2.2 Specifying Synchronization 13 5.2.3 Specifying Quality of Service 13 5.3 Credentials 14 5.4 Components and Multiple Interfaces 15 Summary of Key Points 16 6 Contracts 17 6.1 Contracts and Reciprocal Obligations 18 6.2 Two Senses of Contract 20 Summary of Key Points 21 7 Component Models and Frameworks 23 7.1 What are Component Models? 23 7.2 Component Framework 25 7.3 Custom Frameworks and Programmable Middleware 26 Summary of Key Points 28

Abstract: From the Publisher: Don't become a statistic—take control of your software projects and plan for success! Success in all types of organization depends increasingly on the development of customized software solutions, yet more than half of software projects now in the works will exceed both their schedules and their budgets by more than 50%. While some types of overruns remain unpredictable, most can be avoided by sound modeling. COCOMO II provides you with a thorough rework of the classic COCOMO model to address modern software processes and construction techniques along with representative examples of applying the models to key software decision situations. It was calibrated and validated using innovative statistical techniques to fit both expert judgment and 161 carefully collected project data points. The book also introduces emerging COCOMO II extensions for cost and schedule estimation of COTS integration and rapid development. You'll also: Learn firsthand from knowledgeable authors—over 100 person-years of software cost estimation experience Make better software decisions by exploring their cost implications Use the cost and schedule estimates to better plan and control your projects and manage your risks Get started now with the software on the accompanying CD Keep up to date with the authors' Web site Software engineers, managers, and students will all find Software Cost Estimation with COCOMO II an invaluable guide to developing and managing successful software projects on time and under budget. About the CD-ROM The accompanying CD-ROM includes a current copy of COCOMO II,along with demonstration versions of three commercial COCOMO II packages and an extensive documentation suite. All examples from the book are provided live, so you can work them hands on, along with the reading.

Abstract: Software Product Lines are large systems intended for reuse in concrete products. As such these large systems provide reusable architecture and implementation that the individual products have in common. The differences between the product are left open. We refer to these open spots as variability points. In this article we provide a conceptual framework of terminology for the concept of variability and we discuss how variability can be managed in Software Product Lines.

Abstract: Because of our present inability to produce error-free software, software fault tolerance is and will continue to be an important consideration in software systems. The root cause of software design errors is the complexity of the systems. Compounding the problems in building correct software is the difficulty in assessing the correctness of software for highly complex systems. After a brief overview of the software development processes, we note how hard-to-detect design faults are likely to be introduced during development and how software faults tend to be state-dependent and activated by particular input sequences. Although component reliability is an important quality measure for system level analysis, software reliability is hard to characterize and the use of post-verification reliability estimates remains a controversial issue. For some applications software safety is more important than reliability, and fault tolerance techniques used in those applications are aimed at preventing catastrophes. Single version software fault tolerance techniques discussed include system structuring and closure, atomic actions, inline fault detection, exception handling, and others. Multiversion techniques are based on the assumption that software built differently should fail differently and thus, if one of the redundant versions fails, it is expected that at least one of the other versions will provide an acceptable output. Recovery blocks, N-version programming, and other multiversion techniques are reviewed.

Abstract: A pattern is a common solution to a problem that occurs in many different contexts. Patterns capture expert knowledge about “best practices” in software design in a form that allows that knowledge to be reused and applied in the design of many different types of software. Antipatterns are conceptually similar to patterns in that they document recurring solutions to common design problems. They are known as antipatterns because their use (or misuse) produces negative consequences. Antipatterns document common mistakes made during software development as well as their solutions. While both patterns and antipatterns can be found in the literature, they typically do not explicitly consider performance consequences. This paper explores antipatterns from a performance perspective. We discuss performance problems associated with one well-known design antipattern and show how to solve them. We also propose three new performance antipatterns that often occur in software systems.

Abstract: Component-based software development approach is based on the idea to develop software systems by selecting appropriate off-the-shelf components and then to assemble them with a well-defined software architecture. Because the new software development paradigm is very different from the traditional approach, quality assurance (QA) for component-based software development is a new topic in the software engineering community. In this paper, we survey current component-based software technologies, describe their advantages and disadvantages, and discuss the features they inherit. We also address QA issues for component-based software. As a major contribution, we propose a QA model for component-based software which covers component requirement analysis, component development, component certification, component customization, and system architecture design, integration, testing and maintenance.

Abstract: the code is not complete with all the import java.util.*; statements and the like that are needed to actually make the it run. That is why the book is so refreshing, it just uses both as tools to illustrate certain aspects of the software development process. We don't have to put up with tired old graphics hierarchy for explaining inheritance, but there is an interesting example with a watch that uses GPS to determine the time zone the wearer is in and an accident management system for police officers. The examples are taken from software engineering projects courses that were taught at Carnegie-Mellon University. at the end of the book, as the only chapter in part IV \"Starting Over.\" The Testing chapter has a deliberate major error in the diagrams and code, I circled four places it occurs explicitly and two where it occurs implicitly until I hit a page which rather off-handedly informs the reader that there was an error a couple of pages back. I'm afraid that not everyone will catch the error correction, although surely no one believes that March has 32 days in it, do they? I like the style of writing and the balance of text and diagrams in this book, and look forward to using it as a textbook soon. Starting up a test suite in the evening, returning the next day to read a pass/fail result indicating that the system is bug-free is the dream of every software tester, and most software developers. After reading Software. Test Automation, one realizes that this dream can only be approached in reality. However, along the way, one learns many practical facts about how to apply automated testing in a useful and effective manner. Software Test Automation is organized into two parts. The first part, \"Techniques for Automating Test Execution consists of eleven chapters that describe how to implement an effective \"test regime, the authors term for a consistent testing environment, policies and procedures, tools, and scripts. The first chapter, \"Test Automation Context, begins by drawing the important distinction between testing and test automation. In their description, testing requires the skill to select a small set of test cases that will uncover the greatest proportion of the defects in the system. Test automation, on the other hand, requires the skills necessary to turn a test case into an automated test case. The quality of a test case …

Abstract: The work described in this paper is an investigation of COTS-based software development within a particular NASA environment, with an emphasis on the processes used. Fifteen projects using a COTS-based approach were studied and their actual process was documented. This process is evaluated to identify essential differences in comparison to traditional software development. The main differences, and the activities for which projects require more guidance, are requirements definition and COTS selection, high level design, integration and testing. Starting from these empirical observations, a new process and guidelines for COTS-based development are developed and briefly presented. The new process is currently under experimentation.

Abstract: Traditionally, software development techniques have been implementation-driven in the sense that the programming paradigm of the day dictated the design and requirements analysis techniques used For example, structured programming led to structured analysis and design techniques in the ‘70s More recently, object-oriented programming gave rise to object-oriented analysis and design In this chapter we explore a software development methodology which is requirements-driven in the sense that the concepts used to define requirements for a software system are also used later on during design and implementation Our proposal adopts Eric Yu's i* framework [1], a modeling framework for early requirements, based on the notions of actor and goal We use these notions as a foundation to model late requirements, as well as architectural and detailed design The proposed framework, named Tropos, seems to complement nicely current proposals for agent-oriented programming platforms

Abstract: Tools and environments to aid developers in producing software have existed, in one form or another, since the early days of computer programming. They are becoming increasingly crucial as the demand for software increases, time-to-market decreases, and diversity and complexity grow beyond anything imagined a few decades ago. In this paper, we briefly review some of the history of tools and environments in software engineering, and then discuss some key challenges that we believe the field faces over the next decade.