Abstract

Software is permeating every aspect of our personal and social life. And yet, the cluster of concepts around the notion of software, such as the notions of a software product, software requirements, software specifications, are still poorly understood with no consensus on the horizon. For many, software is just code, something intangible best defined in contrast with hardware, but it is not particularly illuminating. This erroneous notion, software is just code, presents both in the ontology of software literature and in the software maintenance tools. This notion is obviously wrong because it doesn’t account for the fact that whenever someone fixes a bug, the code of a software system changes, but nobody believes that this is a different software system. Several researchers have attempted to understand the core nature of software and programs in terms of concepts such as code, copy, medium and execution. More recently, a proposal was made by Irmak to consider software as an abstract artifact, distinct from code, just because code may change while the software remains the same. We share many of his intuitions, as well as the methodology he adopts to motivate his conclusions, based on an analysis of the condition under which software maintains its identity despite change. However, he leaves the question of ‘what is the identity of software’ open, and we answer this question here. Trying to answer the question left open by Irmak, the main objective of this dissertation is to lay the foundations for an ontology of software, grounded on the foundational ontology DOLCE. This new ontology of software is intended to facilitate the communication within the community by reducing terminological ambiguities, and by resolving inconsistencies. If we had a better footing on answering the question ‘What is software?’, we'd be in a position to build better tools for maintaining and managing a software system throughout its lifetime. The research contents of the thesis consist of three results. Firstly, we dive into the ontological nature of software, recognizing it as an abstract information artifact. To support this proposal the first main contribution of the dissertation is demonstrated from three dimensions: (1) We distinguish software (non-physical object) from hardware (physical object), and demonstrate the idea that the rapid changing speed of software is supported by the easy changeability of its medium hardware; (2) Furthermore, we discuss about the artifactual nature of software, addressing the erroneous notion, software is just code, presents both in the ontology of software literature and in the software maintenance tools; (3)At last, we recognize software as an information artifact, and this approach ensures that software inherits all the properties of an information artifact, and the study and research could be directly reused for software then. Secondly, we propose an ontology founded on the concepts adopted from Requirements Engineering (RE), such as the notions of World and Machine phenomena. In this ontology, we make a sharp distinction between different kinds of software artifacts (software program, software system, and software product), and describe the ways they are inter-connected in the context of a software engineering process. Additionally, we study software from a Social Perspective, explaining the concepts of licensable software product and licensed software product. Also, we discuss about the possibility to adopt our ontology of software in software configuration management systems to provide a better understanding and control of software changes. Thirdly, we note the important role played by assumptions in getting software to fulfill its requirements. The requirements for most software systems -- the intended states-of-affairs these systems are supposed to bring about -- concern their operational environment, usually a social world. But these systems don’t have any direct means to change that environment in order to bring about the intended states-of-affairs. In what sense then can we say that such systems fulfill their requirements? One of the main contributions of this dissertation is to account for this paradox. We do so by proposing a preliminary ontology of assumptions that are implicitly used in software engineering practice to establish that a system specification S fulfills its requirements R given a set of assumptions A, and our proposal is illustrated with a meeting scheduling example.