Abstract Context Modern software systems change continuously. Larger changes like architectural redesigns, feature additions, or system-wide refactorings regularly impact the file structures within a software repository (i.e., developers adding, deleting, or moving files). Objective While a normal evolutionary phenomenon, file-structure changes in software repositories have received little attention in past research. An important question that arises is whether outliers (i.e., changes increasing or decreasing file structures more strongly) are potential signs of quality issues in repository management and tooling. Method In this article, we contribute the first large-scale study on outliers of file-structure changes. To this end, we investigated more than 12.2 million file-structure changes from 94,247 GitHub repositories that span ten programming languages. We first performed a quantitative analysis of all these changes to establish a baseline regarding the depths of file structures and changes to these. Using this baseline, we identified and manually inspected 3,049 outliers. Results Our quantitative data shows that file-structure changes are pervasive in the evolution of software repositories, representing 17.9% of all commits across the studied projects. Via our manual inspection, we found that outliers are often associated with programming errors, initial setups, and misconfigurations of package managers. Thus, they are an indicator of potential mistakes and quality problems. Conclusions Our findings demonstrate that current practices and tools for managing software repositories should take file-structure changes into account. This could help practitioners monitor for and mitigate erroneous or unintended structural changes. Researchers can use our methodology and findings to design follow-up studies and new techniques for more robust repository management.

Software is designed for humans and must account for their values. However, current research and practice focus on a narrow range of well-explored values, e.g. security, overlooking a more comprehensive perspective. Those exploring a broader array of values rely on manual identification, which is labour-intensive and prone to human bias. Moreover, existing methods offer limited reliability as they fail to explain their findings. In this paper, we propose leveraging the reasoning capabilities of Large Language Models (LLMs) for automated inference about values. This allows for not only detecting values but also explaining how they are expressed in the software. We aim to examine the effectiveness of LLMs, specifically ChatGPT (Chat Generative Pre-Trained Transformer), in automated detection and explanation of values in software artifacts. Using ChatGPT, we investigate how mobile APIs align with human values based on their documentation. Human evaluation of ChatGPT's findings shows a reciprocal shift in understanding values, with both ChatGPT and experts adjusting their assessments through dialogue. While experts recognise ChatGPT's potential for revealing values, emphasis is placed on human involvement to enhance the accuracy of the findings by detecting and eliminating convincing but inaccurate explanations provided by the language model due to potential hallucinations or confabulations.

This paper presents the Layered BubbleTea Visualisation, a novel approach to software visualisation that enhances the comprehension of software systems from an architectural perspective. The visualisation addresses the challenge of understanding complex software structures by mapping software components to architectural layers and elucidating their contents according to their relation to the stereotypical functionality of architectural layers. The paper details the development and presentation of the Layered BubbleTea Visualisation technique, illustrated using the source code of an Android email client application, K-9 Mail. We highlight the technique's potential to identify design issues and guide refactoring efforts. This work contributes to the field of software visualisation by offering a new approach to understanding and managing the complexity of software systems. Video URL-https://youtu.be/wvQNhmbyLtk

Software engineering is becoming more and more distributed. Developers and other stakeholders are often located in different locations, departments, and countries and operating within different time zones. Most online software design and modeling tools are not adequate for distributed collaboration since they do not support awareness and lack features for effective communication. The aim of our research is to support distributed software design activities in Virtual Reality (VR). Using design science research methodology, we design and evaluate a tool for collaborative design in VR. We evaluate the collaboration efficiency and recall of design information when using the VR software design environment compared to a non-VR software design environment. Moreover, we collect the perceptions and preferences of users to explore the opportunities and challenges that were incurred by using the VR software design environment. We find that there is no significant difference in the efficiency and recall of design information when using the VR compared to the non-VR environment. Furthermore, we find that developers are more satisfied with collaboration in VR. The results of our research and similar studies show that working in VR is not yet faster or more efficient than working on standard desktops. It is very important to improve the interface in VR (gestures with haptics, keyboard and voice input), as confirmed by the difference in results between the first and second evaluation.

Maintaining a software system is a continuous and complex process, typically following a workflow defined by the responsible organization. However, in practice, developers often deviate from the defined process due to personal preferences, varying customer requirements, or urgent deadlines. Such deviations may cause problems later on, or they may indicate potential process improvements. To deal with deviations and improve processes, it is first necessary to fully understand the processes actually employed by developers. For this purpose, process-mining techniques have been proposed that primarily build on version-control data. In this paper, we present a complementary process-mining technique that uses Jira issues to recover process activities not visible in version-control data, particularly focusing on developers’ interactions with issues and each other. We conducted a case study with 74 repositories of 24 developer teams from one large international company to understand the technique’s merits. Our technique revealed process differences across teams and depending on the types of Jira issues, providing novel insights for the company that helped to better understand the employed processes.

This work presents a knowledge-representation-based approach for analysing software systems. Its main components are: a generic and extensible knowledge model, and a knowledge extractor tool that generates instance-level knowledge graphs from software repositories (currently Java). Our knowledge model can be used as a shared data-model in a software analysis pipeline. We illustrate the potential uses of our knowledge representation by performing experimental architecture recovery and identifying design pattern instance. We intend to use our ontology and extraction tool as a partial foundation for automated reasoning on software systems.

