The Extensible Tool-chain for Evaluation of Architectural Models

Slides:



Advertisements
Similar presentations
Object-Oriented Application Frameworks Much of the cost and effort stems from the continuous re- discovery and re-invention of core concepts and components.
Advertisements

2009 – E. Félix Security DSL Toward model-based security engineering: developing a security analysis DSML Véronique Normand, Edith Félix, Thales Research.
Architecture Representation
The design process IACT 403 IACT 931 CSCI 324 Human Computer Interface Lecturer:Gene Awyzio Room:3.117 Phone:
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
Creating Domain-Specific Development Infrastructures George Edwards Computer Science Department University of Southern California.
Automated Analysis and Code Generation for Domain-Specific Models George Edwards Center for Systems and Software Engineering University of Southern California.
A Model-Driven Framework for Architectural Evaluation of Mobile Software Systems George Edwards Dr. Nenad Medvidovic Center.
21-February-2003cse Architecture © 2003 University of Washington1 Architecture CSE 403, Winter 2003 Software Engineering
Software Engineering for Safety : A Roadmap Presentation by: Manu D Vij CS 599 Software Engineering for Embedded Systems.
XTEAM: Automated Synthesis of Domain-Specific Code Generators George Edwards Introduction to the Center for Systems and Software Engineering.
Chapter 10: Architectural Design
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Assessing the Suitability of UML for Modeling Software Architectures Nenad Medvidovic Computer Science Department University of Southern California Los.
Lecture 9: Chapter 9 Architectural Design
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
HCI in Software Process Material from Authors of Human Computer Interaction Alan Dix, et al.
Model-Driven Analysis Frameworks for Embedded Systems George Edwards USC Center for Systems and Software Engineering
Chapter 13 Architectural Design
University of Southern California Center for Systems and Software Engineering Model-Based Software Engineering Supannika Koolmanojwong Spring 2013.
1 Introduction to Software Engineering Lecture 1.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Performance evaluation of component-based software systems Seminar of Component Engineering course Rofideh hadighi 7 Jan 2010.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Architecture Analysis Techniques
Requirements Engineering-Based Conceptual Modelling From: Requirements Engineering E. Insfran, O. Pastor and R. Wieringa Presented by Chin-Yi Tsai.
Software Deployment and Mobility. Introduction Deployment is the placing of software on the hardware where it is supposed to run. Redeployment / migration.
Smart Home Technologies
Department of Computer Science University of Southern California Los Angeles, CA, USA George Edwards Nenad Medvidovic
POSAML: A Visual Language for Middleware Provisioning Dimple Kaul, Arundhati Kogekar, Aniruddha Gokhale ISIS, Dept.
Chapter 13 설계 개념 Architectural Design 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for the book “Software Engineering: A Practitioner’s.
George Edwards Computer Science Department Center for Systems and Software Engineering University of Southern California
Chapter 9 Architectural Design. Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software.
1 The XMSF Profile Overlay to the FEDEP Dr. Katherine L. Morse, SAIC Mr. Robert Lutz, JHU APL
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Software Processes (a)
Distribution and components
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.
Software Processes.
Embedded Systems Hardware/ Software Co-Development
Enterprise Data Model Enterprise Architecture approach Insights on application for through-life collaboration 2018 – E. Jesson.
Gabor Madl Ph.D. Candidate, UC Irvine Advisor: Nikil Dutt
Model-Driven Analysis Frameworks for Embedded Systems
The Extensible Tool-chain for Evaluation of Architectural Models
Chapter 9 Requirements Modeling: Scenario-Based Methods
Component-Based Software Engineering: Technologies, Development Frameworks, and Quality Assurance Schemes X. Cai, M. R. Lyu, K.F. Wong, R. Ko.
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Tools for Composing and Deploying Grid Middleware Web Services
Software Architecture
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Implementing Architectures
HCI in the software process
An Introduction to Software Architecture
Architecture Analysis Techniques
Chapter 9 Architectural Design.
MANAGING THE DEVELOPMENT AND PURCHASE OF INFORMATION SYSTEMS
HCI in the software process
Automated Analysis and Code Generation for Domain-Specific Models
Presented By: Darlene Banta
Chapter 5 Architectural Design.
Human Computer Interaction Lecture 14 HCI in Software Process
Software Development Process Using UML Recap
UML Design for an Automated Registration System
Logical Architecture & UML Package Diagrams
Presentation transcript:

