Systematic Architecture Design


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The outline of the presentation will begin with an introduction, then the motivation, the SOTA, then our proposal, an NFR #en efar# aware MDD process. And finally the research agenda and the conclusions.
  • To end with the introduction I want to clarify which is the objective of this work.#read blue box#We need to identify these challenges #read answer 1#.#haw# To do so, #read answer 2#.
  • The approaches that not support NFRs can deal with NFRs outside of the process.One way is to Modify the PSM… #read##click# Other way is to modify the M2M… #read##click# the situation is worse if… #read#
  • Many authors said that NFRs and the architecture of the system are very related topics, in fact this conference have a whole dedicated session to architecture. Concretely we think that NFRs are used to make architectural decisions.#click# also we consider as a type of these decisions, the technological decisions. For example a requirement such as #read NFR# will impact on a technological decision.
  • To motivate this work I will use an example about a travel agency with two scenarios. On the one hand ACME luxury that offers vacation packages…In the other hand ACME WW offers…Both scenarios share common functionalities. For example user management…
  • To exemplify the impact of the NFRs in the architecture we will use as example the deployment view. For this view of the architecture we have several configurations e.g. SSC and DBMS separated. And we have several components that can be used with these configurations.
  • #click# In this table we see the relationship between quality attributes and NFRs. Observe that the configurations have concrete values while the components can improve or damage the initial values.#click# in the concrete case of the ACME travel agency. Scalability will determine the use of replication #click# and the Security will determine the use of BDMS separated and Firewall.
  • Here we can see again that different NFRs lead to different software systems.So, Our position.. #read#
  • As I said before, a MDD process should be able to deal with NFRs and also should be able to certify the result is compliant with the specified NFRs.To do this we propose two variants of a process that can deal with NFRs.One is fully automatic and the second one is interactive.
  • The problem of the previous variant is that it is too complex. For this variant we use a standard “pi Ai Em” #click#, a PIM unaware of NFRs.And we use #click# interaction with the user to obtain the NFRs necessary to: first, generate the architecture, and second, generate the PSM.From this point we will have all necessary NFRs to generate the software product.#click# it is important to notice that these are extreme variants, it is more than possible that the best solution is between the two variants.
  • #read##click&read##click&read#
  • In the paper you will find a more exhaustive list of topics that require further research. This is a selection of the most relevant ones.#click&read##click&read##click&read##click&read##click&read##click&read##click&read#
  • Systematic Architecture Design

    1. 1. Systematic Architecture Design  David Ameller <>
    2. 2. Systematic Architecture Design Outline 1. 2. 3. 4. 5. 6. Introduction Motivation example NFR-aware MDD process SAD contributions Arteon Conclusions and future work 2
    3. 3. Systematic Architecture Design 1. INTRODUCTION 3
    4. 4. Systematic Architecture Design 1.1 (Initial) Objective Define a MDD framework that integrates NFRs • Why? – NFRs is one of our topics of interest – It is problem with critical consequences – Most existing MDD approaches do not consider NFRs 4
    5. 5. Systematic Architecture Design 1.2 Main topics Adaptable process MDD NFRs Semi-automatic treatment 5
    6. 6. Systematic Architecture Design 1.3 MDD definition PIM HelloWorld M2M Show() PSM Swing HelloWorld POJO Show() M2T Code JDBC … show() { print(“Hello World”); } … “Model-driven development is simply the notion that we can construct a model of a system that we can then transform into the real thing” S. Mellor et al., “Model-Driven Development”. IEEE Software, 2003. 6
    7. 7. Systematic Architecture Design 1.4 State of practice • NFRs are dealt outside of the MDD process • Modify the PSM, the M2T transformation and the generated code E.g. Modify the code to obtain a service application Longer production, lower reliability, and worse maintenance • Modify the M2M transformation in order to support specific NFRs E.g. Add SOA to the M2M transformation Increases complexity, longer production if new transformation is needed This situation is even worse if we consider the current tool limitations 7
    8. 8. Systematic Architecture Design 1.5 The role of NFRs Many prominent researchers say that NFRs mainly impact on the architecture, more concretely in the decision making process. Security Req. "The system shall detect and report unauthorised data accesses” Architectural decisions Integrability Req. "The system shall keep our current Data Base Management System (DBMS)” Technological decisions 8
    9. 9. Systematic Architecture Design 2. MOTIVATION EXAMPLE 9
    10. 10. Systematic Architecture Design 2. Motivation example (I) • ACME travel agency web portal • We consider two different scenarios: A. ACME luxury offers vacation packages to exotic destinations in 5-star hotels. B. ACME world-wide offers hundreds of packages from other transportation and accommodation sites. 10
    11. 11. Systematic Architecture Design 2. Motivation example (II) • Both scenarios have common functionalities  User management, payment facilities, searches • But some NFRs are different: ACME Luxury ACME World-wide Security “The system shall detect and “The system shall detect and report unauthorised data report unauthorised data accesses” accesses” Scalability Not important, low expected visitors “The system should be prepared to high connection demands to ensure the success of the portal” 11
    12. 12. Systematic Architecture Design 2. Motivation example (III) • Starting the decision making  The type of application • It is a constraint of the system to be a web application  The architecture of the system • In this example, we focus on the deployment view 12
    13. 13. Systematic Architecture Design 2. Motivation example (IV) • Architectural decisions Performance Security Availability Maintenance Scalability Complexity Single-Server Configuration Poor Poor Poor Good Poor Good DBMS separated Firewall Replication Average Good Poor Average Poor Average Neutral Improve Neutral Damage Neutral Damage Improve Neutral Improve Damage Improve Damage The table is based on S. Ceri et al., Designing Data-Intensive Web Applications, 2002. 13
    14. 14. Systematic Architecture Design 2. Motivation example (V) Different NFR specifications lead to different software systems ACME Luxury ACME World-wide Our position is that it should be possible to generate both systems with a MDD process that considers NFRs 14
    15. 15. Systematic Architecture Design 3. NFR-AWARE MDD PROCESS 15
    16. 16. Systematic Architecture Design 3. Our proposal A MDD process should be able to deal with NFRs and should be able to certify that the result is compliant with the initial NFRs Drive NFRs ADs Compliance • We explore two variants of the MDD process:  Automatic and Interactive 16
    17. 17. Systematic Architecture Design 3.1 Automatic NFR-aware MDD • All requirements are specified at PIM level • We propose to use M2M transformations able to deal with NFRs (M2March, M2Mtech) • We propose an intermediate model (PIM/PSM) to reflect architectural decisions made from NFRs • The code (software product) is compliant with the stated NFRs 17
    18. 18. Systematic Architecture Design 3.2 Interactive NFR-aware MDD • The first approach is conceptually sound but may be too complex • In this case PIM is unaware of NFRs • We propose to use human interaction to obtain NFRs (with architectural and technological consequences) • Hybrid approaches are possible 18
    19. 19. Systematic Architecture Design 3.3 Firewall example • Deciding the need of firewall components 19
    20. 20. Systematic Architecture Design 3.4 Benefits of our proposal  NFRs are fully integrated into MDD  No need to modify the code  Architectural decisions depend on NFRs  Knowledge reuse 20
    21. 21. Systematic Architecture Design 3.5 Drawbacks of our proposal New model (PIM/PSM) need to be maintained New transformations are needed We need to maintain the architectural knowledge 21
    22. 22. Systematic Architecture Design 4. SAD CONTRIBUTIONS 22
    23. 23. PIMF+NF M2MArch PIM/PSM F+NF • What do we need to do?  The main effort should be to include architectural design as part of the MDD. M2MTech PSMF+NF M2T He lp t Ar c od rede hiitscc aso e otv cn isa uer l ion raan bos ut d NFRs c ati s tom ces n -au e pro t mi altme Se pttab a re Ad Systematic Architecture Design 4.1 From MDD to Architecture AK MDD Architectural design Need of detailed as part of the process knowledge CodeF+NF 23
    24. 24. 4.2 SAD Overview Systematic Architecture Design PIMNF Context PIMNF SRS NF Human support PIMF M2MArch SAD Architectural decisions Architectural views M2MTech PSMF+NF 24
    25. 25. Systematic Architecture Design 4.2 SAD Overview Context SRSNF Requirements analysis Human support Quality Goals And Constraints Architectural decision-making Architectural decisions 25
    26. 26. Systematic Architecture Design 4.3 Quark method Knowledge acquisition 26
    27. 27. Systematic Architecture Design 4.4 Arteon Arteon Requirements Stakeholder needs Rationale Constraints and goals to fulfill Structural Elements Architectural elements to use MDD Transformations to apply * One of the design principles recommended the separation of ontology concepts in modules Architecture design 27
    28. 28. Systematic Architecture Design 4.5 ArchiTech • Implemented as Eclipse Plugin  To be near the MDD community • Knowledge management is already implemented • We are working now on the Decision-Making part of the tool  As a difference, the tool will use a question-answer mechanism to obtain the non-functional aspects • Implemented by Oriol Collell 28
    29. 29. Systematic Architecture Design 4.6 Empirical studies • “How do Software Architects consider Non-Functional Requirements: A Survey”  Electronic survey, 60 software architects. • “How do Software Architects consider Non-Functional Requirements: An Exploratory Study”  13 semi-structured interviews. • “The role of quality attributes in service-based systems design”  Electronic survey, 31 SOA software architects. • Everis collaboration  9 semi-structured interviews. 29
    30. 30. Systematic Architecture Design 5. ARTEON 30
    31. 31. Systematic Architecture Design 5.1 Introduction AK1 = Design + Decisions + Rationale Ontologybased AK Support System 1Kruchten et al. “Building up and reasoning about architecture knowledge”, 2006. 31
    32. 32. Systematic Architecture Design 5.2 Arteon overview Arteon Requirements Stakeholder needs Rationale Constraints and goals to fulfill Structural Elements Architectural elements to use MDD Transformations to apply * One of the design principles recommended the separation of ontology concepts in modules Architecture design 32
    33. 33. Systematic Architecture Design 5.3 Structural Elements (I) File PHP Apache MySQL 33
    34. 34. Systematic Architecture Design 5.3 Structural Elements (II) Logical File Development PHP Deployment Platform Apache MySQL 34
    35. 35. Systematic Architecture Design 5.3 Structural Elements (III) 35
    36. 36. Systematic Architecture Design 5.3 Structural Elements (IV) Architectural Element Style belong_to * belong_to Architectural Architectural View 1 * Framework * ViewModel Style Variation Component Implementation 36
    37. 37. Systematic Architecture Design 5.3 Structural Elements (V) 3-layer style (Layered style) Web development (Package based) Web deployment (DBMS separated) LAMP (Stack solution) Architectural views have their own styles 37
    38. 38. Systematic Architecture Design 5.3 Structural Elements (VI) Variations: • DAO • Controllers • Replication • OSS DAO and datamapper are not combinable Components: • Class, Layer • Package • Server • Script language Layers are composed by classes 38
    39. 39. Systematic Architecture Design 5.3 Structural Elements (VII) specializes related_to 0..1 * * * Architectural Element Architectural View Architectural Framework { Disjoint } < variation_for 1 Style 1..* < apply_to * * Style Variation * incompatible_with * implementable_with * * Component * * connectable_with * * Implementation * * composable_with < apply_to 39
    40. 40. 5.4 Reasoning module (I) Systematic Architecture Design impose * * Property Decision /set_action_over * Decisional Element * * Architectural Element * { disjoint, complete} Existence Decision * 1..* /have_impact_on Decision /give_value /set_condition 1..* Element Property Quality Attribute * { disjoint, complete} Attribute 40
    41. 41. 5.4 Reasoning module (II) “use only OSS” Systematic Architecture Design impose /have_impact_on Decision * * { disjoint, complete} Property “License” equal “OSS” Existence Decision * 1..* * Element “Apache” Architectural Element Property Decision /set_action_over * Decisional Element “Apache” has the value Element “OSS” for the property “License” * * /give_value /set_condition 1..* Element Property Property “License” Quality Attribute * { disjoint, complete} Attribute 41
    42. 42. Systematic Architecture Design 5.5 Benefits of Arteon Share AK between architects Ontologybased AK Support System Reuse AK between projects Community oriented solution Decision-making guidance More reliability to architecture design 42
    43. 43. Systematic Architecture Design 6. CONCLUSIONS AND FUTURE WORK 43
    44. 44. Systematic Architecture Design 6.1 Conclusions • We have…  Formulated an NFR-aware general process • Explored variations of this process • Compared all different alternatives  Described the SAD role and its contributions • ArchiTech, Arteon, Quark, …  Went into the details of Arteon 44
    45. 45. Systematic Architecture Design 6.2 Future work • Our research agenda includes:  In relation to the presented work • • • • Consider the bottom-up process Include correctness and completeness Implement the key-parts of the framework Modeling NFRs as part of the MDD process  Drive empirical studies to: • Obtain Architectural Knowledge • Understand the architectural design practice (NFRs) • Validate the ontology in a case study 45
    46. 46. Comments and Questions David Ameller <>