1 / 40

More Software Architectures

More Software Architectures. Blackboard Architecture. In a blackboard system, a set of problem solving modules (typically called knowledge sources ) share a common global database (called the blackboard ).

hallie
Download Presentation

More Software Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. More Software Architectures

  2. Blackboard Architecture • In a blackboard system, a set of problem solving modules (typically called knowledge sources) share a common global database (called the blackboard). • Knowledge sources respond to changes on the blackboard, and interrogate and subsequently directly modify the blackboard

  3. Blackboard Architecture • To solve a complex problem, the intelligent agents cooperate as functional specialists, observing updates to the blackboard and self-actualizing (in an event driven process) when there is new information to process. • Agents continually update the blackboard with partial solutions when the agents capabilities for processing match the state of the blackboard.

  4. Blackboard Architecture • The blackboard architecture is a distributed computing model for a metaphor describing how people work together to collaboratively solve a problem around a blackboard (whiteboard in todays lingo). 

  5. Blackboard Architecture • The blackboard architecture can be very effective in solving complex distributed computing problems, including event processing problems; however, scheduling the self-actuating agents can be a key challenge.

  6. References • A Brief Introduction to Blackboard Architectures. (2007, 08 20). Retrieved 01 31, 2012, from http://www.thecepblog.com: http://www.thecepblog.com/2008/07/20/a-brief-introduction-to-blackboard-architectures/ • Hunt, :. D. (2002, 05 27). Blackboard Architectures. Retrieved 01 31, 2012, from http://www.agent.ai: http://www.agent.ai/doc/upload/200402/hunt02_1.pdf

  7. Software Architectures: Interpreter Team 2 February 2, 2012

  8. Interpreter • Also called virtual machine • Parses and executes input commands, updating the state maintained by the interpreter • Basic Idea: • A program is written in a particular language, the interpreter translates the language, and begins to act upon it

  9. cOMPOsitions • Interpreter Engine • Finishes work of interpreter • Data Store Field • Includes source code • Interpreter State • Data structure that stores state of the engine • Program State • Records progress of interpreted code

  10. INterpreter

  11. Disadvantages • Hard to design and test • Cannot generate all possible programs that could possibly be executed

  12. Advantages • Ideal for end-user programmability • Permits flexibility • Supports dynamically changing the set of capabilities • Highly dynamic behavior allowed • Can combine with other architectural styles

  13. Questions?

  14. References • Software Architecture: http://books.google.com/books?id=WHMksQOj6ScC&pg=PA76&lpg=PA76&dq=interpreter+software+architecture&source=bl&ots=Wz3582xfgT&sig=E18v3bzd0LMGcKGHQynBW5Y5dh0&hl=en&sa=X&ei=waMoT4CBCuiU2AWOy83iAg&ved=0CHcQ6AEwCA#v=onepage&q=interpreter%20software%20architecture&f=false • Interpreted Program: http://www.thomasalspaugh.org/pub/fnd/architecture.html#Interpreter • Architectural Styles Software Lecture: http://www.google.com/url?sa=t&rct=j&q&esrc=s&source=web&cd=1&ved=0CCgQFjAA&url=http%3A%2F%2Fsunset.usc.edu%2Fclasses%2Fcs578_2012b%2F05_Architectural_Styles.ppt&ei=9HkoT8u4GoSc2AWvvNneAg&usg=AFQjCNEJT5OYN9cKGFTbs8apyMPYN66RlQ

  15. Team 3Plug-in Architecture http://prezi.com/esg2ox3qu9rz/plug-in-software-architecture/

  16. Search-Oriented Architecture Team 4

  17. Search Oriented Software Architecture • Search engine is the main integration component of the architectural layer • As opposed to the traditional relational database management system • Keyboard search instead of SQL queries

  18. Overview of Search-Oriented Design

  19. In Depth Look

  20. Search Oriented Software Architecture Benefit: rapid response time and more convenient, in terms as SQL versus keyboard search Drawback: The data tier is not as organized

  21. References • Information: • courses.utep.edu/portals/870/SoftwareArchitecture • http://www.mediabuzz.com.sg/asian-emarketing/november-2011/1424-search-oriented-architecture • Images: • http://www.soainstitute.org/images/contributors/Paradkar_March11_2_Figure2.jpg • http://www.soainstitute.org/images/contributors/Paradkar_March11_2_Figure1.jpg • Thank You

  22. Space – Based Architecture Team 5

  23. Distributive Programing • Remote Procedure Calls (RPC) • Objects communicate and synchronize their process through procedure calls. CORBA, EJB, and COM. • The greater number of participating objects, the longer and more conversational paths become. • Space-Based Architecture simplifies this idea

  24. Space – Based Architecture (Blackboard Communication) • In a space implementation, the space itself synchronizes all of its participants. This is called Blackboard communication. • In Blackboard communication, Participants: • Know nothing about one another (anonymous exchange) • Do not need to be using the same process or machine • Independent of one another

  25. Distributed Caching • It is often difficult, by weighing costs and benefits, to achieve an optimal load balance in a system. • Since workers are well informed about the load upon their respective machines, a “space proxy” is charged with request redistribution. Only requests for which a worker with sufficient resources can be found will be accepted.

  26. Conclusion • Advantages of a space-based approach: • Faster development cycles • High scalability by the addition of cheap standard hardware • Shift of load from web server to concurrent worker processes. • Total decoupling of interfaces • Distributed Caching

  27. Software Architecture Design:Share Nothing • Related to the multiprocessor high transaction rate family of designs:Shared Memory, Shared Disks, Shared Nothing • Like other multiprocessor architecture designs, shared nothing is a distributed computing architecture. • A distributed system is made up of multiple computers that communicate through a computer network. The computers interact with each other in order to achieve a common goal.

  28. Shared Nothing (cont.) • Shared nothing systems, like the name implies, do not share memory nor disks among the computers within, called nodes. • Instead each node is independent and self-sufficient and does not depend on any outside resource. Shared Nothing Shared Everything Reference: http://gerardnico.com/wiki/data_storage/shared_disk_nothing

  29. Share Nothing: Advantages • Nodes that may go down or become unavailable to the network do not slow down or inhibit any other node in the system. • Subsequently, no true bottlenecks occur since no node has to “wait” for another. • Since nodes are completely independent right from the start, more can be added to the system without the need to configure any other existing node. • This leads to systems with very good scalability. System can grow as needed without significant interruption.

  30. Publisher - Subscriber • Reduce complexity between producers and consumers • Solves problem of consumers receiving irrelevant information/messages • Solution is to put information into topics/subjects and allow a consumer to subscribe to desired subjects • Reduce code • Reduces communication interactions

  31. Actors : • Publisher • Subscriber • Communication Infrastructure (optional) http://msdn.microsoft.com/en-us/library/ff649664.aspx

  32. Rule Evaluation Architecture CS 4311

  33. Rule Evaluation Architecture • Inference engine parses user input and determines whether it is a fact/rule or a query. If it is a fact/rule, it adds this entry to the knowledge base. Otherwise, it queries the knowledge base for applicable rules and attempts to resolve the query/goal. • Also known as rule-based/expert system architecture. • It is a type of layered architecture

  34. Rule Evaluation Architecture • Solve problems understood as sets of predicates • Iteratively explores problems whose general solution approach is unclear • Modifiability/Maintainability • Behavior of the application can easily be modified through dynamic addition or deletion of rules from the knowledge base • Reusability • By only changing the facts/rules the system can be used to solve problems in various domains • Flexibility • Additional facts/rules are easy to add

  35. Rule Evaluation Architecture • Actors • User interface • Inference engine • Knowledge base (shared memory)

  36. Rule Evaluation Architecture • How do they relate to each other? • Components are tightly interconnected, with direct procedure calls and/or shared data access • User interface provides two modes, one for adding rules to knowledge base and another to query knowledge base • Inference engine operates on knowledge base in response to user input. • Facts and production rules are added to the knowledge base; goals are compared against existing facts in the database. If an exact match is found, it returns true to the user interface. Otherwise, it evaluates the rules as necessary to determine the validity of the goal.

  37. Rule Evaluation Architecture • Drawbacks • When a large number of rules are involved, understanding the interactions between multiple rules affected by the same facts can become very difficult. Understanding the logical basis for a computed result can be as important as the result itself.

  38. Rule Evaluation Architecture Example: Lunar Lander in a rule-based style To see what the status of the spacecraft is, the user can switch to the goal mode and asks whether the spacecraft has landed safely :landed(spacecraft) To handle this query, the inference engine queries the database. If the existing facts and other production rules satisfy the conditions "altitude < = 0" and "velocity < 3 ft/s", then the engine returns true to the user interface. Otherwise, it returns false.

  39. Rule Evaluation Architecture Source: Taylor, R. et al., Software Architecture: Foundations, Theory, and Practice. New Jersey: John Wiley & Sons, Inc., 2010

More Related