version 1.0

The Software Design Reference Ontology (SDRO)

domain ontology from SEON

1. Ontology Description

The Software Design Reference Ontology (SDRO) aims at providing a well-founded consensual conceptualization of the design phenomenon in the software context. SDRO is integrated to SEON, uses the works by Ralph and Wand (2009) and Guarino (2014) as a reference to describe the core design notions and reuses concepts from other SEON ontologies to address software particularities. By combining general notions of design and specific aspects of Software Engineering, it is possible to provide a conceptualization about design in the software context integrated to other aspects, such as requirements, code and testing.

SDRO allows the instantiation of software design situations regardless of the design paradigm, process or method used in software development. It is focused on design as noun, i.e., it is not focused on describing activities involved in a general software design process, which is addressed in SEON by the Design Process Ontology (DPO). SDRO may serve as a reference model, being used or specialized in the development of other ontologies that refer to software design.

2. Related Ontologies

Networked ontologies used by SDRO:

Ontology	Relation	Integration Level
RSRO - Reference Software Requirements Ontology
SysSwO - System and Software Ontology
SPO - Software Process Ontology

Ontologies (re)used by SDRO.

3. Ontology Models

Figure 1 presents the packages of the SDRO Modularization.

Figure 1. SDRO Modularization.

3.1. Mental Aspects

Figure 2 presents the conceptual model of the Mental aspects subontology.

Figure 2. Mental aspects conceptual model.

Mental aspects are treated in SDRO as Software Designer Mental Moments that inhere in a Software Designer, which is a Person Stakeholder that uses his/her skills to directly contribute to the outcome of the design effort. The propositional content of a Software Designer Mental Moment is a Software Design Proposition, i.e., a sentence describing an idea in the designer’s mind about software design aspects of a certain object. Thus, Software Designer Mental Moments represent mental properties of a Software Designer that enable him/her to imagine possible solutions for software design problems, while Software Design Propositions are the expression of such solutions in a conversation or in the internal dialogue of the designer. The realization of design solutions is given by situations in reality where the propositional content of Software Designer Mental Moments (i.e., Software Design Propositions) are true. The number of design solutions that can be actually realized varies according to the intersection between desirable situations that satisfy the requirements and feasible situations that respect the constraints (e.g., time, cost and computational resources) (BAKER; HOEK, 2006).

Five different types of Software Design Propositions were identified, based on what their subject refers to. A Mental Software Design Object concerns the software object being designed, which may not exist yet (i.e., it represents what designers visualize as the final design object when they refer to “the system”). A Mental Software Design Object is specified by a Mental Software Design Specification, a detailed description of the object structure (i.e., how the object should be decomposed and organized in smaller elements and how these elements interact with each other). In the beginning of the design process, this description usually represents the object structure in a higher level of abstraction (e.g., architecture aspects) and as design iterations occur, it is refined into more detailed representations (e.g., components and modules) at lower levels of abstraction (PRESSMAN; MAXIM, 2020). The Mental Software Design Specification consists of one or more Mental Software Design Choices made by the Software Designer. Each Mental Software Design Choice can be motivated by Requirements or by other Mental Software Design Choices and contains details about a decision made by the Software Designer concerning structural or behavioral properties of the designed object or about its components and their connections. Thus, a Mental Software Design Choice may concern Mental Software Design Components, which represent what the Software Designer expects to exist as a part of the designed object in a particular place, playing a specific role and having its own properties (e.g., modules, partitions and layers in which the system’s architecture is organized), also referred as “conventional system components” by Guarino and Melone (2015). A Mental Software Design Choice may also concern a Mental Computing Resulting State, which represents an expected result of a Mental Software Design Choice that can only be assessed in runtime (e.g., obtaining a certain return code after the execution of a system’s module).

3.2. Physical Aspects

Figure 3 presents the conceptual model of the Physical aspects subontology.

Figure 3. Physical aspects conceptual model.

SDRO physical aspects, in turn, are treated as sub-types of Software Artifact. For example, a Software Design Object is a Software System that implements one or more Mental Software Design Objects. This does not imply that every Mental Software Design Object results in the development of a new Software System. An existing Software System is also considered a Software Design Object when it implements at least one Mental Software Design Object specified by a Mental Software Design Specification. Software Design Objects are composed of Software Design Components, which are Programs that play specific roles in the designed Software System, implementing Mental Software Design Components. Software Design Components can be composed of sub-components, allowing the representation of more complex architectures. A (sub)component can also be part of more than one component (e.g., in situations where the code is properly modularized and reused).

