(4) We offer a dataset of labeled UML class diagrams. (3) We evaluate the performance of our layout evaluator. (2) We analyze which features of UML class diagrams are most strongly related to the quality of their layout. (1) We show the feasibility of the automatic evaluation of the layout quality of UML class diagrams. ![]() This paper makes the following contributions: As ground truth, we use a dataset of 600+ UML Class Diagrams for which experts manually label the quality of the layout. We use machine learning techniques to build (linear) regression models based on features extracted from the class diagram images using image processing. In this way, this evaluator opens up the road for using machine learning to learn good layouting algorithms. (3) In the field of algorithm design for graph layouts, our evaluator can assess the layouts generated by such algorithms. (2) In an educational setting, the evaluator can grade the layout aspect of student assignments in courses on software modeling, analysis, and design. For example, automated feedback can be generated once a UML diagram is checked in the project repository. Such an automated evaluator has several uses: (1) From an industrial perspective, this tool could be used for automated quality assurance for class diagrams (e.g., as part of a quality monitor integrated into a DevOps toolchain). We use machine learning based on features extracted from the class diagram images using image processing. In this paper, we present an automated method for evaluating the layout quality of UML class diagrams. The quality of the layout of UML diagrams plays a crucial role in their comprehension. A key purpose of UML diagrams is to share knowledge about the system among developers. Mostly, UML diagrams capture an abstract view of a (piece of a) software system. UML diagrams are used in the analysis, construction, and maintenance of software systems. UML is the de facto standard notation for graphically representing software. Additionally, we compared the accuracy of Xamã and state-of-the-art tool img2UML, and we observe that Xamã outperformed img2UML in both precision and recall, being able to recognize 433 out of 614 textual elements as opposed to 171 by img2UML. With and without shape detection, Xamã correctly identified 956 and 905 elements, respectively, out of 1171. Xamã includes two approaches to identify whether the elements are positioned on a single line or multiple lines, and merge those identified as positioned on multiples lines. To address the multi-line text error, we build Xamã on top of Google Cloud Vision. This error happens when OCR misinterprets one textual element as two separate elements. We identified the multi-line text error as one of the main issues of using OCR to recognize textual elements in models from different domains. ![]() Errors made by Google Cloud Vision are due to absence of support for text common in engineering formulas, e.g., Greek letters, equations, and subscripts. ![]() Google Cloud Vision performed better than Microsoft Cognitive Services being able to detect text of 70% of model elements. We start by analyzing the performance of Google Cloud Vision and Microsoft Cognitive Services, two off-the-shelf OCR services. We select graphical models from various domains that typically combine textual and graphical elements. ![]() In this study, we investigate the suitability of optical character recognition (OCR) as a basis for such a uniformed approach. Notation independence implies that such a uniform approach can only be based on elements commonly present in models of different domains, i.e., text, boxes, and lines. Therefore, to ensure maintenance of multi-domain systems, we need a uniform approach that would be independent from the peculiarities of the notation. Indeed, these models are created using different modeling notations and it is not plausible to use a multitude of parsers geared toward each and every modeling notation. Only few tools, however, support management of models from different domains. Although these models belong to different domains, the changes in one model can affect other models causing inconsistencies in the entire system. For example, to develop a mechatronic component one might need to combine expertise about mechanics, electronics, and software. The development of systems following model-driven engineering can include models from different domains.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |