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 consumption2.Flexibility – dynamic reconfiguration without

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