Antony Tang 1, Ann Nicholson 2, Yan Jin 1, Jun Han 1 1 Faculty of ICT, Swinburne University of Technology 2 School of Computer Science and Software Engineering,

Slides:



Advertisements
Similar presentations
Linking regions and central governments: Indicators for performance-based regional development policy 6 th EUROPEAN CONFERENCE ON EVALUATION OF COHESION.
Advertisements

MDI 2010, Oslo, Norway Behavioural Interoperability to Support Model-Driven Systems Integration Alek Radjenovic, Richard Paige The University of York,
Maintenance Forecasting and Capacity Planning
Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Systems.
Fujitsu Services Oy ETTEI TIETOTEKNIIKKA KÄVISI TYÖSTÄ EVALUATING THE BUSINESS VALUE OF INFORMATION TECHNOLOGY , Janne Laine.
Bayesian Network and Influence Diagram A Guide to Construction And Analysis.
Chapter 6 HCI in the software process. Software engineering and the design process for interactive systems Usability engineering Iterative design and.
By Philippe Kruchten Rational Software
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Quantitative vs. Qualitative Research Method Issues Marian Ford Erin Gonzales November 2, 2010.
Knowledge Engineering for Bayesian Networks
1 Knowledge Engineering for Bayesian Networks Ann Nicholson School of Computer Science and Software Engineering Monash University.
The Architecture Design Process
SE 555 Software Requirements & Specification Requirements Management.
1 Knowledge Engineering for Bayesian Networks Ann Nicholson School of Computer Science and Software Engineering Monash University.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
1 © 1998 HRL Laboratories, LLC. All Rights Reserved Development of Bayesian Diagnostic Models Using Troubleshooting Flow Diagrams K. Wojtek Przytula: HRL.
Knowledge Engineering a Bayesian Network for an Ecological Risk Assessment (KEBN-ERA) Owen Woodberry Supervisors: Ann Nicholson Kevin Korb Carmel Pollino.
Lecture 10 Comparison and Evaluation of Alternative System Designs.
Software Architecture Quality. Outline Importance of assessing software architecture Better predict the quality of the system to be built How to improve.
Measuring User Satisfaction in Virtual Environment Maciej A. Orzechowski Design System and Urban Planning TU/e Workshop Mass Customisation
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Principle of Functional Verification Chapter 1~3 Presenter : Fu-Ching Yang.
What is Software Architecture?
The design process z Software engineering and the design process for interactive systems z Standards and guidelines as design rules z Usability engineering.
Discussion Gitanjali Batmanabane MD PhD. Do you look like this?
CSI315 Web Applications and Technology Overview of Systems Development (342)
1 BTEC HNC Systems Support Castle College 2007/8 Systems Analysis Lecture 9 Introduction to Design.
Chapter 6 : Software Metrics
1 Department of Electrical and Computer Engineering University of Virginia Software Quality & Safety Assessment Using Bayesian Belief Networks Joanne Bechta.
Chapter 6 Use Cases. Use Cases: –Text stories Some “actor” using system to achieve a goal –Used to discover and record requirements –Serve as input to.
Lecture 7: Requirements Engineering
LEVEL 3 I can identify differences and similarities or changes in different scientific ideas. I can suggest solutions to problems and build models to.
1 Introduction to Software Engineering Lecture 1.
The Nature and Kinds of Research Subject matter of course  Class about quantitative research  How is research different from other ways of answering.
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
Software Architectural Assumptions in Software Architecting Chen Yang a,b, Peng Liang a, Paris Avgeriou b a State Key Lab of Software Engineering, Wuhan.
Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU.
Research, Research, Research Understanding the Basics Jim Yonazi, Ph. D The Center for ICT Research and Innovations – C i RI
Copyright Prof. Dr. Shuichiro Yamamoto Prof. Dr. Shuichiro Yamamoto Nagoya University.
From description to analysis
Chapter 1 Introduction n Introduction: Problem Solving and Decision Making n Quantitative Analysis and Decision Making n Quantitative Analysis n Model.
Systems Development Life Cycle
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
SOFTWARE METRICS Software Metrics :Roadmap Norman E Fenton and Martin Neil Presented by Santhosh Kumar Grandai.
1-1 Copyright © 2014, 2011, and 2008 Pearson Education, Inc.
2.2.1 U NDERSTANDINGMANAGEMENT DECISION MAKING AQA Business 2 M ANAGERS, LEADERSHIP AND DECISION MAKING What decisions do managers make: On a day to day.
Copyright (c) 2014 Pearson Education, Inc. Introduction to DBMS.
Chapter Ten: Mixed Methods Procedures. Chapter Outline Components of Mixed Methods Procedures – The Nature of Mixed Methods Research – Types of Mixed.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Using Bayesian Belief Networks in Assessing Software Architectures Jilles van Gurp & Jan Bosch.
CHAPTER 7 Apply Phase. What is Application? The application of the theory to the problem, phenomenon or issue in the world of practice.
Slide 7.1 Saunders, Lewis and Thornhill, Research Methods for Business Students, 5 th Edition, © Mark Saunders, Philip Lewis and Adrian Thornhill 2009.
Decision Support Systems INF421 & IS Introduction To distinguish between normative theories, descriptive studies and prescriptive analysis; To.
P3 Business Analysis. 2 Section F: Project Management F1.The nature of projects F2. Building the Business Case F4. Planning,monitoring and controlling.
Managing Qualitative Knowledge in Software Architecture Assesment Jilles van Gurp & Jan Bosch Högskolan Karlskrona/Ronneby in Sweden Department of Software.
A fault tree – Based Bayesian network construction for the failure rate assessment of a complex system 46th ESReDA Seminar May 29-30, 2014, Politecnico.
© 2008 Thomson South-Western. All Rights Reserved Slides by JOHN LOUCKS St. Edward’s University.
Software Engineering and Best Practices
Unified Process Source & Courtesy: Jing Zou.
HCI in the software process
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
Introduction to Problem Solving
Quantitative vs. Qualitative Research Method Issues
HCI in the software process
HCI in the software process
Human Computer Interaction Lecture 14 HCI in Software Process
Presentation transcript:

