Data-Centered Software Architecture

Dewan Tanvir Ahmed, Ph.D.

King Saud University
dtahmed@ksu.edu.sa

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

Overview
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

Insertion
Deletion
Update and
Retrieval

Classification
Classified into two categories (based on Flow Control Strategy)
Repository
Blackboard

Repository
Repository
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

Examples
Database management system
Library Information system
Interface repository in CORBA
UDDI registry for Web Services
CASE tools IBM Rational Rose
IDE (Interactive Development Endowment)

Blackboard
Blackboard
Data store is active
Clients are inactive/passive

Flow of logic is determined by the current data status

The clients of a blackboard system are called
Knowledge sources
Listeners or subscribers

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

Example:
Knowledge-based AI system
voice and image recognition system
Security system
Business resource management systems.

Repository Style
Dash line means clients have full control over logic flow
Each agent might have different interface, functionality, privilege

Bootstrap

Agent 1

Agent 2

Repository

Repository Architecture

Agent n

Example: Student Record DB

It describes the static relationships between data classes and their backup
database tables
It describes the static relationships between data classes and their
collection classes collection classes
A programming oriented view of the repository design architecture
class

class

Students

Student

- Vector or Arraylist

Students table

r0

123

Solomon

r1

234

Anderson

987

Smith

- SSN
- Name
database

+
+
+
+
+

Students()
add()
remove()
next()
first()

+
+
+
+
+

Student()
getSSN()
setSSN()
getName()
setName()

connectivity

Instance of Student class represent

one specific record in the database
table

rn

Client: Students class, has a list of Student instances (in Vector)

Store: Students table (student_id, student_name)
Follows Model-View-Controller model

The relational database management system is a typical design

domain for the repository architecture.
The data store of the repository maintains all types of data
including schema (metadata), data tables, and index files for data
tables.
Many tools are available to develop applications on the database
stored in the database management system.
These include design, development, maintenance, and
documentation tools.

Example 2: CASE Tool

Commands

Program
Scripts

menu

CASE tool

Diagrams

Diagram drawing

Reports (Text
Specifications)

Data
reposition

Fill -in- Forms

(Specifications)

Generated diagram
form RE

Code for
Reverse Engineering

Graphic
Files

Text Report
Files

Text Code
Files

A Computer Aided Software Engineering (CASE) system is another popular

application domain for the repository software architecture.
There are many CASE tools surrounding the data store
A user of CASE tools can draw a UML design diagram such as a class diagram,
collaboration diagram, or sequence and store the design blueprints in the
CASE data store.
These UML diagrams can then be converted from one format to another.
Java or C++ skeleton code can also be generated based on these UML
diagrams. If there is code without the original design diagram, the UML
diagram can still be regenerated by reverse engineering tool.
There are many other input formats available for design and many output
formats, as well.

Compiler construction is another good example of the

repository architecture design.
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.
These tables' data structure in memory is shared by all
phases of the compilation.
Each phase will generate new data or update the
existing data in the data repository.

The flow control is controlled by a program which takes a source

code as its input, then goes through each phase step by step, and
finally produces the target binary code which is either executable
or interpretable, such as Java bytecode. In other words, all agents
in a repository system are not necessarily completely
independent.
There is a logical order in the executions of all compilation
phases. There may still be some communication between
individual agents.
For example, the lexical analysis may find some unacceptable
characters, so that the compilation must be abandoned and
compile errors must be reported.

Example 3:
Compiler
Construction

Compiler tool

scanner

int x, y;
x= y + 1;

code
generator

parser

int

int

Statement

Var
(Int)

x
(Int)

exp
(Int)

y
(Int)

1
(Int)

mov ax, [y]

add ax, 1
mov [x], ax

[x] address of variable x

In symbol table

Symbol
table

parse tree

Type check
By semantic
Question: why not batch
parser
sequence?
The data in memory are shared by all agents and the agents dont pass on
data to each other directly.

The scanner takes two lines of an int type variable declaration

and an assignment statement.
The lexical analyzer (scanner) tokenizes all input entities and puts
them in the symbol table used by the syntax analyzer (parser) to
build a syntax tree based on the grammar.
This syntax tree is checked again by the semantics analyzer (not
shown) and is also used by the code generator to produce the
target code.
We can see that the data in memory are shared by all agents and
that 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

Variants of Data Repository

