Use of a multidimensional approach to study the evolution of software complexity

The ability of a software system to survive is not only dependent on a good architectural design, but also the effective management of architectural changes as the system evolves over time. With the emergence of incremental and evolutionary development approaches, this evolution is no longer restricted to the maintenance phase of development, but now manifests itself during system elaboration and construction. Structural complexity is often inadvertently introduced as the number of interdependencies between parts of the system grows and design goals are violated. Such increasing complexity may paradoxically impede its survivability. Software architects must, therefore, learn to track, manage, and mitigate software complexity since, left unchecked, it can lead to systems that are difficult to maintain and evolve. There are two key aspects of software systems that must be monitored in order to effectively manage the inherent complexity that is systematically introduced in evolving systems: the stability of intermediate forms must be preserved, and structural complexity must be monitored to prevent incidental (excessive) complexity from being introduced. While these key aspects of software architecture are often monitored independently in evolving systems, an integrative metric-based approach would provide a more comprehensive means of assessing the impact that architectural changes have on overall system quality. In this study, an integrative, multidimensional approach was used to examine the evolutionary changes that occurred in the architectural stability and structural complexity over 21 releases of Hibernate, a large-scale open source software system.     

Variability-aware architecture level optimization techniques for robust nanoscale chip design

The design space for nanoscale CMOS circuits is vast, with multiple dimensions corresponding to process variability, leakage, power, thermal, reliability, security, and yield considerations. These design issues in the form of either objectives or constraints can be handled at various levels of digital design abstraction, such as architectural, logic and transistor. At the architectural level (a.k.a. Register-Transfer Level, RTL), there is a balanced degree of freedom for fast design exploration by exploring various values of design parameters. Correct design decisions at an early phase of the design cycle ensure that design errors are not propagated to lower levels of circuit abstraction, where it is costly to correct them. Moreover, design optimization at higher levels of abstraction provides a convenient way to deal with design complexity, facilitates design verification, and increases design reuse through intellectual property (IP) cores.     

Agent系统软件体系结构形式化建模方法

基于Agent技术为复杂分布式问题提供了求解方法。软件体系结构是控制软件复杂性、提高软件系统质量、支持软件开发和复用的重要手段之一。软件体系结构设计可用于描述Agent与Agent之间的交互和组织结构的规划,因此Agent系统能从良好的体系结构设计中受益。该文整合了图表句法理论和层次谓词变迁网理论,提出一种形式化建模方法,从抽象层(架构)和实现层(动态行为)两方面来构建Agent系统的软件体系结构。模型具有可验证和追踪性,为Agent系统软件体系结构分析与评估提供了良好的基础。     

基于体系结构模型检查分布式控制系统

分布控制系统是大量硬件设备通过计算机系统得以控制和协调的高度复杂系统,它们也是任务统,需要保障其功能的高度正确性和可靠性.分析复杂控制系统的过程包含了证明或验证设计的系统确实满足某种需求.但由于系统的复杂度,有效分析系统是相当困难的.从系统设计和分析的角度看,基于体系结构方法可以运用层次化构造和抽象的方法来减小模型复杂度.模型检查技术是分析复杂系统构造满足正确和可靠性需求的有效方法.结合软件体系结构描述方法和模型检查技术,提出了基于体系结构的分布式控制系统形式分析方法,通过楼宇综合控制系统实例研究,展示了该方法在提高分布式控制系统设计质量方面的效果.     

一种支持设计时软件重用的方法ArchBean

目前,在设计阶段重用软件体系结构所面临的主要问题是:虽然存在大量的具有重用价值的体系结构制品,但是这些制品却难以得到成功的重用.提出了一种支持软件体系结构设计时重用的ArchBean方法.该方法基于反射机制将支持重用的元信息和体系结构制品本身封装成自包含、自描述的大粒度可重用资.源.给出了支持这种方法的反射机制RMRSA和反射式软件体系结构.基于Object-Z形式化描述了PMB协议.详细给出了基于ArchBean方法的支撑工具ArchBean Studio的设计和实施过程.     

以决策为中心的软件体系结构设计方法

提出针对体系结构层次设计的决策抽象和问题分解原则,以及基于该原则的一种以决策为中心的体系结构设计方法.该方法从决策的视角对体系结构进行建模,并通过一个从导出体系结构关键问题到对体系结构方案决策的过程完成设计,还在其中实现了候选体系结构方案的自动合成以及设计决策与理由的捕捉.这种以决策为中心的方法切合体系结构层次的特点,降低了体系结构设计的复杂性和设计决策与理由捕捉的代价.     

