Formal approaches to software architecture design thesis presentation

Editor's Notes

• #2: Good evening and good morning. It is good to be here today presenting my thesis Formal Approaches to Software Architecture design. This research focuses at designing software architecture using combination of formal techniques. Let’s get started.
• #3: Today, I am going to start by discussing the background of software architecture design, some of the challenges in design software architecture, then I will present the the research questions that this study aims to answer. After that, we will look at how we can formally model and analyse the architecture design in different aspects and tools that we develop to support the analysis. Then, I will present the second part of this research which focus on utilising the formal analysis of software architecture design in other area such as design smell detection, security analysis and architecture migration. Last,  I will conclude the presentation with the list of contributions and discuss some of the future research directions.
• #4: First of all, let me discuss some of challenges in designing software architecture.
• #5: Software architecture plays an important role in software development as it serves as a starting point when you design a software system. Software architecture is a design but not all design is software architecture. It give a layout of how software system will be contructed such as what component there are, how they are linked and how they are interact to each other. They are usually represented as graphical notation with box and line connecting to each other. They are usually inconsistent and ambiguous Also, It is important to verify the design before they are carried on to the next phase such as making detailed design and implementation. As the mistake or failure in architecture design could cause lots of time and effort to fix.  
• #6: Another challenge is that, As a software architect, when we first design the software system we look into new technology such as cloud and microservice to enhance maintainability and flexibility in development and deployment or we look into enhancing security by adopting blockchain technology. To utilise the benefit of thse new technologies, architect need to apply proper architecture pattern/styles to support them.
• #7: So this research aims to answer the following questions: First, Due to emerging technologies that have been applied to software system, new architecture styles have been invented to incorporate these technologies.  So  in this research we explore how we can formally model software architecture design based on architectural styles applied in modern software systems, as well as how  to extend our approach to support other styles in the future. Second, verifying architecture design usually involve determining the quality attributes. As the verification of attributes such as security and maintainability usually require custom algorithms or metrics specific to the attributes. These custom algorithms are usually hard-coded in the analysis tools that are hard to extend. So we have looked at how formal technique can standardize the verification of these attributes using the formal representation of software architecture design. Third, throughout the software cycle, software need to changed over time. To modernise the software system, the architecture design is usually be changed to apply new architectural styles. Migrating legacy system at the architecture level radically impact the software system, planning is hence a challenging task. So we look at how our approach can support this migration.
• #8: Let’s take a look how our formal analysis of software architecture design looks like.
• #9: This is an overview of our approach, Our approach aims at formalizing the structural and behavioural details of architecture design, in the way that we can use formal methods to process it. In this picture, we formalise the structure to OWL, while the behaviour is formalise to ADL. Then, to verify the design, we use ontology reasoning to process OWL and model checking to process ADL.  This is an overall approach that we appiled to support different tasks in designing software architecture that I will talk about later in this presentation.
• #10: As I previously mention that we have two types of analysis. The first one is structural analysis that is supported by this modelling. We applied OWL to define the modelling. As Designing software architecture can be done in different views. We focus on two views namely C&C and deployment view that architect usually use them to reason the design. In this meta-model, the C&C view has …. and deploy has .. We define these elements as ontology class, as well as the architecture pattern that extend this model to characterise the structural design according ot the pattern With this meta model, we can create the design for specific system by creating ontology individuals based on these classes
• #11: With the ontology representation of architecture design, we can perform checking such as  pattern consistency that checks how design is layouted according to the patterns. Or view consistency to check if the design elements in C&C view and deployment view are consistent. These two checking save much time for architect from manual checking, minimize the human-error.
• #12: Another type of analysis we have is behavioural analysis which is support by this behavioural modelling, we use wright# as an ADL architecture description language toe define the behaviour of architecture elements. Wright# contains similar architecture element to structural modelling such as component, connector, port and role but we focus on defining how these elements interacts to each other. We have development a new module in PAT model checker to support wright# called PAT ADL.  This module has ADL parser which parses the code in Wright# syntax and convert them into objects and later translated to CSP, which PAT model checker can process.
• #13: We perform the behavioural anlaysis by defining the verification properties in Linear Temporal logic. For this analysis we can perform two things. One is functional requirement such as the first sample LTL. It means to check if the system can serve the functional requirement, The second is architecture pattern constainst, to check if the design behave according to the pattern that we apply to the design.
• #14: As many software engineers do not have knowledge of how to use formal methods such as ontology reasoning and model checking that we use. We have developed a graphical user interface tools called Arch Modeller. This tool allow user to draw the diagrams representing the model of architecture design and seamlessly verify it.
• #15: In this research, we mainly evaluate our approach through empirical studies using the design model derived from real-world software systems and open-source projects.  Based on the resuls, We have found that our approach is effective in … In term of performance, we have found that some partterns takes more time that another as they inlcud more roles that have more interaction to other components. 
• #16: Utilisation, This part of my thesis focusing on apply the formal analysis that I just presented to different area, starting with the design smell analysis
• #17: Architecture smells are bad practice applied to the architecture design. They does not cause error in the system but cause add difficulty in maintaining or changing the software system In thesis, we presented sample architecture smells to be detected by our approach. Some can be structurally detected, and some can be behaviourally detected. THere are 3 smells that we perform Structural Analysis - Unused Interface (UI), Lava Flow (LF), Extraneous Adjacent Connector (EA) THere are 4 smells that we perform Behavioural Analysis - Ambiguous Interface (AI), Functional Decomposition (FD), Circular Dependency (CD) Poltergeists (PG).
• #18: This is how we apply formal analysis to detect the design smell. For some smell that can be detected structurally, we define them as onotlogy class with condition to select affected elements according their relationship to other design elements,  some smells that require more complicated relationship, we define it as SWRL rule. For the smell to be detected behaviourally, we enhance the model checking algorithm to add condition that detect supicious interaction caused by the smells. In our work, we implement that in Depth first search of PAT model checker.
• #19: The second work that we utilise our approach is for security anlaysis in the system that applies emerging technologies such as event-based microservice and blockchain.  This is an overall approach, we firstly define the security characteristics as OWL class. The characteristics can be the some security specific chracteristics that architect use them to reason security such as attack sruface, lease priviledge or some vulnerability specifc attack such as DOS and data tampering We then use ontology reasoning to detect those characteristics in thee design.  Then, we use the behavioural analysis to trace how the system can be attacked. 
• #21: WIth the detected vulnerabliitieis, we added the attacker component and generate LTL based on this formula to generate the system trace that show how the system behave when it is attacked.
• #22: The last work we have conducted is applying our approach to support the architectural migration. THe architecture migration happen when you want to modernise the legacy system to support the new technologies. So new pattern need to applied into the design to support such technologies With our approach, it can... Last the evolution path can be generated based on the migration plan
• #23: Once have that the existing (current) architecture and the target architecture that allows new principles and technologies to be utilised. Our approach can then generate the migration plan from the current architecture to the target one.  the models of interim design are created according to the migration process. An interim model represents the architecture design that is partly changed after some migration steps have been performed. the interim models are verified against the functional and architectural constraints to determine whether the interim designs can meet the requirements when some parts of the design are changed. After the models of interim design have been verified, we can derive the evolution path that consists of architectural designs that the system can be safely and incrementally evolved towards the target design.
• #24: When both functional and architectural constraints are proved valid on the interim model, it can be used as a milestone in the evolution path towards the target design. These milestones are where the software system can be safely evolved into before all changes will be complete according to the target design. In our example the interim 7, 9, 15 are proved valid for both functional and architectural constraints so they can be used as stepping stones before the system is completely changed according to the target design.
• #27: There are 11 papers in total including 8 conference proceedings and 3 journals. Most of them are B and A rank venue according to CORE database
• #28: 10 of them have been published and there are 1 paper is under review. There is 1 paper we have nominated for best paper award at ECSA, an A ranked conference in software architecture. This paper is about design refactoring for architecture migration.