scholarly journals Documenting architectural rationale using source code annotations: An exploratory study

10.29007/f5md ◽  
2019 ◽  
Author(s):  
Santiago Hyun Dorado ◽  
Julio Ariel Hurtado

The architectural rationale is the documentation of the reasons why certain software design decisions are made that satisfy quality needs in a system. On many occasions this rationale is implicitly found in precise sentences of the system's documentation or the same source code, making it difficult to understand and make decisions on the maintenance phase, leading to a deviation and erosion of the architecture and therefore aging of the software. In this paper, we discuss the utility of a tool based on code annotations as an alternative to document the architectural rationale with the source code. For this, a quasi-experiment with local industry software engineers is done, in order to answer the research question: Does the source code annotations, with information about the architectural rationale, improves the software maintenance? The quasi-experiment is done with software engineers who know Java language and notions of software architectures. It included 3 tasks that involve changes to the architecture and its documentation. After the results were analyzed using the t-student test, concluding that the participants who use the annotations with information of the Architectural Rationale achieve a better understanding of the architecture and its Rationale than those using a traditional way for documenting the rationale(documents). However, the efficiency and effectiveness of maintenance time do not depend on the Rationale specification. With the same problem, the variation was due to the ability of individuals to develop software, but the documentation of the architecture, in general, was very important to be able to make the changes within the limits.

Technologies ◽  
2020 ◽  
Vol 9 (1) ◽  
pp. 3
Author(s):  
Gábor Antal ◽  
Zoltán Tóth ◽  
Péter Hegedűs ◽  
Rudolf Ferenc

Bug prediction aims at finding source code elements in a software system that are likely to contain defects. Being aware of the most error-prone parts of the program, one can efficiently allocate the limited amount of testing and code review resources. Therefore, bug prediction can support software maintenance and evolution to a great extent. In this paper, we propose a function level JavaScript bug prediction model based on static source code metrics with the addition of a hybrid (static and dynamic) code analysis based metric of the number of incoming and outgoing function calls (HNII and HNOI). Our motivation for this is that JavaScript is a highly dynamic scripting language for which static code analysis might be very imprecise; therefore, using a purely static source code features for bug prediction might not be enough. Based on a study where we extracted 824 buggy and 1943 non-buggy functions from the publicly available BugsJS dataset for the ESLint JavaScript project, we can confirm the positive impact of hybrid code metrics on the prediction performance of the ML models. Depending on the ML algorithm, applied hyper-parameters, and target measures we consider, hybrid invocation metrics bring a 2–10% increase in model performances (i.e., precision, recall, F-measure). Interestingly, replacing static NOI and NII metrics with their hybrid counterparts HNOI and HNII in itself improves model performances; however, using them all together yields the best results.


Author(s):  
HYEON SOO KIM ◽  
YONG RAE KWON ◽  
IN SANG CHUNG

Software restructuring is recognized as a promising method to improve logical structure and understandability of a software system which is composed of modules with loosely-coupled elements. In this paper, we present methods of restructuring an ill-structured module at the software maintenance phase. The methods identify modules performing multiple functions and restructure such modules. For identifying the multi-function modules, the notion of the tightly-coupled module that performs a single specific function is formalized. This method utilizes information on data and control dependence, and applies program slicing to carry out the task of extracting the tightly-coupled modules from the multi-function module. The identified multi-function module is restructured into a number of functional strength modules or an informational strength module. The module strength is used as a criterion to decide how to restructure. The proposed methods can be readily automated and incorporated in a software tool.


Author(s):  
Hiba Al Sghaier

Software engineering is one of computer science branches, it comprises of building and developing software systems and applications. Software engineering is a discipline that has a constant growth in research in aim to identify new technologies and adopt it in different areas; there is a considerable investment on software engineering trends at the current time due to the availability of mobile technologies. With millions of billions of smart devices that are connected to the internet, all industries around the world are rapidly becoming a technology driven industries. Software engineers are aware of programming languages that are employed to develop software systems, by applying engineering principles to development process; they can design customized software systems for individual or organizational customers. The new trends in software engineering are numerous, Cloud Computing, machine learning, deep learning, big Data, mobile Computing. Nevertheless, there are many more other research trends in software engineering's field that have been intensively explored and implemented in many different industries. In this paper, authors try to summarize the most fields that are integrated with software engineering recently.


2021 ◽  
Author(s):  
Thi Mai Anh Bui ◽  
Nhat Hai Nguyen

Precisely locating buggy files for a given bug report is a cumbersome and time-consuming task, particularly in a large-scale project with thousands of source files and bug reports. An efficient bug localization module is desirable to improve the productivity of the software maintenance phase. Many previous approaches rank source files according to their relevance to a given bug report based on simple lexical matching scores. However, the lexical mismatches between natural language expressions used to describe bug reports and technical terms of software source code might reduce the bug localization system’s accuracy. Incorporating domain knowledge through some features such as the semantic similarity, the fixing frequency of a source file, the code change history and similar bug reports is crucial to efficiently locating buggy files. In this paper, we propose a bug localization model, BugLocGA that leverages both lexical and semantic information as well as explores the relation between a bug report and a source file through some domain features. Given a bug report, we calculate the ranking score with every source files through a weighted sum of all features, where the weights are trained through a genetic algorithm with the aim of maximizing the performance of the bug localization model using two evaluation metrics: mean reciprocal rank (MRR) and mean average precision (MAP). The empirical results conducted on some widely-used open source software projects have showed that our model outperformed some state of the art approaches by effectively recommending relevant files where the bug should be fixed.


