article

Formalizing style to understand descriptions of software architecture

Abstract

The software architecture of most systems is usually described informally and diagrammatically by means of boxes and lines. In order for these descriptions to be meaningful, the diagrams are understood by interpreting the boxes and lines in specific, conventionalized ways. The informal, imprecise nature of these interpretations has a number of limitations. In this article we consider these conventionalized interpretations as architectural styles and provide a formal framework for their uniform definition. In addition to providing a template for precisely defining new architectural styles, this framework allows for analysis within and between different architectural styles.

References

  1. ~ALEXANDER, C., ISHIKAWA, S., SILVERSTEiN, M., ~IACOBSON, M., FIKSOLAHL-KiNC, I., AND ANGEL, S. ~1977. A Pattern Language: Towns, Buildm~;~, Constructzon. Oxford Umversity Press, New ~York.Google ScholarGoogle Scholar
  2. ~ALLEN R. AND GARLAN, D. 1992a. A formal approach to software architectures In Proceedings ~oflFIP '92, J. van Leeuwen, Ed. Elsevier Science Publishers, B.V., Amsterdam. Google ScholarGoogle Scholar
  3. ~ALLEN, R. AND GARLAN, D. 1992b. Towards formalized software architectures. Tech Rep ~CMU-CS-92-163, School of Computer Science, Carnegie Me~ilon Univ., Pittsburgh, Pa. July. Google ScholarGoogle Scholar
  4. ~ALLEN, R. ANn GARLAN, D. 1994a. Beyond definition/use: Architectural mterconnection. In ~Proceedtngs of the ACM Interface Definztton Language Worhshop. SIGPLAN Not. 29, 8 Google ScholarGoogle Scholar
  5. ~ALLEN, R. ANn GARLAN, D. 1994b Formalizing architectural connection. In Proceedtngs of the ~16th International Conference on So~~u,are Engtneerzng (Sorrento, Italy). IEEE Computer ~Society Press, Los Alamltos, Calif., 71-80. Google ScholarGoogle Scholar
  6. ~BERRY, G. AND BOUDOL, G. 1992. The chemical abstract machine. Theor. Compztt. Set. 96, ~216-248. Google ScholarGoogle Scholar
  7. ~DARPA. 1990. Proceedzngs of the Workshop on Domain-Spect/~c Software ArclTltecture. Soft- ~ware Engineering Inst. Hidden Valley, Pa.Google ScholarGoogle Scholar
  8. ~EARL, A. 1990. A reference model for computer assisted software engineering envirenment ~frameworks. Tech. Rep. HPL-SEG-TN-90-11, Hewlett Packard Laboratories, Bristol, England ~Aug.Google ScholarGoogle Scholar
  9. ~FREEMAN, P. AND WASSERMAN, A I. 1976. Tutorial o~ So/tware Design Techniques. IEEE ~Computer Society Press, Los Alamitos, Cahf. Google ScholarGoogle Scholar
  10. ~GAMMA, E, HFLM, R., JOHNSON, R., AND VLISSIDES, J. 1994 Design Patterns: Elements of ~Reusable Object-Oriented Design. Addison-Wesley, Reading, Mass. Google ScholarGoogle Scholar
  11. ~GARLAN, D, AND DELISLE, N. 1990. Formal specificahons as reusable frameworks. In VDM '90: ~VDM and Z Formal Methods in Software Development (Kiel, Germany). Lecture Notes in ~Computer Science, vol. 428. Springer-Verlag, Berlin, 150-163. Google ScholarGoogle Scholar
  12. ~GARLAN, D, AND NOTK1N, D. 1991. Formalizing design spaces: Implicit invocation mechanisms. ~In VDM '91: Formal Software Development Methods. Lecture Notes in Computer Science, vol. ~551. Springer-Verlag, Berlin, 31-44. Google ScholarGoogle Scholar
  13. ~GARLAN, D. AND SCOTT, C. 1993. Adding imphcit invocatmn to traditional programming lan- ~guages. {n Proceedtngs o{ the 15th International Con/~rence on So/heare Engtneerlng (Bal- ~timore, Md.). IEEE Computer Society Press, Los Alamitos, Calif. Google ScholarGoogle Scholar
  14. ~G^l~L~d~, D. AND SHAW, M. 1993. An introduction to software architecture. In Advances tn ~Software Engineering and Knowledge E,gineerzng, V. Ambriola and G. Tortora, Eds. World ~Scientific, Singapore, I 39. Also appears as SCS and SEI Tech. Reps. CMU-CS-94-166, ~CMU/SEI-94-TR-21, ESC-TR-94-021.Google ScholarGoogle Scholar
  15. ~GARLAN, D., ALLEN, R., AND OCKERBLOOM, d. 1994. ExploiLing style in architectural design ~environments. In Proceedings of SIGSOFT '94: The 2rid ACM SIGSOFT Symposium ell the ~Foundations of Software Engineerzng. ACM Press, New York, 179-185. Google ScholarGoogle Scholar
  16. ~GARLAN, D,, KAISER, G. E., AND NOTKIN, n. 1992. Using reel abstraction to compose systems. ~IEEE Comput. 25, 6 (June). Google ScholarGoogle Scholar
  17. ~HAYES-RoTH, B, PFL~;C;ER, K., LALANL)^, P., MOmGNOT, P., AND BALABANOWC, M. 1995 A ~domain-specific software architecture for adaptive intelligent systems. IEEE Trans. Softw. ~Eng. 21, 4 (Apr.), 288-301. Google ScholarGoogle Scholar
  18. ~HOARE, C. A. R. 1985. Communzcating Sequential Processes, Prentice-Hall International, ~London. Google ScholarGoogle Scholar
  19. ~INYERARDi, P. AND WOLF, A. 1995. Formal specification and analysis of software architectures ~using the chemmal, abstract machine model. I~EE Trans. So/?w. Eng. 21, 4 (Apr), 373 386. Google ScholarGoogle Scholar
  20. ~LUCKi-I~M, D. C., AUGUSTIN, L. M, KEENNEY, J. J., VERA, J., BRYAN, D., ~D MANN, W. 1995. ~Specification and analysis of system architecture using Rapide IEEE Trans. So/tw En~ 21, 4 ~(Apr.), 336-355. Google ScholarGoogle Scholar
  21. ~MAGEE, J. AND KRAMER, J. 1995. Modelling distributed software architectures. Tech. Rep ~CMU-CS-95-151, Carnegie Mellon Univ., Pittsburgh, Pa.Google ScholarGoogle Scholar
  22. ~METTALA, E. AND GRAHAM, M H 1992. The domain-specific software architecture program ~Tech. Rep. CMU/SEI-92-SR-9, Carnegie Mellon Software Engineering Institute, Pittsburgh, ~Pa. June.Google ScholarGoogle Scholar
  23. ~MORICONI, M, ZIAN, X, AND RIEMENSCHNEIDER, R 1995 Correct architecture refinement. ~IEEE Trans. Softw. Eng. 21, 4 (Apr.), 356 372 Google ScholarGoogle Scholar
  24. ~MORRIS, C. R. AND FERGUSON, C.H. 1993. How architecture wins technolog~v wars Harvard ~Bus. Rev 71, 2 (Mar -Apr.)Google ScholarGoogle Scholar
  25. ~NII, H. P 1986a. Blackboard systems: Pa~t I A/Mag 7, 3, 38 53. Google ScholarGoogle Scholar
  26. ~NII, H.P. 1986b. Blackboard systems: Part 2. A/Meg 7, 4, 62 69Google ScholarGoogle Scholar
  27. ~PERRY, D E. AND WOLf, A.L. 1992. Foundatmns for the study of software architecture. Softw ~Eng. Not 17, 4 (Oct.}, 40-52 Google ScholarGoogle Scholar
  28. ~PREE, W 1995 Design Patterns for Object-Oriented Software Development Addlson-Wesley~ ~Reading, Mass. Google ScholarGoogle Scholar
  29. ~REdes, S 1990. Connecting tools using message passing in the Field Environment. IEEE ~Softw. 7, 4 (July), 57 66. Google ScholarGoogle Scholar
  30. ~SHAW, M. 1989. Larger scale systems require higher level abstractions In Proceedings of the ~5th International Workshop on Software Spec~fzcatmn and Deszgn. So/tw. Eng. Not. 14, 3 ~(May), 143-146. Google ScholarGoogle Scholar
  31. ~SHAW, M AND GARLAN, D. 1995. Formulatmn~ and Formall,~ms zn Software Archztecture ~Lecture Notes m Computer Science. Vol. 1000. Springer-Verlag, Berhn.Google ScholarGoogle Scholar
  32. ~SHAW, M., DELINE, R., KLEIN, D. V., ROSS, T. L., YOUNG, D. M., AND ZELESNIK, G. 1995. ~Abstractions for software architecture and tools to support them. 1EEE Trans. So/tw. Eng. 21, ~4 (Apr), 314-335 Google ScholarGoogle Scholar
  33. ~SPIVEY, J. 1992. The Z Notatmn:A Reference Manual, 2nd ed. Prentice-Hall, Englewood Cliffs, ~NJ Google ScholarGoogle Scholar
  34. ~SULLIVAN, K J. AND NOTKiN, a 1992. Reconciling- environment integration and software ~evolution. ACM Trans Softw. Eng. Method l, 3 (July}, 229-268 Google ScholarGoogle Scholar
  35. ~VESTAL, S. 1994. Mode changes m real-time architecture description language. In Proceedzngs ~of the 2nd Internatmnal Worhs}7op on Co~ll~lgurable D~strLbuted Systeras. IEEE Computer ~Society Press, Los Alamitos, Calif.Google ScholarGoogle Scholar

