Software architecture styles families_research_gssi_nov2013

1,177 views
987 views

Published on

This seminar lecture, provided at the Gran Sasso Science Institute, provides an overview on software architecture styles, product lines, and my research

Published in: Education, Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,177
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Software architecture styles families_research_gssi_nov2013

  1. 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. 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
  3. 3. Prescriptive vs descriptive use of an architectural language
  4. 4. The Classical Style The Californian Style
  5. 5. “A set of design rules that identify the kinds of components and connectors that may be used to compose a system or subsystem, together with local or global constraints on the way the composition is done” (Shaw & Clements, 1996) IMP A set of constraints you put on your development to elicit desirable properties from your software architecture. Topological Behavioral Communication-oriented etc. etc.
  6. 6. Architectural styles typically determine four kinds of properties [AAG93]: IMP
  7. 7. Many similarities between patterns and styles But they have come from different communities Differences Architectural Styles Design Patterns Few Many Large-scale system organization Localized, small-scale design solutions
  8. 8. ElevatorSynchronizer ElevatorADT1 ElevatorPanel1 ElevatorSynchronizer ElevatorADT2 ElevatorADT2 ElevatorADT1 ElevatorPanel2 ElevatorPanel1 ElevatorPanel2 Scheduler Scheduler C2 connector C2 component BuildingPanel comm. channel request notification BuildingPanel
  9. 9. 1. The top of a component may be connected to the bottom of a single connector. 2. The bottom of a component may be connected to the top of a single connector. 3. There is no bound on the number of components or connectors that may be attached to a single connector. 4. When two connectors are attached to each other, it must be from the bottom of one to the top of the other. 5. Components can communicate only through connectors
  10. 10. 10
  11. 11. Application Application Presentation Presentation Session Session Transport Transport Network Network Network Network Data Link Data Link Data Link Data Link Physical Physical Physical Physical
  12. 12. Advantages Disadvantages
  13. 13. GLOBAL XCONN XCONN SHELF PERIPHE RAL XCONN1 XCONN1 1..1 1..1 1..2 1..1 1..2 XCONN2 1..1 XCONN2 1..1 1..1 XCONN3 1..1 1..1 1..1 … 1..1 1..1 1..1 … 1..1 XCONN3 1..1
  14. 14. Blackboad style 1..* Controller KS 1..* Blackboard
  15. 15. The Blackboard Style This style is characterized by a central data structure and a collection of components operating on the central data store The Blackboard is characterized by three main types of components (Corkill, 1991): Connector Property
  16. 16. Advantages Disadvantages
  17. 17. Distributed Peer-to-Peer Systems Components Connectors Configurations Computational model
  18. 18. 3-Tier Client/Server Systems (example)
  19. 19. WHAT IS P2P? 3rd: SKYPE
  20. 20. Advantages Disadvantages Distributed state Potential for deadlock, starvation, race conditions, service outages Data marshalling and unmarshalling Proxies and stubs for RPC Legacy wrappers
  21. 21. 22 [Garlan94] Exploiting Style in Architectural Design Environments, David Garlan, Robert Allen and John Ockerbloom. Proceedings of SIGSOFT '94 Symposium on the Foundations of Software Engineering, December 1994. [SC97] A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems, M. Shaw and P. Clements, In Proc. COMPSAC97, 21st Int'l Computer Software and Applications Conference, August 1997, pp. 6-13. [Shaw96] Some Patterns for Software Architectures, M. Shaw, In John Viissides, James O. Coplien, and Norman L. Kerth, editors, Pattern Languages of Program Design 2. AddisonWesley, 1996.
  22. 22. The Software Architecture is the earliest model of the whole software system created along the software lifecycle  A brief Introduction to Product Lines (i.e., families of products)
  23. 23. Product Lines and Product Families Product Line: → This term was introduced by the US community Product Family: → This term originated within a series of European industrial-cooperation projects
  24. 24. Product Line Definition: A software product line is a set of software intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. [P. Clements - L. M. Northrop, 2001] (Software Engineering Institute, CMU)
  25. 25. The general idea… The idea behind a system-family approach is to: → build a new system or application from a common set of assets… ─ A software asset might be a component, known requirements or design elements, models, artifacts that an engineer uses to build or modify a software product… → in the same line (i.e., domain)… ─ pertaining to a general production line of a company
  26. 26. 27 An example
  27. 27. An example • Car product line
  28. 28. Keywords > 1/3 Variability: → Variability is the ability to change or customize a software system [Jan Bosch, 2002] Variation point: A variation point refers to a delayed design decision, i.e., it indicates a specific point in the development or deployment phase of a software system → The intention of designing a variation point into a system is to insert a variant (alternative) at a later phase in the lifecycle →
  29. 29. Keywords > 2/3 Features: Underlying def: a feature groups related requirements → Features are an abstraction mechanism to express variability → Cross-cutting features → FODA: Feature Oriented Domain Analysis →
  30. 30. Keywords > 3/3 Levels: → → Domain Application
  31. 31. Why Product Lines?
  32. 32. 33 Feature Model
  33. 33. Product Lines and Reuse
  34. 34. 35 SPLC Conference
  35. 35. The Software Architecture is the earliest model of the whole software system created along the software lifecycle  Our current research on Architecture Description Languages and Frameworks
  36. 36. 37
  37. 37. 38 ADL = Architecture Description Language = any mode of expression used in an architecture description Informal UML-based Formal
  38. 38. 39 Pro:  of immediate use  perfect for sketching  communicative Cons:  ambiguous  non automated Pro:  not too difficult  same notation for SA and design modeling Cons:  not a 100% fit  tool investment Pro:  formal semantics  computable Cons:  difficult to learn  general lack of tools  prolifetarion But.. What Industry needs from Architectural Languages? I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, A. Tang. IEEE TSE 2012 (pre-print) Main Finding: Introvert versus extrovert nature of architects role ADLs should combine features supporting both communication and disciplined development.
  39. 39. 41
  40. 40. 42 Medvidovic et al. [12] Woods and Hilliard [17] Woods [18] Pandey [19] Hilliard and Rice [20] Clements [21]
  41. 41. 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)
  42. 42. usefulness of ADL features in past and future projects
  43. 43. 47 C1: need of models interoperability  multiple languages are used to describe the architecture of a software system C2: need of extending existing ALs C3: need of creating, storing, re-using, views and Architecture Frameworks C4: need of communicative and analytic AL
  44. 44. S1. DUALLY (dually.di.univaq.it) →An MDE interoperability framework for existing ADLs [TSE2010,SOSYM2012] S2.ByADL (byadl.di.univaq.it) 48 DUALLY supports interoperability among MDE framework for customizing existing ADLs ADLs. One model written in an ADL, can be then automatically [ICSE2010, ECSA2010] transformed into another model conforming to a S3.MEGAF (megaf.di.univaq.it) a change is applied to different ADL. Moreover, if one model in the transformation network, it is →A repository and a framework for creating your architecture descriptionpropagated to all the models. based on different viewpoints/views/concerns →An [ASE2010, WICSA/ECSA2012] S4.WIKI & AL
  45. 45. 49 •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
  46. 46. DUALLY Motivating Example Performance Performance analysis Model PM System ? Security Model Security analysis ?
  47. 47. 53 Tech Foundation: Model Transformations and Weaving Model 2 Model   From design to analysis models From one view to another ADLb ADLa Model 2 Code:   Executable code Simulation code Transformation
  48. 48. 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
  49. 49. S1. DUALLY (dually.di.univaq.it) →An MDE interoperability framework for existing ADLs [TSE2010,SOSYM2012] S2. ByADL (byadl.di.univaq.it) →An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010] MEGAF (megaf.di.univaq.it) ByADL framework for creating your for repository and a is Eclipse-based solution architecture descriptionextending and customizing architecture based on different viewpoints/views/concerns →A [ASE2010, WICSA/ECSA2012] description languages (or, more in →S4.WIKI &general, domain specific modeling AL languages) to adapt an ADL to better fit stakeholders’ concerns.
  50. 50. ByADL (byadl.di.univaq.it) →An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010] PROBLEM SOLUTION current ADLs mostly fail to capture multiple (and varying) stakeholders concerns extending and customizing existing ADLs w.r.t. to domain- & organization- specific concerns
  51. 51. 59 Tech Foundation: Metamodel Composition Metamodels (and models) can be “composed” so to generate a new metamodel (model) MM MMext composition model transformation s MMcomp
  52. 52. S1.DUALLY (dually.di.univaq.it) →An MDE interoperability allows software architects MEGAF framework for existing ADLs to [TSE2010,SOSYM2012] create new and re-usable architecture S2.ByADL (byadl.di.univaq.it) frameworks →An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010] S3.MEGAF (megaf.di.univaq.it) →A repository and a framework for creating your architecture description based on different viewpoints/views/concerns [ASE2010, WICSA/ECSA2012] S4.WIKI & AL
  53. 53. To provide an infrastructure that enables to build reusable architecture frameworks by treating views, viewpoints, concerns as first-class entities. MEGAF is an MDE approach to create new architecture frameworks by means of mechanisms: i. ii. iii. to store, retrieve, and combine existing viewpoints, by properly selecting and reusing models previously defined and resident in MEGAF; to define correspondences among views, viewpoints, stakeholders, system concerns and their elements; to enforce consistency and completeness checks based on defined architectural relationships and rules among elements.
  54. 54. Tech. Foundation: Megamodeling A megamodel can be seen as a map to find and link together all the involved models A megamodel is a kind of model in which elements could represent and/or refer to models or metamodels [Bézivin et al., OOPSLA/GPCE 2004] A megamodel specifies properties and rules governing model construction, including multiple models and metamodels →Models and metamodels are first-class entities →It offers also the possibility to specify relationships between them and to navigate them.
  55. 55. 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
  56. 56. DUALLy byADL MEGAF other engines MEGAF AMMA AM3 AMW EMF ATL
  57. 57. 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

×