Abstract There is a growing awareness of the importance of human values in software systems. However, limited tools are available to support the integration of human values during software development. Most of these tools are focused on concepts related to specific, well-known human values (e.g., privacy, security) in software engineering. This paper aims to (partially) address this gap by developing a human values dashboard. We conducted a multi-stage study to design, implement and evaluate a human values dashboard. First, an exploratory study was conducted by interviewing 15 software practitioners to investigate the possibility of using a human values dashboard to help address human values in software development, its potential benefits, and required features. Second, we experimented with four Machine Learning approaches to detect the presence of human values in issue discussions. We used the best approach to develop a human values dashboard for software development. The dashboard displays whether any human values are present in each issue discussion. Finally, we interviewed ten different practitioners to investigate the usefulness of the dashboard in practice. This study found that the human values dashboard could help raise awareness, focus attention, and prioritise issues based on the presence of values. This study also identified two potential challenges to the adoption of the dashboard. First, the possible incorrect issues description that can mislead the automated values identification in the dashboard. Second, the lack of willingness of a company to adopt the dashboard.

Since 1998, the ACM/IEEE 25th International Conference on Model Driven Engineering Languages and Systems (MODELS) has been studying all aspects surrounding modeling in software engineering, from languages and methods to tools and applications. In order to enable empirical studies, the MODELS community developed a need for having examples of models, especially of models used in real software development projects. Such models may be used for a range of purposes, but mostly related to domain analysis and software design (at various levels of abstraction). However, finding such models was very difficult. The most used ones had their origin in academic books or student projects, which addressed “artificial” applications, i.e., were not base on real-case scenarios. To address this issue, the authors of this reflection paper, members of the modeling and of the mining software repositories fields, came together with the aim of creating a dataset with an abundance of modeling projects by mining GitHub. As a scoping of our effort we targeted models represented using the UML notation because this is the lingua franca in practice for software modeling. As a result, almost 100k models from 22k projects were made publicly available, known as the Lindholmen dataset. In this paper, we analyse the impact of our research, and compare this to what we envisioned in 2016. We draw practical lessons gained from this effort, reflect on the perils and pitfalls of the dataset, and point out promising avenues of research. We base our reflection on the systematic analysis of recent research literature, and especially those papers citing our dataset and its associated publications. What we envisioned in the original research when making the dataset available has to a major extent not come true; however, fellow researchers have found alternative uses of the dataset. By understanding the possibilities and shortcomings of the current dataset, we aim to offer the research community i) future research avenues of how the data can be used; and ii) raise awareness of the limitations, not only to point out threats to validity of research, but also to encourage fellow researchers to find ideas to overcome them. Our reflections can also be helpful to researchers who want to perform similar mining efforts.

Abstract Designing software is an activity in which software developers think and make design decisions that shape the structure and behavior of software products. Designing software is one of the least understood software engineering activities. In a collaborative design setting, various types of distances can lead to challenges and effects that potentially affect how software is designed. To contribute to a better understanding of collaborative software design, we investigate how communication gaps caused by social and geographic distances affect its design thinking and the creativity of its discussions. To this end, we conducted a multiple‐case study exploring the design thinking and creativity of colocated and distributed software developers in a collaborative design setting. Compared with colocated developers, distributed developers spend less time on exploring the problem space, which could be related to different sociotechnical challenges, such as lack of awareness and common understanding. Distributed development does not seem to affect the creativity of their activities. Developers engaging in collaborative design need to be aware that problem space exploration is reduced in a distributed setting. Unless distributed teams take compensatory measures, this could adversely affect the development. Regarding the effect distance has on creativity, our results are inconclusive and further studies are needed.

Software is the main driver of added-value in many of the systems that surround us. While its complexity is increasing, so is the diversity of systems driven by software. To meet the challenges emerging from this combination, it is necessary to mobilize increasingly large and heterogeneous multidisciplinary teams, comprising software experts, as well as experts from various domains related to the systems driven by software. Hence, the quality of communication about software between stakeholders of different domains and with different personalities is becoming a key issue for successfully engineering software-intensive systems. The goal of this study, thus, is to investigate the effect of the representation of software design models on the communication of design decisions between stakeholders with diverse personality traits. As a result, this study finds that graphical representations of software design models are better than textual representations in enhancing the communication and increasing the productivity of stakeholders with diverse personalities.

UML is the de facto standard notation for graphically representing software. UML diagrams are used in the analysis, construction, and maintenance of software systems. Mostly, UML diagrams capture an abstract view of a (piece of a) software system. A key purpose of UML diagrams is to share knowledge about the system among developers. The quality of the layout of UML diagrams plays a crucial role in their comprehension. In this paper, we present an automated method for evaluating the layout quality of UML class diagrams. We use machine learning based on features extracted from the class diagram images using image processing. 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). For example, automated feedback can be generated once a UML diagram is checked in the project repository. (2) In an educational setting, the evaluator can grade the layout aspect of student assignments in courses on software modeling, analysis, and design. (3) In the field of algorithm design for graph layouts, our evaluator can assess the layouts generated by such algorithms. In this way, this evaluator opens up the road for using machine learning to learn good layouting algorithms. We use machine learning techniques to build (linear) regression models based on features extracted from the class diagram images using image processing. As ground truth, we use a dataset of 600+ UML Class Diagrams for which experts manually label the quality of the layout. This paper makes the following contributions: (1) We show the feasibility of the automatic evaluation of the layout quality of UML class diagrams. (2) We analyze which features of UML class diagrams are most strongly related to the quality of their layout. (3) We evaluate the performance of our layout evaluator. (4) We offer a dataset of labeled UML class diagrams. In this dataset, we supply for every diagram the following information: (a) a manually established ground truth of the quality of the layout, (b) an automatically established value for the layout-quality of the diagram (produced by our classifier), and (c) the values of key features of the layout of the diagram (obtained by image processing). This dataset can be used for replication of our study and others to build on and improve on this work. Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board..

