Particular Piece Of Software Research Articles

Automated Theorem Proving in the Classroom

We report on several scenarios of using automated theorem proving software in university education. In particular, we focus on using the Theorema system in a software-enhanced logic-course for students in computer science or artificial intelligence. The purpose of using logic-software in our teaching is not to teach students the proper use of a particular piece of software. In contrast, we try to employ certain software in order to spark students' motivation and to support their understanding of logic principles they are supposed to understand after having passed the course. In a sense, we try to let the software act as a logic-tutor, the software is not an additional subject we teach.

The Intention; Requirements for Software as a Medical Device in EU Law

The role of software in society has changed drastically since the start of the 21st century. Software can now partially or fully facilitate anything from diagnosis to treatment of a disease, regardless of whether it is psychological or pathological, with the consequence of software being comparable to any other type of medical equipment. Furthermore, software can be disembodied from the traditional role of medical equipment, which is clearly seen in the use of apps. %Make that clearer We see this with the medical device legislation, specifically the Medical Device Regulation (MDR) not being explicitly created for software, as well as unpredictable developments in the field such as contact tracing applications or self diagnostic tools in general. Any uncertainties concerning the interpretation of these rules must therefore be cleared, both for the sake of the manufacturer as well as the user. In this paper, we show how and when software is considered a medical device in EU law, more specifically in the Medical Device Regulation. To do this, we first create a framework for the intention of the manufacturer, since this would otherwise likely pose a barrier that would prevent software from being seen as a medical device at all. We show how and where software is specifically mentioned in the regulation, and how it is understood. We also include a comparison between US law and the EU regime, and take a quick look at contact tracing applications as such, as well as the practice of two European regulators. We finally create, from existing requirements, a decision diagram comprising a guide to determining whether a piece of software is a medical device or not under the MDR, to illustrate our findings and combine this with with the aforementioned manufacturer's intention framework. We find that in theory it is possible to determine whether software is a medical device, and therefore falls within the MDR's scope or not, but this assessment remains very unsure. This is because of the ambiguity of the criteria as well as how the MDR is designed. A literal interpretation of the Regulation yields immediate issues with whether a particular piece of software should be included or not. Furthermore, if software is considered to be a medical device, the software's manufacturer will be subject to strict organisational and cybersecurity obligations, and can face severe penalties such as withdrawal or bans on their software for infractions. At the same time, enforcement is left to national regulators in each Member State, creating potential inconsistencies in oversight and interpretations, as well as lacking a clear body of legal practice. We see that because of the pivotal importance of manufacturer's intention for triggering the application of the MDR, there exists an actual risk of circumvention of the MDR, and show that the Principle of Circumvention could be applied. However, we find that US law, via FDA guidelines, has measures that can be used as inspiration for reform of medical device law and practice in the EU, including an exclusion list and overarching federal penalties in the form of withdrawal, for not reporting which and how one's software is a medical device.

Measuring Software Modularity Based on Software Networks.

Modularity has been regarded as one of the most important properties of a successful software design. It has significant impact on many external quality attributes such as reusability, maintainability, and understandability. Thus, proposing metrics to measure the software modularity can be very useful. Although several metrics have been proposed to characterize some modularity-related attributes, they fail to characterize software modularity as a whole. A complex network uses network models to abstract the internal structure of complex systems, providing a general way to analyze complex systems as a whole. In this paper, we introduce the complex network theory into software engineering and employ modularity, a metric widely used in the field of community detection in complex network research, to measure software modularity as a whole. First, a specific piece of software is represented by a software network, feature coupling network (FCN), where methods and attributes are nodes, couplings between methods and attributes are edges, and the weight on the edges denotes the coupling strength. Then, modularity is applied to the FCN to measure software modularity. We apply the Weyuker’s criteria which is widely used in the field of software metrics, to validate the modularity as a software metric theoretically, and also perform an empirical evaluation using open-source Java software systems to show its effectiveness as a software metric to measure software modularity.

Editorial: Ethics and Publishing

Editorial: Ethics and Publishing

The Design of Learning Software: Principles Learned from the Computer as Learning Partner Project.

This paper describes general curriculum design principles and specific software design implementations resulting from an ongoing collaboration between software designers and programmers, researchers, and a classroom teacher and his students. Research and observations in the classroom setting led to both the emergence of useful learning principles as well as the design of a specific piece of software, E-LabBook. The paper traces the development of the software in the context of the principles that emerged during the design process.

Do lab modules in CS actually help students?

Three laboratory modules were developed to teach C pointers to novice programming students, using two different versions of software. The first version was an intelligent tutoring system; the second was a multimedia tutorial. Six classes of students participated in an empirical study involving both versions of software. What was discovered as a result of this experiment was more than just the answer to whether or not a particular piece of software helped the students to learn the subject matter. We discovered who used the software, given the freedom of choice. We learned about the characteristics of software users, which software was more helpful, and what the students think about using software to learn. The more significant results of this study are presented in this paper.

Java's reliability: An analysis of software defects in Java

