Model formalism

On the basis of the point-charge model formalism, applied on the experimental nuclear quadrupole splitting rationalization, I Agxp I, the results obtained were interpreted in terms of strong complex formation by either Me2Sn(OH)2 or Me3Sn(0H)(H20) with (n = 1 or 2, obtained in phosphate buffer) and... 

In Chap. C, the thermodynamic and structural outlook of the bond, which had been the matter of discussion in Part A of this chapter, is further developed, and the model formalism, which takes advantage of the well known Friedel s model for d-transition metals but is inspired by the results of refined band calculations, is presented for metals and compounds. Also, a hint is given of the problems which are related to the nonstoichiometry of actinide oxides, such as clustering of defects. Actinide oxides present an almost purely ionic picture nevertheless, covalency is present in considerable extent, and is important for the defect structure. 

In spite of the fact that a six-state model is a natural choice for describing the conformational distribution in PIB chains, a simpler model can be obtained by labeling all the bond conformations in the domain [60,160°] and all those in the domain [-60, - 180°I with the symbols g+ and g , respectively. This leads to a four state model formally analogous to the older ones but leaves the exact location of the gauche states undefined. 

In this chapter, the development of a mesoscopic modeling formalism is presented in order to gain fundamental insight into the structure-wettability influence on the underlying liquid water transport and interfacial dynamics in the PEFC CL and GDL. 

Finally, the overriding implications of the mesoscopic modeling formalism coupled with realistic microstructure reconstruction... 

For the nuclei studied in this experiment the dominant decay mode is Gamow-Teller beta decay.Partial halflives corresponding to Gamow-Teller beta decay calculated in a spherical shell model formalism [Bro85] are shown in Table I.The calculated lifetimes are with one exception(17C) all shorter than the measured lifetimes. 

This last equation is valid as long as the diffusion front of the diffusing species in solution phase remains within the electrode coating, a condition that applies for times shorter than 10-20 msec (Miller and Majda, 1986,1988). Dynamics of electron hopping processes have been recently modeled by Denny and Sangaranarayan (1998) using kinetic Ising model formalism. 

CLiP is implemented by means of different modeling formalisms. Both Meta... 

Process integration in PRIME is based on the integration of the contextual description of the design process steps with descriptions of the tools responsible to perform these steps. A tool model is constructed in a tool modeling formalism describing its capabilities (i.e. services provided) and GUI elements (menu items, tool bars, pop-up menus etc.). Process and tool metamodels are integrated within the so-called environment metamodel (Fig. 3.3). The interpretation of environment models enables the tools to adapt their behavior to the applicable process definitions for the current process state. Thus, the user is able to better understand and control the process execution. 

In contrast, our solution follows a situation-based approach and models the context only in situations where a well-defined method fragment exists. When such a situation occurs, the user is offered the opportunity to, on demand, follow the methodical guidance of the process engine, without being restricted to do so. Further, most of the existing approaches use process modeling formalisms with a coarse- or medium-grained representation of the process. Thus,... 

Some other researchers like Finkelstein [669] use the concept of a view in different way than we do. These approaches focus on the consistent integration of these views in order to maintain a consistent and up-to-date representation of the whole development process by superimposition of all views. While these approaches focus on the problems of view-based process definition that arise with modifiable views, we use views which usually are not modified by anyone else than the view pubhsher, so we do not face problems of consistent integration to that extent. Because we do not use different modeling formalisms for all process views (we always use dynamic task nets in all process views), we do not face the problem that two views onto the same process part model different aspects of it in a conflicting way. 

Similar work is being done to integrate the administrative and work-flow level concepts of IMPROVE into the Core Ontology. This concerns the C3 modeling formalism and method as described in Subsect. 2.4.4, and the AHEAD task management concepts from Subsect. 3.4.4. 

The internal tool models needed for tool construction reside at layer 3. Such tool models comprise the contextual process, tool and product models that are based on the disseminated application models. The first two flavors use generic modeling formalisms for their representation (i.e., elements from the environment metamodel), whereas the latter depends on the tool. At this layer, tools are further refined to the services and GUI capabilities to be considered for their process-conformed behavior. Contextual models are further extended to formulate guidance and traceability models inside the tool wrapper. 

So, what is missing is either a new general modeling formalism for conceptual realization models which can replace NATURE and Graph Transformations (or any other suitable approach) as a superset. However, this idea is not very realistic. What is more realistic is that some glue moder can be given, by which it is possible to define the connections between suitable formalisms. Here, more specifically, that means that a NATURE spec and a Graph Transformation spec can be unified in one spec. 

The integration rule modeling formalism introduced in Subsect. 3.2.3 provides the possibility to specify the behavior of integrators in a clean and consistent way. Nevertheless, it has to be extended for two reasons First, it has to be made more user-friendly by offering specific views. Second, it has to be enriched by additional constructs to support more complex rules. 

Furthermore, to reduce the development effort for building required wrappers, the subproject aimed at specifying wrappers using visual models. A corresponding modeling formalism was defined. Based on such models, executable code for the wrappers is generated and embedded into the general framework. 

This section describes how these results are transferred to the area of business application integration in order to apply the approach in an industrial environment. Based on the idea of service-oriented architectures, the modeling formalism to specify wrappers is extended to model an integrated business application as a loosely coupled set of interacting services. 

We expect technical adapters equipped with a COM interface to exist. This enables to parse the interfaces of legacy systems by the existing parser. Furthermore, a model of the COM component according to our modeling formalism can be generated (cf. technical wrapper in Subsect. 5.7.4). In this way, layer 2 is covered by phase 1 of the development process. 

Finally, the service layer is modeled (phase 6 and 7 related to layer 4) and, again, the program code is generated (phase 8). Specifications for service descriptions and service compositions and their transformation into a programming language are not yet covered by our modeling formalism. They are one of the main scientific extensions of the approach, which will be introduced in the next subsection. 

As stated in the previous subsection, the main goal of our activities is to extend our modeling formalism and its associated tools for the model-based specification of a service-oriented architecture concerning legacy systems. This includes generation of executable program code based upon such specifications. Afterwards, the program code is embedded into a test environment for evaluation and exploration of service-oriented concepts. 

The modeling formalism is enriched with concepts to model a service as a functional module, i.e. on the one hand to define the export and the import interface of the service service description), whereas imports are either other services or functions of business objects. On the other hand, the body of the service has to be specified. The body defines the control flow between the imports, i.e. sequences, alternatives, and loops of service or function calls with according execution conditions service composition). 

In addition, the modeling formalism is extended by analyses validating on the one hand syntactical correct concatenation of services and business object... 

A precise conceptualization and a compact notation for modeling the aspects mentioned above is challenging. Furthermore, to determine suitable analyses for completeness and correctness of the models, so that program code generation is possible, is also not trivial. Both are interesting aspects of the extensions of the modeling formalism to specify service descriptions and service compositions. 

As already stated in Sect. 5.7, the modeling formalism for model-driven wrapper development is formulated as a graph rewriting system using the PROGRES language [412, 414]. Consequently, the necessary concepts to model service descriptions and service compositions will be implemented as an extension of the PROGRES specification shown in Fig. 5.60 on p. 571 and Fig. 5.67 on p. 586. 

In this section, we gave a brief overview over the transfer of the results of the IMPROVE subproject 13 to industrial application. We show, how the model-driven wrapper development process and its associated tool support (cf. Subsect. 5.7.4) can be applied to business application systems. A sketch of an integrated business application architecture following a service-oriented architectural style was drawn. Furthermore, we discussed the adaptation and necessary extensions of the existing approach, namely the technical infrastructure, the modeling formalism, the code generation, and the user interface. 

---