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