The Extensible Tool-chain for Evaluation of Architectural Models 12/3/2018 The Extensible Tool-chain for Evaluation of Architectural Models George Edwards gedwards@usc.edu Center for Systems and Software Engineering University of Southern California

Presentation Outline Introduction and Background Project Overview 12/3/2018 Presentation Outline Introduction and Background Architecture Description Languages Model-Driven Engineering Project Overview Goals and Approach XTEAM Extensible Modeling Environment Model Interpreter Framework Scenario-Driven Dynamic Analysis Key Capabilities Ongoing and Future Work December 3, 2018

Background - ADLs Architecture Description Languages (ADLs) 12/3/2018 Background - ADLs Architecture Description Languages (ADLs) Capabilities: Capture crucial design decisions Can be leveraged throughout the software development process Shortcomings: Rely on rigid formalisms Focus on structural elements Lack support for domain-specific extensibility Chart is taken from Medvidovic et al., A Classification and Comparison Framework for Software Architecture Description Languages December 3, 2018

Background - MDE Model-Driven Engineering (MDE) 12/3/2018 Background - MDE Model-Driven Engineering (MDE) Combines domain-specific modeling languages with model analyzers, transformers, and generators Domain-Specific Modeling Languages (DSMLs) Codify domain concepts and relationships as first-class modeling elements Metamodels define elements, relationships, views, and constraints Model interpreters leverage domain-specific models for analysis, generation, and transformation December 3, 2018

12/3/2018 Project Goals Provide an extensible infrastructure to aid software architects… …provide design rationale “Using a peer-to-peer architectural style for System X will result in greater scalability.” …weigh architectural trade-offs “Increasing the reliability of Service Y will incur an increase in latency.” …evaluate off-the-shelf component assemblies “The set of components selected will meet system energy consumption requirements.” …test and validate systems incrementally “The prototype of Component Z is not behaving as expected.” December 3, 2018

12/3/2018 High-Level Approach December 3, 2018

Application Simulations 12/3/2018 The XTEAM Tool-chain XTEAM employs a metaprogrammable graphical modeling environment (GME) XTEAM composes existing general-purpose ADLs: xADL Core (structures and types) and FSP (behavior) GME configures a domain-specific modeling environment with the XTEAM ADL Architecture models that conform to the XTEAM ADL are created XTEAM implements a model interpreter framework The XTEAM ADL is enhanced to capture domain-specific information The XTEAM Model Interpreter Framework is utilized to implement simulation generators Application simulations execute in the adevs discrete event simulation engine Simulations operate on the information captured in ADL extensions to perform scenario-driven analysis GME Metamodeling Environment GME Metamodeling Paradigm GME Domain-Specific Modeling Environment XTEAM ADL XTEAM Model Interpreter Framework adevs Simulation Engine XTEAM Simulation Generators Application Simulations XTEAM ADL Metamodel XTEAM Architecture Models xADL Structures and Types Finite State Processes ADL Extensions Application Architectures Energy Consumption Analysis Reliability Analysis End-to-end Latency Analysis Memory Usage Analysis Scenario-driven Analysis Results December 3, 2018

12/3/2018 Extensible Modeling Environment Capturing Domain-Specific Architectures Key Challenges: Development of ADLs is inherently difficult Combining extensibility with formal semantics Solution: Codify ADLs as metamodels ADL composition enables the combination of constructs from multiple ADLs within a single model ADL enhancement allows the definition of new, customized ADL constructs Reuse of existing ADLs maximizes the potential for reuse of the tool infrastructure. Incremental language extensions enable a specific architectural analysis technique. December 3, 2018

