Towards a design-by-contract based approach for realizable connector-centric software architectures

Despite being a widely-used language for specifying software systems, UML remains less than ideal for software architectures. Architecture description languages (ADLs) were developed to provide more comprehensive support. However, so far the application of ADLs in practice has been impeded by at least one of the following problems: (i) advanced formal notations, (ii) lack of support for complex connectors, and (iii) potentially unrealizable designs. In this paper we propose a new ADL that is based on Design-by-Contract (DbC) for specifying software architectures. While DbC promotes a formal and precise way of specifying system behaviours, it is more familiar to practising developers, thus allowing for a more comfortable way of specifying architectures than using process algebras. Furthermore, by granting connectors a first-class status, our ADL allows designers to specify not only simple interaction mechanisms as connectors but also complex interaction protocols. Finally, in order to ensure that architectural designs are always realizable we eliminate potentially unrealizable constructs in connector specifications (the connector “glue”)

Competences of IT Architects

The field of architecture in the digital world uses a plethora of terms to refer to different kinds of architects, and recognises a confusing variety of competences that these architects are required to have. Different service providers use different terms for similar architects and even if they use the same term, they may mean something different. This makes it hard for customers to know what competences an architect can be expected to have.\ud \ud This book combines competence profiles of the NGI Platform for IT Professionals, The Open Group Architecture Framework (TOGAF), as well as a number of Dutch IT service providers in a comprehensive framework. Using this framework, the book shows that notwithstanding a large variety in terminology, there is convergence towards a common set of competence profiles. In other words, when looking beyond terminological differences by using the framework, one sees that organizations recognize similar types of architects, and that similar architects in different organisations have similar competence profiles. The framework presented in this book thus provides an instrument to position architecture services as offered by IT service providers and as used by their customers.\ud \ud The framework and the competence profiles presented in this book are the main results of the special interest group “Professionalisation” of the Netherlands Architecture Forum for the Digital World (NAF). Members of this group, as well as students of the universities of Twente and Nijmegen have contributed to the research on which this book is based

Development of Variant of Software Architecture Implementation for Low-power General Purpose Microcontrollers by Finite State Machines

As a result of the research, two directions for development of software architecture for low-power general purpose microcontrollers (LPGPM) are identified. The first, classical approach is the development using standard State patterns. The second is the development of programs, algorithms and structures based on mathematical analysis.The first direction is chosen in the work. The variant of the implementation of a typical pattern for development of software architecture (SA) in the form of a finite state machine (FSM) is proposed to discussion. This pattern allows to divide the development of the architectural part of the program for LPGPM and programming the LPGPM hardware. This approach makes it possible to divide the work of the software architect and the work of LPGPM hardware specialists. Advantage of the solution in comparison with the real time operating system (RTOS) is the saving of LPGPM hardware resources. In addition, it improves the readability of code and good testing prospects. The resulting architecture makes it possible to easily accompany the software and switch to other types of microcontroller. The disadvantage is an increase in the required amount of RAM with an increase in the number of states. It is this disadvantage that requires the application not only of experimental and engineering-intuitive methods, but also to continue research in the second direction

A Longitudinal Study of Identifying and Paying Down Architectural Debt

Architectural debt is a form of technical debt that derives from the gap between the architectural design of the system as it "should be" compared to "as it is". We measured architecture debt in two ways: 1) in terms of system-wide coupling measures, and 2) in terms of the number and severity of architectural flaws. In recent work it was shown that the amount of architectural debt has a huge impact on software maintainability and evolution. Consequently, detecting and reducing the debt is expected to make software more amenable to change. This paper reports on a longitudinal study of a healthcare communications product created by Brightsquid Secure Communications Corp. This start-up company is facing the typical trade-off problem of desiring responsiveness to change requests, but wanting to avoid the ever-increasing effort that the accumulation of quick-and-dirty changes eventually incurs. In the first stage of the study, we analyzed the status of the "before" system, which indicated the impacts of change requests. This initial study motivated a more in-depth analysis of architectural debt. The results of this analysis were used to motivate a comprehensive refactoring of the software system. The third phase of the study was a follow-on architectural debt analysis which quantified the improvements made. Using this quantitative evidence, augmented by qualitative evidence gathered from in-depth interviews with Brightsquid's architects, we present lessons learned about the costs and benefits of paying down architecture debt in practice.Comment: Submitted to ICSE-SEIP 201

Evaluating Software Architectures: Development Stability and Evolution

We survey seminal work on software architecture evaluationmethods. We then look at an emerging class of methodsthat explicates evaluating software architectures forstability and evolution. We define architectural stabilityand formulate the problem of evaluating software architecturesfor stability and evolution. We draw the attention onthe use of Architectures Description Languages (ADLs) forsupporting the evaluation of software architectures in generaland for architectural stability in specific

Extending architectural vocabulary

A discussion of the role of metaphor and reinterpretation in extending architectural vocabularies

Framework for software architecture visualization assessment.

In order to assess software architecture visualisation strategies, we qualitatively characterize then construct an assessment framework with 7 key areas and 31 features. The framework is used for evaluation and comparison of various strategies from multiple stakeholder perspectives. Six existing software architecture visualisation tools and a seventh research tool were evaluated. All tools exhibited shortcomings when evaluated in the framework