Creating product line architectures

The creation and validation of product line software architectures are inherently more complex than those of software architectures for single systems. This paper compares a process for creating and evaluating a traditional, one-of-a- kind software architecture with one for a reference software architecture. The comparison is done in the context of PuLSE-DSSA, a customizable process that integrates both product line architecture creation and evaluation

Reliability prediction in model driven development

Evaluating the implications of an architecture design early in the software development lifecycle is important in order to reduce costs of development. Reliability is an important concern with regard to the correct delivery of software system service. Recently, the UML Profile for Modeling Quality of Service has defined a set of UML extensions to represent dependability concerns (including reliability) and other non-functional requirements in early stages of the software development lifecycle. Our research has shown that these extensions are not comprehensive enough to support reliability analysis for model-driven software engineering, because the description of reliability characteristics in this profile lacks support for certain dynamic aspects that are essential in modeling reliability. In this work, we define a profile for reliability analysis by extending the UML 2.0 specification to support reliability prediction based on scenario specifications. A UML model specified using the profile is translated to a labelled transition system (LTS), which is used for automated reliability prediction and identification of implied scenarios; the results of this analysis are then fed back to the UML model. The result is a comprehensive framework for addressing software reliability modeling, including analysis and evolution of reliability predictions. We exemplify our approach using the Boiler System used in previous work and demonstrate how reliability analysis results can be integrated into UML models

Communication: key factor in multidisciplinary system design

System design research often looks at ways to model the system that is developing. Many modelling techniques and model representations exist. Another aspect these models can be used for is to enable, facilitate and improve communication among the developers during the process. The young System Design Group at the faculty of Engineering Technology of the University of Twente, the Netherlands, aims at focusing on this communication aspect in system design.\ud In the paper, a few finished and running projects undertaken in close cooperation with industry are described concisely. From these projects three research themes are derived. These are: creation of high-level models, combining model representations and condense information. The paper ends with plans for future research

The influence of CMMI on establishing an architecting process

A large IT company is creating a generic architecting process. Since the company has set an objective to achieve Maturity Level 3 of the Capability Maturity Model Integration (CMMI), the process needs to comply with the relevant requirements set by the CMMI. This paper presents the elicitation of such requirements, and the resulting set of requirements. It analyzes their potential impact on generic architecting processes found in literature. It turns out that many key architectural concepts are at best loosely defined in the CMMI. CMMI is strong in support of the development-related architecting activities, but gives only indirect support for other architecting activities, particularly in a product development context

AN EMERGING THEORY ON THE INTERACTION BETWEEN REQUIREMENTS ENGINEERING AND SYSTEMS ARCHITECTING BASED ON A SUITE OF EXPLORATORY EMPIRICAL STUDIES

Requirements Engineering and Systems Architecting are often considered the most important phases of the software development lifecycle. Because of their close proximity in the software development lifecycle, there is a high degree of interaction between these two processes. While such interaction has been recognized and researched in terms of new technology (particularly methods and tools), there is a distinct lack of empirical understanding regarding the scientific properties of this interaction. Furthermore, in Requirements Engineering and Systems Architecting, not only technical but human aspects are considered critical for the success of these processes due to these processes lying at the front-end of the development cycle and therefore being more aligned with real-world issues. Thus, the scientific properties of the interactions between Requirements Engineering and Systems Architecting can be broken down into these two key aspects. For instance, the following example research questions relate to such scientific properties: What is the impact of an existing system’s architecture on requirements decision-making? What kinds of requirements-oriented problems are encountered during architecting? What is the impact of an existing systems architecture on new requirements being elicited? What is the impact of requirements engineering knowledge on systems architecting? There is little in the literature addressing such questions. This thesis explores such issues through a suite of six exploratory empirical studies that were conducted over the last five years. Based on the observations from these studies, an emerging theory is proposed that describes the impact of human and process factors in the interaction between Requirements Engineering and Systems Architecting. The impact of this emerging body of knowledge is deemed to be on the following: technology development for Requirements Engineering and Software Architecting (methods, tools, processes, etc.); hiring and training personnel for Requirements Engineering and Systems Architecture processes in industry; Requirements Engineering and Systems Architecture project planning; curriculum improvement in academia; and future empirical research in Requirements Engineering and Systems Architecting

