Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)
Upcoming SlideShare
Loading in...5
×
 

Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)

on

  • 443 views

These slides present the needs, challenges, and opportunities in architecture description languages. They have been presented at the Empirical Software Engineering unit, at the University of ...

These slides present the needs, challenges, and opportunities in architecture description languages. They have been presented at the Empirical Software Engineering unit, at the University of Bolzano.
The presentation starts with an introduction to software architecture, then presents some challenges and opportunities in architecture description languages.

Statistics

Views

Total Views
443
Views on SlideShare
443
Embed Views
0

Actions

Likes
0
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013) Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013) Presentation Transcript

  • Università degli Studi dell’Aquila Henry Muccini DISIM, University of L’Aquila henry.muccini@univaq.it, @muccinihenry, henrymuccini.com Seminar lecture @Uni Bozen – Dec 2013
  • 2 Introduction to (Modern) Software Architecture Components and Connectors Design Decisions Views and Viewpoints Architectural Languages Our TSE 2013 Study
  • 3 Research interests On developing methods and tools for the analysis and design of software architectures →Using MDE for Architecture Description: →Interoperable Software Architecture Descriptions → Multi-view Architecture Framework →Extensible Architecture Languages →Nagivation Design of Mobile Applications →Architecting Wireless Sensor Network →Architecting Fault Tolerant Systems →Architecture-driven Model-based Testing →Model-checking Architectures
  • 4 The Software Architecture is the earliest model of the whole software system created along the software lifecycle  A set of components and connectors communicating through interfaces A set of architecture design decisions Focus on set of views and viewpoints
  • 5 Software Architecture definitions Perry and Wolf, ’92 (aspects): →“Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.” →Elements are divided into processing elements, data elements and connection elements Garlan and Shaw, ’93 (elements): Architecture for a specific system may be captured as “a collection of computational components - or simply components - together with a description of the interactions between these components - the connectors –” →
  • 6 Let us reason about the Gaudi’s Sagrada Familia
  • 7 Software Architecture… the power of abstraction…
  • 8 TELECOM ITALIA NETWORK ARCHITECTURE WDM ADM ADM ADM ADM ADM ADM STM-16 Ring ADM ADM ADM WL WL STM-16 Ring ADM ADM ADM ADM ADM ADM National Level ADM STM-4/16 SXA ADM Regional level ADM ADM ADM ADM SXC SXA 4/1 ADM STM-4/16 SXA ADM STM-4/16 STM-1/4 ADM ADM ADM STM-1/4 ADM ADM ADM STM-1/4 ADM ADM Urban Level ADM ADM ADM ADM
  • 9 standard standard standard standard laws standard p r o c e s s
  • 10 Privacy e confidentiality Autenticity Need of Standards Shared Process Management Scalability Docs digitalization
  • 11 But which Architecture? Implications on privacy, confidentiality, performance, scalability, maintaina
  • 12 But which Architecture? Implications on privacy, confidentiality, performance, scalability, maintaina
  • 13 The Software Architecture is the earliest model of the whole software system created along the software lifecycle  A set of components and connectors communicating through interfaces A set of architecture design decisions Focus on set of views and viewpoints
  • 14 Architecture Design Decisions Decisions about: Selected components/interfaces/connectors Distribution/Configuration of components/connectors Expected behavior SA Styles, Patterns and Tactics HW/SW/Deployment and other views Components’ Nesting and sub-systems NF attributes
  • 15 Architecture as a set of design decisions A set of architecture design decisions taken to generate the architecture artifact Design problem subproblem (or issue) sub- problem (or issue) Decision = best option Design option Design option Alternative solutions Problem space Design option Alternative solutions Design option Solution space Decision = best option Best, with respect to some criterion Jansen, A.; Bosch, J., "Software Architecture as a Set of Architectural Design Decisions," Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on , vol., no., pp.109,120, 2005. doi: 10.1109/WICSA.2005.61
  • 16 Notations and Tools Archium: A meta-model and tool developed by Anton Jansen et al ADDSS: a web based tool developed by Rafael Capilla et al AREL: a rationale based model developed by Antony Tang et al DAMSAK: Data Model for Software Architecture Knowledge developed by Babar et al PAKME : a tool that supports DAMSAK SEURAT: Software Engineering using Rationale, which integrates tools for rationale capture, visualization, and use into a standard software engineering environment
  • 17 ADD: what is interesting to discuss? 1. Granularity of design decisions 2. Dependencies among decisions 3. ADD taken in a collaborative way Smrithi Rekha V, and Henry Muccini. A Study on Group DecisionMaking in Software Architecture. To appear @ WICSA 2014 4. ADD that uses genetic algorithms in order to find the optimal solution 5. Evolving ADD
  • 18 The Software Architecture is the earliest model of the whole software system created along the software lifecycle  A set of components and connectors communicating through interfaces A set of architecture design decisions Focus on set of views and viewpoints
  • 19
  • 20 Architectural Views AckRU1 AlarmUR1 User1 Check1 AlarmRS (c) AlarmUR Check Router Nofunc 3 Server AlarmUR2 User2 Check2 AckSR (c) 2 0 Clock AckRU2 Timer 5 1 4
  • 21 ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011
  • 22 RUP 4+1 views Logical View Implementation (Development) View Object Model of Design Static Organization of the Software End-user Functionality Programmers Software management Use Case View Process View Concurrency and Synchronization System integrators Performance Scalability Throughput Conceptual Deployment View System engineering System topology Delivery, installation Communication Software Mapping To Hw Physical
  • 23 The Software Architecture is the earliest model of the whole software system created along the software lifecycle Architecture Languages
  • HOW TO DOCUMENT SOFTWARE ARCHITECTURES?
  • 26 Documenting Software Architecture (how to) Architecture Description Languages (ADLs): any mode of expression used in an architecture description. ADL provides model kinds selected to frame one or more concerns. ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011
  • 27 ADL = Architecture Description Language = any mode of expression used in an architecture description Informal UML-based Formal
  • 28 Pro:  of immediate use  perfect for sketching  communicative Pro:  not too difficult  same notation for SA and design modeling Cons:  ambiguous  non automated Cons:  not a 100% fit  tool investment Pro:  formal semantics  computable Cons:  difficult to learn  general lack of tools  prolifetarion
  • 29 100+ ALs
  • 30 Issues (1/2)  Proliferation of languages for (SA) description  without a clear understanding of their merits and limitations.  Tens of ALs, characterized by slightly different conceptual architectural elements, different syntax, or semantics.  Focussing on a generic or a specific operational domain  Some support automated analysis, some others do not
  • 31 Issues (2/2)  An IDEAL and general purpose ADL is NOT likely to exist   Stakeholder concerns are various, ever evolving, and adapting to changing system requirements. [ISO/IEC/IEEE 42010] Difficult to capture all such concerns with a single, narrowly focused notation.  Architectural languages must be able to focus on “what is needed” by the stakeholders involved in the architecting process.
  • 32
  • 33 Medvidovic et al. [12] Woods and Hilliard [17] Woods [18] Pandey [19] Hilliard and Rice [20] Clements [21]
  • 34 Goal of the study: → to better understand the real needs about using ALs for software architecture modeling in industry ─ RQ1: What are the architectural description needs of practitioners? ─ RQ2: What features typically supported by existing ALs are useful (or not useful) for the software industry? Ivano Malavolta, Patricia Lago, Henry Muccini, Patrizio Pelliccione, Antony Tang: What Industry Needs from Architectural Languages: A Survey. IEEE Trans. Software Eng. 39(6): 869-891 (2013),http://doi.ieeecomputersociety.org/10.1109/TSE.2012.74
  • 35 The study population Participants = 48 ─ 25 interviews ─ 23 on-line questionnaires Localization: 15 countries → USA (9), Sweden (6), Germany (5), Netherlands (5), Canada (4), Australia (4), France (4), Argentina (2), UK (2), Austria (1), Belgium (1), Chile (1), Croatia (1), India (1), Switzerland (1), unknown (1) Number of employees A(0-99) 25% 23% 18% 34% B(100-999) C(1000-4999) D(5000-above)
  • 36
  • 37 Usefulness of ADL features in past and future projects
  • 38 C1: need of communicative and analytic AL C2: need of models interoperability, and extensibility. C3: need of multi-view management C4: need of analysis (especially, extra functional) C5: need of versioning and collaborative work
  • 39 Survey TSE 2013 + Needs and Challenges Models Interoperability Multi View Management Domains Usable & Analytic DSL WSN Group Design Decision Mobile Technical Foundations Metamodel Composition Model Transformation Semantic Wiki DLSs Editors Resilience (DS)Language Extensibility SA-based Testing and MC any Software Architecture Model Weaving Megamodeling MDE
  • 40 communicative analytic Dual role of a software architect:   as communication bridge  the extrovert nature of the architect role and as design and analyst means  realizing its introvert nature also in Kruchten [59] and Hoorn et al. [60] Need to cover a combination of features… Type of needs 25 20 15 10 5 0 Analysis -1 +1 -1 +1 Implementation Communication Design Process Documentation
  • 41 ALs for formal analysis (academic focus)  Analytic and expressive languages, but expensive for industries ALs for communicating DD and solutions (industry focus)  UML as the most used language, but less suitable for analysis Standard notation types 50 40 30 20 10 0 UML only: 24%
  • 42 MDE engine with a “domain-specific, user-usual” input reason on the architecture design Experience so far:  Semantic Wiki <-> MDE  just accepted @ WICSA 2014  Software architects access and record AK Mobile <-> MDE create, acce ss, and tune models continuous alignment Domain-specific knowledge base m1 m2 ... mn
  • 43 implementation idea
  • 44 •Use of different ALs to model or analyze different architectural aspects of a system Bridging the different descriptions to be kept consistent and coherent is of paramount relevance
  • 45 Motivating Example Performance Performance analysis Model PM System ? Security Model Security analysis ?
  • 46 DUALLY (dually.di.univaq.it) →An MDE interoperability framework for existing ADLs [TSE2010,SOSYM2012] 46 DUALLY supports interoperability among ADLs. One model written in an ADL, can be then automatically transformed into another model conforming to a different ADL. Moreover, if a change is applied to one model in the transformation network, it is propagated to all the models.
  • 47 2) Star topology: 1) Full-mesh topology: Other ADLs Darwin/ LTSA ACME AADL SA UML profiles n notations  n (n-1)/2 weaving models Other ADLs A0 Profile SA UML profiles Darwin/ LTSA ACME AADL n notations  n weav. models Consistency of models may be verified in A0
  • 48 Tech Foundation: Model Transformations and Weaving Model 2 Model   From design to analysis models From one view to another ADLb A0 ADLa Model 2 Code:   Executable code Simulation code Transformation
  • 49 A0 extension mechanisms Lost-in-translation Change propagation
  • 50 PROBLEM current ADLs mostly fail to capture multiple (and varying) stakeholders concerns SOLUTION extending and customizing existing ADLs w.r.t. to domain- & organization- specific concerns ByADL (byadl.di.univaq.it) →An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010]
  • 51 o byADL allows to define a new ADL by starting from an existing one and • adding domain specificities, • new architectural views, • new analysis constructs, • fine tuning it new ADL
  • 52 Tech Foundation: Metamodel Composition Metamodels (and models) can be “composed” so to generate a new metamodel (model) MM MMext composition model transformation s MMcomp
  • 53 Composed AF Extended/customized ADL generated in byADL generated in MEGAF St1 VP 1 BPMN VP 2 Darwin/FSP FT MK1 SA UML profiles other ADLs ACME pivot metamodel (A0) AADL xADL DUALLy: an automated approach for ADLs interoperability byADL: an approach to adapt and customize existing ADLs MEGAF: a model-driven infrastructure for building reusable and extensible architecture frameworks
  • 54 DUALLy byADL MEGAF other engines MEGAF AMMA AM3 AMW EMF ATL
  • 55 megaf.di.univaq.it • Preliminary prototype in Eclipse, using megamodeling techniques dually.di.univaq.it • Prototype in Eclipse, using model-driven engineering techniques byadl.di.univaq.it • Prototype in Eclipse, using model-driven engineering techniques
  • 56 C1: need of communicative and analytic AL C2: need of models interoperability, and extensibility. C3: need of multi-view management C4: need of analysis (especially, extra functional) C5: need of versioning and collaborative work
  • RQ3: Which is the role of Viewpoints when architecting a software system? → 85% uses multiple views → Use of multiple views for architectural description. ─ Types of views → 50% of multi view users apply consistency check
  • ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011
  • RQ3: Which is the role of Viewpoints when Type of views architecting a software system? 45 40 35 30 25 20 15 10 5 0 → Use of multiple views for architectural description. ─ Types of views → 50% of multi view users apply consistency check Type of views
  • → About 33% model/focus on relevant system concerns → 43% extended ADLs for adding new views → Tool support Is the focus on modeling the entire system? 45 40 35 30 25 20 15 10 5 0 Yes, but at a very abstract level ─ (tool feature missing: 14% viewpoint) → Additional feature required to ADLs ─ (cross-view consistency) Summary: → Yes in detail Just for some specific viewpoint No, it is too complex Yes, but at a very abstract level Yes in detail Just for No, it is No, the some too used specific complex notation viewpoint does not allow it No, the used notation does not allow it Practitioners use multiple views and others would like to do so. They also apply consistency checking. Better Tool support is required
  • → About 33% model/focus on relevant system concerns → 43% extended ADLs for adding new views → Tool support Extension/customization: how? 45 40 35 30 25 20 15 10 5 0 ─ (tool feature missing: 14% viewpoint) → Additional feature required to ADLs ─ (cross-view consistency) Extension/customization: how? Summary: → Practitioners use multiple views and others would like to do so. They also apply consistency checking. Better Tool support is required
  • 62 Using multiple views has become standard practice in industry • • IEEE Std 1471 (2000) -> … -> ISO/IEC/IEEE 42010 (2011) Based on our survey  85% uses multiple views [Survey2012] “What Industry needs from Architectural Languages: A Survey”, I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, A. Tang (under review)
  • Is analysis perceived as a need when architecting a software system? Need for analysis → Need to analyze an architecture 10% → Most important needs 37% ─ need: 30% ─ Dissadisfaction with ADL: 45% of those needing analysis 63% (the second most important unsatisfactory need was about analysis) → Did you analyse your architecture description produced with the ADL? ─ (did you analyse: 74% is yes, but 32% is manual) ─ (why you analyse: 48% for extra functional) ─ (why not: no value, ADLs too limited/imprecise, ...) yes no blank
  • Is analysis perceived as a need when architecting a software system? Type of needs → 25 Need to analyze an architecture 20 → Most important needs 15 Analysis ─ need: 30% 10 ─ Dissadisfaction with ADL: 45% of those needing it -1 5 -1 +1 Implementation Communication Design Process (the second most important unsatisfactory need was about analysis) +1 0 Documentation ???????? → Did you analyse your architecture description produced with the ADL? ─ (did you analyse: 74% is yes, but 32% is manual) ─ (why you analyse: 48% for extra functional) ─ (why not: no value, ADLs too limited/imprecise, ...)
  • Is analysis perceived as a need when architecting a level of satisfaction software system? → Need to analyze an architecture 35% 45% Satisfied Neutral → Most important needs 20% Not satisfied ─ need: 30% ─ Dissadisfaction with ADL: 45% of those needing analysis (the second most important unsatisfactory need was about analysis) → Did you analyse your architecture description produced with the ADL? ─ (did you analyse: 74% is yes, but 32% is manual) ─ (why you analyse: 48% for extra functional) ─ (why not: no value, ADLs too limited/imprecise, ...)
  • RQ2: Is analysis perceived as a need when architecting a software system? Analysis → → Need to analyze an architecture 26% Most important needs ─ need: 30% ─ Dissadisfaction with ADL: 45% of those needing analysis Yes 74% (the second most important unsatisfactory need was about analysis) → Did you analyse your architecture description produced with the ADL? ─ (did you analyse: 74% is yes, but 32% is manual) ─ (why you analyse: 48% for extra functional) ─ (why not: no value, ADLs too limited/imprecise, ...) No
  • RQ2: Is analysis perceived as a need when architecting a software system? Kind of analyzed properties → Need to analyze an architecture Extra-functional properties 12% → 24% Needs but unsatisfaction with current ADLs 8% 4% ─ need: 30% ─ Dissadisfaction with ADL: 45% of those needing it Functional properties 48% HW/SW integration Behavior No info (the second most important unsatisfactory need was about analysis) → Did you analyse your architecture description produced with the ADL? ─ (did you analyse: 74% is yes, but 32% is manual) ─ (why you analyse: 48% for extra functional) ─ (why not: no value, ADLs too limited/imprecise, ...)
  • RQ2: Is analysis perceived as a need when architecting a software system? → Need to analyze an architecture → Needs but unsatisfaction with current ADLs ─ need: 30% ─ Dissadisfaction with ADL: 45% of those needing it (the second most important unsatisfactory need was about analysis) → Did you analyse your architecture description produced with the ADL? ─ (did you analyse: 74% is yes, but 32% is manual) ─ (why you analyse: 48% for extra functional) ─ (why not: 26%. no value, ADLs too limited/imprecise, ...)
  • 69 20+ years of research, but still a lot to be done to bridge the gap between academic research and industry needs Notation • MDE can be a valuable technological tool, but… Analytic vs Communicative • Known issue… stop the “mine is the best” war!! Multi-view Analysis Empirical studies • Domain models + MDE could be a solution! • A topic that deserves more investigation • Not simply a consistency checking problem • Need of Integration of different functional and extra-functiona approaches • Still little has been done in this domain
  • Università degli Studi dell’Aquila Henry Muccini DISIM, University of L’Aquila henry.muccini@univaq.it, @muccinihenry, henrymuccini.com Seminar lecture @Uni Bozen – Dec 2013