Background: There is a growing awareness of the importance of human values (e.g., inclusiveness, privacy) in software systems. However, there are no practical tools to support the integration of human values during software development. We argue that a tool that can identify human values from software development artefacts and present them to varying software development roles can (partially) address this gap. We refer to such a tool as human values dashboard. Further to this, our understanding of such a tool is limited. Aims: This study aims to (1) investigate the possibility of using a human values dashboard to help address human values during software development, (2) identify possible benefits of using a human values dashboard, and (3) elicit practitioners' needs from a human values dashboard. Method: We conducted an exploratory study by interviewing 15 software practitioners. A dashboard prototype was developed to support the interview process. We applied thematic analysis to analyse the collected data. Results: Our study finds that a human values dashboard would be useful for the development team (e.g., project manager, developer, tester). Our participants acknowledge that development artefacts, especially requirements documents and issue discussions, are the most suitable source for identifying values for the dashboard. Our study also yields a set of high-level user requirements for a human values dashboard (e.g., it shall allow determining values priority of a project). Conclusions: Our study suggests that a values dashboard is potentially used to raise awareness of values and support values-based decision-making in software development. Future work will focus on addressing the requirements and using issue discussions as potential artefacts for the dashboard.

Context: Designing software is an activity in which software developers think and make design decisions that ultimately shape the structure and behavior of software products. Currently, designing software is one of the least understood activities in which software developers engage. In a collaborative design setting, distances such as geographic, cultural, or social distance can lead to socio-technical challenges that potentially affect the way software is designed.

Motivation: Software visualization can be helpful in comprehending the architecture of large software systems. Traditionally, software visualisation focuses on representing the structural perspectives of systems. In this paper we enrich this perspective by adding the notion of role-stereotype. This rolestereotype carries information about the type of functionality that a class has in the system as well as the types of collaborations with other classes that it typically has.Objective: We propose an interactive visualization called RoleViz, that visualizes system architectures in which architectural elements are annotated with their role-stereotypes.Method: We conducted a user-study in which developers use RoleViz and Softagram (a commercial tool for software architecture comprehension) to solve two separate comprehension tasks on a large open source system. We compared RoleViz against Softagram in terms of participant's: (i) perceived cognitive load, (ii) perceived usability, and (iii) understanding of the system. Result: In total, 16 developers participated in our study. Six of the participants explicitly indicated that visualizing roles helped them complete the assigned tasks. Our observations indicate significant differences in terms of participant's perceived usability and understanding scores.Conclusion: The participants achieved better scores on completing software understanding tasks with RoleViz without any cognitive-load penalty.

Abstract Context Software engineering is a social and collaborative activity. Communicating and sharing knowledge between software developers requires much effort. Hence, the quality of communication plays an important role in influencing project success. To better understand the effect of communication on project success, more in-depth empirical studies investigating this phenomenon are needed. Objective We investigate the effect of using a graphical versus textual design description on co-located software design communication. Method Therefore, we conducted a family of experiments involving a mix of 240 software engineering students from four universities. We examined how different design representations (i.e., graphical vs. textual) affect the ability to Explain, Understand, Recall, and Actively Communicate knowledge. Results We found that the graphical design description is better than the textual in promoting Active Discussion between developers and improving the Recall of design details. Furthermore, compared to its unaltered version, a well-organized and motivated textual design description–that is used for the same amount of time–enhances the recall of design details and increases the amount of active discussions at the cost of reducing the perceived quality of explaining.

To fulfill the contractual requirement of the Sweden Compact agreement, the following funding note has to be added and placed in the Funding section of the original article: Open access funding provided by University of Gothenburg .

Role stereotypes indicate generic roles that classes play in the design of software systems (e.g. controller, information holder, or interfacer). Knowledge about the role-stereotypes can help in various tasks in software development and maintenance, such as program understanding, program summarization, and quality assurance. This paper presents an automated machine learning-based approach for classifying the role-stereotype of classes in Java. We analyse the performance of this approach against a manually labelled ground truth for a sizable open source project (of 770+ Java classes) for the Android platform. Moreover, we compare our approach to an existing rule-based classification approach. The contributions of this paper include an analysis of which machine learning algorithms and which features provide the best classification performance. This analysis shows that the Random Forest algorithm yields the best classification performance. We find however, that the performance of the ML-classifier varies a lot for classifying different role-stereotypes. In particular its performs degrades for rare role-types. Our ML-classifier improves over the existing rule-based classification method in that the ML-approach classifies all classes, while rule-based approaches leave a significant number of classes unclassified.