In order to be executed and used, a Software Design Object and its Software Design Components must be, respectively, materialized as a Loaded Software Design Object (Loaded Software System Copy) and Loaded Software Design Components (Loaded Program Copies) inhering in a Computer Machine, i.e., the software must be loaded in the computer’s main memory. A Loaded Software Design Component can be executed as a Program Copy Execution that brings about a Computing Resulting State. If the program was implemented and executed correctly, this Computing Resulting State may satisfy a Mental Computing Resulting State associated in a Mental Software Design Choice with the corresponding Mental Software Design Component materialized by the executed Loaded Software Design Component. This relationship allows us to verify if the implemented software meets the design specification.

Another type of Software Artifact is a Software Design Specification, which is created by one or more Software Designers and can be either a Model (e.g., a class diagram), a Document (e.g., a detailed textual description) or a Software Item (e.g., a functional prototype), providing an explicit representation that describes Mental Software Design Specifications (also referred as Software Design Descriptions in IEEE 1016 (IEEE, 2009)). A Software Design Specification is an aggregation of Software Design Choices, which are Information Items describing Mental Software Design Choices. Therefore, a Software Design Choice is a piece of information that physically represents choices made by a Software Designer and can be used for communication and evaluation purposes (e.g., a sentence like “The system will be implemented in Java” or details added in a class diagram that indicates how entities and relations should be represented in the database). As a derived relation, a Software Design Choice is motivated by (and, thus, intends to satisfy) a Requirement Artifact when the Mental Software Design Choice it describes is motivated by the Requirement described by the Requirement Artifact. This connection establishes a traceability relation between design and requirements artifacts.

4. Concepts Definition

The following table shows the definitions for SDRO concepts.

SDRO concepts definition.
Concept	Definition
Loaded Software Design Component	The materialization of a Software Design Component (i.e., the resulting designed program loaded in the computer memory).
Loaded Software Design Object	The materialization of a Software Design Object (i.e., the resulting designed software loaded in the computer memory).
Mental Computing Resulting State	A Software Design Proposition that represents an expected result of a Mental Software Design Choice that can only be assessed in runtime. E.g.: obtaining a certain return code after the execution of a system’s module
Mental Software Design Choice	A Software Design Proposition concerning a choice in the mind of a designer about how certain requirements of the system should be met. It involves defining which components are part of the system and how they are connected to each other. src.: Adapted from [Guarino, N. (2014)]
Mental Software Design Component	A Software Design Proposition describing parts, or components, of the software system being designed. It represents what the designer has in mind about how components of system should be implemented. Thus, these components have specific properties, play specific roles and are expected to exist in particular places in the software system. E.g.: System modules, UI elements. src.: Adapted from [Guarino, N., & Melone, M. R. S. (2015)]
Mental Software Design Object	A Software Design Proposition concerning the software system being designed, i.e., the picture the designer has in mind about the system he/she is designing. E.g.: what designers visualize as the final design object when they refer to "the system".
Mental Software Design Specification	A complex Software Design Proposition consisting in design choices about the designed system. It represents the ideas in the designer’s mind that form a detailed description of the system in terms of its structure. src.: Adapted from [Ralph, P., & Wand, Y. (2009)] and [Guarino, N. (2014)]
Software Design Choice	Information Item describing a Mental Software Design Choice, i.e. a physical representation of design choices that can be used for communication and evaluation purposes. E.g.: A sentence like “The system will be implemented in Java”; Further details added in a class diagram that indicates how entities or relations should be represented on the database.
Software Design Component	A Program that plays a specific role in a Software System, implementing a Mental Software Design Component. src.: Adapted from [Guarino, N., & Melone, M. R. S. (2015)]
Software Design Object	A Software System which is the concrete realization of some Software Design Specification, implementing Mental Software Design Objects.
Software Design Proposition	The propositional content of Software Designer Mental Moments.
Software Design Specification	A Software Artifact that provides a physical representation of a mental specification. It can be presented as a Model, a Document or a Software Item. E.g.: a class diagram; a detailed textual description; a functional prototype.
Software Designer	A Person Stakeholder that uses his or her skills to directly contribute to the outcome of the design effort. src.: Adapted from [Ralph, P., & Wand, Y. (2009)]
Software Designer Mental Moment	A mental moment inhering in a Software Designer representing mental properties that enable him/her to imagine possible solutions for software design problems.

Specializes:

UFO::Mental Moment

Definition:

A mental moment inhering in a Software Designer representing mental properties that enable him/her to imagine possible solutions for software design problems.

Relations:

Software Designer Mental Moment (0..*) inheres in (1..1) Software Designer Software Design Proposition (1..1) propositional content of (1..*) Software Designer Mental Moment