Lecture Notes
Lecture 11 – SHARED DATA SOFTWARE ARCHITECTURE
An architecture style (also known as an “architecture pattern”) abstracts the common properties of a
family of similar designs. Define a family of systems in terms of a pattern of its structural organization.
Components Of A Style
The key components of an architecture style are:
• Elements/components that perform functions required by a system
• Connectors that enable communication, coordination, and cooperation among elements
• Constraints that define how elements can be integrated to form the system
• Attributes that describe the advantages and disadvantages of the chosen structure
Categories of Architectural Styles
•
•
•
•
•
•
•
Hierarchal Software Architecture
– Layered
Distributed Software Architecture
– Client Server
– SOA
Data Flow Software Architecture
– Pipe n Filter
– Batch Sequential
Event Based Software Architecture
Data Centered Software Architecture
– Black board
– Shared Repository
Interaction-Oriented Software Architectures
– Model View Controller
Component-Based Software Architecture
DATA CENTERED SOFTWARE ARCHITECTURE:
Data-centered software architecture is characterized by a centralized data store that is shared by all
surrounding software components. The software system is decomposed into two major partitions: data
store and independent software component or agents. The connections between the data module and the
software components are implemented either by explicit method invocation or by implicit method
invocation. In pure data-centered software architecture, the software components don't communicate with
each other directly; instead, all the communication is conducted via the data store. The shared data
module provides all mechanisms for software components to access it, such as insertion, deletion, update,
and retrieval.
There are two categories of data-centered architecture: repository and blackboard. These are
differentiated by the flow control strategy. The data store in the repository architecture is passive, and
clients of the data store are active; that is, clients (software components or agents) control the logic flow.
Clients may access the repository interactively or by a batch transaction request. The repository style is
widely used in database management systems, library information systems, the interface repository (IR)
in CORBA, the UDDI registry for web services, compilers, and Computer Aided Software Engineering
(CASE) environments. A well-known CASE tool is Rational Rose. It supports a graphic editor to draw
UML diagrams, generates various programming code, and provides reverse engineering functionality to
generate graphic diagrams from code. All Interactive Development Environments (IDE), and similar
software development kits are good examples of application domains for the repository architecture. It is
also widely used in complex information management systems where the most important issue is reliable
data management.
The data store in the blackboard architecture option is active, and its clients are passive; thus, the flow of
logic is determined by the current data status in the data store. The clients of a blackboard 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, which may in turn
change the logic flow; this could happen continuously until a goal is reached. Many applications designed
in the blackboard architecture include knowledge-based AI systems, voice and image recognition
systems, security systems, business resource management systems, etc.
REPOSITORY ARCHITECTURE
The repository architecture style is a data-centered architecture that supports user interaction for data
processing (as opposed to the batch sequential transaction processing discussed earlier). The software
component agents of the data store control the computation and flow of logic of the system.
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 in figure shown
below. A user of CASE tools can draw a UML design diagram such as a class diagram, collaboration
diagram, or sequence diagram by Booch method, Rumbaugh method, or Jacobson method, 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.
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.
Applicable domains of repository architecture:
• Suitable for large, complex information systems where many software component clients need to access
them in different ways
• Requires data transactions to drive the control flow of computation
Benefits:
• Data integrity: easy to back up and restore
• System scalability and reusability of agents: easy to add new software components because they do not
have direct communication with each other
• Reduces the overhead of transient data between software components
Limitations:
• Data store reliability and availability are important issues. Centralized repository is vulnerable to failure
compared to distributed repository with data replication.
• 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.