The authors consider Java's claim to be a safe and reliable language. First, Java and the aims of the language are introduced and its relationship with C++ is briefly considered. The results of analysing a selection of the software bugs, limitations, weaknesses and flaws that have been found in Java (generically described as Java related defects) are then presented. This analysis is based on reports made available by the worldwide web, on developmental experiences and on analysis of the Java Language Specification. The results obtained indicate that the Java-related defects can be categorised into 12 different categories (not all of which will be relevant to every software project). However, an understanding of these categories can be used to reduce the potential impact that such defects (including those yet to be identified) may have on a particular piece of software. The intention is that a developer who is forewarned is forearmed. A set of strategies is proposed which can be used to minimise the effect of identified defects in the Java language and environment. Such strategies may, of course, have implications for the whole development cycle. It is therefore necessary to consider these effects. In addition, the strategies may have limited applicability and consideration is given to this. Finally, the results of these studies in the light of previous experiences with other object oriented languages are considered and determine the extent to which the Java language developers achieved their aim.

Ten desiderata for Computer-Assisted Language Learning programs: The example of ELSE

The article briefly reviews the history of the ELSE program, one of the first Computer-Assisted Language (CALL) programs to use sophisticated error analysis. Its development evokes ten desiderata for such programs (not all of which are found in ELSE). The article, addressed to language teachers and to programmers working with CALL, describes those desiderata and the problems that ensue as one tries to implement them into a specific piece of software.

Virtual History: An Outline of Research Being Undertaken at Sheffield Hallam University

The Education section seeks to cover education broadly, encompassing its materials, methods, assessment, evaluation, organisation and resources, and to do so by means of news, views, comments, reports, reviews and articles from the readers of History and Computing. Examples would be reports on the experience of running a new computer-based course, reflections on the value for teaching a specific piece ofsoftware, or consideration of the costs and benefits ofa particular approach to implementing the computer in the classroom. Discussions of the interconnections (or lack thereof!) between research and teaching in historical computing are also appropriate. Contributions concerning developments outside as well as within the UKare warmly welcomed. Likewise the intention to cover schools as well as higher education remains undiminished. Items for future numbers should be sent to: AllanMartin, University ofGlasgow, Office ofInformation Technology, 3, The Square, Glasgow, G12 8QQ, e-mail: a.martin@compserv.gla.ac.uk. The following two items, however, are the responsiility of the editor.

Autobiblio: A Set of Bibliography Programs for the Apple Macintosh™ Computer

Luddites was the name given to organized bands of English textile workers who in 1812 destroyed the machinery that they perceived as taking away their livelihood. The thoughts of the first reviewer, when sitting down to review this disk, went out to these Luddites: books I understand, but disks, floppy or hard, regrettably were outside my sphere of reference. It was then I enlisted the aid of a computer-sensitive colleague to help me understand what must surely be a revolution in educational tools. In reviewing, several questions arose: (1) What is the function of this particular piece of software? (2) How easy is it to use? (3) Does it fulfill its stated function? Autobiblio is a set of programs that may be used with an Apple Macintosh computer to automate bibliographic chores for individuals preparing manuscripts for publication. With any word processor, the user prepares a list of complete citations

A micro/macro measure of software complexity

A software complexity metric is a quantitative measure of the difficulty of comprehending and working with a specific piece of software. The majority of metrics currently in use focus on a program's “microcomplexity.” This refers to how difficult the details of the software are to deal with. This paper proposes a method of measuring the “macrocomplexity,” i.e., how difficult the overall structure of the software is to deal with, as well as the microcomplexity. We evaluate this metric using data obtained during the development of a compiler/environment project, involving over 30,000 lines of C code. The new metric's performance is compared to the performance of several other popular metrics, with mixed results. We then discuss how these metrics, or any other metrics, may be used to help increase the project management efficiency.

A Grassroots Approach to German Computer Courseware

Educators in general are constantly searching for quality software which will allow them to make effective use of microcomputers in their instructional program. This has certainly been true for many members of our local AATG chapter. During chapter meetings, conversation often turned to a discussion of the relative value of computers in the foreign language classroom. These discussions generally became a dialogue between individuals with computer expertise and individuals without computer expertise. Most frequently, the discussion centered around the enormous potential benefits versus the fear of the unknown. This was compounded by the lack of familiarity with software in general and quality software in particular. All of these were theoretical in nature since no specific piece of software was at hand. At one such AATG business meeting, a discussion of the relative merits of microcomputer use in the classroom led to several suggestions. One suggestion was to sponsor a software fair which would provide the opportunity for teachers to view commercial and teacher-made software. Another suggestion was to sponsor a German-language programming contest for high school students. No decisions were reached concerning any of the suggestions presented during this meeting. However, the more I thought about it, the more it seemed feasible to combine the two suggestions into one activity. A German Software Contest/Fair/Swap would offer the opportunity for German teachers to investigate a variety of commercial, teacher-produced, and student-produced software. At the same time creative students would be able to combine their interest in German and computers with the possibility of financial reward. In addition, all participants would leave with software for their use, since they would be given a disk containing the programs entered in the contest.

Tolerant software for the recognition of user-defined commands in a data-base environment

Abstract The need for software which tolerates errors in user input is discussed and a particular piece of software is described which accepts inadequacies and extreme abbreviations in keywords stored in easily prepared dictionary files. Though its previous application has been in the recognition of user-defined commands, evaluation shows that it can be easily adapted to other more general applications, provided that the hardware and software environment of the installation is compatible.