基于组件模型分析的组件容器产品线体系结构

组件容器为组件提供部署和运行环境,是基于组件分布式应用开发的核心.近年来分布式组件的多样化和快速演化对组件容器的开发方法提出了挑战.产品线工程是基于公共的核心资产开发特定领域内软件产品系列的软件工程方法,产品线体系结构是其中最重要的部分.进行组件容器产品线体系结构的研究能够提高组件容器的结构复用性,获得更高的生产效率和质量.由于组件模型是组件容器设计的基础,在领域分析阶段引入组件模型分析,提出了组件模型分析框架,通过组件模型元素到领域需求元素的映射,建立组件容器领域模型.提出了组件容器设计的基本原则,并根据变化性封装原则,提出了组件容器产品线体系结构PLACE,通过引入可选属性、模块层次结构和决策模型,实现组件容器的领域需求.PLACE产品线体系结构已在网驰平台的多个组件容器设计中得到应用.     

从领域需求到产品线体系结构的映射——一种面向特征的方法

领域需求之间的依赖关系对软件产品线的体系结构有很大的影响,在已有的面向特征的管理产品线需求依赖的方法中很少有研究从需求到产品线体系结构的映射.基于一种特征依赖的分类方法,提出了从领域需求到特征,以及从特征到产品线体系结构的映射规则.通过这些映射规则,一致的需求通过映射得到一致的产品线核心资产,从而减少产品线中核心资产的不一致性并增加产品线的复用程度.用金融领域的现货交易产品线作为实例说明这个方法的实用性.     

产品线体系结构复杂性度量

产品线体系结构需要支持多种变化性以满足其内部成员特性，因而是重要又复杂的软件产品线子系统。本文通过分析产品线体系结构的vADL规约，充分考虑产品线体系结构变化性对其复杂性度量的影响，生成产品线体系结构信息流图PLA—IFG，基于PLA—IFG，实现自动化度量产品线体系结构复杂性，提出了支持变化性的产品线体系结构复杂性度量方法。     

基于高阶π演算的构件演化模型研究*

为满足构件演化形式化分析的需要,确保演化正确性,提出了一种基于高阶π演算的构件演化模型。在定义演化构件的基础上,将演化过程中的行为描述为原子行为、结构行为和操作行为,建立行为与高阶π演算间的转换规则、演化行为推演规则,根据演化过程中行为之间的关系,建立演化冲突检测机制,定义互斥冲突、重复冲突、条件冲突和包含冲突等四类冲突,在分析冲突条件的基础上,设计了演化冲突检测算法,实现了构件演化的形式化分析。通过实例验证了模型的可行性。     

高技术虚拟企业利益分配冲突求解系统的构建

为支持高技术虚拟企业对利益分配冲突的监控、识别和求解,基于可拓逻辑设计了一套具有较强元决策能力的冲突求解系统。根据发散思维和收敛思维相结合的问题求解框架,构建了利益分配冲突求解系统的体系结构;定义了实时监控利益分配冲突强度的可拓集,给出了表层利益分配冲突的识别方法和核心利益分配冲突的拓展方法,并设计了基于传导规则和共轭规则的启发式求解逻辑,使系统具备了自动调整利益分配策略的能力。系统体系结构的设计方案及其冲突求解策略可独立于利益分配冲突管理的背景,具有较好的可移植性。     

通用的软件产品线领域与应用特征模型演化同步框架

软件产品线领域特征模型和应用特征模型都会发生独立的演化,在产品线的整体演化过程中必须使其始终保持一致,然而,分别为基于不同描述方式的特征模型创建同步设施往往费时、容易出错。因此,提出一个通用的软件产品线领域与应用特征模型的演化同步框架,该框架提供一套统一的特征模型元模型描述方式,并且基于该元模型提出了演化同步规则。 不同的软件产品线开发组织使用该框架时仅需定义特定的特征描述与通用描述方式之间的转换。最后,通过一个实例对框架的可用性进行了验证。     

产品线体系结构层次组装技术研究

产品线体系结构是软件产品线成功开发的基础,层次组装是产品线体系结构设计的重要支撑技术。在产品线体系结构描述语言vADL的基础上,针对产品线体系结构层次组装的特点,首次引入变化性组装概念,并研究了两种变化性组装技术:变量映射和守护条件约束。在传统端口绑定基础上,引入组装件技术支持多个异型组件端口组装和多种类型的端口行为组装。给出基于π演算理论的行为组装推导算法,并充分考虑变化性对行为组装的影响。     

面向体系结构的可视化服务集成开发环境Artemis-VIDE

为支持直观易扩展的软件服务集成和所集成之应用系统的动态演化,本文提出了一个面向体系结构的可视化服务集成开发环境。该环境支持以图形化的方式定义系统的软件体系结构及相关协同逻辑,并据此生成内置于应用系统之中的运行时刻体系结构对象,作为应用系统运行和演化的基础。该环境还集成了服务搜索、基于图文法的体系结构检查等功能,为系统的开发、运行、监控和动态演化提供了一个一致、易用、可扩展的支撑平台。     