Model Interpreter Framework Implementing Architectural Analyses 12/3/2018 Model Interpreter Framework Implementing Architectural Analyses Key Challenge: Implementation of semantic mappings is time-consuming and error prone Solution: Utilize a model interpreter framework Transforms architectural models into executable simulations Provides empty “hook” methods that are implemented by the architect to perform analysis calculations and record measurements XTEAM Simulation Generators Generator Information Required Analysis Provided Latency task and process execution times for each required interface, the response time for each invocation Reliability failure probabilities and recovery times time and type of failures and an overall component reliability metric Energy consumption computational and communication energy costs energy consumption of each host (remaining battery power) over time Memory usage memory required by each task amount of memory being used on each host over time December 3, 2018

Scenario-Driven Dynamic Analysis 12/3/2018 Scenario-Driven Dynamic Analysis Allows the architect to rapidly investigate the consequences of design decisions in terms of their impact on non-functional properties Results depend heavily on the environmental context (e.g., the load put on the system) May contain elements of randomness and unpredictability (e.g., the timing of client requests) The set of scenarios to be simulated should include high-risk situations and boundary conditions December 3, 2018

12/3/2018 Project Goals Provide an extensible infrastructure to aid software architects… …provide design rationale “Using a peer-to-peer architectural style for System X will result in greater scalability.” …weigh architectural trade-offs “Increasing the reliability of Service Y will incur an increase in latency.” …evaluate off-the-shelf component assemblies “The set of components selected will meet system energy consumption requirements.” …test and validate systems incrementally “The prototype of Component Z is not behaving as expected.” December 3, 2018

Providing Design Rationale 12/3/2018 Providing Design Rationale Client-Server Architecture Architects rely on intuition and experience to make important decisions early in the design phase What architectural style to use How to allocate functionality among subsystems What types of connectors to use XTEAM allows architects to rationalize such decisions with experimental evidence Model confidence level: Low Peer-to-peer Architecture Potential Workload Comparison of latency  P2P achieves greater scalability December 3, 2018

Weighing Architectural Trade-offs 12/3/2018 Weighing Architectural Trade-offs Nearly all architectural decisions come down to trade-offs between multiple desirable properties Emphasis on one system property may yield diminishing returns XTEAM allows architects to evaluate design alternatives in terms of their impact on multiple non-functional properties Model confidence level: Medium Decreases response time Replication of components Consumes more battery power December 3, 2018

Evaluating COTS Assemblies 12/3/2018 Evaluating COTS Assemblies Contemporary large-scale distributed systems contain numerous off-the-shelf components Detailed information about the behaviors and properties of individual components may be known Component assemblies may exhibit unforeseen behavior due to subtle interactions between constituent components XTEAM allows an architect to determine the emergent properties of a composed system Model confidence level: High Determination of emergent properties Off-the-shelf components Highly accurate parameterization December 3, 2018

Incremental System Validation 12/3/2018 Incremental System Validation Individual component implementations may become available in a piecemeal fashion XTEAM allows architects to Immediately incorporate component implementations into a simulated system, increasing the accuracy of analysis results Rapidly test individual components in the context of a wide variety of operational scenarios Model confidence level: High Component implementation available Invoke implementation from behavior model Integrated simulation and test environment December 3, 2018

Ongoing and Future Work 12/3/2018 Ongoing and Future Work Evaluate XTEAM using a real-world security application that operates in an embedded, wireless environment Collaboration with Bosch RTC Integrate XTEAM with other complementary architecture-based development tools DeSi (model interchange) Prism-MW (code generation) Mae (product line architectures) Further define ways in which our approach can be integrated with widely-used architectural development processes Architecture Trade-off Analysis Method (ATAM) Prediction-Enabled Component Technology (PECT) December 3, 2018