Author(s):  
D. Berry

Open source software (OSS) is computer software that has its underlying source code made available under a licence. This can allow developers and users to adapt and improve it (Raymond, 2001). Computer software can be broadly split into two development models: • Proprietary, or closed software, owned by a company or individual. Copies of the binary are made public; the source code is not usually made public. • Open-source software (OSS), where the source code is released with the binary. Users and developers can be licenced to use and modify the code, and to distribute any improvements they make. Both OSS and proprietary approaches allow companies to make a profit. Companies developing proprietary software make money by developing software and then selling licences to use the software. For example, Microsoft receives a payment for every copy of Windows sold with a personal computer. OSS companies make their money by providing services, such as advising clients on the GPL licence. The licencee can either charge a fee for this service or work free of charge. In practice, software companies often develop both types of software. OSS is developed by an ongoing, iterative process where people share the ideas expressed in the source code. The aim is that a large community of developers and users can contribute to the development of the code, check it for errors and bugs, and make the improved version available to others. Project management software is used to allow developers to keep track of the various versions. There are two main types of open-source licences (although there are many variants and subtypes developed by other companies): • Berkeley Software Distribution (BSD) Licence: This permits a licencee to “close” a version (by withholding the most recent modifications to the source code) and sell it as a proprietary product; • GNU General Public Licence (GNU, GPL, or GPL): Under this licence, licencees may not “close” versions. The licencee may modify, copy, and redistribute any derivative version, under the same GPL licence. The licencee can either charge a fee for this service or work free of charge. Free software first evolved during the 1970s but in the 1990s forked into two movements, namely free software and open source (Berry, 2004). Richard Stallman, an American software developer who believes that sharing source code and ideas is fundamental to freedom of speech, developed a free version of the widely used Unix operating system. The resulting GNU program was released under a specially created General Public Licence (GNU, GPL). This was designed to ensure that the source code would remain openly available to all. It was not intended to prevent commercial usage or distribution (Stallman, 2002). This approach was christened free software. In this context, free meant that anyone could modify the software. However, the term “free” was often misunderstood to mean no cost. Hence, during the 1990s, Eric Raymond and others proposed that open-source software was coined as a less contentious and more business-friendly term. This has become widely accepted within the software and business communities; however there are still arguments about the most appropriate term to use (Moody, 2002). The OSMs are usually organised into a network of individuals who work collaboratively on the Internet, developing major software projects that sometimes rival commercial software but are always committed to the production of quality alternatives to those produced by commercial companies (Raymond, 2001; Williams, 2002). Groups and individuals develop software to meet their own and others’ needs in a highly decentralised way, likened to a Bazaar (Raymond, 2001). These groups often make substantive value claims to support their projects and foster an ethic of community, collaboration, deliberation, and intellectual freedom. In addition, it is argued by Lessig (1999) that the FLOSS community can offer an inspiration in their commitment to transparency in their products and their ability to open up governmental regulation and control through free/libre and open source code.


2009 ◽  
pp. 1-13 ◽  
Author(s):  
Gregory W. Hislop

There is a strong and growing global demand for skilled software engineers. The institutions that educate software engineers are evolving and changing to meet this need. This chapter provides an overview of this effort to develop software engineering education. It discusses the historical development of software engineering education, provides some perspective on current status, and identifies some of the challenges faced by software engineering educators. The intended audience for this chapter is anyone interested in software engineering education who has not participated in the developments to the present time. The goal is to provide a summary background of how the discipline has evolved and pointers to key publications that are part of that history. Since this chapter surveys foundational topics in software engineering education, many of the topics touched on in this chapter are covered in more detail in other chapters of this volume.


Author(s):  
Yoshinobu Tamura ◽  
Shigeru Yamada

We discuss a method of software dependability assessment based on stochastic differential equation modeling in order to consider the interesting factors of the numbers of components, cloud applications and users. Then, we consider the determination of an optimum software maintenance time, minimizing the total expected software cost. In particular, we develop the three-dimensional AIR application for reliability and cost optimization analyses based on the proposed method. Moreover, the three-dimensional application based on NW.js, known as the latest technology, is developed in this paper. Furthermore, we show several numerical examples of the developed application software to evaluate the performance of software optimization and reliability assessment tools for the big data on cloud computing.


2016 ◽  
Vol 23 (2) ◽  
pp. 488
Author(s):  
Tim Benson

Background: Open source software (OSS) is becoming more fashionable in health and social care, although the ideas are not new. However progress has been slower than many had expected.Objective: The purpose is to summarise the Free/Libre Open Source Software (FLOSS) paradigm in terms of what it is, how it impacts users and software engineers and how it can work as a business model in health and social care sectors.Method: Much of this paper is a synopsis of Eric Raymond’s seminal book The Cathedral and the Bazaar, which was the first comprehensive description of the open source ecosystem, set out in three long essays. Direct quotes from the book are used liberally, without reference to specific passages. The first part contrasts open and closed source approaches to software development and support. The second part describes the culture and practices of the open source movement. The third part considers business models.Conclusion: A key benefit of open source is that users can access and collaborate on improving the software if they wish. Closed source code may be regarded as a strategic business risk that that may be unacceptable if there is an open source alternative. The sharing culture of the open source movement fits well with that of health and social care.


Sign in / Sign up

Export Citation Format

Share Document