Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 6 - Data-Centered Software Architecture - Coggle Diagram
Chapter 6 - Data-Centered Software Architecture
6.1 Overview
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
Software component does not communicate directly
The shared data module provides
Retrival
Update and
Deletion
Insertion
Classification
Blackboard
Repository
The connection between the data module and the software components is either implemented by explicit method invocation or Implicit method invocation
Compare between Repository and Blackboard
Blackboard
Data store is active
Clients are inactive/passive
Respository
Data store is passive
Clients of the data store are active
6.2 Repository Architecture Style
Applicable domains of repository architecture
Suitable for large, complex information systems
Requires data transactions to drive the control flow of computation
Benefits
Data integrity
System scalability and reusability of agents
Reduces the overhead of transient data between software components
Limitations
Data store reliability and availability are important issues
High dependency between data structure of data store and its agents. Changes in data structure have significant impacts on its agents. Data evolution is more difficult and expensive
Cost of moving data on network if data is distributed.
The repository architecture style is a data-centered architecture that supports user interaction for data processing
Variants of Data Repository
Virtual repository
Most DB allows users to create views that are virtual repositories since they do not exist physically
Built up on the top of multiple physical repositories
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
6.3 Blackboard Architecture Style
was developed for speech recognition applications in the 1970s.
Applicable domain of blackboard architecture
Suitable for solving open-ended and complex problems
The problem spans multiple disciplines, and each problem involves completely different types of knowledge expertise and roblemsolving paradigms that require cooperation.
Exhaustive searching is impossible and impractical since it
Exhaustive searching is impossible and impractical since it may take forever because available knowledge and even data and hypotheses may not be complete or precisely accurate
Benefits
Scalability: easy to add or update knowledge source.
Concurrency: all knowledge sources can work in parallel since they are independent of each other
Supports experimentation for hypotheses.
Limitations
Due to the close dependency between the blackboard and knowledge source, the structure change of the blackboard may have a significant impact on all of its agents
it can be difficult to decide when to terminate reasoning
Synchronization of multiple agents is an issue
Debugging and testing of the system is a challenge.
Motivated by classroom teaching
Consists of three partitions
Knowledge Source: stores domain specific knowledge
controller: initiating the blackboard and knowledge sources
Blackboard: Used to store data (Hypothesis and fact)
Blackboard Arch. in Box-Line
They don’t need to interact with each other
Only interact and respond to the blackboard subsystem
Each knowledge source is relatively independent