协同图形编辑系统中并发操作冲突检测的研究

实时协同设计是CSCW应用的重要领域。实时协同设计过程实际上就是并发冲突产生和消解的过程。本文描述协同图形编辑系统中多对象之间的冲突相关定义,提出一种判别并发操作冲突的关联对象冲突检测策略,设计实现相应的冲突检测算法,最后对算法的可行性进行分析。     

C/E网系统中交叠式序列的计数

在CCS中,Milner把系统中的两个事件处于并发定义为“它们可以按任意顺序发生”。这个关于并发的定义被称之为“交叠式并发”。然而在网论中,Petri把并发定义为“非序”,并指出并发是冲突的精确对偶。Petri关于并发的定义被公认为“真并发”。为了研究这两种并发概念的联系和差异,以C/E系统为模型,分别从这两种不同定义的视角出发,讨论了并发的表现和实质,并对网系统中存在的不同并发组合情况给出了求交叠式序列(根据交叠式并发概念而得出)个数的一组计算公式。     

产品线可变性的需求方法研究

软件产品线领域需求记录了不同软件产品的共性和可变性。在现有需求过程框架下,对产品线需求获取方法与需求分析方法进行了研究,完善了产品线需求可变性的管控机制。以原子需求为视点,提出了利用需求场景获取产品线领域需求的方法;通过原子需求构建的产品需求矩阵与用例需求矩阵,分析得出需求资源的可变性关系;通过可变性关系的形式化描述,建立产品线可变性用例模型。     

Automated diagnosis of feature model configurations

Software product-lines (SPLs) are software platforms that can be readily reconfigured for different project requirements. A key part of an SPL is a model that captures the rules for reconfiguring the software. SPLs commonly use feature models to capture SPL configuration rules. Each SPL configuration is represented as a selection of features from the feature model. Invalid SPL configurations can be created due to feature conflicts introduced via staged or parallel configuration or changes to the constraints in a feature model. When invalid configurations are created, a method is needed to automate the diagnosis of the errors and repair the feature selections.This paper provides two contributions to research on automated configuration of SPLs. First, it shows how configurations and feature models can be transformed into constraint satisfaction problems to automatically diagnose errors and repair invalid feature selections. Second, it presents empirical results from diagnosing configuration errors in feature models ranging in size from 100 to 5,000 features. The results of our experiments show that our CSP-based diagnostic technique can scale up to models with thousands of features.     

Feature Nets: behavioural modelling of software product lines

Software product lines (SPLs) are diverse systems that are developed using a dual engineering process: (a) family engineering defines the commonality and variability among all members of the SPL, and (b) application engineering derives specific products based on the common foundation combined with a variable selection of features. The number of derivable products in an SPL can thus be exponential in the number of features. This inherent complexity poses two main challenges when it comes to modelling: firstly, the formalism used for modelling SPLs needs to be modular and scalable. Secondly, it should ensure that all products behave correctly by providing the ability to analyse and verify complex models efficiently. In this paper, we propose to integrate an established modelling formalism (Petri nets) with the domain of software product line engineering. To this end, we extend Petri nets to Feature Nets. While Petri nets provide a framework for formally modelling and verifying single software systems, Feature Nets offer the same sort of benefits for software product lines. We show how SPLs can be modelled in an incremental, modular fashion using Feature Nets, provide a Feature Nets variant that supports modelling dynamic SPLs, and propose an analysis method for SPL modelled as Feature Nets. By facilitating the construction of a single model that includes the various behaviours exhibited by the products in an SPL, we make a significant step towards efficient and practical quality assurance methods for software product lines.     

Evolutionary robust optimization for software product line scoping: An explorative study

Background: Software product line (SPL) scoping is an important phase when planning for product line adoption. An SPL scope specifies: (1) the extent of the domain supported by the product line, (2) portfolio of products in the product line and (3) list of assets to be developed for reuse across the family of products.Issue: SPL scope planning is usually based on estimates about the state of the market and the engineering capabilities of the development team. One challenge with these estimates is that there are inaccuracies due to uncertainty in the environment or accuracy of measurement. This may result in issues ranging from suboptimal plans to infeasible plans.Objective: To address the above, we propose to include uncertainty as part of the SPL scoping model. Plans developed in consideration of uncertainty would be more robust against possible fluctuations in estimates.Approach: In this paper, a method to incorporate uncertainty in scoping optimization and its application to generate robust solutions is proposed. We capture uncertainty as part of the formulation and model scoping optimization as a multi-objective problem with profit and stability as fitness functions. Profit stability and feasibility stability are considered to represent stability concerns.Results: Results show that, compared to other scope optimization approaches, both performance stability and feasibility stability are improved while maintaining near optimal performance for profit objective. Also, generated results consist of solutions with trade-offs between profit and stability, providing the decision maker with enhanced decision support.Conclusion: Multi-objective optimization with stability consideration for SPL scoping provides project managers with a robust and flexible way to address uncertainty in the process of SPL scoping.     