一种软件体系结构设计决策的建模工具

体系结构设计在整个软件生命周期中起到关键作用,而设计知识的蒸发会导致系统演化花费代价高、涉众之间交流出现障碍、体系结构制品的复用受到限制等问题,为此需要在软件体系结构层次对设计决策进行显式化的建模.基于一种以决策为中心的体系结构设计方法,实现了一个软件体系结构设计决策的建模工具.该工具帮助架构师对体系结构设计中的问题、方案、决策、理由等核心概念进行建模,完成从需求到体系结构的设计过程,并实现了自动化的候选体系结构方案的合成和部分设计理由的捕捉.该工具还提供了体系结构设计模型与设计决策之间的相互追踪性,以及帮助实现体系结构设计过程中设计决策知识的复用.     

A comparative evaluation of hardware-only and software-only directory protocols in shared-memory multiprocessors

The hardware complexity of hardware-only directory protocols in shared-memory multiprocessors has motivated many researchers to emulate directory management by software handlers executed on the compute processors, called software-only directory protocols.In this paper, we evaluate the performance and design trade-offs between these two approaches in the same architectural simulation framework driven by eight applications from the SPLASH-2 suite. Our evaluation reveals some common case operations that can be supported by simple hardware mechanisms and can make the performance of software-only directory protocols competitive with that of hardware-only protocols. These mechanisms aim at either reducing the software handler latency or hiding it by overlapping it with the message latencies associated with inter-node memory transactions. Further, we evaluate the effects of cache block sizes between 16 and 256 bytes as well as two different page placement policies. Overall, we find that a software-only directory protocol enhanced with these mechanisms can reach between 63% and 97% of the baseline hardware-only protocol performance at a lower design complexity.     

Fault Tolerance via Diversity for Off-the-Shelf Products: A Study with SQL Database Servers

If an off-the-shelf software product exhibits poor dependability due to design faults, then software fault tolerance is often the only way available to users and system integrators to alleviate the problem. Thanks to low acquisition costs, even using multiple versions of software in a parallel architecture, which is a scheme formerly reserved for few and highly critical applications, may become viable for many applications. We have studied the potential dependability gains from these solutions for off-the-shelf database servers. We based the study on the bug reports available for four off-the-shelf SQL servers plus later releases of two of them. We found that many of these faults cause systematic noncrash failures, which is a category ignored by most studies and standard implementations of fault tolerance for databases. Our observations suggest that diverse redundancy would be effective for tolerating design faults in this category of products. Only in very few cases would demands that triggered a bug in one server cause failures in another one, and there were no coincident failures in more than two of the servers. Use of different releases of the same product would also tolerate a significant fraction of the faults. We report our results and discuss their implications, the architectural options available for exploiting them, and the difficulties that they may present.     

基于场景的面向方面软件体系结构度量方法

软件体系结构的评估为提高软件质量、控制系统复杂性提供保证,但多数单纯基于场景或基于度量的评估技术普遍存在度量角度单一的问题.针对该问题,结合场景技术提出了一种支持面向方面软件体系结构的度量方法.通过一组度量指标对体系结构进行度量并量化其结构特征;引入场景更细粒度地刻画体系结构的质量属性,考察场景在体系结构中的映射程度.最后对某保险案例的体系结构设计方案进行对比与选择,验证了方法的可行性及实用价值.两种技术的结合为更全面地进行面向方面软件体系结构的评估提供支持与参考.     

Architectural design of a common operating environment

The Global Command and Control System is the next generation replacement for the legacy World Wide Military Command and Control System, which has served the command and control needs of several high level US military commands for more than 20 years. The GCCS is implemented on heterogeneous Unix workstations as opposed to the WWMCCS's mainframe implementation. The GCCS will eventually extend down to tactical levels of command and control not encompassed by the earlier system. For this and other reasons, the Defense Information Systems Agency is undertaking the architectural design of the new GCCS common operating environment. The architecture for the Global Command and Control System's new common operating environment will comprise several modern architectural concepts currently used in complex, distributed systems. We plan to reduce the environment's complexity by using architectural components supported by existing commercial products and standards     

