Conference PaperPDF Available

Software architecture for systems of software intensive systems (S3): The concepts and detection of inter-system relationships

Authors:

Abstract and Figures

Key to software architecture is the description of relationships between software components [10] supported by commonly understood semantic definitions [9][8]. However, the definitions do not adequately capture the inter-system level software relationships. This leaves software architects either unaware of critical relationships or, to 'roll their own' based on aggregations of code-level call/use structures. This leads to critical gaps in the architectural description and communication problems within distributed development environments - as poorly understood relationships can inadvertently propagate changes and break system interoperability [2]. The solution requires a description of new system level relationships and a new systematic, repeatable technique to detect both immediate and linked system level relationships. The solution will be developed through the mining of existing software ecosystems and industry systems of software intensive systems (S3) architectures. Validation will be performed through case studies from industry collaborations.
Content may be subject to copyright.
Article
ContextComplex software-intensive systems comprise many subsystems that are often based on heterogeneous technological platforms and managed by different organizational units. Multi product lines (MPLs) are an emerging area of research addressing variability management for such large-scale or ultra-large-scale systems. Despite the increasing number of publications addressing MPLs the research area is still quite fragmented.Objective The aims of this paper are thus to identify, describe, and classify existing approaches supporting MPLs and to increase the understanding of the underlying research issues. Furthermore, the paper aims at defining success-critical capabilities of infrastructures supporting MPLs.Method Using a systematic literature review we identify and analyze existing approaches and research issues regarding MPLs. Approaches described in the literature support capabilities needed to define and operate MPLs. We derive capabilities supporting MPLs from the results of the systematic literature review. We validate and refine these capabilities based on a survey among experts from academia and industry.ResultsThe paper discusses key research issues in MPLs and presents basic and advanced capabilities supporting MPLs. We also show examples from research approaches that demonstrate how these capabilities can be realized.Conclusions We conclude that approaches supporting MPLs need to consider both technical aspects like structuring large models and defining dependencies between product lines as well as organizational aspects such as distributed modeling and product derivation by multiple stakeholders. The identified capabilities can help to build, enhance, and evaluate MPL approaches.
Article
Full-text available
An important aspect of architectural knowledge is the cap-ture of software relationships[25]. But current definitions[25] [21][23] do not adequately capture external system relation-ships[5], and offer no guidance on implicit relationships[29]. This leaves architects either unaware of critical relationships or, to 'roll their own' based on aggregations of code-level call structures, resulting in critical architectural gaps and com-munication problems within Systems of Software intensive Systems (S3) environments[2]. These environments may also restrict the sharing of architectural knowledge due to either legal, or contractual constraints, or overwhelm due to the size and number of involved systems adding to the challenges of identifying and describing the relationships. This paper presents a novel S3 Architectural Viewpoint consisting of; 1) an extensible taxonomy of relationships (building on existing relationship concepts), 2) a systematic, repeatable technique to detect both immediate and com-posite relationships, and 3) proposes the Annotated Design Structure Matrix to link S3 views, with existing dependency analysis technique. The goal is an architectural approach for sharing and analysis of architectural knowledge relating to relationships, in an S3 environment. The research is on-going and validation will be performed through case studies from industry collaborations.
Conference Paper
Full-text available
It has been well documented that there is a correlation between the structure of an architecture and the organization that produces it. More concretely there is a correlation between task interdependencies and coordination among the people or teams realizing these tasks. The amount of coordination needed among teams is related to the nature of these task interdependencies. As the scale and complexity of organization and systems grow it is not uncommon to have factors such as geographic boundaries, organization boundaries, cultural differences, and so forth impede the ability of certain individuals or teams to coordinate effectively. While there is some understanding of the factors that impede the ability of teams to coordinate, the factors that cause task interdependence in software systems is less well understood. The current view is that it is the interactions across module boundaries (assuming a module is assigned as a task or work item to a single team) that cause task interdependence; we have found that this view is not sufficient. In this paper we present three cases where additional architectural mechanisms created task interdependencies that the organizations were unable to accommodate. We go on to discuss the implications of these findings and suggest future research activities.
Conference Paper
Full-text available
According to Parnas's information hiding principle and Baldwin and Clark's design rule theory, the key step to decomposing a sys- tem into modules is to determine the design rules (or in Parnas's terms, interfaces) that decouple otherwise coupled design decisions and to hide decisions that are likely to change in independent mod- ules. Given a modular design, it is often difficult to determine whether and how itsimplementation realizes the designed modular- ity. Manually comparing code with abstract design is tedious and error-prone. We present an automated approach to check the con- formance of implemented modularity to designed modularity, using design structure matrices as a uniform representation for both. Our experiments suggest that our approach has the potential to manifest the decoupling effects of design rules in code, and to detect mod- ularity deviation caused by implementation faults. We also show that design and implementation models together provide a com- prehensive view of modular structure that makes certain implicit dependencies within code explicit. Categories and Subject Descriptors: D.2.11 (Software Engineer- ing): Software Architecture
Article
Full-text available
Prior research has shown that customer-reported software faults are often the result of violated dependencies that are not recognized by developers implementing software. Many types of dependencies and corresponding measures have been proposed to help address this problem. The objective of this research is to compare the relative performance of several of these dependency measures as they relate to customer-reported defects. Our analysis is based on data collected from two projects from two independent companies. Combined, our data set encompasses eight years of development activity involving 154 developers. The principal contribution of this study is the examination of the relative impact that syntactic, logical, and work dependencies have on the failure proneness of a software system. While all dependencies increase the fault proneness, the logical dependencies explained most of the variance in fault proneness, while workflow dependencies had more impact than syntactic dependencies. These results suggest that practices such as rearchitecting, guided by the network structure of logical dependencies, hold promise for reducing defects.
Article
While the phrase “system-of-systems” is commonly seen, there is less agreement on what they are, how they may be distinguished from “conventional” systems, or how their development differs from other systems. This paper proposes a definition, a limited taxonomy, and a basic set of architecting principles to assist in their design. As it turns out, the term system-of-systems is infelicitous for the taxonomic grouping. The grouping might be better termed “collaborative systems.” The paper also discusses the value of recognizing the classification in system design, and some of the problems induced by misclassification. One consequence of the classification is the identification of principal structuring heuristics for system-of-systems. Another is an understanding that, in most cases, the architecture of a system-of-systems is communications. The architecture is nonphysical, it is the set of standards that allow meaningful communication among the components. This is illustrated through existing and proposed systems. © 1999 John Wiley & Sons, Inc. Syst Eng 1: 267–284, 1998
Article
Software systems of today are frequently composed from prefabricated, heterogeneous components that provide complex functionality and engage in complex interactions. Software architecture research has revealed the importance of component interactions on our ability to perform software composition. Various development organizations have found interaction mismatches to be both difficult and a core issue behind failed software integration efforts. This paper is aimed at improving the understanding of component interactions, embodied in the notion of software connectors, in order to prevent such failures. Our previous work has resulted in a four-level classification framework for studying the characteristics of connectors. This paper presents a comprehensive taxonomy of software connectors based on the previously published connector classification framework. This taxonomy is used to explain various existing software connectors and study compatibility of connector characteristics, intended to prevent component interaction mismatches.
Article
Enterprise modeling using data dependencies is common in monitoring and business performance management systems. The modern enterprise is a dynamic creature, constantly adapting itself to the changing environment. This adaptation may result in changes in enterprise components and data dependencies between them. An enterprise model must be able to express this dynamism, and business performance management services must be able to react accordingly. In this paper, we briefly introduce ADI (Active Dependency Integration Technology), a language for modeling data dependencies between entities. We discuss developments related to support in modeling dynamic environments, where elements may be added or deleted. Dynamism-related developments include the support of automatic dependency instantiation from an abstract dependency. The abstract dependency expresses a general pattern in the ontology, functioning as a template for dependency instances. Another aspect of dynamism is support for changes in existing dependencies rather than only creating new dependencies; for example, adding a new entity to a dependency. Changes in topology do not imply system redeployment. ADI also supports the influence of dynamism on data items and subsequent propagation of this influence through the model.
Conference Paper
Evolution of software systems is characterized by inevitable changes of software and increasing software complexity, which in turn may lead to huge maintenance and development costs. For long-lived systems, there is a need to address and maintain evolvability (i.e. a systempsilas ability to easily accommodate changes) during the entire lifecycle. As designing software for ease of extension and contraction depends on how well the software structure is organized, this paper explores the relationships between evolvability, modularity and inter-module dependency. Through a case study of an industrial power control and protection system, we describe our work in managing its software architecture evolution, guided by the dependency analysis at the architectural level. The paper includes also the main analysis results, our experiences and reflections during the dependency analysis process in the case study.
Article
The primary objective of service-oriented architecture (SOA) is to use information technology to address the key goals of business today: innovation, agility, and market value. Agility in SOA is achieved by use of the principles of encapsulation, modularity, and loose coupling, which facilitates a cleaner separation of concerns. While loose coupling enables customers to rapidly reuse services in new applications, strong coherency must be maintained to achieve the primary business objectives of the application. When applications are composed of loosely coupled services that are independent (owned by different parts of the organization, based on disparate technology assumptions, and evolving on independent schedules and with diverse priorities) the coherency of the composite application can be undermined. In this paper, we examine how coherency can be created and maintained in loosely coupled applications. We examine, in this context, various techniques and design approaches, such as service management, the use of service buses, the role of industry models and semantic ontologies, and governance, to achieve and maintain coherency of composite applications using SOA.
Conference Paper
Modern systems modelling languages frequently support the use of multiple views in order to provide flexible, extensible, and rich mechanisms for capturing system characteristics. Architectural description languages (ADLs) often provide many useful capabilities but fail to provide support for ensuring view consistency simply because they present a single view of the system. An ADL used for building dependable systems must provide multiple views. For these kinds of systems, ensuring view consistency is critical so as to provide guarantees about the system as a whole. In this paper, we outline an architectural modelling language, AIM, which supports multiple views, but we focus on its first-class support for dependency links, which are used to ensure view consistency. We illustrate the principles on examples from a real engine control system.
Article
Methodological guidelines for object-oriented software construction that improve the reliability of the resulting software systems are presented. It is shown that the object-oriented techniques rely on the theory of design by contract, which underlies the design of the Eiffel analysis, design, and programming language and of the supporting libraries, from which a number of examples are drawn. The theory of contract design and the role of assertions in that theory are discussed.< >