The composition paradox in software architecture

SUMMARY One of the most prominent activities in software architecture design is the partitioning of systems into parts, resulting in architectures decomposed into elements and their relations. This decomposition is important to manage increasingly complex systems. However, complex designs largely driven by decomposition lead to elements with many complex and varied interconnections. The resulting highly coupled structures are harmful for systems that have to be composed from parts with isolated interfaces. Decomposition and composition are complementary activities in software architecture design and equally important to balance cohesion and coupling. Consequently, explicit focus is needed to compose elements into a working system as well as to decompose systems into smaller elements and relations to manage their complexity. Software architectures only designed with decomposition in mind lead to monolithic systems and thus achieve the opposite of what was originally intended. We named this nonintuitive side-efiect of realizing systems the composition paradox. Addressing this composition paradox will lead software architects to decisions that will strike a better balance between partitioning and integrating both monolithic and componentized structures. We explain the composition paradox along the design and assembly of a security system.

[1]  Frederick P. Brooks,et al.  The Mythical Man-Month: Essays on Softw , 1978 .

[2]  Shuyu Li,et al.  A contract-based component model for embedded systems , 2004, Fourth International Conference onQuality Software, 2004. QSIC 2004. Proceedings..

[3]  Ralf Lämmel,et al.  Architectural modifications to deployed software , 2005, Sci. Comput. Program..

[4]  Chung Laung Liu,et al.  Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment , 1989, JACM.

[5]  Dean Leffingwell,et al.  Managing software requirements: a unified approach , 1999 .

[6]  Rene L. Krikhaar,et al.  Software architecture reconstruction , 1999 .

[7]  Jan Bosch Software Variability Management , 2004, SPLC.

[8]  Dionisio de Niz,et al.  Time weaver: a software-through-models framework for embedded real-time systems , 2003 .

[9]  David Garlan,et al.  Documenting software architectures: views and beyond , 2002, 25th International Conference on Software Engineering, 2003. Proceedings..

[10]  R. J. A. Buhr,et al.  Use Case Maps for Object-Oriented Systems , 1995 .

[11]  Kurt C. Wallnau,et al.  Volume III: A Technology for Predictable Assembly from Certifiable Components , 2003 .

[12]  Jian Wu,et al.  A contract-based component model for embedded systems , 2004 .

[13]  Deborah Estrin,et al.  Adaptive Energy-Conserving Routing for Multihop Ad Hoc Networks , 2000 .

[14]  Paul Clements,et al.  Software architecture in practice , 1999, SEI series in software engineering.

[15]  Krzysztof Czarnecki,et al.  Generative programming - methods, tools and applications , 2000 .

[16]  J. H. Lala,et al.  Architectural principles for safety-critical real-time applications , 1994, Proc. IEEE.

[17]  Arvinder Kaur,et al.  Component Based Software Engineering , 2010 .

[18]  Edgar H. Callaway,et al.  Wireless Sensor Networks: Architectures and Protocols , 2003 .

[19]  Paul Clements,et al.  Software Architecture in Practice: Addison-Wesley , 1998 .

[20]  Raghu V. Hudli,et al.  CORBA fundamentals and programming , 1996 .

[21]  Mikael Lindvall,et al.  Evaluating software architectures , 2004, Adv. Comput..

[22]  D. Kalinsky Design patterns for high availability systems , 2005 .

[23]  Martin Fowler Design - Who needs an architect? , 2003, IEEE Software.

[24]  Ken Frazer,et al.  Review of "Managing software requirements, a use case approach by Dean Leffingwell and Don Widrig." Addison-Wesley 2003 , 2004, SOEN.

[25]  Leonard J. Bass,et al.  SAAM: a method for analyzing the properties of software architectures , 1994, Proceedings of 16th International Conference on Software Engineering.

[26]  Bashar Nuseibeh,et al.  Expressing the relationships between multiple views in requirements specification , 1993, ICSE '93.