China
Africa
Explore chapters and articles related to this topic
C++ and Objective C
Published in Paul W. Ross, The Handbook of Software for Engineers and Scientists, 2018
One of the most distinguishing means of representing relationships between abstractions in an OO program is with inheritance. Inheritance means forming subclass/superclass relationships between classes, also known as a base class and derived class relationship. A subclass inherits members from its superclass. Many classes together form an inheritance, or a class, hierarchy. Classes at the top of a hierarchy represent the data and functionality common between the classes that inherit from them. Classes at the top tend to be more abstract; objects are usually not instantiated from such classes. Classes at the bottom of the hierarchy are more concrete, and are more likely to be instantiated into objects. Classes that inherit from only one superclass exhibit single inheritance. Classes that inherit from more than one superclass exhibit multiple inheritance. Rich language that it is, C++ supports both single and multiple inheritance.
The Object-Oriented Approach
Published in Julio Sanchez, Maria P. Canton, Software Solutions for Engineers and Scientists, 2018
Julio Sanchez, Maria P. Canton
In object-oriented systems inheritance refers to the possibility of one class acquiring the public members of its parent class. As in knowledge bases, class inheritance promotes the highest level of abstraction, reduces code size, and simplifies programming. This allows the building of a class hierarchy, from the most general to the most specific. In the diagram of Figure 28.2 we could say that animal is a base class, and that bird, fish, and canary are derived classes. The derived class usually incorporates all the features of its parent classes and adds some unique ones of its own. Also, a derived class has access to all the public members of its base class. The terms parent, child, and sibling are sometimes used to express degrees of inheritance between classes. As in biological systems, sibling classes do not inherit from each other. Therefore the properties of fish (in Figure 28.2) are not inherited by its sibling class, bird.
Knowledge-based engineering approach for defining robotic manufacturing system architectures
Published in International Journal of Production Research, 2023
Chen Zheng, Yushu An, Zhanxi Wang, Xiansheng Qin, Benoît Eynard, Matthieu Bricogne, Julien Le Duigou, Yicha Zhang
The authors’ research team developed a requirement-driven design approach for complex mechatronic systems based on the assumption that designers can easily gather complete user requirements (interested readers are referred to (Zheng, et al. 2019) for more information). However, the literature review showed that it is actually a challenge for designers to gather user requirements. Therefore, as a continuation of previous research, in this study, a part of the user requirements in the knowledge model is developed to gather user requirements and organise them in a structured representation. The authors adopted Protégé — a free, open source, and user-friendly ontology editor developed by Stanford University — to construct the ontological knowledge model. Figure 2(a) presents the class hierarchy of the user requirements described by the ontology. Such class hierarchies can be generated by OWLViz, a Protégé plug-in that enables the class hierarchies in an OWL ontology to be viewed. Figure 2(b) presents the data properties of the ontological model represented in OWL. These representations can also be generated by Protégé.
Parallel Domain Decomposition of a FEM-based Tool for Numerical Modelling Mineral Slurry-like Flows
Published in International Journal of Computational Fluid Dynamics, 2022
Sergio Peralta, Jhon Córdova, Cesar Celis, Danmer Maza
The main developments associated with the parallelisation of the FEM based tool utilised here are discussed in this section. Before doing so, it is worth highlighting first that the referred FEM tool represents one of the modules of a larger in-house computational package, which is being developed using both an object oriented programming (OOP) paradigm and C++ as the main programming language. Details of the associated C++ class hierarchy can be found in Peralta et al. (2020a). As emphasised above, in order to parallelise the FEM based tool, a DDM based approach has been followed in this work. The general steps of DDM for parallelisation purposes are shown in Figure 1. The first step involves decomposing a computational domain and distributing the work in parallel environments. The governing equations, discretised according to Equations (10) and (11), are next solved simultaneously in each subdomain. Finally, the solution of the governing equations is reconstructed in the final step. Notice that, when implementing these general steps in a CFD tool, there are many different aspects to account for. These aspects, which some of them will be separately addressed in this section, include domain partitioning, communication algorithms between computer processes, and transmission conditions, i.e. the approach followed for iteratively updating boundary conditions on subdomains interfaces.
Towards software reuse through an enterprise architecture-based software capability profile
Published in Enterprise Information Systems, 2022
Abdelhadi Belfadel, Emna Amdouni, Jannik Laval, Chantal Bonner Cherifi, Nejib Moalla
To build our OWL ontology, we first analysed the class hierarchy of our semantic modules (namely, TOGAF, BPMN, IAO and OWL-S). Then, we aligned existing ontologies’ classes to the BFO class hierarchy. By doing this alignment work, we improved the definition of key concepts of the TOGAF ontology by making them more clear, for example the class ‘TOGAF:core content’ regroups heterogeneous sub-classes as ‘TOGAF:function’, ‘TOGAF:process’, ‘TOGAF:capability’, ’TOGAF:process’, ‘TOGAF:role’ and ‘TOGAF:organisation unit’. As we can notice, the meaning of the ’TOGAF:core content’ class as it is defined within the TOGAF ontology is confusing and ambiguous regarding the description of the kind of data that it covers, i.e. does it refer to functions? Roles? Processes? Dispositions? Objects? Or data items? In order to remove this confusion and inconsistency, we first defined the class ‘TOGAF:content classification’ as a ’BFO:entity’ and then we defined the classes like ’TOGAF:function’, ’TOGAF:role’, ’TOGAF:capability’ as sub-classes of ‘TOGAF:core content’ and ’BFO:specifically dependent continuant’ given that they describe a continuant that inheres in or is borne by other entities. As consequence, the meanings of theses sub-classes are more explicit and clear under the BFO framework.