Applications of clustering techniques to software partitioning,recovery and restructuring

The artifacts constituting a software system are sometimes unnecessarily coupled with one another or may drift over time. As a result, support of software partitioning, recovery, and restructuring is often necessary. This paper presents studies on applying the numerical taxonomy clustering technique to software applications. The objective is to facilitate those activities just mentioned and to improve design, evaluation and evolution. Numerical taxonomy is mathematically simple and yet it is a useful mechanism for component clustering and software partitioning. The technique can be applied at various levels of abstraction or to different software life-cycle phases. We have applied the technique to: (1) software partitioning at the software architecture design phase; (2) grouping of components based on the source code to recover the software architecture in the reverse engineering process; (3) restructuring of a software to support evolution in the maintenance stage; and (4) improving cohesion and reducing coupling for source code. In this paper, we provide an introduction to the numerical taxonomy, discuss our experiences in applying the approach to various areas, and relate the technique to the context of similar work.     

Characteristics of multiple-component defects and architectural hotspots: a large system case study

The architecture of a large software system is widely considered important for such reasons as: providing a common goal to the stakeholders in realising the envisaged system; helping to organise the various development teams; and capturing foundational design decisions early in the development. Studies have shown that defects originating in system architectures can consume twice as much correction effort as that for other defects. Clearly, then, scientific studies on architectural defects are important for their improved treatment and prevention. Previous research has focused on the extent of architectural defects in software systems. For this paper, we were motivated to ask the following two complementary questions in a case study: (i) How do multiple-component defects (MCDs)—which are of architectural importance—differ from other types of defects in terms of (a) complexity and (b) persistence across development phases and releases? and (ii) How do highly MCD-concentrated components (the so called, architectural hotspots) differ from other types of components in terms of their (a) interrelationships and (b) persistence across development phases and releases? Results indicate that MCDs are complex to fix and are persistent across phases and releases. In comparison to a non-MCD, a MCD requires over 20 times more changes to fix it and is 6 to 8 times more likely to cross a phase or a release. These findings have implications for defect detection and correction. Results also show that 20% of the subject system’s components contain over 80% of the MCDs and that these components are 2–3 times more likely to persist across multiple system releases than other components in the system. Such MCD-concentrated components constitute architectural “hotspots” which management can focus upon for preventive maintenance and architectural quality improvement. The findings described are from an empirical study of a large legacy software system of size over 20 million lines of code and age over 17 years.     

A granularity model for balancing the structural complexity of manufacturing systems equipment and layout

The structural complexity of a manufacturing system results primarily from the complexity of its equipment and their layout. The balance between both complexity sources can be achieved by searching for the best system granularity level, which yields a manufacturing system with the least overall structural complexity. A new system granularity complexity index is developed to sum up and normalize the complexity resulting from the system layout complexity and the equipment structural complexity. A previously developed layout complexity index together with a code-based structural complexity assessment are used to determine the structural complexity of standalone pieces of equipment and to arrive at a balance between the two sources of complexity. Cladistics analysis is used to hierarchically cluster required pieces of equipment and bundle them into more integrated equipment and machines and demonstrate the possible different system granularity levels. The new developed model is a useful tool to create specific system configuration and layout alternatives based on system components adjacency, and then select the system design with the least overall structural complexity among those alternatives. The results of the presented case study clearly demonstrated this trade-off where decomposing manufacturing systems into a highly granular configuration with standalone machines maximizes system layout complexity and minimizes equipment complexity, while at a low level of granularity pieces of equipment are bundled into complex integrated machines, lines or cells but with a very simple system layout.     

Setting quality targets for coming releases with QUPER: an industrial case study

Quality requirements play a critical role in driving architectural design and are an important issue in software development. Therefore, quality requirements need to be considered, specified, and quantified early during system analysis and not later in the development phase in an ad-hoc fashion. This paper presents the quality performance model that estimates quality targets in relation to market expectations as a basis for the architecting of quality requirements. The purpose of the model is to provide concepts for qualitative reasoning of quality levels in the decision-making of setting actual targets of quality requirements for coming releases of the product. The quality performance model is evaluated at one case company, using a market-driven development approach, in the electronic payment-processing domain. The results show that the model is useful for supporting early decision-making in, e.g., release planning of quality requirements.     

几种常见软件体系结构模型的分析