Issues of Architectural Description Languages for Handling Dynamic Reconfiguration

Dynamic reconfiguration is the action of modifying a software system at runtime. Several works have been using architectural specification as the basis for dynamic reconfiguration. Indeed ADLs (architecture description languages) let architects describe the elements that could be reconfigured as well as the set of constraints to which the system must conform during reconfiguration. In this work, we investigate the ADL literature in order to illustrate how reconfiguration is supported in four well-known ADLs: pi-ADL, ACME, C2SADL and Dynamic Wright. From this review, we conclude that none of these ADLs: (i) addresses the issue of consistently reconfiguring both instances and types; (ii) takes into account the behaviour of architectural elements during reconfiguration; and (iii) provides support for assessing reconfiguration, e.g., verifying the transition against properties.Comment: 6\`eme Conf\'erence francophone sur les architectures logicielles (CAL'2012), Montpellier : France (2012

Architecting specifications for test case generation

The Specification and Description Language (SDL) together with its associated tool sets can be used for the generation of Tree and Tabular Combined Notation (TTCN) test cases. Surprisingly, little documentation exists on the optimal way to specify systems so that they can best be used for the generation of tests. This paper, elaborates on the different tool supported approaches that can be taken for test case generation and highlights their advantages and disadvantages. A rule based SDL specification style is then presented that facilitates the automatic generation of tests

Missing Requirements Information and its Impact on Software Architectures: A Case Study

[Context & motivation] In the development of large, software-intensive systems, the system’s requirements are seldom, if ever, concluded upon prior to commencing with systems architecture. Research shows that, in order to manage development and domain complexities, instances of requirements engineering (RE) and systems architecting (SA) processes tend to inter-weave. [Question/problem] However, missing requirements information can cause one to create (or recreate) the needed information during different SA activities. While backtracking in the software development process is known to be costly, the costs associated with missing requirements in the SA process have not been investigated empirically. [Principal ideas/results] We thus conducted a case study where we investigated to what extent requirements or requirements attributes’ information found missing during the SA process and impact of those missing information on SA in terms of effort. The study involved five architecting teams that involve final year undergraduate and graduate students enrolled in the university course on SA, working on architecting a system falls under “banking” domain. Our result shows that, architects did find requirements and requirements attributes’ information missing while architecting. Among requirements information, architects found that, system functionality information, constraints information and system interaction (users/systems) information are missing in requirements at higher percentages. Within requirements’ attributes, architects found requirements priority, dependency and rationale missing at higher percentages. It is also found that, out of total time spent on architecting the system, effort given to recreate missing requirements information is higher for group3 (21.5%), group1 (18%), and group2 (17%) other than group4 (12.37%) and group5(10.18%). [Contribution] The anticipated benefits of the findings are, it can motivate researchers to venture into other areas of software engineering (such as coding, testing, maintenance, etc.) from the view point of missing requirements information and its impact on those areas. This knowledge could help software practitioners to decide what kind of information need to take care of, during RE process, that could possibly ease SA process and later development phases. To the best of my knowledge, this is the first work which focuses on, to what extent requirements and requirements’ attributes information found missing during SA; characteristics and impact of those requirements missing information on SA process in terms of effort

Flexible and Intelligent Learning Architectures for SOS (FILA-SoS)

Multi-faceted systems of the future will entail complex logic and reasoning with many levels of reasoning in intricate arrangement. The organization of these systems involves a web of connections and demonstrates self-driven adaptability. They are designed for autonomy and may exhibit emergent behavior that can be visualized. Our quest continues to handle complexities, design and operate these systems. The challenge in Complex Adaptive Systems design is to design an organized complexity that will allow a system to achieve its goals. This report attempts to push the boundaries of research in complexity, by identifying challenges and opportunities. Complex adaptive system-of-systems (CASoS) approach is developed to handle this huge uncertainty in socio-technical systems