Data centered architecture:
2 types:
1- Repository
2- Blackboard
Repository:
The repository architecture style is a data centered architecture that supports
user interaction for data processing.
Benefits:
• Suitable for large complex information systems where many software
component clients need to access it in different ways.
• Data integrity: easy to backup and restore.
• System scalability and reusability of agents: easy to add new software
components because they do not have direct communication with each
other.
• Reduce the overhead of transient data between software components.
Blackword:
The knowledge is represented in the format of production rules with condition
and action parts.
For each rule, if the condition is true then the action is taken.
The action is to put new conclusion data in the data store, which is the
blackboard.
Benefits:
• Suitable for solving open-ended and complex problems such that artificial
intelligence (AI) problems where no deterministic solutions exist.
• The problem spans multiple disciplines, each of them has complete
different knowledge expertise and problem solving paradigms that cooperation is a must.
• Partial, or approximate solution is acceptable to the problems.
• Exhaustive searching is impossible and impractical since it may take forever
because available knowledge and even data and hypotheses may not
complete or precisely accurate.
Hierarchical architecture:
The software system is decomposed into logical modules (sub-systems) at
different levels in the hierarchy.
Modules at different levels are connected by explicit or implicit method
invocations.
A lower-level module provides services to its adjacent upper level modules, which
invokes the methods or procedures in lower level.
3 types:
-main-subroutine
-master-slave
-layered architectures
main-subroutine:
the data is encapsulated in each individual object so that the information is
protected.
A Data Flow Diagram (DFD) is often used to model the software requirement in
this case, where bubbles or circles represent processing or activities and arrows
represent data flow.
Benefits:
- Easy to decompose the system based on the definition of the tasks in a topdown refinement manner.
- This architecture can still be used in a sub-system of OO Design.
Limitations:
- Globally shared data in classical main-subroutines introduces
vulnerabilities.
- Tight coupling may cause more ripple effects of changes as compared to
OO Design.
Master-Slave:
In this architecture, slaves provide replicated services to the master, and the
master selects a particular result among slaves by certain selection strategy.
Benefits:
It is used for the software system where the reliability is critical.
This is due to the replication (redundancy) of servers
If the master node is deleted then the slave node does not have any reason to stay.
layered architectures:
As its name suggests, in a layered architecture the system is decomposed into a
number of higher and lower layers in a hierarchy, each layer has its own sole
responsibility in the system.
Applicable Design Domains:
• Any system that can be divided between the application specific portions
and platform specific portions which provide generic services to the
application of the system.
• Applications that have clean divisions between core services, critical
services, user interface services, etc.
Benefits:
• Incremental software development based on increasing levels of
abstraction.
• Enhanced independence of upper layer to lower layer since there will be no
impact from the changes of lower layer services as long as their interfaces
remain unchanged.
• Enhanced flexibility: interchangeability and reusability are enhanced due to
the separation of the standard interface and its implementation.
• Component-based technology is a suitable technology to implement the
layered architecture; this makes the system much easier to allow for plugand-play of new components.
• Promotion of portability: each layer can be an abstract machine (see below)
deployed independently.
Lower runtime performance since a client’s request or a response to client must
go through potentially several layers
Many applications cannot fit this architectural design
Exceptions and error handling is an issue in the layered architecture, since faults
in one layer must propagate upwards to all calling layers.