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 multiuser 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. 2 Research methodology 2.1 Identifying and filtering the UML modelling tools The existing UML modelling tools used in this study have been determined through a comprehensive literature search that has been conducted systematically. The literature search herein required four steps to be performed: (i) the Google search, (ii) the search for any websites that list some UML tools, (iii) the search for online forums on UML, and (iv) the Google scholar search. Concerning
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.
Architectural connectors can increase the modularity and reusability benefits of Component-based Software Engineering, as they allow one to specify the general case of an interaction pattern and reuse it from then on. At the same time they enable components to be protocol-independent -components do not need to know under which interaction patterns they will be used, as long as their minimal, local interaction constraints are satisfied. Without connectors one can specify only specific instances of such patterns and components need to specify themselves the interaction protocols that they will follow, thus reducing their reusability.Connector frameworks so far allow designers to specify systems that are unrealizable in a decentralized manner, as they allow designers to impose global interaction constraints. These frameworks either ignore the realizability problem altogether, ignore connector behaviour when generating code, or introduce a centralized controller that enforces these global constraints but does so at the price of invalidating any decentralized properties of the architecture.We show how the XCD ADL extends Design-by-Contract (DbC) for specifying (i) protocol-independent components, and (ii) arbitrary connectors that are always realizable in a decentralized manner as specified by an architecture -XCD connectors impose local constraints only. Use of DbC will hopefully make it easier for practitioners to use the language, compared to languages using process algebras. We show how XCD specifications can be translated to ProMeLa so as to verify that (i) provided services local interaction constraints are satisfied, (ii) provided services functional pre-conditions are complete, (iii) there are no race-conditions, (iv) event buffer sizes suffice, and (v) there is no global deadlock. Without formally analyzable architectures errors can remain undiscovered for a long time and cost too much to repair.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.