Software Architecture: a Roadmap David Garlen

1. Software Architecture: a RoadmapDavid Garlen Roshanak Roshandel Yulong Liu

2. Software Architecture • Design and specification of complex software systems in terms of coarse-grained building blocks • High-level abstraction representing structure, behavior, and key properties of software systems • System’s blueprint • Shaw & Garlen: Elements, their interactions, patterns, constraints • Perry & Wolf: { Elements, Forms, Rational } what? how? why?

3. Architecture Implementation Specification

4. Roles of Architecture • Understandinghigh level design • Reusecomponent libraries, component, framework (domain specific SWA, reference FW, arch. Design patterns) • Construction arch. description: blueprint for components and their dependencies • Evolution separation of concerns (functionality vs. interaction) • Analysis consistency, constraints, dependency, domain specific • Management critical evaluation of arch.  clearer understanding of requirements, implementation and risks

5. Yesterday – 1990’s • Box and lines – ad-hoc • No analysis of consistency of specification • No checking of architecture-implementation consistency • Importance of architecture in industry • recognition of a shared repository of methods, techniques, patterns and idioms (engineering) • exploiting commonalities in specific domains to provide reusable frameworks for product families

6. Today – 10 years later • Architecting A first class activity in software development life cycle • Architecture Description Languages (ADLs) • Product Lines and Standards • Codification and Dissemination

7. ADLs • Formalization • analysis for consistency, completeness, correctness • Conceptual framework and concrete syntax for characterizing SW arch • Tools for parsing, analysis, simulation and code generation • May be tied to particular Architectural Style

8. Example ADLs • C2 : Highly distributed event-based systems • Darwin: Analysis of distributed message passing systems • Meta-H: Design of real-time avionic systems • Rapide: Simulation of architectural design • Wright: formal spec and analysis of interaction between components • SADL, Unicon, Aesop, Adage, …

9. Architectural Style • Vocabulary of component types, connector types, and constraints governing them • pipe-and-filter, layered, C2, blackboard, client-server, GenVoca, event-based • Key determinant of system’s success • What about a style for embedded systems??

10. Architectural Interchange? • ADLs integration • Acme • xADL • UML?

11. Product Lines and Standards • Commonalities across products • Requirements for family of systems and their relationships • Cross-vendor integration standards • HLA framework for distributed simulation • interface standards • formalized and standardized • EJB distributed Java-based enterprise application • vendor neutral interface • ad-hoc

12. Codification and Dissemination • Lack of shared body of knowledge • Standard architectural styles • Identification & documentation of these styles  patterns  engineering • Mismatch analysis (e.g. COTS integration)  identify architectural strategies for bridging mismatches

13. Tomorrow • Build vs. Buy • Network-Centric Computing • Pervasive Computing

14. Build vs. Buy • Key issue in the development of system • Buying + saves development time • may not completely satisfy the need • less under control of the dev. team • Economic pressures to reduce time-to-market changes the balance

15. New trends in SW architecture • Need for industry-wide standards • component-based engineering • Agree on common architectural FW (COM, JavaBeans, CORBA) • architecture-based engineering (HLA, EJB) • New SW subcontracting process • higher standards of architecture conformance (commercial or governmental) • Standardization of notations and tools • architectural modeling (UML, XML)

16. Network-Centric Computing • PC-centric model  Network-centric model • distribution, mobility, resource constraints • riche set of computing and information retrieval services • Closed-system  open-system • mainly static architecture  dynamic architecture • less centralized control (e.g. Internet) • Several new challenges

17. Challenges • Scaling up to the size and variability of the internet • implementation and specification changed • Computing with dynamically-formed, task-specific, coalitions of distributed autonomous resources • manage architecture models at run time • evaluate the properties of components ensembles

18. Challenges (cont.) • Need for architectures that flexibly accommodate commercial application service providers • local & remote computing, billing, security • Need for architectures that allows system composition by end users • unnecessary to be technical experts

19. Pervasive Computing • A large number of devices • Heterogeneous systems • Physical resource and computing power • Challenges • Resource usage – power consumption • Flexibility – dynamic reconfiguration without interruption • Mobility – automated control over the management of computational services for changing environment

20. Conclusion • It is all about the Architecture  • We are sitting in the right class!! • From science to engineering • Still immature but we are on the right track