Pub Date : 2019-03-01DOI: 10.1109/ICSA-C.2019.00049
Fabian Gilson, Danny Weyns
Software engineering is an intrinsically collaborative activity, especially in the era of Agile Software Development. Many actors are partaking in development activities, such that a common understanding should be reached at numerous stages during the overall development life-cycle. For a few years now, Natural Language Processing techniques have been employed either to extract key information from free-form text or to generate models from the analysis of text in order to ease the sharing of knowledge across all parties. A significant part of these approaches focuses on retrieving lost domain and architectural knowledge through the analysis of documents, issue management systems or other forms of knowledge management systems. However, these post-processing methods are time-consuming by nature since they require to invest significant resources into the validation of the extracted knowledge. In this paper, inspired by collaborative tools, bots and Natural Language extraction approaches, we envision new ways to collaboratively record and document design decisions as they are discussed. These decisions will be documented as they are taken and, for some of them, static or behavioural models may be generated on-the-fly. Such an interactive process will ensure everyone agrees on critical design aspects of the software. We believe development teams will benefit from this approach because manual encoding of design knowledge will be reduced and will not be pushed to a later stage, when not forgotten.
{"title":"When Natural Language Processing Jumps into Collaborative Software Engineering","authors":"Fabian Gilson, Danny Weyns","doi":"10.1109/ICSA-C.2019.00049","DOIUrl":"https://doi.org/10.1109/ICSA-C.2019.00049","url":null,"abstract":"Software engineering is an intrinsically collaborative activity, especially in the era of Agile Software Development. Many actors are partaking in development activities, such that a common understanding should be reached at numerous stages during the overall development life-cycle. For a few years now, Natural Language Processing techniques have been employed either to extract key information from free-form text or to generate models from the analysis of text in order to ease the sharing of knowledge across all parties. A significant part of these approaches focuses on retrieving lost domain and architectural knowledge through the analysis of documents, issue management systems or other forms of knowledge management systems. However, these post-processing methods are time-consuming by nature since they require to invest significant resources into the validation of the extracted knowledge. In this paper, inspired by collaborative tools, bots and Natural Language extraction approaches, we envision new ways to collaboratively record and document design decisions as they are discussed. These decisions will be documented as they are taken and, for some of them, static or behavioural models may be generated on-the-fly. Such an interactive process will ensure everyone agrees on critical design aspects of the software. We believe development teams will benefit from this approach because manual encoding of design knowledge will be reduced and will not be pushed to a later stage, when not forgotten.","PeriodicalId":239999,"journal":{"name":"2019 IEEE International Conference on Software Architecture Companion (ICSA-C)","volume":"143 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115110165","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-03-01DOI: 10.1109/ICSA-C.2019.00028
Dominik Ernst, Alexander Becker, S. Tai
Canary releasing is a means to check quality aspects of new software versions in a production environment, keeping risk to a minimum. We propose a novel approach to minimize the interference of canarying with the production system by (1) actively controlling request distribution in order to shorten the time a canary has to be running to achieve representative results and (2) unifying responsibility for that purpose and the collection of performance data about the canary on an ephemeral proxy load balancer. For (1) we contribute a two-stage load balancing approach, that implements weighted round-robin and a bucketing approach for HTTP-based services, that equalizes requests based on request URL. With explicit assumptions about infrastructure capabilities, we also describe the design of a proxy-based canary assessment tool to support (2). Both parts are implemented as a prototype and evaluated regarding feasibility, effectiveness and overhead. While the results cannot represent realistic production scenarios, they strongly indicate the validity of shortening a canary's lifetime by accepting a small overhead in client latency.
{"title":"Rapid Canary Assessment Through Proxying and Two-Stage Load Balancing","authors":"Dominik Ernst, Alexander Becker, S. Tai","doi":"10.1109/ICSA-C.2019.00028","DOIUrl":"https://doi.org/10.1109/ICSA-C.2019.00028","url":null,"abstract":"Canary releasing is a means to check quality aspects of new software versions in a production environment, keeping risk to a minimum. We propose a novel approach to minimize the interference of canarying with the production system by (1) actively controlling request distribution in order to shorten the time a canary has to be running to achieve representative results and (2) unifying responsibility for that purpose and the collection of performance data about the canary on an ephemeral proxy load balancer. For (1) we contribute a two-stage load balancing approach, that implements weighted round-robin and a bucketing approach for HTTP-based services, that equalizes requests based on request URL. With explicit assumptions about infrastructure capabilities, we also describe the design of a proxy-based canary assessment tool to support (2). Both parts are implemented as a prototype and evaluated regarding feasibility, effectiveness and overhead. While the results cannot represent realistic production scenarios, they strongly indicate the validity of shortening a canary's lifetime by accepting a small overhead in client latency.","PeriodicalId":239999,"journal":{"name":"2019 IEEE International Conference on Software Architecture Companion (ICSA-C)","volume":"60 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130534342","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-03-01DOI: 10.1109/ICSA-C.2019.00041
J. Bogner, J. Fritzsch, S. Wagner, A. Zimmermann
Microservices are a topic driven mainly by practitioners and academia is only starting to investigate them. Hence, there is no clear picture of the usage of Microservices in practice. In this paper, we contribute a qualitative study with insights into industry adoption and implementation of Microservices. Contrary to existing quantitative studies, we conducted interviews to gain a more in-depth understanding of the current state of practice. During 17 interviews with software professionals from 10 companies, we analyzed 14 service-based systems. The interviews focused on applied technologies, Microservices characteristics, and the perceived influence on software quality. We found that companies generally rely on well-established technologies for service implementation, communication, and deployment. Most systems, however, did not exhibit a high degree of technological diversity as commonly expected with Microservices. Decentralization and product character were different for systems built for external customers. Applied DevOps practices and automation were still on a mediocre level and only very few companies strictly followed the you build it, you run it principle. The impact of Microservices on software quality was mainly rated as positive. While maintainability received the most positive mentions, some major issues were associated with security. We present a description of each case and summarize the most important findings of companies across different domains and sizes. Researchers may build upon our findings and take them into account when designing industry-focused methods.
{"title":"Microservices in Industry: Insights into Technologies, Characteristics, and Software Quality","authors":"J. Bogner, J. Fritzsch, S. Wagner, A. Zimmermann","doi":"10.1109/ICSA-C.2019.00041","DOIUrl":"https://doi.org/10.1109/ICSA-C.2019.00041","url":null,"abstract":"Microservices are a topic driven mainly by practitioners and academia is only starting to investigate them. Hence, there is no clear picture of the usage of Microservices in practice. In this paper, we contribute a qualitative study with insights into industry adoption and implementation of Microservices. Contrary to existing quantitative studies, we conducted interviews to gain a more in-depth understanding of the current state of practice. During 17 interviews with software professionals from 10 companies, we analyzed 14 service-based systems. The interviews focused on applied technologies, Microservices characteristics, and the perceived influence on software quality. We found that companies generally rely on well-established technologies for service implementation, communication, and deployment. Most systems, however, did not exhibit a high degree of technological diversity as commonly expected with Microservices. Decentralization and product character were different for systems built for external customers. Applied DevOps practices and automation were still on a mediocre level and only very few companies strictly followed the you build it, you run it principle. The impact of Microservices on software quality was mainly rated as positive. While maintainability received the most positive mentions, some major issues were associated with security. We present a description of each case and summarize the most important findings of companies across different domains and sizes. Researchers may build upon our findings and take them into account when designing industry-focused methods.","PeriodicalId":239999,"journal":{"name":"2019 IEEE International Conference on Software Architecture Companion (ICSA-C)","volume":"330 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121252029","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-03-01DOI: 10.1109/ICSA-C.2019.00030
Philipp Obergfell, Stefan Kugele, Christoph Segler, A. Knoll, E. Sax
One major challenge in the automotive industry is to deliver innovative functions more frequently. Hence, the standard development process with a fixed release plan is likely to be turned into a more continuous procedure. From a methodological perspective, this change includes applying well-established agile development techniques. In contrast to pure software-related domains, the successful implementation of software-based functions in embedded systems highly depends on non-functional requirements, and therefore we see the need for extending the pure code-centric notion of agility. In order to do so, we reflect on architectural drivers that are beneficial for the transformation of OEMs into software companies. Finally, we present our perspective on future automotive software engineering by illustrating how continuous integration is applied by a software engineer not only on the level of source code, but also on the system architecture level and the respective role.
{"title":"Continuous Software Engineering of Innovative Automotive Functions: An Industrial Perspective","authors":"Philipp Obergfell, Stefan Kugele, Christoph Segler, A. Knoll, E. Sax","doi":"10.1109/ICSA-C.2019.00030","DOIUrl":"https://doi.org/10.1109/ICSA-C.2019.00030","url":null,"abstract":"One major challenge in the automotive industry is to deliver innovative functions more frequently. Hence, the standard development process with a fixed release plan is likely to be turned into a more continuous procedure. From a methodological perspective, this change includes applying well-established agile development techniques. In contrast to pure software-related domains, the successful implementation of software-based functions in embedded systems highly depends on non-functional requirements, and therefore we see the need for extending the pure code-centric notion of agility. In order to do so, we reflect on architectural drivers that are beneficial for the transformation of OEMs into software companies. Finally, we present our perspective on future automotive software engineering by illustrating how continuous integration is applied by a software engineer not only on the level of source code, but also on the system architecture level and the respective role.","PeriodicalId":239999,"journal":{"name":"2019 IEEE International Conference on Software Architecture Companion (ICSA-C)","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126036039","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-03-01DOI: 10.1109/ICSA-C.2019.00032
J. A. D. Pace, A. Bianchi
Capturing and communicating the architecture decisions of a project is very important in architecture knowledge management, so that those decisions can deliver value to the system stakeholders and also support the system implementation. In agile development contexts, there is often a balancing act between documenting the design decisions in detail and keeping the documentation efforts to a level tolerable for the project. To this end, we present the notion of High-level Design stories (or HLDs), as small, modular artifacts that record the main design decisions and their context, but also include information about architecture assumptions, quality-attribute analysis, and pending issues for the system. HLDs are intended to be created and refined during the different phases of an architecture-centric development process, and assist in the validation of the decisions (and pending issues) in that process. This way, a global (although detailed) architecture design can be obtained from the combination of the HLDs. In this work, we discuss the pros and cons of using HLDs for design decisions based on experiences from an industrial software project.
{"title":"High-Level Design Stories in Architecture-Centric Agile Development","authors":"J. A. D. Pace, A. Bianchi","doi":"10.1109/ICSA-C.2019.00032","DOIUrl":"https://doi.org/10.1109/ICSA-C.2019.00032","url":null,"abstract":"Capturing and communicating the architecture decisions of a project is very important in architecture knowledge management, so that those decisions can deliver value to the system stakeholders and also support the system implementation. In agile development contexts, there is often a balancing act between documenting the design decisions in detail and keeping the documentation efforts to a level tolerable for the project. To this end, we present the notion of High-level Design stories (or HLDs), as small, modular artifacts that record the main design decisions and their context, but also include information about architecture assumptions, quality-attribute analysis, and pending issues for the system. HLDs are intended to be created and refined during the different phases of an architecture-centric development process, and assist in the validation of the decisions (and pending issues) in that process. This way, a global (although detailed) architecture design can be obtained from the combination of the HLDs. In this work, we discuss the pros and cons of using HLDs for design decisions based on experiences from an industrial software project.","PeriodicalId":239999,"journal":{"name":"2019 IEEE International Conference on Software Architecture Companion (ICSA-C)","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121043495","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-03-01DOI: 10.1109/ICSA-C.2019.00014
Darko Durisic, A. Berenyi
System architecture is considered a fundamental element in the development of large and complex electrical systems. This is because a good architecture assures that the system fulfils and will fulfil after future upgrades all required quality demands. In addition to the well-designed architecture, the development of such systems today requires agile methods, especially when it comes to the development of software. This is mostly to assure quality and fast innovations cycles reaching customers early and directly incorporating their feedback into the development process. In order to coordinate the work of many agile teams in large organizations, it is usually necessary to employ frameworks for scaling agile development. One such frameworks is SAFe (Scaled Agile Framework) proven to work in many industries. Despite dedicating roles to the development of the system architecture at all organizational levels (e.g., System and Solution Architects), SAFe does not recognize the need for holistic architectural teams responsible for assuring that all architectural decisions are made in the best interest of the entire system. In this paper, we discuss the organization, responsibility and collaboration between such architecture teams - the Complete System Architects - and System/Solution Architects in SAFe. The results are based on the ongoing agile transformation at Volvo Cars based on SAFe.
{"title":"Agile System Architecture in Large Organizations: An Experience Report from Volvo Cars","authors":"Darko Durisic, A. Berenyi","doi":"10.1109/ICSA-C.2019.00014","DOIUrl":"https://doi.org/10.1109/ICSA-C.2019.00014","url":null,"abstract":"System architecture is considered a fundamental element in the development of large and complex electrical systems. This is because a good architecture assures that the system fulfils and will fulfil after future upgrades all required quality demands. In addition to the well-designed architecture, the development of such systems today requires agile methods, especially when it comes to the development of software. This is mostly to assure quality and fast innovations cycles reaching customers early and directly incorporating their feedback into the development process. In order to coordinate the work of many agile teams in large organizations, it is usually necessary to employ frameworks for scaling agile development. One such frameworks is SAFe (Scaled Agile Framework) proven to work in many industries. Despite dedicating roles to the development of the system architecture at all organizational levels (e.g., System and Solution Architects), SAFe does not recognize the need for holistic architectural teams responsible for assuring that all architectural decisions are made in the best interest of the entire system. In this paper, we discuss the organization, responsibility and collaboration between such architecture teams - the Complete System Architects - and System/Solution Architects in SAFe. The results are based on the ongoing agile transformation at Volvo Cars based on SAFe.","PeriodicalId":239999,"journal":{"name":"2019 IEEE International Conference on Software Architecture Companion (ICSA-C)","volume":"16 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123042330","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-03-01DOI: 10.1109/ICSA-C.2019.00046
Michael Colesky, Katerina Demetzou, Lothar Fritsch, Sebastian Herold
The General Data Protection Regulation (GDPR) impacts any information systems that process personal data in or from the European Union. Yet its enforcement is still recent. Organizations under its effect are slow to adopt its principles. One particular difficulty is the low familiarity with the regulation among software architects and designers. The difficulty to interpret the content of the legal regulation at a technical level adds to that. This results in problems in understanding the impact and consequences that the regulation may have in detail for a particular system or project context. In this paper we present some early work and emerging results related to supporting software architects in this situation. Specifically, we target those who need to understand how the GDPR might impact their design decisions. In the spirit of architectural tactics and patterns, we systematically identified and categorized 155 forces in the regulation. These results form the conceptual base for a first prototypical tool. It enables software architects to identify the relevant forces by guiding them through an online questionnaire. This leads them to relevant fragments of the GDPR and potentially relevant privacy patterns. We argue that this approach may help software professionals, in particular architects, familiarize with the GDPR and outline potential paths for evaluation.
{"title":"Helping Software Architects Familiarize with the General Data Protection Regulation","authors":"Michael Colesky, Katerina Demetzou, Lothar Fritsch, Sebastian Herold","doi":"10.1109/ICSA-C.2019.00046","DOIUrl":"https://doi.org/10.1109/ICSA-C.2019.00046","url":null,"abstract":"The General Data Protection Regulation (GDPR) impacts any information systems that process personal data in or from the European Union. Yet its enforcement is still recent. Organizations under its effect are slow to adopt its principles. One particular difficulty is the low familiarity with the regulation among software architects and designers. The difficulty to interpret the content of the legal regulation at a technical level adds to that. This results in problems in understanding the impact and consequences that the regulation may have in detail for a particular system or project context. In this paper we present some early work and emerging results related to supporting software architects in this situation. Specifically, we target those who need to understand how the GDPR might impact their design decisions. In the spirit of architectural tactics and patterns, we systematically identified and categorized 155 forces in the regulation. These results form the conceptual base for a first prototypical tool. It enables software architects to identify the relevant forces by guiding them through an online questionnaire. This leads them to relevant fragments of the GDPR and potentially relevant privacy patterns. We argue that this approach may help software professionals, in particular architects, familiarize with the GDPR and outline potential paths for evaluation.","PeriodicalId":239999,"journal":{"name":"2019 IEEE International Conference on Software Architecture Companion (ICSA-C)","volume":"65 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129108627","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-03-01DOI: 10.1109/ICSA-C.2019.00007
Ken Power, R. Wirfs-Brock
First, we shape our architecture. Then, our architecture shapes us. As architects we bring part of ourselves to the systems we work with. We evolve with our architectures. In this tutorial we consider the metaphor of “terroir” to understand architectures and their sense of place. Terroir comes from the French word used to describe the set of all environmental factors that affect the observable characteristics of an organism, e.g., the unique set of contextual characteristics of place that influence food crops, coffee, tea, or wine. So too in systems, architectures are uniquely shaped by the culture and context of a place. Factors include people, organization, culture, technology, and tenets shared among the architects and makers. Understanding an architecture is a first step towards evaluating it. The set of concepts and practical tools covered in this tutorial are well suited to being used in conducting architecture analyses and reviews and integrate with any other processes an organization might be using.
{"title":"Sense of Place within the Virtuous Circle of Architecture Decision-Making","authors":"Ken Power, R. Wirfs-Brock","doi":"10.1109/ICSA-C.2019.00007","DOIUrl":"https://doi.org/10.1109/ICSA-C.2019.00007","url":null,"abstract":"First, we shape our architecture. Then, our architecture shapes us. As architects we bring part of ourselves to the systems we work with. We evolve with our architectures. In this tutorial we consider the metaphor of “terroir” to understand architectures and their sense of place. Terroir comes from the French word used to describe the set of all environmental factors that affect the observable characteristics of an organism, e.g., the unique set of contextual characteristics of place that influence food crops, coffee, tea, or wine. So too in systems, architectures are uniquely shaped by the culture and context of a place. Factors include people, organization, culture, technology, and tenets shared among the architects and makers. Understanding an architecture is a first step towards evaluating it. The set of concepts and practical tools covered in this tutorial are well suited to being used in conducting architecture analyses and reviews and integrate with any other processes an organization might be using.","PeriodicalId":239999,"journal":{"name":"2019 IEEE International Conference on Software Architecture Companion (ICSA-C)","volume":"53 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121855425","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-03-01DOI: 10.1109/ICSA-C.2019.00027
Robert Chatley, T. Field, David Wei
We introduce the notion of performance unit testing which allows developers to explore performance characteristics and detect potential performance problems continuously throughout the development of a software system. Our ideas are embodied in PerfMock, which extends a well-established object mocking framework so that each mock object can be configured with a performance model for predicting the time taken to process each message it receives. PerfMock executes tests in virtual time. This allows performance to be evaluated much more quickly than running a full system performance test, making it possible to test performance continuously, as part of a unit test suite. We demonstrate the core features of PerfMock and show how it can be used to support a process of iterative refinement, whereby models can be improved when more about the actual performance of the objects being mocked becomes known, e.g. by building models from production data. We show that even very simple performance models used early on in the development process can provide useful information for estimating both absolute execution times and the effects of changes in functionality and/or design. The iterative approach we support has the pleasing property that as the system evolves, more decisions are made and more data is collected meaning that we can refine our models, and predicted and actual performance gradually converge.
{"title":"Continuous Performance Testing in Virtual Time","authors":"Robert Chatley, T. Field, David Wei","doi":"10.1109/ICSA-C.2019.00027","DOIUrl":"https://doi.org/10.1109/ICSA-C.2019.00027","url":null,"abstract":"We introduce the notion of performance unit testing which allows developers to explore performance characteristics and detect potential performance problems continuously throughout the development of a software system. Our ideas are embodied in PerfMock, which extends a well-established object mocking framework so that each mock object can be configured with a performance model for predicting the time taken to process each message it receives. PerfMock executes tests in virtual time. This allows performance to be evaluated much more quickly than running a full system performance test, making it possible to test performance continuously, as part of a unit test suite. We demonstrate the core features of PerfMock and show how it can be used to support a process of iterative refinement, whereby models can be improved when more about the actual performance of the objects being mocked becomes known, e.g. by building models from production data. We show that even very simple performance models used early on in the development process can provide useful information for estimating both absolute execution times and the effects of changes in functionality and/or design. The iterative approach we support has the pleasing property that as the system evolves, more decisions are made and more data is collected meaning that we can refine our models, and predicted and actual performance gradually converge.","PeriodicalId":239999,"journal":{"name":"2019 IEEE International Conference on Software Architecture Companion (ICSA-C)","volume":"72 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127269332","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-03-01DOI: 10.1109/ICSA-C.2019.00009
Manuel Gotin, Felix Lösch, Ralf H. Reussner
Cloud-loT Applications consist of thousands of smart devices sending sensor data to processing cloud applications. If the processing rate of the cloud application is limited it may be unable to cope with an increasing number of connected devices. If such a situation is not addressed, the cloud application is overloaded with messages, resulting in a high processing delay or loss of data. For this reason we propose a TCP-inspired congestion avoidance which reconfigures the send rate of devices at runtime aiming for a low processing delay and a high throughput. We show, that it is able to avoid congestions by adapting the send rate of devices to a fair share of the processing rate of the cloud application.
{"title":"TCP-Inspired Congestion Avoidance for Cloud-IoT Applications","authors":"Manuel Gotin, Felix Lösch, Ralf H. Reussner","doi":"10.1109/ICSA-C.2019.00009","DOIUrl":"https://doi.org/10.1109/ICSA-C.2019.00009","url":null,"abstract":"Cloud-loT Applications consist of thousands of smart devices sending sensor data to processing cloud applications. If the processing rate of the cloud application is limited it may be unable to cope with an increasing number of connected devices. If such a situation is not addressed, the cloud application is overloaded with messages, resulting in a high processing delay or loss of data. For this reason we propose a TCP-inspired congestion avoidance which reconfigures the send rate of devices at runtime aiming for a low processing delay and a high throughput. We show, that it is able to avoid congestions by adapting the send rate of devices to a fair share of the processing rate of the cloud application.","PeriodicalId":239999,"journal":{"name":"2019 IEEE International Conference on Software Architecture Companion (ICSA-C)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131685550","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：