Overview of Software Architectures (SA) Barbora Bühnova Faculty of Informatics, Masaryk University Brno, Czech Republic LaSArIS Seminar October 1, 2009 ^SMrS^ Three levels of topics • Concepts = general principles • Technologies = realization of concepts • Tools = support of the technologies This talk discusses • Concepts of software architectures • Topics related to software architectures O Introduction to SA Why software architectures? What is a software architecture? @ Topics of SA Architecture design and evaluation Architectures of Information systems Architectures of Embedded systems Q Component-Based Software Engineering Motivation for CBSE Basic terms and notions Why component-based development? Challenges of component-based development Introduction to SA Component-Based Software Engineering Why software architectures? • How to bridge the gap between requirements and code? overview of Software Architectures (SA) The role of software architecture • System-level abstractions • Coarse-grained structure of the system overview of Software Architectures (SA) d Software Engineering Three core views that need to be described • Module view = system components i.e. computational software units, often concurrent (tasks, threads) • Connector view = communication styles e.g. pipe-and-filter, shared-data, publish-subscribe, client-server (synchronous vs. asynchronous) • Allocation view = mapping to hardware (or software) resources Stakeholder communication • Architecture may be used as a focus of discussion by system stakeholders System analysis • Prediction of the quality attributes of the architecture Large-scale reuse • The architecture may be reusable across a range of systems • Existing components can be considered during design Project planning • Cost estimation, mile-stone organisation, dependency / """"'v> analysis, etc. f \*/ v v n y sott w3 re 3 re n i tect u res. What is a software architecture? @ Topics of SA Architecture design and evaluation Architectures of Information systems Architectures of Embedded systems O Component-Based Software Engineering Motivation for CBSE Basic terms and notions Why component-based development? Challenges of component-based development Architecture design • Developer roles, development process, correctness by construction Architectural patterns • Layers, Peer-to-Peer, Client-Server, Pipe & Filter, ... Middleware architectures • Run-time environments realizing architectural concepts ItMM.TJg^ailig] Modelling of SW architectures • Component, Class, Sequence and Deployment diagrams of Unified Modelling Language (UML) Documenting SW architectures • Interface descriptions Evaluation of SW architectures • Qualitative vs. quantitative properties ^SMrS^ Component-based development • System assembly out of prefabricated components Service-oriented architecture (SOA) • Autonomy of services, loose coupling, interoperability, outsourcing Aspect-oriented architecture • Integration of crosscutting concerns Model-driven architecture (MDA) • M2M transformations and completions \iu^ Embedded control systems • Role of sensors and actuators Software product lines • Families of products with similar core, variation points Dynamic and self-adapting architectures • Reaction to changes in system usage, fault tolerance ^SMrS^ v v n y sott w3 re 3 re n i tect u res. What is a software architecture? © Topics of SA Architecture design and evaluation Architectures of Information systems Architectures of Embedded systems Q Component-Based Software Engineering Motivation for CBSE Basic terms and notions Why component-based development? Challenges of component-based development ťJ.JJ.U.lWlJ.l.fM Mechanical components are all around • Cars assembled from engine, gearbox, wheels, tires, breaks, • Computers assembled from processor, memory, sound card, monitor, keyboard, ... And what about software? \iu^ ťJ.JJ.U.lWlJ.l.fM A software component is a contractually specified building block for software which can be readily composed by third parties without understanding its internal structure. [Reussner] Main characteristics: • Encapsulation • Interfaces (services) • Compositionality • Client anonymity • Ready to use • Black-box reusability InterfaceA provides InterfaceB UML Component (black box) requires —C---> InterfaceC Other characteristics: • Language independence • Platform independence • Configurability ^SMrS^ Component: • Executable run-time entity O- • Described by interfaces (IDL) O— • May contain several classes (hierarchical) • No code available (black-box/grey-box) • Developed separately for reuse • Deployment context changes after compilation Class: • Design-time entity • Source code available (white-box) • In most cases designed for one system • Stable deployment context after compilation Component -c Class -attribute +getAttribute() +setAttribute() ťJ.JJ.U.lWlJ.l.fM A component model defines specific representation, interaction, composition, and other standards for software components. [Heineman and Council!] Existing component models have different views on • What constitutes a component • run-time [COM/.NET, Fractal] VS. design-time [KobrA, SOFA, PCM] • dynamic [EJB, CCM, Darwin] VS. Static [Wright, SOFA] • Description of interfaces (services) • signatures [ejb, com/net, ccm], pre/post-conditions [KobrA] • protocols of valid/performed call sequences [pcm, sofa, Wright] • Component composition • synchronous [Darwin, sofa] vs. asynchronous [ejb, com/.net, ccm] jf X • flat [EJB, COM/.NET, CCM] VS. hierarchical [Fractal, SOFA, Koala, ACME] ment? Component libraries • Faster development • Lower risk Reuse of components • Lower cost • Higher quality Maintainability • Com prehensibi lity • Configurability • Language independence • Flexibility w.r.t component update Store new components Architect ^crrs i\',,Q^ •^^ levelopment General difficulties • Components delivered by different vendors • Components developed for different environments • Component environment changes dynamically Correctness of a single component • Unknown deployment context • Unknown component usage Correctness of a composite system • Independently developed components • No compilation after assembly • Common updates and reconfiguration VsT..^ Introduction to SA Component-Based Software Engineering development The aim of CBSE - Engineering of correct and high-quality component-based systems on the level of O Single component @ Assembly process @ Composite system Development Assembly Analysis & Reconfiguration ^ ]^?p.. Correctness of a component • Context and usage independent/dependent • Component certification • of component properties • of behavioural description Component compatibility • Syntactic - on a signature level • Semantic - guarantee of correct interaction • Automatically generated adaptors and wrappers Component assembly • Components first - assembly of existing components • Architecture first - decomposition of system specification to component specifications, and search for the implementations • Correctness by construction System analysis • Verification of coordination errors • Compositional verification (top-down, bottom-up) • Assume-guarantee verification • Prediction of extra-functional properties (performance, reliability, etc.) Markov-chain analysis Simulation-based methods System evolution • Component update - safe substitutability • Reconfiguration - regression verification and testing ^triS!A> v v n y sott w3 re 3 re n i tect u res. What is a software architecture? >pics of SA Architecture design and evaluation Architectures of Information systems Architectures of Embedded systems »mponent-Based Software Engineering Motivation for CBSE Basic terms and notions Why component-based development? Challenges of component-based development Concepts of Software Architectures • What is a software architecture? • Why software architectures? • What are the topics? Component-Based Software Engineering • What are software components? • Why component-based development? • What are the challenges of CBSE? Thank you for your attention! Any questions? ^SMŕS^