The benefits of modeling the design to improve the quality and maintainability of software systems have long been advocated and recognized. Yet, the empirical evidence on this remains scarce. In this paper, we fill this gap by reporting on an empirical study of the relationship between UML modeling and software defect proneness in a large sample of open-source GitHub projects. Using statistical modeling, and controlling for confounding variables, we show that projects containing traces of UML models in their repositories experience, on average, a statistically minorly different number of software defects (as mined from their issue trackers) than projects without traces of UML models.

UML Class diagrams are commonly used to describe the designs of systems. Such designs can be used to guide the construction of software. In practice, we have identified two main types of using UML: (i) FwCD refers to diagrams are hand-made as part of the forward-looking development process; (ii) RECD refers to those diagrams that are reverse engineered from the source code; Recently, empirical studies in Software Engineering have started looking at open source projects. This enables the automated extraction and analysis of large sets of project-data. For researching the effects of UML modeling in open source projects, we need a way to automatically determine the way in which UML used in such projects. For this, we propose an automated classifier for deciding whether a diagram is an FwCD or an RECD. We present the construction of such a classifier by means of (supervised) machine learning algorithms. As part of its construction, we analyse which features are useful in classifying FwCD and RECD. By comparing different machine learning algorithms, we find that the Random Forest algorithm is the most suitable algorithm for our purpose. We evaluate the performance of the classifier on a test set of 999 class diagrams obtained from open source projects.

A recurring theme in discussions about the adoption of Model-Based Engineering (MBE) is its effectiveness. This is because there is a lack of empirical assessment of the processes and (tool-)use of MBE in practice. We conducted a multiple-case study by observing 2 two-month MBE projects from which software for a Mars rover were developed. We focused on assessing the distribution of the total software development effort over different development activities. Moreover, we observed and collected challenges reported by the developers during the execution of projects. We found that the majority of the effort is spent on the collaboration and communication activities. Furthermore, our inquiry into challenges showed that tool-related challenges are the most encountered.

The process of software understanding often requires developers to consult both high- and low-level software artifacts (i.e. models and code). The creation and persistence of such artifacts often take place in different environments, as well as seldom in one single environment. In both cases, software models and code fragments are viewable separately making the workspace overcrowded with many opened interfaces and tabs. In such a situation, developers might lose the big picture and spend unnecessary effort on navigation and locating the artifact of interest. To assist program comprehension and tackle the problem of software navigation, we present OctoBubbles, a multi-view interactive environment for concurrent visualization and synchronization of software models and code. A preliminary evaluation of OctoBubbles with 15 professional developers shows a high level of interest, and points out to potential benefits. Furthermore, we present a future plan to quantitatively investigate the effectiveness of the environment.

One argument in the discussion about the adoption of UML in industry is the supposedly large effort it takes to do modeling. Our study explores how the creation of UML models can be understood to consist of different cognitive activities: (i) designing: thinking about the design (ideation, key-design decision making), (ii) notation expression: expressing a design in a modeling notation and (iii) layouting: the spatial organization of model elements in a diagram. We explain that these different subactivities relate to different short-term and long-term benefits of modeling. In this study we present two controlled experiments with a total of 100 subjects creating models for a small system. In these experiments we focus on software models as represented through UML class diagram. Our results show that at least 56% of the effort spent on creating a class model is actually due to designing. Notation expression is around 41% of the model creation effort and layouting is in the order of 3%. This finding suggests that a significant part of creating models is devoted to design thinking about the problem.

Context: Software startups need to tackle a lot of challenges as they grow. Therefore, reoccurring strategies are applied that can be captured in form of patterns. Objectives: While more and more of these patterns are published, we aimed to discover to what degree they are applied within different regions of the world. Method: We studied the cases of 7 software startups within 2 incubation hubs in Uganda, by performing qualitative interviews. We focused on 5 patterns from diverse areas of concerns to analyze whether the Ugandan startups' strategies match these patterns. Results: For most of the patterns we found matches. However, in some cases the startups strategies are only partially described by the known pattern. Conclusion: The findings indicate that startup patterns can often be transferred from countries such as Switzerland and Finland to Uganda. we also found some variations from the known patterns in the contexts and solutions applied in Ugandan startups.

A key open question in the area of software modeling is which costs and benefits it brings to software development and maintenance. For answering this question, better empirical studies into software modeling are needed. In this paper I focus on what I believe are the pitfalls in- and prospects for such types of studies. This paper is an abstract for an invited keynote at the Modeling in Software Engineering (MiSE) workshop at ICSE 2017.

The Unified Modeling Language (UML) is widely taught in academia and has good acceptance in industry. However, there is not an ample dataset of UML diagrams publicly available. Our aim is to offer a dataset of UML files, together with meta-data of the software projects where the UML files belong to. Therefore, we have systematically mined over 12 million GitHub projects to find UML files in them. We present a semi-automated approach to collect UML stored in images, .xmi, and .uml files. We offer a dataset with over 93,000 UML diagrams from over 24,000 projects in GitHub.