Antony Tang 1, Ann Nicholson 2, Yan Jin 1, Jun Han 1 1 Faculty of ICT, Swinburne University of Technology 2 School of Computer Science and Software Engineering, Monash University Using Bayesian Belief Networks for Change Impact Analysis in Architecture Design

Faculty of ICT Page 2 Presentation Outline Background and Objectives Architecture Design Rationale and Decisions Architecture Rationale and Elements Linkage (AREL) Applying Bayesian Belief Networks to AREL Predicting Change Impacts in Architecture Design Tool Support Conclusions and Future Work

Faculty of ICT Page 3 Background There has been little emphasis on the decision making process on software architecture design. Design Rationale (DR) as a result of a decision is often not captured Even when DR is captured, it is often difficult to explain how decisions relate to and affect the architecture design Change impact cannot be systematically reasoned or explained during the maintenance phase It is difficult to quantify the impact of changes in requirement, design or decision

Faculty of ICT Page 4 What is Design Rationale a reason or an intention for a particular set of thoughts or actions (Cambridge Dictionary) reasons to express the purposes of the designed artefacts with their contextual constraints on realising the purposes (Moran and Carroll 1996) recording the history of how a design comes about through recording logical reasoning to support future reference (Conklin and Burgess-Yakemovic 1996)

Faculty of ICT Page 5 Architecture Design Decisions Early Decision Making Consider Multiple Factors including Functional Requirements, Non-Functional Requirements and Environmental Factors Consider Different Perspectives and Viewpoints Directly and Indirectly Influence the Design Structure of the System Create / Modify Design Elements to Satisfy System Goals / Sub-goals

Faculty of ICT Page 6 Problem Statements How to capture design rationale and represent architecture design decisions in relation to design artefacts? What is the change impact to the system when one or more requirements, designs or decisions are to change?

Faculty of ICT Page 7 Architecture Design Rationale and Design Elements (AREL) Architecture Elements (AE) are requirements and design elements in an Architecture. They are grouped by Architecture Viewpoints (Business, Information, Computation and Engineering) A Design Decision Point is supported by Architecture Rationale (AR) which comprises Qualitative Rationale, Quantitative Rationale and Alternative Architecture Rationale  Qualitative Rationale (QuR) contains constraints, assumptions, arguments, risks & non-risks, weakness and benefits  Quantitative Rationale (QaR) contains measurements of costs, benefits and risks relative to alternative designs  Alternative Design Rationale contains QuR and QaR for alternative designs ARs are related to AEs through a causal relationship

