Architectural Mismatch Tolerance

  • Rogério de Lemos
  • Cristina Gacek
  • Alexander Romanovsky
Part of the Lecture Notes in Computer Science book series (LNCS, volume 2677)

Abstract

The integrity of complex software systems built from existing components is becoming more dependent on the integrity of the mechanisms used to interconnect these components and, in particular, on the ability of these mechanisms to cope with architectural mismatches that might exist between components. There is a need to detect and handle (i.e. to tolerate) architectural mismatches during runtime because in the majority of practical situations it is impossible to localize and correct all such mismatches during development time. When developing complex software systems, the problem is not only to identify the appropriate components, but also to make sure that these components are interconnected in a way that allows mismatches to be tolerated. The resulting architectural solution should be a system based on the existing components, which are independent in their nature, but are able to interact in well-understood ways. To find such a solution we apply general principles of fault tolerance to dealing with arch itectural mismatches

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. 1.
    T. Anderson and P. Lee. Fault-Tolerance: Principles and Practice. Prentice-Hall Int. Englewood Cliffs, NJ. 1981.Google Scholar
  2. 2.
    A. Avizienis, J.-C. Laprie, and B. Randell. Fundamental Concepts of Dependability. Technical Report 739. Department of Computing Science. University of Newcastle upon Tyne. 2001.Google Scholar
  3. 3.
    L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison-Wesley. 1998.Google Scholar
  4. 4.
    D. Compare, P. Inverardi, and A.L. Wolf. “Uncovering Architectural Mismatch in Component Behavior”. Science of Computer Programming (33) 2. 1999. pp. 101–131.CrossRefGoogle Scholar
  5. 5.
    F. Cristian. “Exception Handling”. Dependability of Resilient Computers. T. Anderson (Ed.). Blackwell Scientific Publications. 1989. pp. 68–97.Google Scholar
  6. 6.
    R. de Lemos and A. Romanovsky. “Exception Handling in the Software Lifecycle”. International Journal of Computer Systems Science & Engineering 16(2). March 2001. pp. 167–181.Google Scholar
  7. 7.
    R. DeLine. “A Catalog of Techniques for Resolving Packaging Mismatch”. Proceedings of the 5th Symposium on Software Reusability (SSRV9). Los Angeles, CA. May 1999. pp. 44–53.Google Scholar
  8. 8.
    A. Egyed, N. Medvidovic, and C. Gacek. “Component-Based Perspective on Software Mismatch Detection and Resolution”. IEE Proceedings on Software 147(6). December 2000. pp. 225–236.CrossRefGoogle Scholar
  9. 9.
    C. Gacek, A. Abd-Allah, B. Clark, and B. Boehm, “On the Definition of Software Architecture”. Proceedings of the First International Workshop on Architectures for Software Systems-In Cooperation with the 17th International Conference on Software Engineering. D. Garlan (Ed.). Seattle, WA, USA. April 1995. pp. 85–95.Google Scholar
  10. 10.
    C. Gacek. Detecting Architectural Mismatches during System Composition. PhD Dissertation. Center for Software Engineering. University of Southern California. Los Angeles, CA, USA. 1998.Google Scholar
  11. 11.
    D. Garlan, R. Allen, and J. Ockerbloom, “Architectural Mismatch: Why Reuse is so Hard”. IEEE Software 12(6). November 1995. pp. 17–26.CrossRefGoogle Scholar
  12. 12.
    P. Inverardi, A.L. Wolf, and D. Yankelevich. “Checking Assumptions in Component Dynamics at the Architectural Level”. Proceedings of the 2nd International Conference on Coordination Models and Languages. Lecture Notes in Computer Science 1282. Springer, Berlin. September 1997. pp. 46–63.CrossRefGoogle Scholar
  13. 13.
    C. Jones, A. Romanovsky, and I. Welch. A Structured Approach to Handling On-Line Interface Upgrades. Proceedings of the 26th Annual International Computer Software and Applications Conference (COMPSAC 2002). Oxford, UK. August 2002. IEEE CS Press, pp. 1000–1005.Google Scholar
  14. 14.
    J.-C. Laprie. “Dependable Computing: Concepts, Limits, Challenges”. Special Issue of the 25th International Symposium On Fault-Tolerant Computing. IEEE Computer Society Press. Pasadena, CA. June 1995. pp. 42–54Google Scholar
  15. 15.
    N. Medvidovic, D.S. Rosenblum, and R.N. Taylor. “A Language and Environment for Architecture-Based Software Development and Evolution”. Proceedings of the 21st International Conference on Software Engineering (ICSEV9). Los Angeles, CA. May 1999. pp. 44–53.Google Scholar
  16. 16.
    N. Medvidovic and R.N. Taylor. “A Classification and Comparison Framework for Software Architecture Description Languages”. IEEE Transactions on Software Engineering 26(1). 2000. pp. 70–93.CrossRefGoogle Scholar
  17. 17.
    P. Oberndorf, K. Wallnau, and A.M. Zaremski. “Product Lines: Reusing Architectural Assets within an Organization”. Software Architecture in Practice. Eds. L. Bass, P. Clements, R. Kazman. Addison-Wesley. 1998. pp. 331–344.Google Scholar
  18. 18.
    D.E. Perry and A.L. Wolf. “Foundations for the Study of Software Architecture”. SIGSOFT Software Engineering Notes 17(4). 1992. pp. 40–52.CrossRefGoogle Scholar
  19. 19.
    D.S. Roseblum and R. Natarajan. “Supporting Architectural Concerns in Component Interoperability Standards”. IEE Proceedings on Software 147(6). December 2000. pp. 215–223.CrossRefGoogle Scholar
  20. 20.
    M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall. 1996.Google Scholar
  21. 21.
    R.N. Taylor, N. Medvidovic, K.M. Anderson, E.J. Whitehead, J.E. Robbins, K.A. Nies, P. Oreizy, and D.L. Dubrow “A Component-and Message-Based Architectural Style for GUI Software”. IEEE Transactions on Software Engineering 22(6). June 1996. pp. 390–406.CrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2003

Authors and Affiliations

  • Rogério de Lemos
    • 1
  • Cristina Gacek
    • 2
  • Alexander Romanovsky
    • 2
  1. 1.Computing LaboratoryUniversity of Kent at CanterburyUK
  2. 2.School of Computing ScienceUniversity of Newcastle upon TyneUK

Personalised recommendations