There exists a large body of work on the specification and detection of anti-patterns in the source code of software systems. However, there are very few studies on the origins of the occurrences of anti-patterns in the source code: do the very design of the systems lead to the occurrences of anti-patterns or are anti-patterns introduced during implementation? Knowing when anti-patterns are introduced could help software designers and developers improve the quality of the source code, for example by eliminating fault-prone anti-patterns early during the design of the systems, even before their implementation. Therefore, we detect occurrences of anti-patterns in design models and in the source code of some systems, trace these occurrences between design and implementation, and study their relation and impact on the source code. First, we analyze both the UML design models and the source code of 10 open-source systems and show that antipatterns exist in design models. We observe that, on average, 37% of the classes in the design models that belong to anti-patterns also exist in the source code and also play roles in the same anti-patterns. Second, we investigate two open-source systems to assess the impact of the anti-patterns in their design models on the source code in terms of changes and faults. We show that classes that have anti-patterns in the design models have more changes and faults in the source code. Our results suggest that the design of the systems lead to anti-patterns and that the antipatterns impact negatively the change-and fault-proneness of the classes in the source code. Thus, designers should be wary of anti-patterns in their design models and could benefit from tools that detect and trace these anti-patterns into the source code.

Domain-specific modelling (DSM) is a modern software development technology that aims at enhancing productivity. One of the claimed advantages of DSM is increased maintainability of software. However, current empirical evidence supporting this claim is lacking. In this paper, we contribute evidence from a case study conducted at a software development company. We study how the introduction of DSM affected the maintenance of a legacy system. We collected data about the maintenance phase of a system that was initially developed using manual programming, but which was gradually replaced by DSM development. We performed statistical analyses of the relation between the use of DSM and the time needed to resolve defects, the defect density, and the phase in which defects were detected. The results show that after introducing DSM the defect density is lower, that defects are found earlier, but resolving defects takes longer. Other observed benefits are that the number of developers and the number of person-hours needed for maintaining the system decreased, and the portability to new platforms increased. Our findings are useful for organizations that consider introducing DSM and would like to know which benefits can be realized in software maintenance.

Context: This research is positioned in the field of methods for creating software design and the teaching thereof. Goal: The goal of this research is to study the effects of using a collection of examples for creating a software design. Method: We ran a controlled experiment for evaluating the use of a broad collection of examples for creating software designs by software engineering students. In this study, we focus on software designs as represented through UML class diagrams. The treatment is the use of the collection of examples. These examples are offered via a searchable repository. The outcome variable we study is the quality of the design (as assessed by a group of experts). After this, all students were offered the opportunity to improve their design using the collection of examples. We ran a post-assignment questionnaire to collect qualitative data about the experience of the participants. Results: Considering six quality attributes measured by experts, our results show that: 1) the models of the students who used examples are 18% better than those of who did not use examples. 2) the models of the students who did not use examples for constructing became 19% better after updating their models using examples. We complement our statistical analysis with insights from the post assignment questionnaire. Also, we observed that students are more confident about their design when they use examples. Conclusion: Students deliver better software designs when they use a collection of example software designs.

Context: To compare the effectiveness of development techniques, the size of compared software systems needs to be taken into account. However, in industry new development techniques often come with changes in the applied programming languages. Goal: Our goal is to investigate how different size metrics and approximations are biased towards the languages c and c++. Further, we investigate whether triangulation of metrics has the potential to compensate for biases. Method: We identify crucial preconditions for a triangulation and investigate on 34 open source projects, whether a set of 16 size metrics fulfills these preconditions for the languages c and c++. Results: We identify how metrics differ in their biases and find that the preconditions for triangulation are fulfilled. Conclusion: Triangulation has the potential to address language biases, but high variance among metrics and tools need to be taken into account, too.

This paper presents the findings of a survey on the use of UML in software maintenance, carried out with 178 professionals working on software maintenance projects in 12 different countries. As part of long-term research we are carrying out to investigate the benefits of using UML in software maintenance, the main objectives of this survey are: 1) to explore whether UML diagrams are being used in software industry maintenance projects; 2) to see what UML diagrams are the most effective for software maintenance; 3) to find out what the perceived benefits of using UML diagrams are; and 4) to contextualize the kind of companies that use UML documentation in software maintenance. Some complementary results based on the way the documentation is used (whether it is UML-based or not) during software maintenance are also presented.

Graphical modelling of various aspects of software and systems is a common part of software development. UML is the de-facto standard for various types of software models. To be able to research UML, academia needs to have a corpus of UML models. For building such a database, an automated system that has the ability to classify UML class diagram images would be very beneficial, since a large portion of UML class diagrams (UML CDs) is available as images on the Internet. In this study, we propose 23 image-features and investigate the use of these features for the purpose of classifying UML CD images. We analyse the performance of the features and assess their contribution based on their Information Gain Attribute Evaluation scores. We study specificity and sensitivity scores of six classification algorithms on a set of 1300 images. We found that 19 out of 23 introduced features can be considered as influential predictors for classifying UML CD images. Through the six algorithms, the prediction rate achieves nearly 96% correctness for UML-CD and 91% of correctness for non-UML CD.

A large fraction of the time consumed in software development and maintenance is spent on understanding the software, which indicates it is a critical activity. Software documentation, including software architecture design documentation, is an important aid in software comprehension. However, keeping documentation up to date with evolving source code is often challenging and absence of up date or more comprehensive design-level documentation is not uncommon. As a solution, software architecture design may be recovered using reverse engineering techniques. However, existing reverse engineering methods produce complete design diagrams that include all the details that exist in the source code. The absence of abstraction from implementation details limits the usefulness of existing reverse engineering techniques for understanding software. This paper aims to address this problem by providing a method and tool that interactively allows developers to interactively explore a reverse engineered class diagram at scalable levels of abstraction. To this end, we propose a Software Architecure Abstraction (SAAbs) framework and an automated tool which implements the SAAbs framework. The SAAbs framework applies a machine learning scoring algorithm to produce a class importance ranking for class diagrams, this ranking is the basis for software architecture abstraction and visualization. We validate this framework by validating the SAAbs tool using a semi-structured survey. On average, 30 respondents of this survey rated 5.40 out of 6 points, which indicate that this is a useful tool to assist software developers in understanding a system.

