Software architecture and reuse-an inherent conflict?

Summary form only. Software architecture is loosely defined as the packaging of functions and objects, together with their interface, and control to implement applications in a domain. An accepted model of software reuse consists of taking a library of reusable assets, instituting a reuse process that permits augmentation of the assets in a supportive environment and providing deliverables via a streamlined development process. Classification of reusable libraries aids in packaging of objects/functions. Given the proper consideration at an earlier (architectural) level it is possible to attain large scale reuse. Without well understood constraints there is little possibility of a high degree of reuse. Role separation and constraints provide the needed stability for reuse. One way to view architecture is as a collection of architectural styles and services. An architectural style helps in arranging the components. The services support the non-functional requirements of the architectural styles. Thus to increase reuse the key is to identify a set of styles and services and combine them appropriately. Besides code, other reusable entities include scripts, documents, design, experience, specification, and application system. Reusability of specification often leads to reusable software components. Architectural constraints may dictate what components may be reused and availability of reused entities may enhance the stability of the architecture