Index Terms

  1. Formalizing style to understand descriptions of software architecture

            Reviews

            Marian Gheorghe

            Software architecture is an important part of software systems. In this context, the systems are treated as collections of components communicating with each other in different ways and by means of some connections. The architectural descriptions are often informal and diagrammatic, using boxes to represent components and lines for the connections. The diagrams have conventional descriptions associated, but these are ambiguous and imprecise, so the architectural descriptions have serious limitations. In order to overcome these inconveniences, this paper introduces a formal approach for describing the conventional interpretations of the diagrammatic elements as architectural styles. An architectural style is a collection of conventions used to interpret a class of architectural descriptions. The main idea of this formal approach is to associate a formal framework, which maps the syntactic domain of the description into the semantic one, with an architectural style. In this framework, a new style can be defined by instantiating similar sets of definitions. To present this method, the authors first introduce the formal approach of an architectural style by defining the basic syntactic elements: components, connectors, and configurations. Then two architectural styles, pipe-filter and implicit invocation event system, are developed in the defined formal framework. The formal model is defined in the Z specification language. The last part analyzes the benefits of the formal model for software architecture. The author points out that when different formal methods are used, it is important to compute the costs to this process, since it is known that any formal approach increases the costs. The authors believe that their proposed formal approach succeeds. Among other facts, they mention the formal specifications of families of systems rather than individual systems, a set of general theorems applying to all the systems in the family, and the usefulness of the method for investigating a common framework for style specification, allowing for a new style to be specified as an incremental modification of an existing style. The paper ends with an appendix containing some common definitions in Z and some longer proofs and definitions. The paper is a valuable contribution to the formal description of software architecture. It discusses the usefulness of applying formal methods and their advantages and limitations.

            Access critical reviews of Computing literature here

            Become a reviewer for Computing Reviews.

            Comments

            Login options

            Check if you have access through your login credentials or your institution to get full access on this article.

            Sign in

            Full Access

            PDF Format

            View or Download as a PDF file.

            PDF

            eReader

            View online with eReader.

            eReader
            About Cookies On This Site

            We use cookies to ensure that we give you the best experience on our website.

            Learn more

            Got it!