A class diagram of a software system enhances our ability to understand software design. However, this diagram is often unavailable. Developers usually reconstruct the diagram by reverse engineering it from source code. Unfortunately, the resultant diagram is often very cluttered; making it difficult to learn anything valuable from it. Thus, it would be very beneficial if we are able to condense the reverse- engineered class diagram to contain only the important classes depicting the overall design of a software system. Such diagram would make program understanding much easier. A class can be important, for example, if its removal would break many connections between classes. In our work, we estimate this kind of importance by using design (e.g., number of attributes, number of dependencies, etc.) and network metrics (e.g., betweenness centrality, closeness centrality, etc.). We use these metrics as features and input their values to our optimistic classifier that will predict if a class is important or not. Different from standard classification, our newly proposed optimistic classification technique deals with data scarcity problem by optimistically assigning labels to some of the unlabeled data and use them for training a better statistical model. We have evaluated our approach to condense reverse-engineered diagrams of 9 software systems and compared our approach with the state-of-the-art work of Osman et al. Our experiments show that our approach can achieve an average Area Under the Receiver Operating Characteristic Curve (AUC) score of 0.825, which is a 9.1% improvement compared to the state-of-the-art approach.

Context: UML has been the de facto standard notation for modeling object-oriented software systems since its appearance in 1997. UML diagrams are important for maintainers of a system, especially when the software was developed by a different team. These diagrams of the system are not always available, however, and are commonly recovered using Reverse Engineering (RE) techniques. When obtained through RE, UML diagrams have a high level of detail as compared to those developed in the forward design activity. Method: In this paper we report on a comparison of the attitude and performance of maintainers when using these two kinds of diagrams during the maintenance of source code. Our findings were obtained by carrying out a controlled experiment with 40 students of a Master's degree in Computer Science. Results: The results show a preference for forward design diagrams but do not display significant differences in task performance. The post-experiment survey results have led us to conclude that the subjects did not consider RE diagrams helpful; they found them difficult to understand, particularly the sequence diagrams. In the case of forward design diagrams, subjects considered sequence diagrams as useful, but they did not really employ them. Conclusions: Based on our findings, as regards performance of maintainers, there are no objective results which favor the use of one of these types of diagram in particular, i.e., UML diagrams which come from forwards design, on the one hand, and diagrams obtained from RE, on the other. Subjective opinions do, however, lead us to recommend the use of diagrams created during design. Nevertheless, we realize that the results should be considered as preliminary ones; further replications of this experiment are planned, using students and professionals, the aim being to obtain more conclusive results.

There is a range of techniques available to reverse engineer software designs from source code. However, these approaches generate highly detailed representations. The condensing of reverse engineered representations into more high-level design information would enhance the understandability of reverse engineered diagrams. This paper describes an automated approach for condensing reverse engineered diagrams into diagrams that look as if they are constructed as forward designed UML models. To this end, we propose a machine learning approach. The training set of this approach consists of a set of forward designed UML class diagrams and reverse engineered class diagrams (for the same system). Based on this training set, the method 'learns' to select the key classes for inclusion in the class diagrams. In this paper, we study a set of nine classification algorithms from the machine learning community and evaluate which algorithms perform best for predicting the key classes in a class diagram.

This paper is the result of two related studies done on the estimation of IT projects at a large Dutch multinational company. The first one is a study about the accuracy of different dimensions of IT project estimating: schedule, budget and effort. [Note: This paper is an extension of the paper published by the authors as "An analysis of accuracy and learning in software project estimating" [28].] This study is based on a dataset of 171 projects collected at the IT department of the company. We analyzed the estimation error of budget, effort and schedule. Also, we analyzed whether there is any learning (improvement) effect over time. With the results of the first study we proceeded to research what is causing the current estimation error (inaccuracy). The results of our first study show that there is no relation between accuracy of budget, schedule and effort in the company analyzed. Besides, they show that over time there is no change in the inaccuracy (effectiveness and efficiency of the estimates). In our second study we discovered that the sources of this inaccuracy are: (IT estimation) process complexity, misuse of estimates, technical complexity, requirements redefinition and business domain instability. This paper reflects and provides recommendations on how to improve the learning from historical estimates and how to manage the diverse sources of inaccuracy inside this particular company and also in other organizations.

The design of software architecture is one of the difficult tasks in the modern component-based software development which is based on the idea that develop software systems by assembling appropriate off-the-shelf components with a well-defined software architecture. Component-based software development has achieved great success and been extensively applied to a large range of application domains from realtime embedded systems to online web-based applications. In contrast to traditional approaches, it requires software architects to address a large number of non-functional requirements that can be used to quantify the operation of system. Moreover, these quality attributes can be in conflict with each other. In practice, software designers try to come up with a set of different architectural designs and then identify good architectures among them. With the increasing scale of architecture, this process becomes time-consuming and error-prone. Consequently architects could easily end up with some suboptimal designs because of large and combinatorial search space. In this paper, we introduce AQOSA (Automated Quality-driven Optimization of Software Architecture) toolkit, which integrates modeling technologies, performance analysis techniques, and advanced evolutionary multiobjective optimization algorithms (i.e. NSGA-II, SPEA2, and SMS-EMOA) to improve non-functional properties of systems in an automated manner.