Distributed repository system (distributed database 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: Data Repository

Application Domain
Suitable for large complex information system
Data transactions drive the control flow

Benefits
Data integrity:
easy to backup and restore,

System scalability and Reusability of agents:

Reduce the overhead of transient data between software components

Cons
Data store reliability and availability
High dependency between data structure of data store
Overhead cost of moving data on network

Blackboard Architecture Style

Introduction
Blackboard system:
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 1970s

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

How does it work?

Data driven a change in the data stored in Blackboard triggers one or
more knowledge source might lead to more changes

The connections between the blackboard subsystem and

knowledge sources are basically implicit invocations from the
blackboard to specific knowledge sources, which are registered
with the blackboard in advance.
Data changes in the blackboard trigger one or more matched
knowledge source to continue processing.
Data changes may be caused by new deduced information or
hypotheses results by some knowledge sources.
This connection can be implemented in publish/subscribe mode.

Blackboard Arch. in Box-Line

Properties
Many domain-specific knowledge sources collaborate together to solve a
complex problem such as pattern recognition or authentication in
information security
Each knowledge source is relatively independent
They dont need to interact with each other
Only interact and respond to the blackboard subsystem
Each source works on a specific aspect of the problem and contributes a
partial solution to the ultimate solution

Blackboard Arch. in Box-Line

Agent 1

Agent 2

Agent n

Also called subscriber

mode

Data links
Blackboard

Flow logic
control

Note the direction of

control flow

Class Diagram of Blackboard Arch.

A UML diagram for rule-based blackboard software

Blackboard
-facts
+inspect()
+update()

Knowledge
Source (KS1)
-rules
+matchInspect()
+update()

n
1

Control
-Blackboard
-KS
-controller
+execute()

As we can see, one blackboard may have many knowledge sources associated with it,
working on given data and deduced data available in the blackboard subsystem.
Each knowledge source helps to solve problems in its expertise area. Knowledge can be
stored in different knowledge representation formats depending on the reasoning
strategy.
For example, a knowledge source stores all related rules and provides activation
mechanisms for the blackboard to trigger in rule-based expert system.
Of course, knowledge sources must register themselves with the blackboard so that if
any change takes place in the blackboard, they will be notified to fire up actions in the
corresponding knowledge sources, which can deduce new facts and update the
blackboard.
Each individual knowledge source may have its own problem solving strategy and use
its own knowledge expertise to contribute to a partial solution which will lead to a final
solution.
The blackboard class holds the current data state, and the final problem solution will be
placed in the blackboard for the controller to pick up and use to generate a final report.
The rule-based strategy is one of many reasoning algorithms in use today.
There are many other problem solving strategies that can be applied including Fuzzy
set theory, probability and statistics, neural network, data mining, and heuristic
searching.

Example: KBS
Since the blackboard architecture is basically a self-activated
system, the controller subsystem in the architecture only acts at
the beginning of the process to initiate blackboard and all
knowledge sources; it also periodically inspects the current state of
the blackboard to determine whether to terminate the processing
if the solution is acceptable or optimal enough.
KBS: Knowledge Based System
Knowledge: represented as production rule
Condition
Action

Example Setting
Here is a set of rules:
R1: IF animal gives milk THEN animal is mammal
R2: IF animal eats meat THEN animal is carnivore
R3: IF animal is mammal AND animal is carnivore AND animal has tawny
color AND animal has black stripes THEN animal is tiger

The set of facts is

F1:
F2:
F3:
F4:

animal eats meat

animal gives milk
animal has black strips
animal has tawny color

GOAL: Which animal it is?

How to Solve Problems

Two major approaches
Forward Reasoning
Backward Reasoning

Both can use the blackboard arch.

Facts in blackboard
Rules in agents

Example: forward reasoning

F1 matches R2 produces new fact F5: it is a mammal
F2 matches R1 produces new fact F6: it is carnivore
F5,F6,F3,F4 matches R3 produces the result

Matching Process
Knowledge
Source i

Control

Blackboard

initiate()
intiate()
matchInspect()
update()
matchInspect()
update()
inspect()

Dynamic interaction in a Blackboard system

How is the subscribing implemented?

KS 0
Event Sink 0
handleEvent 0
( exec) action

Blackboard ( Fact i )
addEventListener()
KS EventTrigger()
Vector V

0 1

n-1

.
scan

KS (n-1)
Event Sink (n-1)
handleEvent (n-1)
(exec) action

Publish/subscriber relationship between blackboard and knowledge

sources

Another Example: Travel Reservation

Travel Consulting System
Process
A client submits a request
The system stores all the data in the blackboard
The blackboard makes a request to the air agent
Once air reservation data is returned and stored in blackboard,
the change triggers hotel, auto rental, attraction agents for a
travel plans under budge and time
Client chooses one of the plan
The system triggers the billing process
Two major approaches

Example: Travel Reservation

Air agent

Attraction
agent

Hotel agent

Auto agent

Travel Reservation System

Billing agent

control

db
client

Why not repository arch. for travel

reservation?

Observation:

User requests in relatively fixed format

Hard to integrate all knowledge (business logic) in a central store, why?
Hotel discounts rules changes every day!
Many specialized hotel reservation services available?

best solution: publish the contract data and let all of them bid.

Summary - Blackboard
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.

Pros
Scalability: easy to add new knowledge source
Concurrency: all knowledge sources can work in parallel
Reusability of knowledge source agents

Cons
Tight dependency between the blackboard and knowledge source
Synchronization of multiple agents is an issue
Debugging and testing of the system is a challenge.