Architecture Based Evolution of Software Systems [chapter]

Luis Filipe Andrade, José Luiz Fiadeiro
2003 Lecture Notes in Computer Science  
Although architectural concepts and techniques have been considered mainly as a means of controlling the complexity of developing software, we argue, and demonstrate, that they can play a vital role in supporting current needs for systems that can evolve and adapt, in run-time, to changes that occur in the application or business domain in which they operate. techniques have proved useful in taming the complexity of software construction, they cannot cope, on their own, with the levels of
more » ... y required for evolution. Object-oriented techniques such as inheritance and clientship are too "static" and "white box" when it comes to change. The use of inheritance requires us to know, understand, and modify the internals of objects. In many circumstances, this may not be acceptable (e.g. for economic or security reasons) or even possible (in the case of third-party, closed components, e.g. legacy systems). On the other hand, because interactions in object-oriented approaches are based on identities [20] , in the sense that, through clientship, objects interact by invoking specific methods of specific objects (instances) to get something specific done, the resulting systems are too rigid to support the identified levels of agility [40] . Any change on the collaborations that an object maintains with other objects needs to be performed at the level of the code that implements that object and, possibly, of the objects with which the new collaborations are established. See [3] for an expanded explanation around an example. Naturally, object-oriented technology does not prevent more flexible modes of interconnections to be implemented. Design mechanisms that make use of event publishing/subscription through brokers and other well-known patterns [15] have already found their way into commercially available products that support implicit invocation [36] instead of feature calling (explicit invocation). However, solutions based on the use of design patterns or, for that matter, Aspect-Oriented Programming, are not at the level of abstraction in which the need for change arises and needs to be managed. Being mechanisms that operate at the design level, there is a wide gap that separates them from the business modelling levels at which change is better perceived and managed. This conceptual gap is not easily bridged, and the process that leads from the business requirements to the identification and instantiation of the relevant design patterns is not easily documented or made otherwise explicit in a way that facilitates changes to be operated. Once instantiated, design patterns code up interactions in ways that, typically, requires evolution to be intrusive because they were not conceived to be evolvable; as a consequence, most of the times, the pattern will dissolve as the system evolves. Therefore, we need semantic primitives through which interconnections can be externalised, modelled explicitly, and evolved directly as representations of business rules.
doi:10.1007/978-3-540-39800-4_8 fatcat:st6qoyw5nvbgtovjjtexwa3pwi