Software architecture design documentation should communicate design decisions effectively. However, little is known about the way recipients respond to the different types of media used in documentation. We therefore conducted a controlled experiment to study whether visual or textual artifacts are more effective in communicating architecture software design decisions to software developers. Our participant group consisted of 47 participants from both industry and academia. Our results show that neither diagrams nor textual descriptions proved to be significantly more efficient in terms of communicating software architecture design decisions. Remarkably, participants who predominantly used text, scored significantly better, overall and with respect to topology related questions. Furthermore, surprisingly, diagrams were not able to alleviate the difficulties participants with a native language other than English had in extracting information from the documentation. In combination, these findings at the very least question the role of diagrams in software architecture documentation.

This paper summarizes the workshop on Architecture-Based Testing and System Validation which was organized in conjunction with the 9th Working IEEE/IFIP Conference on Software Architecture. The main goal of the workshop was to bring together researchers and practitioners both from the architecture design and software testing community to enable architecture-based software testing.

In the last decade, a large number of different software component models have been developed, with different aims and using different principles and technologies. This has resulted in a number of models which have many similarities, but also principal differences, and in many cases unclear concepts. Component-based development has not succeeded in providing standard principles, as has, for example, object-oriented development. In order to increase the understanding of the concepts and to differentiate component models more easily, this paper identifies, discusses, and characterizes fundamental principles of component models and provides a Component Model Classification Framework based on these principles. Further, the paper classifies a large number of component models using this framework.

Global Software Development (GSD) is associated with many potential pitfalls. Some of these pitfalls, such as the lack of a structured and agreed upon process and unclear tasks, roles and responsibilities can be alleviated by using a process description. While GSD takes up a large percentage of industrial software development, it remains unclear whether organizations tailor their process descriptions for GSD-specific issues. This paper reports results of a comparative study of GSD process descriptions used for custom software development of three industrial organizations. The two methods applied in this research are in-depth analysis of process descriptions and interviews with process designers. We conclude that the level of detail of the process descriptions varies strongly and that the intended use of the prescribed process does not necessarily correspond with the provided level of detail. Also, the design of the process descriptions seems to be partly dependent on the expertise and professional background of the process designers. Other important factors in the design and intended use of the process descriptions are the size of an organization and organizational maturity.

Identifying and fixing software problems before implementation are believed to be much cheaper than after implementation. Hence, it follows that predicting fault-proneness of software modules based on early software artifacts like software design is beneficial as it allows software engineers to perform early predictions to anticipate and avoid faults early enough. Taking this motivation into consideration, in this paper we evaluate the usefulness of UML design metrics to predict fault-proneness of Java classes. We use historical data of a significant industrial Java system to build and validate a UML-based prediction model. Based on the case study we have found that level of detail of messages and import coupling-both measured from sequence diagrams, are significant predictors of class fault-proneness. We also learn that the prediction model built exclusively using the UML design metrics demonstrates a better accuracy than the one built exclusively using code metrics.

Rational Unified Process (RUP) effort data from industrial projects is explored (1) to improve our understanding of project dynamics from a resource perspective, (2) to develop a method for project management to gain insight in resource allocation and (3) to follow up on earlier work on RUP effort visualization [2].

The UML (Unified Modeling Language) has become the de facto standard for software modeling in the software industry. Despite its wide acceptance, little is known about how UML is used in practice, let alone the challenges and difficulties faced by engineers who work with this modeling notation. In this paper, we provide empirical findings from a survey on the use of UML amongst 80 professional software engineers. We explore software engineers' opinions on common styles of using UML and how they perceive the impact of using UML on productivity and quality in software development. One of the results reveals that the impact of using the UML on productivity is perceived mostly in the design, analysis, and implementation phases.

UML sequence diagrams describe the interaction between objects of a system. In this paper, we present four approaches to analyze the quality of sequence diagrams. First, we propose formal model checking techniques and visualization to analyze the possible interaction traces and to identify ambiguities in a sequence diagram. Second, we identified patterns of common interactive behavior and we present an approach to identify these patterns. This approach is useful to identify implicit patterns and make them explicit. Third, we propose a series of checks to identify syntactic defects in sequence diagrams. The fourth approach consists of metrics describing properties such as coverage. The proposed approaches complement each other rather than being competing alternatives. We implemented these approaches in our SquAT tool and conducted a multi case study on three industrial and five research models to validate them. These models showed a large number of defects which were acknowledged by their designers.

Solid frameworks and toolkits for design and analysis of embedded systems are of high importance, since they enable early reasoning about critical properties of a system. This paper presents a software toolkit that supports the design and performance analysis of real-time component-based software architectures deployed on heterogeneous multiprocessor platforms. The tooling environment contains a set of integrated tools for (a) component storage and retrieval, (b) graphics-based design of software and hardware architectures, (c) performance analysis of the designed architectures and, (d) automated code generation. The cornerstone of the toolkit is a performance analysis framework that automates composition of the individual component models into a system executable model, allows simulation of the system model and gives design-time predictions of key performance properties like response time, data throughput, and usage of hardware resources. The efficiency of this toolkit was illustrated on a car radio navigation benchmark system

