|
Proceedings editors |
|
|
Copyright © 2001 |
|
| All rights reserved | |
|
Proceedings Copyright: The above institutions reserve the rights to reprint the full workshop proceedings. Papers Copyright: The authors reserve the rights to copying, reprint or republication of their respective papers. General Copyright and Reprint Permissions: Abstracting is permitted with credit to the source. |
|
|
The papers in this book comprise the proceedings of the meeting mentioned on the cover and title page. They reflect the authors' opinions and, in the interests of timely dissemination, are published as presented and without change. Their inclusion in this publication does not necessarily constitute endorsement by the editors, the IEEE Computer Society, the Institute of Electrical and Electronics Engineers, Inc., Monash University, or, Carnegie Mellon University. |
|
|
Additional copies may be ordered from |
|
|
Software Engineering Institute |
School of |
|
Editorial production by Judith Stafford and Heinz Schmidt
|
|
Certification of Distributed Component Computing Middleware and Applications -- S. Ghosh and A.P. Mathur
Is Third Party Certification Necessary? -- J.A. Stafford and K.C. Wallnau
Ensuring General-Purpose and Domain-Specific Properties Using Architectural Styles -- D.S. Wile
Experiences with Certification of Reusable Components in the GSN Project in Ericsson, Norway -- P. Mohagheghi and R. Conradi
Protective Wrapping of OTS Components -- P. Popov, L. Strigini, S. Riddle and A. Romanovsky
Issues of CBD Product Quality and Process Quality -- M. Woodman, O. Benediktsson, B. Lefever and F. Stallinger
Component-Based Software Engineering in Pervasive Computing Environments -- D. Garlan and B. Schmerl
Modular Regression Testing: Connections to Component-Based Software -- B.W. Weide
Rule-driven Component Composition for Embedded Systems -- T. Genßler and C. Zeidler
Probability Density Functions in Program Analysis -- D. Mason
Trusted Components: Towards Automated Assembly with Predictable Properties -- H. Schmidt
Component Synthesis Theory: The Problem of Scale -- D. Hamlet
Component Certification and System Prediction: Is There a Role for Formality -- K. Lau
Verifying Component-Based Collaboration Designs -- K. Fisler, S. Krishnamurthi and D. Batory
Towards a Composition Model Problem based on IEC61850 -- O. Preiss and A. Wegmann
Compositional Performance Reasoning -- M. Sitaraman
Third-Party Certification and Its Required Elements -- B. Councill
Documented Quality of COTS and OCM Components -- P. Kallio and E. Niemela
Describing Dependencies in Component Access Points -- M.E.R. Vieira, M.S. Dias and D.J. Richardson
Component Verification and Certification in NASA Missions -- D. Giannakopoulou and J. Penix
Components play a critical role in many software systems. Thus, our ability to reason about the properties of assemblies of components is of great concern to modern system developers. Our ability to understand the functional and extra-functional properties of such systems suffer from:
This fourth Workshop on Component-Based Software Engineering of the International Conference on Software Engineering therefore brings together researchers and practitioners from the areas of
The workshop is open. Submission of position papers was encouraged but was not required for workshop registration. Full papers were reviewed by at least two independent reviewers, many by three. Ultimately only 20 papers were accepted. We plan to invite authors of selected papers to contribute to a special journal issue.
Papers submitted to this workshop are representative of the topics we wished to explore. All papers in this set of proceedings address a number of common issues:
We wish all participants a rewarding and enjoyable time, stimulating open exchange of ideas and sharing of experience and vision.
Finally we would like to thank the members of both the Workshop Program Committee and the unnamed but most helpful contacts of the ICSE Organizing Committees for their effort and support in making this workshop a reality.
Ivica Crnkovic, Heinz Schmidt, Judith Stafford and Kurt
Wallnau
Organizing Committee
April 2001
For the past 7 years, Voas has been quietly pioneering new ways of looking at old problems. Several of Voas's ideas have made it into the software engineering mainstream: (1) the Propagation, Infection, and Execution Analysis (PIE) model, (2) Sensitivity Analysis (a testability model), and (3) the Squeeze Play dependability model. Voas has published over 140 articles and has co-authored two Wiley books: Software Assessment: Reliability, Safety, Testability (1995) and Software Fault Injection: Inoculating Programs Against Errors: Inoculating Programs Against Errors (1998). Voas is writing a new Wiley book on software certification and has co-authored a book chapter on software liability for the "Advances in Computers" book series that will be available in 2000 (Academic Press).
After years of both academic and entrepreneurial experience, Clemens Szyperski has joined Microsoft Research in Redmond, Washington in early 1999, where he works on furthering the principles, technologies, and methods supporting component software. He is the author of the award-winning book "Component Software: Beyond Object-Oriented Programming" (Addison Wesley) and of numerous other publications. He is a frequent speaker at events of both academic and industrial nature. Clemens received his Masters in Electrical Engineering in 1987 from the Aachen Institute of Technology, in Germany. He received his Ph.D. in Computer Science in 1992 from ETH Zurich under the guidance of Niklaus Wirth. After a postdoctoral fellowship at the International Computer Science Institute at UC Berkeley, he was tenured as associate professor at the Queensland University of Technology, Australia, where he continues to hold an adjunct professorship. He is a cofounder of Oberon Microsystems, Inc., Zurich, with its recent spin-off, esmertec inc, also Zurich.
David Garlan is an Associate Professor in the School of Computer Science at Carnegie Mellon University, where he heads the ABLE Project, and is a Principle Investigator on the Aura Project. He received his Ph.D. from Carnegie Mellon University in 1987. Dr. Garlan's research interests include software architecture, ubiquitous computing, formal methods, and software development environments. Dr. Garlan is one of the founders of the field of software architecture. His research group has developed a number of languages and tools for design of software architectures including: Wright (a formal language for software architectures that focuses on specification and analysis of component interactions), Aesop (a design environment for software architecture, supporting rapid customization to architectural styles), and Acme (a language for interchange of architectural designs). Dr. Garlan has written dozens of papers on software architecture, and co-authored the book "Software Architecture: Perspectives on an Emerging Discipline".
George Heineman
The primary goal of component-based software engineering (CBSE) is to enable system assemblers to compose systems and applications from software components. The players in this process - component producers and consumers - must naturally understand how CBSE technology will help ensure desired properties in the composed system. There are many properties that developers would like to ensure in the systems they develop, including:
- Performance, security, availability, modifiability, adaptability, nomadicity, survivability, evolvability, responsiveness (Chung and Yu, 1999)
- Reliability, scalability, affordability, understandability, agility, maintainability (Fillman, 1999)
This list is certainly not exhaustive. In this session, we will identify and focus on those relevant system properties that meet the following criteria
- The component producer can include specific information regarding the desired property in the component's descriptive documentation.
- The component assembler can verify at design time, hopefully with tool assistance, that the resultant composition of components ensures the system property to an appropriate degree.
- Once the final system is complete, it must be possible to verify the existence of the desired property.
Certainly, the implementation of a component itself is greatly responsible for ensuring a property, but we must also include the component model to which the component conforms. The major component models - EJB, COM+, CORBA CCM - all enable component assembly, but they do not declare the properties that they guarantee. These component models all provide some form of transaction and security support, enabled by the specific component model implementation provided by a vendor, such as BEA Systems, Microsoft, or Iona. In the first session paper, "Certification of Distributed Component Computing Middleware and Applications",
Sudipto Ghosh and Aditya Mathur discuss the issues in certifying applications built to the CORBA Component Model (CCM). There will certainly be a need to reconcile local certification, the verification that an individual component satisfies a specific property, with middleware certification. Because CORBA has many possible vendor implementations, it is possible that a specific CORBA application will guarantee a property with one vendor's implementation, but not another's.
David Wile, in "Ensuring General-purpose and Domain-specific Properties using Architectural Styles", raises the issue of validating a set of desired properties in concert with each other, rather than in isolation. He aims to identify composition principles for software architecture styles, a common theme from the software architecture community. We will discuss ways in which properties compose with each other.
We close this session with a paper from Judith Stafford and Kurt Wallnau, "Is Third-Party Certification Necessary?" The authors propose that it may not be necessary to vest a single dedicated organization with the responsibility of certifying properties of components. In their model, the component itself is packaged within an "\active component dossier" that defines the component credentials and provides test harnesses or benchmarking mechanisms to enable unbiased observers to verify these properties.
The overall goal of this session is to identify a key set of desired properties and better understand the ways in which they are composed with each other. We also will engage discussion in the notion of "ensuring a system property to an appropriate degree". For example, it is not enough to state "security" to be the desired system property because there is an entire spectrum. We will draw inspiration from the use of degrees of isolation from within the database community. We will develop a benchmark component-based system that we can use after the workshop as a focal point for comparing different approaches for ensuring system properties.
Betty Cheng
Reasoning about functional and extra-functional quality attributes of a component-based system generally involves knowledge of specific properties of the assembled components. Several questions come to mind when discussing properties of the individual components as well as properties resulting from their integration. For example, what can we know about the properties of a component when we do not have the context in which the component will be deployed and used? Some properties, such as end-to-end latency, require measurement in a test-harness type environment. Others, such as encryption strength, are properties of the algorithm used by the component. While others, such as potential input-to-output data and control pathways, must be identified from the source code of the component.
The four papers in this session discuss a variety of aspects of component reuse. The common thread that ties all four papers together is the focus on information about individual components that impact the composition and adaptation of the components. The papers describe what information needs to be known about components in order to facilitate CBSD, how to obtain that information, the impact of that information, how to encapsulate that information in terms of wrappers, and how to adapt components to changing environments. One paper also discusses the impact of the software development process on the reusability and composability of components. In this session we will explore these and other issues surrounding our ability to identify, analyze, and measure properties of components in isolation so that they can be composed in predictable, reusable, and useful ways. Three specific questions that we will attempt to address are as follows. How can we and should we certify reusable components (what are the criterion)? What properties of a component will maximize its reusability, composability, and adaptability? Which approach has the most potential benefits in terms of costs: domain-specific or domain-independent components?
Murali Sitaraman
What is compositional reasoning? It is reasoning about the (functionality and performance) behavior of a system using the (functionality and performance) specifications of the components of the system, without a need to examine or otherwise analyze the implementations of those components.
Compositionality is important because it localizes the reasoning process (formal or informal) and makes the process scalable. While informal reasoning and metaphors may work adequately for objects in the small, such as stacks or queues, mathematical specifications and formalizable reasoning are necessary for the approach to scale up to non-trivial systems.
There are several problems in practical and sound compositional reasoning, some of which are summarized here. Others will be explored in the panel discussion. Compositional reasoning demands, by its very definition, that participating components have specifications. One obvious problem is that few academic institutions educate their students in most aspects of specification, and few companies invest in specifying components. A related observation is that an automated or semi-automated compositional reasoning system can work effectively only when software developers (i) are capable of understanding specifications and (ii) are sufficiently skilled to supply the system with such assertions as invariants and progress metrics for loops, and abstraction relations and representation invariants for data abstraction implementations.
Education and training in specification formalisms and their connections to tool support, however, are only a part of the problem. There are serious technical problems as well for both formal and informal reasoning. For example, specification of a "classical" component in a popular programming language (such as C++ or Java) involves capturing \object reference copying" that happens implicitly through parameter passing and explicitly in assignment statements. Compositional reasoning in the presence of aliasing is difficult, if not impossible. The overlapping argument problem is an excellent example that illustrates these difficulties. Eliminating routine aliasing without sacrificing efficient computation, on the other hand, demands use of novel parameter passing techniques such as "call by swapping."
While reasoning about sequential functional behavior alone raises non-trivial questions, compositional reasoning about performance behavior is much more difficult and has barely received any attention. There are no widely accepted techniques for specification and compositional reasoning about concurrent behavior, though aspects of this problem (e.g., real-time analysis) have received more attention.
This session will use a panel format. The following four papers will be represented in this session:
One author of each of the four papers will make an initial statement (not to exceed 10 minutes each), addressing among others, the following questions. These initial statements will be followed by a discussion.
Dave Wile
A primary reason component-based technologies are adopted is that reasoning about component behaviors can be raised to levels of abstraction above machine-, system-, or programming language- representations. A second useful abstraction lies in the definition hierarchy among components. This session will cover three innovative approaches to abstract reasoning about component structure and behavior.
In "Verifying Component-Based Collaboration Designs" Fisler, Krishnamurthi and Batory are concerned with the construction of systems as interacting layers or "collaborations" whose contribution to the whole is abstracted into features of the resulting system. Collaborations provide a composition technology quite orthogonal to conventional component decompositions. The roles each actor in the system plays in the various collaborations form the focus of their specification and verification technology.
In "Component Synthesis Theory: The Problem of Scale," Hamlet argues that the mere fact that components are used in truly large-scale systems changes the nature of the properties one wishes to prove and/or measure. In practice, substantially different abstraction mechanisms are used in large-component reasoning, e.g. average performance or worst-case analysis. This paper seeks a theory for making the connection between the macroscopic and microscopic views of components.
In the somewhat whimsically titled "Component Certification and System Prediction: Is there a Role for Formality?" Lau argues that in some sense component reasoning has been at too abstract a level, in that much information necessary for the use of a component is not revealed by the designers. Moreover, the abstraction process itself is often an after-the-fact activity. As distinguished from hardware components, software components are not designed to well-elaborated principles of design and semantic standards that manifest properties critical to a component's use in a real system.
These papers have many common threads despite little common terminology. Each takes a swipe at conventional abstraction techniques and illustrates how many problems with measuring, modifying, adapting, and using today's technology arise from our overly simplistic view of the nature of abstraction. Each proposes a unique approach to solving these problems and should stimulate lively discussion.
Dimitra Giannakopoulou
A number of issues need to be resolved before a component-based approach can make a significant impact to software development. Methods must be developed that allow measurement and prediction of the functional and non-functional characteristics of a system based on properties of system components. Component suppliers must be able to inform consumers about properties of components in a reliable fashion. What these properties are, whether they are context-independent, how they should be specified, and how precise measurements should be, are all open questions.
Three position papers will initiate discussions in this session. In "Towards a Composition Model Problem Based on IEC61850", Otto Preiss and Alain Wegmann introduce the substation automation domain as an interesting case study for research on component assemblies. The standard IEC61850 defines substation automation functionality based on collaborations of atomic functional units. Quality requirements including performance, reliability, and security must be guaranteed before such systems are assembled. The authors propose to realize functional units as software components, and to assemble specific automation applications by a methodology for predictable component compositions. They present some early results from their work in this domain.
In "Compositional Performance Reasoning", Murali Sitaraman argues that good performance is an essential property of any useful component. It is therefore essential to be able to predict performance characteristics of component assemblies. In this domain, the author identifies difficulties associated with abstraction, precision and parameterization. For example, a precise estimate of the performance of a component would need to be based on the values of the objects it involves, rather than simply their sizes (as in traditional big-O notations). The main question that the author opens for discussion is how to design component-based systems for performance predictability while retaining the benefits of modern software engineering.
Finally, in "Third Party Certification and its Required Elements", Bill Councill discusses the necessary elements for component-based software development to revolutionize software development. The importance of standards is stressed, as a means of facilitating the establishment of contracts between component producers and consumers. Standards should be associated with all phases of the software lifecycle. Third-party certification is presented as a method to establish conformance to standards. Such a systematic approach to component-based software engineering can only be achieved by appropriate education of the parties involved, and a clear assignment of their responsibilities.
Clemens Szyperski
Software components seek to enable composition of software out of independently provided parts. The responsibility for the resulting compositions' meeting of requirements rests on multiple shoulders: each component provider asserts meeting some level of specification and the composer asserts that components were used according to their documented requirements and constraints. Proper specification is at the heart of sound assertions; proper modeling is at the heart of understanding requirements.
This session focuses on several modeling and specification aspects germane to software components, with three selected position papers providing the grounds for discussion. In "Documented Quality of COTS and OCM Components", Pivi Kallio, Eila Niemel provide a general template for documenting software components that considers both the buyer's and the provider's view. The template remains at an informal level, but encourages a certain degree of completeness of information by providing a checklist of points to consider. Information items covered include a diverse range from a component's history to performance characteristics.
In "Describing Dependencies in Component Access Points", Marlon Vieira, Marcio Dias, and Debra Richardson discuss issues related to component dependencies and introduce an approach to describe what can happen (in terms of actions/dependencies) after a particular component's access points (services) are called. Their approach rests on formalizing certain dependency forms in specifications of a component's access points. Using information about the diverse components' access points, they propose to construct dependence graphs, showing components in the nodes and actions in the edges.
Finally, in "Component Verification and Certification in NASA Missions", Dimitra Giannakopoulou and John Penix discuss applications for NASA missions that combine ambitious scientific goals with requirements for high reliability. As a result, verification technologies are taken to and pushed beyond their current limits. Also, to meet tight deadlines, reuse and adaptation of software architectures and components must be incorporated in software development within and across missions. While still at an early stage of their research, they already observe the importance of modularity, an inherent property of truly component-oriented architecture, for purposes of verification.