Software Architecture – An Overview

1. Software Architecture – An Overview • The software architecture of a system is the composition of software components, the structures that interconnect them, and the rules by which they interact and integrate • Software architecture as a style and method of design or strategic policies and patterns that shape a system • Separation of architecture from application design

2. Where Do Architectures Come From? • Architectures are influenced by system stakeholders • Influenced by technical and organizational factors • Customers and end users (cost, performance, platform compatibility, security, modifiability, interoperability with other systems, etc.) • Developing organization. (immediate business, long term business, and organizational structure.) • Background and experience of the architects. • Technical environment (industry standard practices, prevalent SE techniques at the time of development.) • Architecture issues are orthogonal to system functionality or functional requirements.

3. Why is Software Architecture Important • Communication among stakeholders • Represents common high-level abstraction of a system • Early design decisions • Earliest point at which the system to be built can be analyzed • Carry weight that is essential to the cost and success of project • Transferable abstraction of a system • Key to extension, migration and evolution • Basis for large-scale reuse

4. Early Design Decisions • Defines constraints on an implementation • Implementation must be divided into prescribed components, which interact with each other in the prescribed fashion, and each component must fulfill its responsibility to the other components as dictated by the architecture • Dictates organizational structure • As the basis for work-breakdown structure • WBS in turn dictates unit planning, budget, scheduling, inter-team communication channels, configuration control, integration/testing procedures, etc.

5. Early Design Decisions - continued • Inhabits a system’s quality attributes • For large systems, quality attributes are increasingly satisfied in system structure and division of functionality, rather than in its algorithms and data structures • E.g., modifiability depends heavily on modularization, performance on volume and nature of communication between components, reusability on nature of coupling • Architecture alone cannot guarantee the functionality and quality required of the system

6. Early Design Decisions - continued • Predicting system qualities by studying its architecture • Makes it easier to reason about and manage change • Helps in evolutionary prototyping • Potential performance problems can be identified early in the product’s life cycle • The system is executable early on • Helps to reduce potential risk in the project early on

7. Elements of Good Architecture • Manage change and complexity • Adapt to system extensions • Minimize interdependencies among complex modules • Allow reasonable cost estimation

8. CORBA Architectural Advantage • Set clear distinction and coupling between enterprise architecture and application design (next slide) • Helps to separate application software from the underlying infrastructure • Location transparency • Dynamic binding • Abstraction of distributed computing environment • Separates interface from implementation, which allows architecture to be defined independent of how it is implemented • Together, the above allow developers to focus on architecture and business logic, and maintain separation of concerns

9. Coupling of Architectural Design and Implementation

10. Still A Long Way To Go … • Current middleware products are becoming too huge, monolithic systems that are themselves almost the antithesis of a component-based system • To date, ORB implementations are not robust and performance is poor above 10K objects • When middleware products have a lifecycle of 6 months to a few years, how does one build applications with fifteen year lifecycle? How do you even migrate an application to new releases of the same middleware product?

11. More Roadblocks • Service as components? Cross vendor portability and cross ORB service are not solved • System developers and runtime administrators find it very difficult to resolve faults that originate with “black-box” components. • How to ensure system-wide reliability, performance, security, etc beyond single vendor ORB

12. Software Architecture and Composition • CORBA only addresses components, but does not have a standard way to specify connections, constraints, or patterns of interactions • How to insert system-wide non-functional properties into component software architecture • How do we go from the customer’s high-level description of property to specifications that can be mapped to code? • Can we support hard real-time Quality of Service?

13. Less Control In Development • “Buying” means less control on every aspect of a system’s development. • How can this loss of control be reconciled with our desire for quality? • Part of answer lies in the assertion that, for larger systems, quality lives primarily in the architecture • The other part of answer: One must take care to integrate components so that they don’t compromise the architecture and the qualities it helps to manifest

14. Architecture Mismatch • Not all components work together - even if they claim to • Components are often “almost” compatible, where “almost” is a euphemism for not • Components appear to work together - the assembled code compiles and even executes - but the system produces the wrong answer because the components don’t work together as expected • Components that were not developed specifically for your system may not meet all of your requirements • Worse, you may not know if they are suitable or not until your buy them and try them, because component interfaces are notoriously poor at specifying their quality attributes

15. What Should Be In Interface • Interface - assumptions that the components can make about each other • Interface = Provides + Requires (+ side affects) , or Syntax + Semantics • Unfortunately, this definition goes beyond what has become the normal concept of interface in current practice.

16. What Can You Do About Interface Mismatch • Avoid it by carefully specifying and inspecting the components for your system • Detect those cases you have not avoided by carefully qualification of the components • Repair those cases you’ve detected by adapting the components

17. Techniques for Repairing Interface Mismatch • Change the code: often not possible and desirable • Wrappers. • A form of encapsulation whereby some component is encased within an alternative abstraction • Clients access wrapped component services only through an alternative interface provided by the wrapper • Interface translation include: • Translating an element of a component interface into an alternative element • Hiding an element of a component interface • Preserving without change of an element of a component’s interface • CORBA IDL can be used to specify the new interface

18. Techniques for Repairing Interface Mismatch • Bridges • Will translate between some requires assumptions of an arbitrary component to some provides assumptions of some other arbitrary component • Key difference with wrapper: the repair code is independent of any particular component, must be explicitly invoked by some external agent, and is typically a transient process • Typically focus on narrower range of translation than wrappers do • E.g. bridge from postscript generator to PDF display

19. Techniques to Avoid Interface Mismatch • Disciplined approach to specifying as many assumptions about a component’s interface as is feasible • Assertions about the sufficiency of services • Assumptions about environment behavior • Assertions about implementability or resource requirements

20. 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?

21. 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

22. 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?

23. 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

24. 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

25. 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

26. Creating and Selecting an Architecture • 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