Abderrahmane Seriai, Salah Sadou, H. Sahraoui, Salma Hamza
Although there are contributions on component-oriented languages, components are mostly implemented using object-oriented (OO) languages. In this perspective, a component corresponds to a set of classes that work together to provide one or more services. Services are grouped together in interfaces that are each implemented by a class. Thus, dependencies between components are defined using the semantic of the enclosed classes, which is mostly structural. This makes it difficult to understand an architecture described with such links. Indeed, at an architectural level dependencies between components must represent functional aspects. This problem is worse, when the components are obtained by re-engineering of legacy OO systems. Indeed, in this case the obtained components are mainly based on the consistency of the grouping logic. So, in this paper we propose an approach to identify the interfaces of a component according to its interactions with the other components. To this end, we use formal concept analysis. The evaluation of the proposed approach via an empirical study showed that the identified interfaces overall correspond to the different functional aspects of the components.
{"title":"Deriving Component Interfaces after a Restructuring of a Legacy System","authors":"Abderrahmane Seriai, Salah Sadou, H. Sahraoui, Salma Hamza","doi":"10.1109/WICSA.2014.27","DOIUrl":"https://doi.org/10.1109/WICSA.2014.27","url":null,"abstract":"Although there are contributions on component-oriented languages, components are mostly implemented using object-oriented (OO) languages. In this perspective, a component corresponds to a set of classes that work together to provide one or more services. Services are grouped together in interfaces that are each implemented by a class. Thus, dependencies between components are defined using the semantic of the enclosed classes, which is mostly structural. This makes it difficult to understand an architecture described with such links. Indeed, at an architectural level dependencies between components must represent functional aspects. This problem is worse, when the components are obtained by re-engineering of legacy OO systems. Indeed, in this case the obtained components are mainly based on the consistency of the grouping logic. So, in this paper we propose an approach to identify the interfaces of a component according to its interactions with the other components. To this end, we use formal concept analysis. The evaluation of the proposed approach via an empirical study showed that the identified interfaces overall correspond to the different functional aspects of the components.","PeriodicalId":346971,"journal":{"name":"2014 IEEE/IFIP Conference on Software Architecture","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-04-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128676231","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}
Consumer-initiated sporadic operations on cloud applications, such as deployment, upgrade and reconfiguration, may fail because of the inherent uncertainty of operating in a cloud environment. For example, if a VM is not able to start, operations dependent on that VM will fail. In this paper we propose an approach for analyzing sporadic operations on cloud applications to facilitate recovery. We do this by first creating a process model of the sporadic cloud operation. The Process may not be suitable for recovery operations or the application's deployment architecture since an individual step may be at the wrong level of granularity or a failure may unnecessarily affect multiple steps. We then propose a set of process division criteria for revising an operation process to support recovery. This set of criteria contains four aspects: 1) Atomicity to support the imposition of transactions on portions of the process, 2) Idempotence to allow for re-execution of a failed portion, 3) Granularity to allow reuse of existing steps, 4) Recovery Actions Identifiable to allow proper recovery actions to be taken to recover from the errors occurring during the operation. We demonstrate the feasibility of imposing these criteria by using the rolling upgrade operation in Asgard - a popular cloud management tool for AWS EC2.
{"title":"A Recoverability-Oriented Analysis for Operations on Cloud Applications","authors":"Min Fu, Liming Zhu, L. Bass, Xiwei Xu","doi":"10.1109/WICSA.2014.14","DOIUrl":"https://doi.org/10.1109/WICSA.2014.14","url":null,"abstract":"Consumer-initiated sporadic operations on cloud applications, such as deployment, upgrade and reconfiguration, may fail because of the inherent uncertainty of operating in a cloud environment. For example, if a VM is not able to start, operations dependent on that VM will fail. In this paper we propose an approach for analyzing sporadic operations on cloud applications to facilitate recovery. We do this by first creating a process model of the sporadic cloud operation. The Process may not be suitable for recovery operations or the application's deployment architecture since an individual step may be at the wrong level of granularity or a failure may unnecessarily affect multiple steps. We then propose a set of process division criteria for revising an operation process to support recovery. This set of criteria contains four aspects: 1) Atomicity to support the imposition of transactions on portions of the process, 2) Idempotence to allow for re-execution of a failed portion, 3) Granularity to allow reuse of existing steps, 4) Recovery Actions Identifiable to allow proper recovery actions to be taken to recover from the errors occurring during the operation. We demonstrate the feasibility of imposing these criteria by using the rolling upgrade operation in Asgard - a popular cloud management tool for AWS EC2.","PeriodicalId":346971,"journal":{"name":"2014 IEEE/IFIP Conference on Software Architecture","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-04-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123840851","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}
In recent years we witnessed the rise of applications in which data is continuously generated and pushed towards consumers in real time through complex processing pipelines. Software connectors like remote procedure call (RPC) do not fit with the needs of such applications, for which the publish/subscribe and the stream connectors are more suitable. This paper introduces the design space of the stream software connector by analyzing recent stream processing engine frameworks and domain specific languages featuring native streaming support. On the one side, we want to classify and compare streaming systems based on a taxonomy derived from the wide range of features they offer (i.e., pipeline dynamicity and representation, load balancing and deployment flexibility). On the other side, the gaps in the design space we identify point at future research directions in the area of distributed stream processing. To do so, we gather valuable architectural knowledge in terms of architectural issues and alternatives, elicited by surveying the most important architectural decisions made by the designers of several representative streaming framework architectures.
{"title":"The Stream Software Connector Design Space: Frameworks and Languages for Distributed Stream Processing","authors":"Masiar Babazadeh, C. Pautasso","doi":"10.1109/WICSA.2014.42","DOIUrl":"https://doi.org/10.1109/WICSA.2014.42","url":null,"abstract":"In recent years we witnessed the rise of applications in which data is continuously generated and pushed towards consumers in real time through complex processing pipelines. Software connectors like remote procedure call (RPC) do not fit with the needs of such applications, for which the publish/subscribe and the stream connectors are more suitable. This paper introduces the design space of the stream software connector by analyzing recent stream processing engine frameworks and domain specific languages featuring native streaming support. On the one side, we want to classify and compare streaming systems based on a taxonomy derived from the wide range of features they offer (i.e., pipeline dynamicity and representation, load balancing and deployment flexibility). On the other side, the gaps in the design space we identify point at future research directions in the area of distributed stream processing. To do so, we gather valuable architectural knowledge in terms of architectural issues and alternatives, elicited by surveying the most important architectural decisions made by the designers of several representative streaming framework architectures.","PeriodicalId":346971,"journal":{"name":"2014 IEEE/IFIP Conference on Software Architecture","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-04-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133411685","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}
Use-case scenarios, with notations such as UML sequence diagrams, are widely used to specify software system behavior. Although intuitive, these notations allow engineers to specify behaviors with unintended semantic side-effects. To address these inconsistencies, one class of languages targets triggered scenario specifications for expressing a system's reactive behaviors. However, these languages lack adequate facilities for modeling the intended behavior of the individual system components. This runs the risks of sacrificing the expressive power required to model component behaviors, misinterpreting the stakeholder intent, and misspecifying the component behaviors. The risks are particularly prominent when the requirements specification and software architecture specification are refined iteratively and in parallel. To remedy these problems, we propose component-aware Triggered Scenarios (caTS), an enhancement to triggered scenario languages that allows an engineer to define components' obligations within a scenario. We have formalized the syntax and semantics of ccaTSats, and have applied cats on a real-world case study, which suggests improved accuracy and conciseness of caTS in comparison to existing alternatives.
{"title":"Component-Aware Triggered Scenarios","authors":"Ivo Krka, N. Medvidović","doi":"10.1109/WICSA.2014.23","DOIUrl":"https://doi.org/10.1109/WICSA.2014.23","url":null,"abstract":"Use-case scenarios, with notations such as UML sequence diagrams, are widely used to specify software system behavior. Although intuitive, these notations allow engineers to specify behaviors with unintended semantic side-effects. To address these inconsistencies, one class of languages targets triggered scenario specifications for expressing a system's reactive behaviors. However, these languages lack adequate facilities for modeling the intended behavior of the individual system components. This runs the risks of sacrificing the expressive power required to model component behaviors, misinterpreting the stakeholder intent, and misspecifying the component behaviors. The risks are particularly prominent when the requirements specification and software architecture specification are refined iteratively and in parallel. To remedy these problems, we propose component-aware Triggered Scenarios (caTS), an enhancement to triggered scenario languages that allows an engineer to define components' obligations within a scenario. We have formalized the syntax and semantics of ccaTSats, and have applied cats on a real-world case study, which suggests improved accuracy and conciseness of caTS in comparison to existing alternatives.","PeriodicalId":346971,"journal":{"name":"2014 IEEE/IFIP Conference on Software Architecture","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-04-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133822540","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}
The documentation of architecture and design decisions lies at the backbone of building a comprehensive architectural knowledge basis within a company. As a consequence, a plethora of supporting frameworks has been lately proposed by the research community. The existing frameworks focus on capturing the rationale that lies behind a certain decision, but less on sustaining the collaborative process that architects employ when making decisions. In this paper, we propose an innovative architectural decision making process that sustains the collaboration of architects, the timely notification of involved stakeholders, the inclusion of feedback cycles to improve the overall quality of the architecting process and a tag-based traceability system that leverages informal learning. The analysis of the current state of the practice in the industry has been conducted within various workshops and interviews with our industry cooperation partner - the software provider of one of the biggest insurance trusts worldwide. Based on these results, we have identified various improvement potentials that are still not addressed by existing research in the field.
{"title":"Systematic Architectural Decision Management, A Process-Based Approach","authors":"Ana Dragomir, H. Lichter, Tiberiu Budau","doi":"10.1109/WICSA.2014.39","DOIUrl":"https://doi.org/10.1109/WICSA.2014.39","url":null,"abstract":"The documentation of architecture and design decisions lies at the backbone of building a comprehensive architectural knowledge basis within a company. As a consequence, a plethora of supporting frameworks has been lately proposed by the research community. The existing frameworks focus on capturing the rationale that lies behind a certain decision, but less on sustaining the collaborative process that architects employ when making decisions. In this paper, we propose an innovative architectural decision making process that sustains the collaboration of architects, the timely notification of involved stakeholders, the inclusion of feedback cycles to improve the overall quality of the architecting process and a tag-based traceability system that leverages informal learning. The analysis of the current state of the practice in the industry has been conducted within various workshops and interviews with our industry cooperation partner - the software provider of one of the biggest insurance trusts worldwide. Based on these results, we have identified various improvement potentials that are still not addressed by existing research in the field.","PeriodicalId":346971,"journal":{"name":"2014 IEEE/IFIP Conference on Software Architecture","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-04-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114875365","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}
Christian Manteuffel, Daniel Tofan, H. Koziolek, Thomas Goldschmidt, P. Avgeriou
Architecture decisions are often not explicitly documented in practice but reside in the architect's mind as tacit knowledge, even though explicit capturing and documentation of architecture decisions has been associated with a multitude of benefits. As part of a research collaboration with ABB, we developed a tool to document architecture decisions. This tool is an add-in for Enterprise Architect and is an implementation of a viewpoint-based decision documentation framework. To validate the add-in, we conducted an exploratory case study with ABB architects. In the study, we assessed the status quo of architecture decision documentation, identified architects' expectations of the ideal decision documentation tool, and evaluated the new add-in. We found that although awareness of decision documentation is increasing at ABB, several barriers exist that limit the use of decisions in practice. Regarding their ideal tool, architects want a descriptive and efficient approach. Supplemental features like reporting or decision sharing are requested. The new add-in, was well-perceived by the architects. As a result of the study, we propose a clearer separation of problem, outcomes, and alternatives for the decision documentation framework.
{"title":"Industrial Implementation of a Documentation Framework for Architectural Decisions","authors":"Christian Manteuffel, Daniel Tofan, H. Koziolek, Thomas Goldschmidt, P. Avgeriou","doi":"10.1109/WICSA.2014.32","DOIUrl":"https://doi.org/10.1109/WICSA.2014.32","url":null,"abstract":"Architecture decisions are often not explicitly documented in practice but reside in the architect's mind as tacit knowledge, even though explicit capturing and documentation of architecture decisions has been associated with a multitude of benefits. As part of a research collaboration with ABB, we developed a tool to document architecture decisions. This tool is an add-in for Enterprise Architect and is an implementation of a viewpoint-based decision documentation framework. To validate the add-in, we conducted an exploratory case study with ABB architects. In the study, we assessed the status quo of architecture decision documentation, identified architects' expectations of the ideal decision documentation tool, and evaluated the new add-in. We found that although awareness of decision documentation is increasing at ABB, several barriers exist that limit the use of decisions in practice. Regarding their ideal tool, architects want a descriptive and efficient approach. Supplemental features like reporting or decision sharing are requested. The new add-in, was well-perceived by the architects. As a result of the study, we propose a clearer separation of problem, outcomes, and alternatives for the decision documentation framework.","PeriodicalId":346971,"journal":{"name":"2014 IEEE/IFIP Conference on Software Architecture","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-04-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126173933","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}
V. Bianco, Varvana Myllärniemi, Marko Komssi, M. Raatikainen
The success of software ecosystems highly depends on the variety and quality of end-user applications. Therefore, attracting third-party developers and facilitating application development is crucial. Platform boundary resources enable third-party developers to create the applications. Thus, the platform boundary resources expose and extend the platform architecture. We conducted an industrial case study on third-party developer experience, particularly on the role of platform boundary resources in exposing the platform architecture and facilitating development. The studied ecosystem is centered on managing end-users' content across devices, the ecosystem was in its pre-commercial phase. The results identify the platform boundary resources in the case study and propose a model for classifying the resources. Further, designing the platform boundary resources is not only about opening up the platform architecture. Instead, the platform boundary resources need to account for a rich variety of applications, or at least not limit too much the creativity of third-party developers, while still aiming at the ease of development. We conclude that the platform boundary resources need to be created for the third-party developers, rather than from the platform architecture.
{"title":"The Role of Platform Boundary Resources in Software Ecosystems: A Case Study","authors":"V. Bianco, Varvana Myllärniemi, Marko Komssi, M. Raatikainen","doi":"10.1109/WICSA.2014.41","DOIUrl":"https://doi.org/10.1109/WICSA.2014.41","url":null,"abstract":"The success of software ecosystems highly depends on the variety and quality of end-user applications. Therefore, attracting third-party developers and facilitating application development is crucial. Platform boundary resources enable third-party developers to create the applications. Thus, the platform boundary resources expose and extend the platform architecture. We conducted an industrial case study on third-party developer experience, particularly on the role of platform boundary resources in exposing the platform architecture and facilitating development. The studied ecosystem is centered on managing end-users' content across devices, the ecosystem was in its pre-commercial phase. The results identify the platform boundary resources in the case study and propose a model for classifying the resources. Further, designing the platform boundary resources is not only about opening up the platform architecture. Instead, the platform boundary resources need to account for a rich variety of applications, or at least not limit too much the creativity of third-party developers, while still aiming at the ease of development. We conclude that the platform boundary resources need to be created for the third-party developers, rather than from the platform architecture.","PeriodicalId":346971,"journal":{"name":"2014 IEEE/IFIP Conference on Software Architecture","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-04-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126775846","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}
The proponents of Agile software development approaches claim that software architecture emerges from continuous small refactoring, hence, there is not much value in spending upfront effort on architecture related issues. Based on a large-scale empirical study involving 102 practitioners who had worked with agile and architecture approaches, we have found that whether or not architecture emerges through continuous refactoring depends upon several contextual factors. Our study has identified 20 factors that have been categorized into four elements: project, team, practices, and organization. These empirically identified contextual factors are expected to help practitioners to make informed decisions about their architecture practices in agile software development.
{"title":"Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development","authors":"Lianping Chen, M. Babar","doi":"10.1109/WICSA.2014.45","DOIUrl":"https://doi.org/10.1109/WICSA.2014.45","url":null,"abstract":"The proponents of Agile software development approaches claim that software architecture emerges from continuous small refactoring, hence, there is not much value in spending upfront effort on architecture related issues. Based on a large-scale empirical study involving 102 practitioners who had worked with agile and architecture approaches, we have found that whether or not architecture emerges through continuous refactoring depends upon several contextual factors. Our study has identified 20 factors that have been categorized into four elements: project, team, practices, and organization. These empirically identified contextual factors are expected to help practitioners to make informed decisions about their architecture practices in agile software development.","PeriodicalId":346971,"journal":{"name":"2014 IEEE/IFIP Conference on Software Architecture","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-04-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115282923","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}
An approach to software architecture creation is described in the context of agile development. It eschews the traditional separation of top-down and bottom-up design. A concrete, cumulative, least-commitment process is demonstrated that establishes an architecture core likely to remain stable as requirements are added.
{"title":"Cumulative Software Architecture Development","authors":"Eric J. Braude","doi":"10.1109/WICSA.2014.26","DOIUrl":"https://doi.org/10.1109/WICSA.2014.26","url":null,"abstract":"An approach to software architecture creation is described in the context of agile development. It eschews the traditional separation of top-down and bottom-up design. A concrete, cumulative, least-commitment process is demonstrated that establishes an architecture core likely to remain stable as requirements are added.","PeriodicalId":346971,"journal":{"name":"2014 IEEE/IFIP Conference on Software Architecture","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-04-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115297242","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}
Growing advances in hardware technologies are enabling significant improvements in application performance by the deployment of components to dedicated executable units. This is particularly valid for Cyber Physical Systems in which the applications are partitioned in HW and SW execution units. The growing complexity of such systems, and increasing requirements, both project- and product-related, makes the partitioning decision process complex. Although different approaches to this decision process have been proposed during recent decades, they lack the ability to provide relevant decisions based on a larger number of requirements and project/business constraints. A sound approach to this problem is taking into account all relevant requirements and constraints and their relations to the properties of the components deployed either as HW or SW units. A typical approach for managing a large number of criteria is a multicriteria decision analysis. This, in its turn, requires uniform definitions of component properties and their realization in respect to their HW/SW deployment. The aim of this paper is twofold: a) to provide an architectural metamodel of component-based applications with specifications of their properties with respect to their partitioning, and b) to categorize component properties in relation to HW/SW deployment. The metamodel enables the transition of system requirements to system and component properties. The categorization provides support for architectural decisions. It is demonstrated through a property guideline for the partitioning of the System Automation and Control domain. The guideline is based on interviews with practitioners and researchers, the experts in this domain.
{"title":"Architectural Decisions for HW/SW Partitioning Based on Multiple Extra-Functional Properties","authors":"Gaetana Sapienza, I. Crnkovic, P. Potena","doi":"10.1109/WICSA.2014.19","DOIUrl":"https://doi.org/10.1109/WICSA.2014.19","url":null,"abstract":"Growing advances in hardware technologies are enabling significant improvements in application performance by the deployment of components to dedicated executable units. This is particularly valid for Cyber Physical Systems in which the applications are partitioned in HW and SW execution units. The growing complexity of such systems, and increasing requirements, both project- and product-related, makes the partitioning decision process complex. Although different approaches to this decision process have been proposed during recent decades, they lack the ability to provide relevant decisions based on a larger number of requirements and project/business constraints. A sound approach to this problem is taking into account all relevant requirements and constraints and their relations to the properties of the components deployed either as HW or SW units. A typical approach for managing a large number of criteria is a multicriteria decision analysis. This, in its turn, requires uniform definitions of component properties and their realization in respect to their HW/SW deployment. The aim of this paper is twofold: a) to provide an architectural metamodel of component-based applications with specifications of their properties with respect to their partitioning, and b) to categorize component properties in relation to HW/SW deployment. The metamodel enables the transition of system requirements to system and component properties. The categorization provides support for architectural decisions. It is demonstrated through a property guideline for the partitioning of the System Automation and Control domain. The guideline is based on interviews with practitioners and researchers, the experts in this domain.","PeriodicalId":346971,"journal":{"name":"2014 IEEE/IFIP Conference on Software Architecture","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2014-04-07","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124092890","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
扫码关注我们
求助内容：
应助结果提醒方式：