Data-Centered Software Architecture
Overview
Data-centered SW Architecture is characterized by a centralized data store that is shared by all surrounding software components
Consists of two types of components
Data Store
Software component agents
The connection between the data module and the software components is either implemented by explicit method invocation or Implicit method invocation
Software component does not communicate directly, via data store
The shared data module provides
Deletion
Update
Insertion
Retrieval
Classification
Classified into two categories (based on Flow Control Strategy)
Repository
Blackboard
Repository architecture style
Data store is passive
Clients of the data store are active
Its clients taking control of flow logic
Client may access the repository
Interactively
Batch transaction
Clients are inactive/passive
Flow of logic is determined by the current data status
Data store is active
The clients of a blackboard system are called
A new data change may trigger events so that the knowledge sources take actions to respond to these events. These actions may result in new data and change in logic flow …
Knowledge sources
Listeners or subscribers
Data-centered architecture that supports user interaction for data processing
Dash line means clients have full control over logic flow
Each agent might have different interface, functionality, privilege
Relational database management system
a typical design domain for
the repository architecture
Data store of the repository maintains all
types of data including schema (metadata), data tables, and index files for data tables
Computer Aided Software Engineering (CASE)
The biggest advantage of CASE tools is its centralized data with many supporting software tools which can generate different products for different purposes based on the same set of data.
Compiler Construction
Every compiler system has its own reserved keyword table, identifier symbol table, constant table generated after lexical analysis, and syntax and semantics trees generated by syntax and semantics analysis
Data in memory are shared by all agents and the agents don’t pass on data to each other directly
Variants of Data Repository
Virtual repository
Built up on the top of multiple physical repositories
Most DB allows users to create views that are virtual repositories since they do not exist physically.
Benefits
Simplify the overall complexity of overall database structure
Security management in terms of scope of data of manipulation for different users
Distributed repository system
All data are distributed over all sites linked by network
Data are replicated in order to Improve reliability and local accessibility
Other issues - concerns
Vertical or horizontal partitions
Synchronization of duplicated data
Cost of data transmission
Collaboration (two-phase transaction commitment)
Summary
Benefits
Limitations
Application Domain
Suitable for large complex information system
Data transactions drive the control flow
Data integrity:
System scalability and Reusability of agents:
easy to backup and restore,
Reduce the overhead of transient data between software components
Data store reliability and availability
High dependency between data structure of data store
Overhead cost of moving data on network
Related architecture
Blackboard Architecture Style
Introduction
A common knowledge base, the "blackboard", is iteratively updated by a diverse knowledge sources,
starting with a problem specification and ending with a solution.
1st Blackboard arch. developed in 1970’s
mainly used for
Speech recognition
Weather forecast
Motivated by classroom teaching
Blackboard
Teacher and students (agents) solve problems together
Agents can work collaboratively or independently
Overview
Blackboard: variation of data-centric
Consists of three partitions
Blackboard: Used to store data (Hypothesis and fact)
Knowledge Source: stores domain specific knowledge
controller: initiating the blackboard and knowledge sources
Data driven – a change in the data stored in Blackboard triggers one or more knowledge source 🡪 might lead to more changes
Blackboard Arch. in Box-Line
Properties
Each knowledge source is relatively independent
They don’t need to interact with each other
Only interact and respond to the blackboard subsystem
Class Diagram of Blackboard Arch.
A UML diagram for rule-based blackboard software
Matching Process
Dynamic interaction in a Blackboard system
Summary
Application Domain
Suitable for solving immature and complex AI problems
The problem spans multiple disciplines, each of which has complete different knowledge expertise
Optimal, partial, or approximate solution is acceptable
Exhausted searching is impossible.
Benefits
Scalability: easy to add new knowledge source
Concurrency: all knowledge sources can work in parallel
Reusability of knowledge source agents
Limitations
Tight dependency between the blackboard and knowledge source
Synchronization of multiple agents is an issue
Debugging and testing of the system is a challenge.
Related architecture
Implicit invocation architecture such as event-based, MVC architecture
Layered, multi-tier, and MVC