1 Software Architecture: a Roadmap David 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 Specification Architecture Implementation

4 Roles of Architecture Understanding high level design Reuse component 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 1.Resource usage – power consumption 2.Flexibility – dynamic reconfiguration without interruption 3.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