Centralized Metadata Repository for Information System Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional architectures for information systems make it time-consuming and error-prone to develop and adapt applications due to difficulties in identifying and verifying dependencies across database, client, and user-interface components, leading to costly and failed projects.
Innovation Solution
An architecture that stores system data, application data, and rule data in a database alongside content data, ensuring integrity through meta-data management and rule interpretation across all components, allowing for quick development and adaptation with guaranteed correctness.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional architecture with distributed feature definitions is used, then developers can place features in different locations (database, client, user-interface), but it becomes difficult to identify and verify dependencies across components
Solution Approach 1:
The patent introduces a centralized metadata repository as an intermediary that stores definitions of all system features (tables, fields, data sets, forms, rules) and their relationships. This metadata acts as a single source of truth that all components (database, client, user-interface) query to understand dependencies, eliminating the difficulty of tracking distributed feature definitions while maintaining placement flexibility.
Solution Approach 2:
The system implements automated dependency verification where the metadata repository provides feedback about relationships between features. When features are defined or modified, the system automatically checks for dependencies across components and verifies correctness, making hidden dependencies visible and manageable.
2Reliability
If developers manually locate and update dependencies in traditional architecture, then system correctness can be maintained, but the process becomes time-consuming and error-prone
Solution Approach 1:
The patent implements self-service through automated dependency management. The metadata repository automatically tracks relationships between features and the system automatically verifies correctness when changes are made. This eliminates the need for developers to manually locate and update dependencies while maintaining system correctness, significantly reducing time and errors.
Solution Approach 2:
The system performs preliminary verification of dependencies before changes are committed. By checking for correctness in advance using the metadata repository, the system prevents errors before they occur rather than requiring time-consuming manual verification after changes are made.
3Reliability
If exhaustive runtime testing is performed to verify system correctness, then all behavior combinations can be checked, but development and adaptation become extremely time-consuming
Solution Approach 1:
The patent shifts verification from runtime testing to compile-time metadata validation. By checking dependency correctness in advance through the metadata repository, the system ensures reliability without requiring exhaustive runtime testing, thereby maintaining high development productivity.
Solution Approach 2:
The patent replaces the mechanical process of runtime testing with an automated metadata-based verification system. Instead of executing tests to verify correctness, the system uses structured metadata definitions and automated dependency checking to guarantee correctness, dramatically reducing verification time while maintaining reliability.
Data Source
Figure 1
Figure 2a~2b
Figure 2c~2d
AI summary
An architecture for the initial development and later adaptation of systems comprising a database, one or more client or user-interface programs and any number of supporting libraries whose system data, application data and rule data are stored in the database alongside the content data so that the correctness of the system can be conclusively verified without having to test every combination of behaviour at run-time. A framework in the database stores system, application and rule data and frameworks in the user-interface and client programs load the system, application and rule data to generate objects and, in doing so, define an application-specific system. Rules, defined in XML format, are executed by the database by calling functions in dynamically linked libraries. User-interfaces and clients load the same rules from the database which are executed by calling the same functions in dynamically linked libraries. Preferably the system structures, application structures, system data, application data, rule data and content data are stored in the same relational database but may instead be stored in different relational databases, in non-relational databases, in any persistent store or an in- memory structure; all application-specific properties and events are stored in the database but some properties and events can be stored external to the database; the integrity checking occurs both at the user-interface or client and then again at the database but such checks could occur any number of times at the point of selecting the options in the user-interface, in a middleware application through which data is passed between the user-interface or client and the database, or on committing the changes in the database.