1. Software Architecture in the Future 1960s. Assembly languages, subroutines, semicolon as connectors 1970s. Structuring of programs to achieve qualities beyond correct function. Data flow analysis, ER diagrams, info hiding. Modules as building blocks 1980s. Module-based languages, information hiding, and associated methodologies crystallized into concept of objects. 1990s. Object matures. Standard object-based architectures in terms of frameworks. Give standard vocabulary for components leading to new infrastructures, e.g. CORBA. Interchangeable components based on OLE. What’s next?

2. Architecture and Legacy Systems Goal. Making intelligent changes to a system in which an organization has a large investment –Determining the existing architecture of a legacy system –Determine the goal state of a re-engineered architecture –Developing a strategy to migrate the system to the new architecture Migration may involves –re-engineering of parts of the system –wrapping of existing parts to work within a new infrastructure –completely replacing the existing system

3. Architecture Archaeology and Conformance Many systems have no documented architecture at all Architecture is represented in such a way that the relationship between the documentation and the actual system, particularly its source code, is unclear Architectural representations are frequently out of phase with the actual system due to maintenance of the system without a similar effort to maintain the architectural representation Serious problem in assessing architectural conformance - how do we what was designed is what was built?

4. Architectural Conformance Problem Maintenance activities may alter architecture How do we know maintenance operations are not eroding the architecture, breaking down abstractions, bridging layers, compromising information hiding, and so forth? Underlying causes : –System has too many runtime relationships (data flow, control flow, code structure, etc) need to be maintained –Architecture represented in a system’s documentation may not coincide with any of these structures. It frequently describes some ad hoc combination of runtime structures Tools for architectural extraction and conformance (fig 19.1)

5. Achieving an Architecture Plan for quality attributes Having meaningful and quantifiable definitions of various qualities Creating or selecting an architecture based on a set of functional and quality requirements Understanding and measuring tradeoffs involved in any architectural decision

6. Understanding Quality Attributes What does “modifiability” mean? Fundamental problem is lack of suitable models for discussing them. Exception: performance can be discussed, analyzed and measured based on resource availability and resource consumption

7. Creating and Selecting an Architecture Possible approaches and technologies (fig 19.3) Major research area: quantitative architecture evaluation Understanding relationship between requirements and architecture - how a system is “driven” into a certain architectural style family. Expected results: –Taxonomy of systems’ problem spaces –Taxonomy of systems’ context spaces –Taxonomy of systems’ solution spaces