The term “digital twin” has gained an ever-increasing popularity since the last five years. Digital twins promote the existence of a virtual counterpart of any physical system for monitoring the system behaviour and suggesting possible improvements automatically. Given many industries’ interest on developing and using digital twin systems, it becomes highly crucial to develop such systems with least cost and high quality. This can be addressed with the architecture-centric design approach. However, the literature still lacks in any approach that can be applied for the specifications of any digital twin system architectures and any concrete modeling notation set. In this paper, we propose an architecture modeling language called DTLang for the high-level specifications of any digital twin architectures. DTLang is based on the well-regarded C4 architecture model and thus offers 4 different architecture viewpoints which are context, container, component, and code viewpoints. Each viewpoint addresses a different concern and is related to another viewpoint for the hierarchical (i.e., traceable) specifications of digital twin system architectures. With DTLang, the viewpoint models can be specified separately using distinct graphical notation sets and also can easily be traced between each other. We demonstrate the use of DTLang via the building fire protection case-study.

SAWUML is a general-purpose software modeling language that extends UML by unifying component and sequence diagrams for the specifications of software architectures.While component diagram is used for modeling the system structures, sequence diagram is extended with the Design-by-Contract approach for the modeling of system behaviors.In this paper, we aim at enhancing the language usability by providing alternative modeling choices for practitioners.To this end, we extended SAWUML's notation set with UML's activity diagram for the behavior modeling.So, practitioners may now use either sequence or activity diagrams, while the system structures are still modeled with component diagrams.We also extended SAWUML's modeling editor for creating software architecture models together with component and activity diagrams and the code generators for automatically obtaining (i) formal models in SPIN's ProMeLa for formal verification and (ii) Java-based implementation.We illustrate our language extension with the gas station case-study.

The ISO SQuaRE software quality standard categorises software quality into eight different characteristics: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability and portability. Each quality characteristic is further considered in terms of a cohesive set of sub-characteristics. In this paper, a survey has been conducted with the goal of understanding which software quality characteristics are popular in industries and any modeling languages and tools used for analysing the software quality. The survey has been performed with 16 experienced practitioners, who work for a Turkish software company and have been requested to answer a pre-determined set of questions. The survey results lead to many interesting outcomes, some of which are as follows: (i) maintainability and performance efficiency are the top-popular characteristics, while portability is the least, (ii) time behaviour is the top-considered performance sub-characteristic, (iii) interoperability is the top-considered compatibility sub-characteristic, (iv) learnability and appropriateness recognisability are the top-considered usability sub-characteristics, (v) availability is the top-considered reliability sub-characteristic, (vi) confidentiality and integrity are the top-considered security sub-characteristics, (vii) modularity and reusability are the top-considered maintainability sub-characteristics, (viii) none of the participants use any modeling languages for analysing the software quality early on, and (ix) the participants use COTS tools for analysing the software implementation.

Defensive programming is considered as a software design approach that promotes the reliable software development via the considerations of different cases for the software modules. Design-by-Contract (DbC) applies defensive programming systematically in terms of contracts that are a pair of pre-conditions on the module input and post-conditions on the module output. In this paper, a DbC-based teaching methodology is proposed, which aims to teach undergraduate students how to use contracts for the modeling and implementation of software systems. The teaching methodology consists of three consecutive steps. Firstly, the students will learn how to model software architectures in terms of components and their communication links. The component behaviours are specified as contracts, which are attached to the messages that the components exchange. In the second step, the students will learn how to implement the contractual software architectures in Java using Java’s assertion mechanisms in a way that the contractual design decisions are all preserved in the code. Lastly, the students will learn the Java Modeling Language for combining the contractual modeling and Java implementation in a single model to avoid any inconsistencies between the model and implementation and automatically verify the correctness of the implementation against the modeled behaviours.

Unified Modelling Language (UML) is essentially a de‐facto standard for software modeling and supported with many modeling tools. In this study, 58 UML tools have been analysed for modelling viewpoints, analysis, transformation & export, collaboration, tool integration, scripting, project management, and knowledge management. The analysis results reveal important findings: (i) 11 UML tools support multiple viewpoints, (ii) 17 tools support large‐viewpoint management, (iii) Umple and Reactive Blocks support formal verification, (iv) 9 tools support the simulation of activity diagrams, (v) while 14 tools check pre‐defined well‐formedness rules, 8 of them support user‐defined rules, (vi) 16 tools support scripting, (vii) 29 tools support code‐generation and 18 of them support round‐trip engineering, (viii) Java is the top popular language, (ix) 38 tools export UML models as image, 32 tools export as HTML, and 32 tools export as XML/XMI, (x) 17 tools enable versioning and 13 of them support multi‐user access, (xi) 15 tools support the plug‐in extensions and 12 tools support the IDE integration, (xii) 6 tools support project management, and (xiii) while most tools provide user‐manuals, interactive guidance is rarely supported. The results will be helpful for practitioners in choosing the right tool(s) and the tool developers in determining the weaknesses/strengths.

