Domain conceptual models

Abstract. In safety-critical domains, conceptual models are created in the form of metamodels using different concepts from possibly overlapping domains. Comparison between those conceptual models can fa cihtate the reuse of models from one domain to another. This paper describes the mappings detected when comparing metamodels and models used for safety assurance. We use a small use case to discuss the mappings between metamodels and models, and the relations between model elements expressed in mappings. Finally, an illustrative case study is used to demonstrate our approach. 

Selection of a conceptual model. As the first step in modeling, it is necessary to decide what kind of a conceptual model to try. For an enzyme this includes a choice of mechanism and an indication of the numerical values that go with it (determination of the best values comes later). Probably this will be better done by an expert human than by a program for some time. Examples of rules (domain knowledge) for enzyme kinetics which are applicable (regardless of the methods of calculation used) are ... 

Figure 7. Conceptual model for the morphological reorganization and continuity of the ionic domains in Nafion as the dry membrane is swollen with water to the state of complete dissolution. (Reprinted with permission from ref 76. Copyright 2000 Elsevier.)...

The success of any mathematical model, and in turn the computer code, depends completely on the clarity of the conceptual model (physical model). The authors have concluded from a comprehensive literature review on the subject of solid-fuel combustion, that there is a slight conceptual confusion in parts of this scientific domain. The first example of this is the lack of distinction between the thermochemical conversion of solid fuels and the actual gas-phase combustion process, which led these authors to the formulation of the three-step model. The thermochemical conversion of solid fuels is a two-phase phenomenon (fluid-solid phenomenon), whereas the gas-phase combustion is a one-phase phenomenon (fluid phenomenon). 

Domain Object The design domain objects that are derived from the conceptual model in Chapter 10. 

In Chapter 10, we presented a conceptual domain object model of CRS. The objects in the conceptual object model represent real-world concepts of the problem domain with which we are dealing. We said that these conceptual objects are candidates of real software objects. We also said that the design model will be more complex than the conceptual model because software... 

Different types of application domain models can be distinguished according to the objective of the model. Information models are created to support the development of software systems. Information models can be differentiated into conceptual models, design models, and implementation models, which form a series of consecutively refined models. Moreover, ontologies are to be mentioned here, whose aim is to provide an explicit specification of a conceptualization of the application domain. In the following, more precise definitions of these different types of models will be given. 

The conceptual model describes the major entities of the domain of interest and their interrelations on a conceptual level, irrespectively of a particular application or implementation. Its function is to familiarize with the vocabulary of the domain of interest and to establish a common understanding of its key concepts. In the areas of software engineering and database design, conceptual models are used as a preliminary draft or template, based on which more specific models can be created. In these communities, the terms domain model or analysis (object) model are often used instead of conceptual model (e.g., [510, 673, 761]). 

Ontologies and information models should not be regarded as mutually exclusive. They have various characteristics in common. In particular, both conceptual models and ontologies provide conceptualizations of the problem domain. Moreover, formal ontologies can be used directly by computer agents - in this respect, they resemble implementation models. 

CLiP provides a conceptualization of the most important entities and their relations in the domain of chemical process design. However, CLiP is not intended as a comprehensive, detailed product data model. Rather, it is understood as a conceptual model, based on which specialized implementation models can be developed, such as data schemata for domain-specific databases and tools, or neutral representation formats for the exchange of product data between heterogeneous software systems. Within the CRC, several implementation models for domain-specific software tools have been elaborated on the basis of CLiP. 

On the Conceptual Layer, a conceptual model of the CAPE domain is established. It corresponds to the Basic Classes layer of VeDa and to the Simple Class Layer of CLiP. 

Moreover, as tools are provided by different vendors, they are based on different system platforms, proprietary document formats, and conceptual models of the application domain. So, there is a heterogeneous landscape of existing tools. These tools constitute a proven solution for carrying out a certain activity. Engineers are familiar with these tools their use can be best practice in the application domain. Maintenance as well as further development is guaranteed due to established vendors, wide deployment, and an actively pursued dialogue between vendors and their clients. For there reasons, it is economically not feasible [973] to replace these tools by newly built ones. 

With respect to notations, methods, and tools we also have some partial results in this book. For example, we find the C3 notation for work processes, notations for representing application domain models, or PROGRES as type-and instance-based notation for conceptual modeling of tools. Furthermore, we find methodologies for using these languages. We also find tools and tool adaptations to support product and process modeling. 

In Sect. 5.7 we argued that current tool support in chemical engineering does not consider the overall design process. This situation is due to the fact that tools are provided by different vendors, that they are based on heterogeneous system platforms, proprietary document formats, and different conceptual models of the application domain. The same holds true for the area of business process support [31, 45, 210] as IT landscapes of companies are typically characterized by a portfolio of heterogeneous business application systems. ... 

This subsection deals with two aspects. (1) How application domain modeling influences tool functionality and tool construction and, furthermore, (2) how conceptual modeling drives reuse in the tool construction process. There are limits in our results in direction of a well-understood realization process with reuse, which are also described here. 

The insight we have got corresponds to the transition from application domain models to precise tool descriptions, and from there to a complete conceptual model describing the details for an executable tool. As mentioned, there are many places, where we just handcraft. 

Copolymers with sites for association in aqueous solutions were pre-pared by copolymerizing acrylamide with N-alkylacrylamides or with the ampholytic monomer pairs sodium 2-acrylamido 2 methylpro-panesulfonate (NaAMPS) and 2-acrylamido-2-methylpropane-dimethylammonium chloride (AMPDAC). The copolymers were characterized by elemental analysis, NMR and Fourier transform infrared spectroscopy, and lowhangle laser and quasielastic lightscattering measurements. Rheological properties were studied as a function of microstructure, molecular weight, polymer concentration, electrolyte concentration, and shear rate. On the basis of those results, a conceptual model that is based on microheterogeneous domain formation in aqueous solutions is proposed. 

Fig. 1 c Entangled network of rodlike aggregates in Nafion . Reproduced with permission from [35]. (2004) American Chemical Society. The position and orientation within an aggregate is characterised by the ionomer peak, and the correlation length by the USAS upturn in (b). d Conceptual model for reorganisation and continuity of the ionic domains as the dry membrane is swollen with water to the state of complete dissolution. Reprinted from [39]. (2000), with permission from Elsevier... 

Soguero-Ruiz C, Lechuga-Suarez L, Mora-Jimenez I, Ramos-Lopez J, Barquero-Perez O, Garcia-Alberola A et al. Ontology for heart rate turbulence domain from the conceptual model of SNOMED-CT. IEEE Transactions on Biomedical Engineering, 2013 60(7) 1825-1833. 

---