随着计算机科学技术的发展，软件的规模和应用领域迅速扩大，造成了软件复杂程度的不断加大，所以高效地开发出高质量的软件产品越来越困难，于是软件开发人员开始关注于如何找到理解软件的更好途径和是否存在更好的途径来构造复杂的大型软件系统。研究软件体系结构就是解决这些问题的有力方法，经过对常见软件体系结构模型的分析后提出：根据待开发软件的应用场合和所处理问题的特点选取合适的体系结构，有利于缩短开发周期、节约开发成本和软件维护。     

CHARMY: A Framework for Designing and Verifying Architectural Specifications

Introduced in the early stages of software development, the Charmy framework assists the software architect in making and evaluating architectural choices. Rarely, the software architecture of a system can be established once and forever. Most likely poorly defined and understood architectural constraints and requirements force the software architect to accept ambiguities and move forward to the construction of a suboptimal software architecture. Charmy aims to provide an easy and practical tool for supporting the iterative modeling and evaluation of software architectures. From an UML-based architectural design, an executable prototype is automatically created. Charmy simulation and model checking features help in understanding the functioning of the system and discovering potential inconsistencies of the design. When a satisfactory and stable software architecture is reached, Java code conforming to structural software architecture constraints is automatically generated through suitable transformations. The overall approach is tool supported.     

Computer aided design of a three-dimensional steel frame

This paper describes the sequence of events leading to the successful construction of a three dimensional welded and bolted steel frame which formed the structural support for the floors and roof of a church in Mt. Washington, Ohio. The structure was conceived, planned, designed and checked using the concept of computer aided design by means of ICES-STRUDL. The paper illustrates analysis, design, construction and shows the completed structure. The architectural concept was based on the structural system. Itwas conceived jointly by the architect and the structural engineer as a working team prior to the job competition.The preliminary design and its necessary analysis was performed during this conceptual stage at which time it was determined that the proposed system was feasible with respectto aesthetics, with respect to construction and costs, as well as with respect to being capable of proper analysis and design. The final design was then accomplished by both planar frame assumptions and space frame assumptions, where proper releases were employed in both analyses to account for the designer's best estimation of the actual behavior of the physical joints and connections. This was handled by ICES STRUDL-I on the IBM 360/365 digital computer using the capabilities of loading combinations, joint releases, section properties, deformation values, etc. The lack of accuracy of such an elastic and linear structural computer package is also briefly documented. It is relevant with respect to the actual connections in field construction. The framed structure was actually controlled by deflection criteria, although said criteria was not actually provided by the specifications per se, but rather by the psychological aspects of observable sway. Since this was a highly indeterminate and complex space frame, the interaction of member properties, joint framing, analysis, member checks with respect to specifications, and deformation could only have been successfully satisfied by means of a computer aided process.The main theme is the use of computer-aided design techniques in the planning stage and the preliminary design stage, where it was mandatory to determine the general feasibility of the overall system so that the architectural presentation could be accurately portrayed. An above normal degree of accuracy was also essential in the final design checks and thus a computer oreinted design process was essential to the successful execution of this type of structural system and its integration a priori into the architectural system.     

Guest Editors' Introduction: Raising the Abstraction Level of Hardware Design

Design complexity is continually rising with the higher levels of integration implied by Moore's law. Functional complexity increases as more computation is added to SoCs and as more-complex applications are developed. Additional complexity is introduced by the need to control power consumption and to tackle challenges with respect to physical timing closure and process variations. To manage this complexity requires automation, letting designers focus on high-level design decisions that have the most effect in the implementation's quality. A higher level of hardware design abstraction also enables an effective exploration of software and hardware architectures, making high-level synthesis a cornerstone of electronic system-level design. This special issue features nine articles that the authors believe will generate interest in the use of high-level synthesis and its further development.     

软件体系结构求精方法研究

1.引言软件设计在相当大的程度上可与建筑设计相类比,在古今中外建筑设计中,有诸多如欧洲的“歌特式”、“巴洛克式”、“维多利亚式”,中国的“园林式”、“宫廷式”等不同结构风格的建筑。同样在软件设计上,经过多年的理论探索和工程实践,也逐渐形成了一系列不同结构风格的软件体系结构。如UNIX操作系统中的管道一过滤器(pipe-filters)风格、分布式系统中典型的客户机/服务器(client/server)风格以及通信系统中的分层(layer)系统等等。