Faculty of ICT Page 8 A Simple AREL Structure in UML Notation > AE and AR Dependency > Design Rationale Encapsulation > Qualitative Rationale Quantitative Rationale Qualitative Rationale Quantitative Rationale Alternative Design & Use Cases

Faculty of ICT Page 9 An AREL Example Input AEs into AR1 Decision supported by AR1 AE as Outcome of AR1 Input AEs into AR3 Decision supported by AR3 Outcome AE of AR3 Note: UML Drawings are created by Enterprise Architect

Faculty of ICT Page 10 Applying Bayesian Belief Networks to AREL Causal Relationship of a decision set AE-AR-AE AE states: Stable / Volatile (indicate the volatility of a requirement or a design object) AR states: Valid / Invalid (indicate the validity of a decision) Root node AE1 contains Prior Probabilities AR1 is conditionally dependent on AE1 (specified by conditional probabilities) AE2 is conditionally dependent on AR1 (specified by conditional probabilities)

Faculty of ICT Page 11 An Example Using Cheque Image Clearing Requirement ANSI Std X9.37,X9.46 Requirements Bundling/reconciling Requirement checks/min Requirement No loss/No duplicate Decision Single-pass processing Design Single-pass presentment design R1.0R2.0R12.0R11.0P(AR1=V|R1. 0,R2.0,R12.0, R11.0) SSSS1.0 SSSV0.9 SSVS SVSS0.8 more……

Faculty of ICT Page 12 An Example Using Cheque Image Clearing (cont’d) Decision AR2 Select multi-nodes over Large single node Design Dual-Node design Decision AR3 Use Fail-over mechanism Design Design for Fail Over Recovery Decision Select Checkpoint Recovery over Full File Recovery Design Design for Checkpoint Recovery

Faculty of ICT Page 13 Predicting Change Impacts Insert Evidence, Say single node Decision based on dual-node no longer valid Node Recovery has to change Checkpoint decision may / may not be affected

Faculty of ICT Page 14 Diagnostic Reasoning Insert Evidence, Say single pass design was to change

Faculty of ICT Page 15 Tool Support UML Package (e.g. Enterprise Architect) to capture and represent AEs and ARs  Capture Quantitative and Qualitative Rationale  Capture Requirements, Information, Design and Deployment Models  Relate them using > association BBN Package (e.g. Netica) to Quantify Causal Relationship  Capture Prior probabilities for root nodes  Capture Conditional Probability Tables for other nodes  Compute Joint Probabilities AREL Tools:  Check Directed Cycle  Extract UML Model into BBN  Merge the model modifications in the two tool-sets

Faculty of ICT Page 16 AREL Tool Set – Extract UML Model into BBN

Faculty of ICT Page 17 AREL Tool Set – Merge UML and BBN Changes

Faculty of ICT Page 18 Conclusions & Future Work AREL defines a causal relationship between architecture elements and decisions (supported by architecture rationale) Apply BBN to AREL to quantify the strength of the causal relationships between architecture elements and decisions This application enables  Tracing of design rationale with requirements and design artefacts  Estimate change impacts / diagnose design reasoning using BBN Further Considerations  Semi-objective probability estimations based on experience  Costs-benefits of applying the method Future Work  Apply utility function to estimate expected cost of maintenance

Faculty of ICT Page 19 Related Work Zhang & Jarzabek, “ A Bayesian Network Approach to Rational Architectural Design ”, International Journal of Software Engineering and Knowledge Engineering, Vol. 15, No. 4 (2005) Possible designs Design Outcomes

Faculty of ICT Page 20 Related Work (Cont’d) Characteristics of Zhang and Jarzabek’s work  Model different combinations of design choices  Use BBN to calculate the quality of the configuration of the architecture for selecting an architecture design Differences to Our Work  Decision making is an incremental process  The design rationale behind a decision is based on many considerations, encapsulated in a decision node  The architecture design is modelled in a series of causes and effects to represent what has been decided  Use the BBN model for analysing change impact

Faculty of ICT Page 21 Thank you.