SEON: Networked Ontology Specification

Design Process Ontology (DPO)

1. Ontology Description

The Design Process Ontology (DPO) aims at representing the activities, artifacts and stakeholders involved in the software Design Process. DPO is in the core of the technical processes in software development, thus it reuses some concepts from other SEON networked ontologies, as well provides some concepts for reusing.

2. Related Ontologies

Networked ontologies used by DPO:

3. Ontology Models

Figure 1 presents the conceptual model of the DPO.

Figure 1. DPO conceptual model.

The Design Process is a Process with the purpose of defining the architecture, elements, interfaces, and other characteristics of a software, aiming at its implementation.
Some notions are important for this process. Software Architecture is a model describing the fundamental structures of a software. It is composed of Architectural Elements, which can be a Component, describing a software module, or a Connector, connecting two or more components. Architectural Elements have Interfaces, which can be internal or external. The Design is a refinement process involving several design choices. It starts defining an architecture and follows by detailing each element to the extent it can be implemented.
The Design Process is composed of four main Activities. (1) Architectural Design makes the high-level design choices, defining a Software Architecture and involved elements. Its three sub-activities are Architecture Development, for producing the architecture and specifying its components and connectors; Interface High-level Design, for specifying the interfaces between components and with external elements (users or other systems); and Data High-level Design, for establishing the high-level choices regarding the software data. (2) Detailed Design refines a preliminary software design to the extent that it is sufficiently complete to be implemented. It has four sub-activities: Component Design, for refining each architectural component; Component Interface Design, for detailing each software interface; User Interface Design, specifically for detailing the user interfaces; and Data Design, for producing a detailed Data Model for data storage and management. (3) Design Documentation registers the architectural and detailed design choices made, producing a Design Document. (4) Finally, Design Evaluation evaluates a Design Document, registering the identified issues.
The process has two main Stakeholders, the Software Architect, responsible for making the high-level design choices, and establishing a software architecture; and the Designer, responsible for making the detailed design choices.

4. Concepts Definition

The following table shows the definitions for DPO concepts.

Concept	Definition
Architectural Component	Architectural Element describing a software module as part of an Architecture.
Architectural Connector	Architectural Element connecting two or more Components in an Architecture.
Architectural Design	Activity for making the high-level design choices, defining the Software Architecture and involved elements.
Architectural Element	Model Element referring to an Architectural Component or Connector, and its Interfaces.
Architecture Development	Activity aiming to produce the Software Architecture and specifying its Architectural Components and Connectors.
Component Design	Activity for refining each Architectural Component of a software.
Component Interface Design	Activity for refining each Interface Specification of a software.
Data Definitions	Information Item describing the high-level choices of how the software will manage data.
Data Design	Activity for producing a detailed Data Model for data storage and management.
Data High-level Design	Activity for establish the high-level choices regarding the software data. Ex.: data management mechanisms, data distribution.
Data Model	Model containing the physical and logical decisions on how to manage and storage the software data. Ex.: a database schema.
Design Document	Document specifying the design of a software, by depicting the software architecture, components, interfaces and data models, as well as other information regarding the design choices and decisions.
Design Documentation	Activity for registering the architectural and detailed design choices and decisions, producing a Design Document.
Design Evaluation	Activity for evaluating a Design Document, registering the identified issues.
Design Evaluation Document	Document registering the issues identified in a Design Document evaluation.
Design Process	Process for defining and specifying a solution to be implemented for a software product, considering the requirements for it. It is a refinement process starting with the software architecture, and going down to the design of its elements, interfaces, and other characteristics of a software, until achieving the design of implementation units.
Designer	Stakeholder responsible for making the Detailed Design choices for a software.
Detailed Design	Activity for refining a preliminary software design to the extent that it is sufficiently complete to be implemented. [ISO/IEC/IEEE 24765]
Interface High-level Design	Activity for specifying the Interfaces between Architectural Components and with external elements (users or other systems).
Interface Specification	Information Item describing an internal or external interface of a software architecture.
Software Architect	Stakeholder responsible for designing the Software Architecture.
Software Architecture	Model describing the fundamental structures of a software, including its components, how they are connected, and its internal and external interfaces.
User Interface Design	Activity for specifying the User Interfaces in detail.
User Interface Specification	Interface Specification focusing on the human-computer interaction.

Detailed Concepts