A Feature Model Based Framework for Refactoring Software Product Line Architecture

Software product line (SPL) is an approach used to develop a range of software products with a high degree of similarity. In this approach, a feature model is usually used to keep track of similarities and differences. Over time, as modifications are made to the SPL, inconsistencies with the feature model could arise. The first approach to dealing with these inconsistencies is refactoring. Refactoring consists of small steps which, when accumulated, may lead to large-scale changes in the SPL, resulting in features being added to or eliminated from the SPL. In this paper, we propose a framework for refactoring SPLs, which helps keep SPLs consistent with the feature model. After some introductory remarks, we describe a formal model for representing the feature model. We express various refactoring patterns applicable to the feature model and the SPL formally, and then introduce an algorithm for finding them in the SPL. In the end, we use a real-world case study of an SPL to illustrate the applicability of the framework introduced in the paper.     

Secure Tropos framework for software product lines requirements engineering

Security and requirements engineering are two of the most important factors of success in the development of a software product line (SPL). Goal-driven security requirements engineering approaches, such as Secure Tropos, have been proposed as a suitable paradigm for elicitation of security requirements and their analysis on both a social and a technical dimension. Nevertheless, goal-driven security requirements engineering methodologies are not appropriately tailored to the specific demands of SPL, while on the other hand specific proposals of SPL engineering have traditionally ignored security requirements. This paper presents work that fills this gap by proposing “SecureTropos-SPL” framework.     

SPL Conqueror: Toward optimization of non-functional properties in software product lines

A software product line (SPL) is a family of related programs of a domain. The programs of an SPL are distinguished in terms of features, which are end-user visible characteristics of programs. Based on a selection of features, stakeholders can derive tailor-made programs that satisfy functional requirements. Besides functional requirements, different application scenarios raise the need for optimizing non-functional properties of a variant. The diversity of application scenarios leads to heterogeneous optimization goals with respect to non-functional properties (e.g., performance vs. footprint vs. energy optimized variants). Hence, an SPL has to satisfy different and sometimes contradicting requirements regarding non-functional properties. Usually, the actually required non-functional properties are not known before product derivation and can vary for each application scenario and customer. Allowing stakeholders to derive optimized variants requires us to measure non-functional properties after the SPL is developed. Unfortunately, the high variability provided by SPLs complicates measurement and optimization of non-functional properties due to a large variant space. With SPL Conqueror, we provide a holistic approach to optimize non-functional properties in SPL engineering. We show how non-functional properties can be qualitatively specified and quantitatively measured in the context of SPLs. Furthermore, we discuss the variant-derivation process in SPL Conqueror that reduces the effort of computing an optimal variant. We demonstrate the applicability of our approach by means of nine case studies of a broad range of application domains (e.g., database management and operating systems). Moreover, we show that SPL Conqueror is implementation and language independent by using SPLs that are implemented with different mechanisms, such as conditional compilation and feature-oriented programming.     

Intelligent software product line configurations: A literature review

A software product line (SPL) is a set of industrial software-intensive systems for configuring similar software products in which personalized feature sets are configured by different business teams. The integration of these feature sets can generate inconsistencies that are typically resolved through manual deliberation. This is a time-consuming process and leads to a potential loss of business resources. Artificial intelligence (AI) techniques can provide the best solution to address this issue autonomously through more efficient configurations, lesser inconsistencies and optimized resources. This paper presents the first literature review of both research and industrial AI applications to SPL configuration issues. Our results reveal only 19 relevant research works which employ traditional AI techniques on small feature sets with no real-life testing or application in industry. We categorize these works in a typology by identifying 8 perspectives of SPL. We also show that only 2 standard industrial SPL tools employ AI in a limited way to resolve inconsistencies. To inject more interest and application in this domain, we motivate and present future research directions. Particularly, using real-world SPL data, we demonstrate how predictive analytics (a state of the art AI technique) can separately model inconsistent and consistent patterns, and then predict inconsistencies in advance to help SPL designers during the configuration of a product.     

Software product line scoping and requirements engineering in a small and medium-sized enterprise: An industrial case study

Software product line (SPL) engineering has been applied in several domains, especially in large-scale software development. Given the benefits experienced and reported, SPL engineering has increasingly garnered interest from small to medium-sized companies. It is possible to find a wide range of studies reporting on the challenges of running a SPL project in large companies. However, very little reports exist that consider the situation for small to medium-sized enterprises and these studies try develop universal truths for SPL without lessons learned from empirical evidence need to be contextualized. This study is a step towards bridging this gap in contextual evidence by characterizing the weaknesses discovered in the scoping (SC) and requirements (RE) disciplines of SPL. Moreover, in this study we conducted a case study in a small to medium sized enterprises (SMEs) to justify the use of agile methods when introducing the SPL SC and RE disciplines through the characterization of their bottlenecks. The results of the characterization indicated that ineffective communication and collaboration, long iteration cycles, and the absence of adaptability and flexibility can increase the effort and reduce motivation during project development. These issues can be mitigated by agile methods.