High-Level Ontology Properties Sample Clauses
High-Level Ontology Properties. Concerning diagram-level, we define the properties shown in Table 3.1. As shown in that Table, several properties are bidirectional. Project project_has_diagram ActivityDiagram ActivityDiagram is_diagram_of_project Project ActivityDiagram diagram_has Actor, AnyActivity, Transition, Property, Condition Actor, AnyActivity, Transition, Property, Condition is_of_diagram ActivityDiagram ActivityDiagram diagram_has_condition PreCondition, PostCondition PreCondition, PostCondition is_condition_of_diagram Requirement The high-level properties shown in Table 3.1 cover the interactions among the main classes of the ontology. In specific, each project can have one or more diagrams and each diagram has to belong to a project. Additionally, each diagram may have a PreCondition and/or a PostCondition. An instance of ActivityDiagram has elements of the five classes Actor, AnyActivity, Transition, Property, and Condition. Note that Action and Object are not included in this high-level view of the system since they are covered by the low-level properties of the next paragraph. This is quite rational since they are not actually elements of the diagram; instead, they are derived from its elements. In the case of Actor, it is possible that it is given or not given by the diagram. For example, in activity diagrams it is common to assume that the activities performed by the system are shaped as rectangles whereas user activities are defined as labels on the diagram arrows. So, we keep Actor as one of the main diagram classes to cover this case.
High-Level Ontology Properties. At first, concerning requirements-level, we define the properties shown in Table 1. As shown in that Table, several properties are bidirectional. Project project_has_requirement Requirement Requirement is_of_project Project Requirement has_compound_requirement Requirement Requirement is_compound_requirement_of Requirement Requirement requirement_consists_of ThingType, OperationType ThingType, OperationType consist_requirement Requirement The high-level properties shown in Table 1 cover the interactions among the four main classes of the ontology (Project, Requirement, ThingType, OperationType). In specific, each project can have many different requirements while each requirement can also be compound, i.e. containing other requirements. In addition, each requirement consists of several ThingType and OperationType instances. Furthermore, since OWL allows defining subproperties, we can further refine the requirement_consists_of and consist_requirement properties as shown in Table 2 and Table 3 respectively. Table 2 Subproperties of the requirement_consists_of property Requirement requirement_has_concept ThingType ThingType is_concept_of_requirement Requirement Table 3 Subproperties of the consist_requirement property Requirement requirement_has_operation OperationType OperationType is_operation_of_requirement Requirement The defined properties are visualized in Figure 2, including only one of the two directions for bidirectional properties for simplicity.
High-Level Ontology Properties. We define the high-level properties shown in Table 5.1. Project has_requirement Requirement Requirement is_requirement_of Project Project has_activity_diagram ActivityDiagram ActivityDiagram is_activity_diagram_of Project Project has_element Element Element is_element_of Project Requirement, ActivityDiagram contains_element Element Element element_is_contained_in Requirement, ActivityDiagram The high-level properties ensure that the aggregated ontology covers all the requirements and diagrams of the static and the dynamic view of software projects. Additionally, the two properties contains_element and element_is_contained_in ensure that any element of the diagram is traceable in the other two ontologies. Given, e.g., the activity ”Create account”, we may trace it back to the corresponding instance of the static ontology (of deliverable 3.1) and find out it has been described by functional requirement FR1.