Software architecture introduction to the abstraction gssi_nov2013
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Software architecture introduction to the abstraction gssi_nov2013

on

  • 1,102 views

This seminar lecture, provided at the Gran Sasso Science Institute, provides an overview on the role of abstraction in software architectures.

This seminar lecture, provided at the Gran Sasso Science Institute, provides an overview on the role of abstraction in software architectures.

Statistics

Views

Total Views
1,102
Views on SlideShare
1,101
Embed Views
1

Actions

Likes
1
Downloads
25
Comments
0

1 Embed 1

https://twitter.com 1

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

Software architecture introduction to the abstraction gssi_nov2013 Presentation Transcript

  • 1. Università degli Studi dell’Aquila Henry Muccini DISIM, University of L’Aquila henry.muccini@univaq.it, @muccinihenry, henrymuccini.com @Gran Sasso Science Instutitue (GSSI) – Nov. 2013
  • 2. 2 W E E L O C M
  • 3. The material in these slides may be freely reproduced and distributed, partially or totally, as far as an explicit reference or acknowledge to the authors is preserved. Henry Muccini
  • 4. 4 Myself:  Main expertise: Software Architecture Description, verification and validation  Software Architecture:  Guest member of the IFIP WG on Software Architecture  Research on Architecture Description (with MDE)  SA-based Testing:  special Issue on “Software Architecture For Code Testing And Analysis”  PC co-chair of AST 2013 @ ICSE 2013  Director of the TAROT 2013 software testing school  Cooperation with some partner Universities in Spaign and China  Resilience:  SC chair of the SERENE workshop (http://serene.uni.lu/Workshops/)  Co-founder of the ERCIM WG on Resilience  New interests:  Architecting Wireless Sensor Networks  Architecting Mobile-Enabled Systems
  • 5. Research interests on developing methods and tools for the analysis and design of software architectures →Architecture-driven Model-based Testing →Model-checking Architectures →Architecting Fault Tolerant Systems →Interoperable and Multi-view Software Architecture Descriptions Other →Global Software Engineering Education →Architecting Wireless Sensor Network →Model Driven Engineering
  • 6. Software Engineering Software System Engineered Software System
  • 7. Process: Architecture as an artefact Requirements Drives Software Architecture Low Level Design Implementation
  • 8. Process: Architecture towards the process Use Case Model Analysis Model Design Model Depl. Model Impl. Model Test Model Models Views • The architecture includes a collection of views • The architecture is NOT a single fase in the software development process
  • 9. 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 Written according to architectural styles
  • 10. 13 Let us reason about the Gaudi’s Sagrada Familia
  • 11. 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 –” →
  • 12. 15 The power of abstraction…
  • 13. 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
  • 14. Plugin Development Environment Core Runtime Workspace User Interface Workbench Java Development Tools SWT JFace
  • 15. standard standard standard standard laws standard p r o c e s s
  • 16. Privacy e confidentiality Autenticity Need of Standards Shared Process Management Scalability Docs digitalization
  • 17. C2 Ideas Software Architecture synthesis Architectural constraints and requirements Constraints Req1:.. Req2:.. Req3:.. ……… Architectural requirements Evaluation and Decisions making C3 C1 C4 Software Architecture
  • 18. But which Architecture? Implications on privacy, confidentiality, performance, scalability, maintaina
  • 19. But which Architecture? Implications on privacy, confidentiality, performance, scalability, maintaina
  • 20. 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 Written according to architectural styles
  • 21. 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
  • 22. 25 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
  • 23. 26 But, which is the right abstraction!?!
  • 24. 27 the right abstraction…
  • 25. “The practices of recording software, system and enterprise architectures so that architectures can be understood, documented, an alysed and realized.” ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011
  • 26. 29 and, which is the right architecture!?!
  • 27. 30 the right architecture… The one that satisfies at best the requirements and constraints The “less” risky one C2 Ideas Software Architecture synthesis Architectural constraints and requirements Constraints Req1:.. Req2:.. Req3:.. ……… Architectural requirements Evaluation and Decisions making C3 C1 C4 Software Architecture
  • 28. 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 Written according to architectural styles
  • 29. 33 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
  • 30. ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural Description, 2011
  • 31. 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
  • 32. Using multiple views has become standard practice in industry • • IEEE Std 1471 (2000) -> … -> ISO/IEC/IEEE 42010 (2011) Based on a survey we conducted with 48 practitioners [Survey2012], and about the usage of ALs in industry  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)
  • 33. 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 Written according to architectural styles
  • 34. The Classical Style The Californian Style
  • 35. 39 but... why to care?
  • 36. Why to care? All the software systems have an architecture  All the critical/complex systems must have it carefully and explicitly specified Architecture-level decisions impact the scalability, performance, testability, functioning of the produced system Even if the code is perfectly written, a wrong architecture produces a wrong system
  • 37. Why to care? A wrong architecture produces a wrong system   Electronic Voting Systems Bad architecting of FT software:  Tens of thousands of people around the large cities weren’t able to travel by train Thursday morning. No trains from and to Amsterdam and Airport Schiphol from early morning until after the morning rush hour. A failure in the back-up system was the cause. The system therefore didn’t start. And then the signals and switches could not be operated. Both primary and backup failed, hence no operations. (april 2012)  the Interim Report on Causes of the August 14th 2003 Blackout in the US and Canada clearly shows that the problem was mostly caused by badly designed fault tolerance, including various architectural issues: poor diagnostics of component failures, longer-than-estimated time for component recovery, failure to involve all necessary components in recovery, inconsistent system state after recovery, failures of alarm systems. (2003)  Denver Airport
  • 38. Why to care?
  • 39. A bad architecture can imply a spaghetti code system
  • 40. 44 Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture". ACM SIGSOFT Software Engineering Notes 17 (4): 40.doi:10.1145/141874.141884. Garlan & Shaw (1994). "An Introduction to Software Architecture". Retrieved 2012-09-13. ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Systems and software engineering -- Architecture description". Retrieved 2012-09-12. Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50. Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, Third Edition. Addison Wesley, 2012, ISBN 0-321-81573-4 (This book, now in third edition, eloquently covers the fundamental concepts of the discipline. The theme is centered around achieving quality attributes of a system.)