Software architecture is considered as the high-level decompositions of software systems into components and connectors. Connectors herein represent the component interactions and may be as simple as basic communication links without any functionalities or complex mediators that enforce some quality requirements on the component interactions. In this paper, the existing 124 different architectural languages (ALs) are analysed to understand which type(s) of connectors they support. The connectors considered in this study are procedure call, event, data access, linkage, stream, arbitrator, adaptor, and distributor. The analysis of the ALs for those connector types lead to many interesting results some of which are as follows: (i) the link connector is supported by almost all the ALs, and half of those ALs further support the specifications of high-level connectors (i.e., interaction protocols) for the linked components, (ii) many ALs define the high-level connectors in terms of the formal specification languages and pi-calculus is the their top choice, (iii) most of the ALs consider the procedure call and event connectors basically for method invocation and data transmission respectively, (iv) the data access connectors are mostly used as a simple data flow mechanism, and complex mechanisms (e.g., data translation) are ignored, (v) the stream connectors are supported indirectly via the formal methods, (vi) the arbitrator connectors are mostly considered for dealing with the concurrency issues, and (vii) the distributor connectors are shown the least interest by ALs.

Summary Architectural languages (ALs) have attracted much attention as the modeling notations for specifying and reasoning about important design decisions. In this study, 124 different existing ALs have been analyzed for a set of requirements that are crucial for practitioners. These requirements are concerned with language definition, language features, and tool support. Some of the important findings obtained from the analysis are as follows: (1) performance is the top popular nonfunctional requirement supported by ALs; (2) no ALs offer both textual and visual notation sets, one of which could be used independently; (3) process algebras are the top preferred formal method by formal ALs; (4) the physical, deployment, and operational viewpoints are rarely supported by ALs; (5) the top preferred extension mechanism of the extensible ALs is XML for syntax extension; (6) Java is the top preferred programming language in generating software code; (7) the exhaustive model checking is the top preferred automated analysis method; (8) the logic‐based formal techniques are so popular in specifying system requirements; (9) among the analysis properties considered, consistency is the top supported property for the automated checking; and (10) most ALs do not provide any discussion platform (eg, forums). Hence, these findings can be used by the new AL developers in addressing the needs of practitioners and bridging the gaps in the field. Practitioners can also use the findings to find out about the existing ALs and compare them to choose the one(s) that suits their needs best.

Software architecture has been proposed in the nineties as a high-level software design method for specifying software systems in terms of components and their relation. Since then, software architectures have become an indispensable part of software design. However, it remains dubious to what extent practitioners use software architectures in their software design. To better understand this, we conduct a survey study among a number of practitioners from both industry and academia and aim at understanding their level of knowledge and experience in software architectures. Our survey consists of a questionnaire of 20 questions, presented in four distinct sections. We run our survey on 50 participants, 11 of whom are from academia and the rest 39 are from industry. As a result of our analysis, we reached the following conclusion: while software architecture is highly crucial for practitioners given the nature of their software projects, practitioners' knowledge on software architectures is too limited. Practitioners use Unified Modelling Language (UML), which views software architectures as a method of communicating system structures. However, other aspects such as architectural analysis are equally crucial in detecting design errors and verifying software designs for quality properties.

Despite promoting precise modelling and analysis, architecture description languages (ADLs) have not yet gained the expected momentum. Indeed, practitioners prefer using far less formal languages like UML, thus hindering formal verification of models. One of the main issues with ADLs derives from process algebras which practitioners view as having a steep learning curve. In this paper, we introduce a new ADL called XCD which enables designers to model their software architectures through a Design-by-Contract approach, as for example in the Java Modelling Language (JML). We illustrate how XCD can be used in architectural modelling and analysis using the Aegis combat software system.

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”).

Design-by-Contract (DbC) gained wide familiarity among software developers for specifying software. It aids in documenting the behaviour of class methods as contracts between clients of the methods (pre-) and their suppliers (post-condition). This not only allows developers to document software behaviour precisely at such a high-level that can more easily be communicated, but also enables the formal verification of the behaviour. In this paper, we provide a comprehensive extension to DbC so that it can also be applied to the level of software architecture design. We illustrate this through our architecture description language XCD. Components in XCD have four different types of interfaces: provided and required interfaces of methods or emitter and consumer interfaces of events where methods/events are contractually specified. Contract specification is separated into functional and interaction contracts thus modularising the functional and interaction component behaviours. Furthermore, treating interaction protocols as connectors, XCD allows to specify connectors with interaction contracts that participating components adhere to. The formal semantics of XCD are defined using Finite State Process (FSP) thus enabling formal analysis of contractually specified software architectures for quality properties, e.g., deadlock.