Correspondence between the design and the code of a system is desirable for several purposes in software development, such as predicting properties of the system based on the design, and for using the documentation for understanding and maintaining the system. In this paper we report on a study into the correspondence between the design of a software system, represented by means of UML, and the implementation of the system. We performed a web-based questionnaire among professional software engineers for finding out how they deal with correspondence. The questionnaire elicited the attitude of professional software engineers with respect to: importance of correspondence, common practice in maintaining correspondence and common reasons for deterioration of correspondence. The results of the questionnaire provide a deeper understanding of the aspects of correspondence and their importance in practical software engineering.

Software development is becoming more and more model-centric. As a result models are used for a large variety of purposes, such as quality analysis, understanding, and maintenance. We argue that the UML and related existing tooling does not offer sufficient support to the developer to understand the models and evaluate their quality. We have proposed and implemented a collection of views to increase model understanding: MetaView, ContextView, MetricView, and UML-City-View. The purpose of this experiment is to validate whether there is a difference between the proposed views and the existing views with respect to comprehension correctness and comprehension effort. The comprehension task performed by the subjects was to answer a questionnaire about a model. 100 MSc students with relevant background knowledge have participated in the experiment. The results are statistically significant and show that the correctness is improved by 4.5% and that the time needed is reduced by 20%.

The Unified Modeling Language (UML) is the de facto standard for designing and architecting software systems. UML offers a large number of diagram types that can be used with varying degree of rigour. As a result UML models may contain consistency defects. Previous research has shown that industrial UML models that are used as basis for implementation and maintenance contain large numbers of defects. This study investigates to what extent implementers detect defects and to what extent defects cause different interpretations by different readers. We performed two controlled experiments with a large group of students (111) and a group of industrial practitioners (48). The experiment's results show that defects often remain undetected and cause misinterpretations. We present a classification of defect types based on a ranking of detection rate and risk for misinterpretation. Additionally we observed effects of using domain knowledge to compensate defects. The results are generalizable to industrial UML users and can be used for improving quality assurance techniques for UML-based development.

Software tools supporting the design and analysis of complex software-intensive systems are highly desirable, since they enable earlier decision making about system realization. This paper presents a tooling environment that supports the design and performance analysis of time-critical component-based software architectures deployed on complex multiprocessor platforms. The tooling environment contains a set of integrated tools for (a) component storage and retrieval, (b) graphics-based design of software and hardware architectures, (c) performance analysis of the defined architectures and, (d) automated code generation. The cornerstone of the toolkit is a performance analyzer that provides efficient simulation of the designed architectures and enables design-time prediction of key performance properties like response time, data throughout, and usage of hardware resources (processor, memory and bus). For every architecture alternative, the performance predictions can be quickly obtained, thereby enabling a fast and yet broad design space exploration. We demonstrate the efficiency and robustness of this toolkit on a Car Radio Navigation benchmark case.

The process of component- and component-based system development differs in many significant ways from the "classical" development process of software systems. The main difference is in the separation of the development process of components from the development process of systems. This fact has a significant impact on the development process. Since the component-based approach is a relatively young approach in software engineering, the main emphasis in the area has been in development of technologies, while process modeling is still an unexplored area. This paper analyses the basic characteristics of the component-based approach and its impact on the development process and lifecycle models. The generic lifecycle of component-based systems and the lifecycle of components are discussed, and the different types of development processes are discussed in detail: architecture-driven component development, productline development and COTS-based development. Finally a short case study illustrates the principles and specifics of component-based processes.

The source code of software systems changes many times during the system lifecycle. We study how developers can get insight in these changes in order to understand the project context and the product artifacts. For this we propose new techniques for code evolution representation and visualization interaction from a version-centric perspective. Central to our approach is a line-based display of the changing code, where each file version is shown as a column and the horizontal axis shows time. We propose a version centric layout of line representations and a constrained interaction scheme that makes it easy to navigate. Additionally, we describe a cushion based technique to enhance visualization with information about stable evolution areas. We demonstrate the usefulness of our approach on real- life data sets.

Inconsistencies between software views are a source of errors for software systems. In this paper we present a general approach that aids in finding inconsistencies between different views. This approach supports both intra phase consistency checking and inter phase consistency checking. The approach is suitable for detecting consistency problems between, for example, multiple diagrams in a UML design as well as between a design and an implementation. The approach is based on verification of rules using relation partition algebra. In this paper, we present two types of rules: obligations and the more commonly used constraints, which can be viewed as lower bounds and upper bounds, respectively. To check consistency between views, rules are derived from one view, the so-called prevailing view, and imposed on another view, the so-called subordinate view. Because our approach does not prescribe which views are prevailing, it can be used in any arbitrary process. Violations to rules can be expressed in terms of either the prevailing view or the subordinate view. Exceptions to rules are easiliy embedded in our general approach to consistency checking.

We advocate the use of publish/subscribe as an interaction style for upgradeable component-based systems. We present an architecture based on publish/subscribe that enables easy, dynamic replacement of components. We describe the rationale behind the design decisions relating to robustness, binding, upgrading and transfer of state. Furthermore, we illustrate our architecture using some scenarios.