Jeffrey E. Kottemann

Model integration and a theory of models

Model integration extends the scope of model management to include the dimension of manipulation as well. This invariably leads to comparisons with database theory. Model integration is viewed from four perspectives: Organizational, definitional, procedural, and implementational. Strategic modeling is discussed as the organizational motivation for model integration. Schema and process integration are examined as the logical and manipulation counterparts of model integration corresponding to data definition and manipulation, respectively. A model manipulation language based on structured modeling and communicating structured models is suggested which incorporates schema and process integration. The use of object-oriented concepts for designing and implementing integrated modeling environments is discussed. Model integration is projected as the springboard for building a theory of models equivalent in power to relational theory in the database community.

plexsys-84: An Integrated Development Environment for Information Systems

Abstract:Integrated Development Environments (ides) are presented as a unified set of information system development concepts, techniques, and computer-aided tools. An ide consists of both a complete and unified development methodology and set of computer aids that support use of the methodology. The need for ides and their characteristics are reviewed. The plexsys-84 ide is reviewed in relation to these needs and characteristics. Techniques and tools which extend the initial work are placed within the original plexsys-84 framework and are described in some detail.

Model Integration and Modeling Languages: A Process Perspective

Development of large-scale models often involves-or, certainly could benefit from-linking existing models. This process is termed model integration and involves two related aspects: 1 the coupling of model representations, and 2 the coupling of the processes for evaluating, or executing, instances of these representations. Given this distinction, we overview model integration capabilities in existing executable modeling languages, discuss current theoretical approaches to model integration, and identify the limiting assumptions implicitly made in both cases. In particular, current approaches assume away issues of dynamic variable correspondence and synchronization in composite model execution. We then propose a process-oriented conceptualization and associated constructs that overcome these limiting assumptions. The constructs allow model components to be used as building blocks for more elaborate composite models in ways unforeseen when the components were originally developed. While we do not prove the sufficiency of the constructs over the set of all model types and integration configurations, we present several examples of model integration from various domains to demonstrate the utility of the approach.

Information Systems Planning and Development: Strategic Postures and Methodologies

Two complementary issues emerge in development and implementation of a comprehensive is plan—the determination of the is functions’s strategic posture and the choice of appropriate is planning and ...

A storage and access manager for ill-structured data

Database management systems are powerful tools for processing large volumes of structured, or normalized, data. Much of the data to be stored in computer systems, however, differs from normalized data in both its logical uses and the storage structure required for its effective management. For instance, Van Rijsbergen (1979) distinguishes database retrieval from information retrieval (IR)—the retrieval of references to text—by comparing the following logical characteristics of IR systems to database management systems: IR Systems employ partial (vs. exact) matching; they are built on an underlying probabilistic (vs. deterministic) model; they classify information on a polythetic (vs. monothetic) basis, and queries are incompletely (vs. completely) specified. Similarly, other forms of relatively ill-structured data such as semantic networks [15]—which require property inheritance, and production rules—which must be joined in logical chains also differ in their logical use from normalized record structures.