Software Paradigms S.H. Kaisler, 440 p., Wiley, Chapters 12-17

Transcription

1 SENG 401 Analysis and Design of Large Scale Software II Focus Programming paradigm Program Structure Variables Structures Classes, Objects Data Types Chapter 5: Architectural Patterns (Styles) Department of Electrical & Computer Engineering, University of Calgary B.H. Far 1 Conceptual view Module view Code view Execution view Design Pattern Components Software Architecture Frameworks 2 Review: Conceptual View Factors Issues Requirements Reference Architecture Reference architecture is usually used to devel the initial conceptual configuration of a system Components Connectors Protocols Resources Behavior using State chart or Activity Diagram Spec using Sequence Diagram Table of Contents Introduction to architectural patterns (AP) Components, connector, attributes, interface, configuration AP1: Data flow systems AP2: Call-and-return systems AP3: Independent components AP4: Virtual machines AP5: Data-centered systems Case study SENG401 (Winter 2008) far@ucalgary.ca 3 far@ucalgary.ca 4 Reference Software Paradigms S.H. Kaisler, 440 p., Wiley, Chapters Architectural Patterns (Styles) An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. Buschman et al, Pattern-Oriented Software Architecture A System of Patterns Examples: Layers (application is decomposed into different levels of abstraction) Model-view-controller (M-V-C) (application is divided into three partitions: The Model, which is the business rules and underlying data; the View, which is how information is displayed to the user; and the Controllers, which process the user input.) Pipes and filters (data is processed in streams that flow through pipes from filter to filter) Blackboard (independent specialized applications collaborate to derive a solution, working on a common data structure) SENG401 (Winter 2008) far@ucalgary.ca 5 far@ucalgary.ca 6

2 Architectural Patterns (Styles) Elements of Architectural Descriptions Architectural patterns (styles): Recurring pattern or idiom for expressing software architecture Ref: Garlan and Shaw Classification of architectural styles Architectural Style Architectural Idiom Data flow systems Batch sequential Pipes and filters Call-and-return systems Main program and subroutines Client server systems Object-oriented systems Hierarchical layers Independent components Communicating processes Event-based systems Virtual machines Interpreters Rule-based systems Data-centered systems Database systems Blackboards Architectural definition of a system includes Components: define the loci of computation Examples: filters, databases, objects, ADTs Connectors: mediate interactions of components Examples: procedure call, pipes, event broadcast Attributes: specify info for construction & analysis Examples: signatures, pre/post conditions An architectural style defines a family of architectures constrained by Component/connector vocabulary + Tology rules + Semantic constraints far@ucalgary.ca 7 far@ucalgary.ca 8 Elements of Architectural Description Component Attributes Ports (Interfaces) Connector Attributes Configuration Ref: Stephen H. Kaisler: Software Paradigms, ch 12, Wiley, 2005 Component Attributes far@ucalgary.ca 9 Components & Attributes Basic building blocks and the active computational entities in a system. A component communicates with its environment (which includes other components) through one or more ports or interfaces. A port may be a user interface, a shared variable, a procedure name that can be called by another component, a set of events that can be emitted, or some other mechanism. Attributes (or prerties) of the component specify information for analysis and develment of the software, such as protocols, real-time constraints, and behavioural constraints. Ref: Stephen H. Kaisler: Software Paradigms, ch 12, Wiley, 2005 far@ucalgary.ca 10 Connectors & Roles Connectors define the interaction between components and describe the rules that govern those interactions. A connector links the ports of two or more components. A Connector has a Role attached to it as an attribute that defines the behaviour of the attached components. e.g., in a unidirectional communication scheme, one component would be the source, while the other component would be the receiver. A Connector can have other attributes. e.g., rates, capacities, and latencies of a connector. Interfaces A component defines an interface through which a connector links one component with another. A component may have multiple interfaces. An interface is associated with one and only one component. therefore we can treat them as one One interface may connect to multiple interfaces in other components. Interfaces may have attributes, too. e.g., direction of communication, buffering capacity, protocols accepted. Ref: Stephen H. Kaisler: Software Paradigms, ch 12, Wiley, 2005 far@ucalgary.ca 11 Ref: Stephen H. Kaisler: Software Paradigms, ch 12, Wiley, 2005 far@ucalgary.ca 12

3 Configuration = Tology A configuration (tology) is a connected graph of components and connectors that describes architectural structure. The configuration must: Adhere to the rules for prer connectivity. Satisfy concurrent and distributed prerties. Adhere to constraints such as design heuristics and style rules. e.g. end-to-end connectivity may be no longer than five components. Configuration can be analyzed for: system prerties such as performance, bottlenecks, concurrency, system reliability, security, etc. Ref: Stephen H. Kaisler: Software Paradigms, ch 12, Wiley, 2005 far@ucalgary.ca 13 Configuration: Multiplicity A system can have several configurations Example: A compiler Ref: Stephen H. Kaisler: Software Paradigms, ch 17, Wiley, 2005 SENG401 (Winter 2008) far@ucalgary.ca 14 Architectural Styles Architectural Style AP1: Data flow systems AP2: Call-and-return systems AP3: Independent components AP4: Virtual machines AP5: Data-centered systems Architectural Idiom Batch sequential Pipes and filters Main program and subroutines Client server systems Object-oriented systems Hierarchical layers Communicating processes Event-based systems Interpreters Rule-based systems Database systems Blackboards Data Flow System In a data flow system the availability of data controls the computational process. Different from vonneumann s controldriven computation model Data centered: what to compute rather than how or when to compute. Data flow conceptual elements: process, file, data flow. Data flows from one process to the next, through a series of processes where each process performs one or more erations on the data. similar to a production line Common forms: Batch sequential; Pipes and filters far@ucalgary.ca 15 far@ucalgary.ca 16 Data Flow System: Types Transform flow: incoming input data is transformed within the system into an internal form. While the information is in the system, it may be subject to further transformations while in its internal form. Finally, outgoing data is transformed within the system from an internal form to its external form. Transaction flow: a single input item triggers data flow along several action paths. Many interactive systems and query/response systems fit this model. Each element along the data flow path usually has multiple outputs. Some elements are incorporated solely as junctions to recombine separate paths. Data Flow System: Example EXCEL spreadsheets Symbolic links in UNIX Shell or other programming scripts, e.g., a Perl script for changing name of several files Filling a template Counter examples: Word processing, CVS system, file-sharing system far@ucalgary.ca 17 far@ucalgary.ca 18

4 Data Flow System: Implementation Components communicate by passing messages through unidirectional ports Components can have one or more I/O ports Component Component Connector Connector Component Component Data Flow System: Issues Each component is isolated from performance of upstream component. If an upstream component computes faster than its downstream neighbour, the results accumulate in the buffer until used. Physical hardware/software limitations impose a finite size on the buffer causing overflow error. Order of processing by components matters. Components may be memoryless (no internal state preserved) or with memory. Only memoryless components can be replaced at runtime. far@ucalgary.ca 19 far@ucalgary.ca 20 AP1.1 Batch Sequential System A batch sequential system is a collection of programs that are arranged and executed sequentially. Each program runs to completion. Data is transmitted between the programs via files stored on external storage. A program reads data from one or more files, processes it, and writes one or more files before exiting. Then the next program, if there is one, is initiated. far@ucalgary.ca 21 Batch Seq. System: Example 1. UNIX pipe command: cat foo.txt grep bar sort > baz.txt cat grep sort foo.txt 2. Master file processing system baz.txt far@ucalgary.ca 22 Batch Seq. System: Prerties Low memory requirement High latency for I/O Trade-off: memory vs. speed Limited portunity for concurrency Limited portunity for synchronization Unable to support interactive systems e.g., cannot interrupt the Unix pipe AP1.2 Pipe & Filter System A pipe and filter architecture is one in which one or more data sets are processed in discrete, separable stages. Each stage is represented by a component. A component erates on the entire data set and passes its results along to the next stage: local transformation of input stream / incremental computation ( Filter) Connectors between components serve as link ( Pipe) far@ucalgary.ca 23 far@ucalgary.ca 24

5 inputs Pipes and Filters: Tology Filter Pipes Filter Filter Filters Filter Filter Filter outputs Pipe & Filter System: Prerties Pure data-driven interaction Each component has a set of inputs and a set of outputs Data transmitted as a whole between Filters Filters are independent programs Each transformation step runs to completion before next step starts possible processing delays Filters ignore identity of upstream/downstream filters Correctness of output depends on the order of filters far@ucalgary.ca 25 far@ucalgary.ca 26 Pipe & Filter System: Example A compiler Pipe & Filter System: Example A Web browser with streaming pipeline Filters Network interface Input data Streaming processor Active reader Document interpreter HTML tree Document formatter HTML file Document displayer Ref: Stephen H. Kaisler: Software Paradigms, ch 13, Wiley, 2005 far@ucalgary.ca 27 Q. What if display has several (dependent or independent) fields to be updated? far@ucalgary.ca 28 Pipe & Filter System: Summary Filter Incrementally transform some amount of the data at inputs to data at outputs Stream-to-stream transformations Use little local context in processing stream Preserve no state between instantiations Pipe Move data from a filter output to a filter input Pipes form data transmission graphs Overall Computation Run pipes and filters (non-deterministically) until no more computations are possible. Pipe & Filter: Advantages Allow designers to understand system input/output behavior as simple composition of the behaviors of individual filters Support of reuse: any two filters can be hooked together, provided they agree on the data transmitted between them Easy maintenance: new filters can be added; old filters can be replaced by improved ones Allow for throughput and deadlock analyses far@ucalgary.ca 29 far@ucalgary.ca 30

6 Pipe & Filter: Disadvantages Order of filters matters should be decided by the designer Difficult to maintain correspondences between two separate but related streams remember Web browser example Multiple I/O problem: difference in arrival data rates can impose a performance bottleneck in the system. Ref: Stephen H. Kaisler: Software Paradigms, ch 13, Wiley, 2005 far@ucalgary.ca 31 Architectural Styles Architectural Style AP1: Data flow systems AP2: Call-and-return systems AP3: Independent components AP4: Virtual machines AP5: Data-centered systems Architectural Idiom Batch sequential Pipes and filters Main program and subroutines Client server systems Object-oriented systems Hierarchical layers Communicating processes Event-based systems Interpreters Rule-based systems Database systems Blackboards far@ucalgary.ca 32 Call & Return System A Call & Return style is a synchronous software architecture in which the client ceases execution while the service provider performs the service. Upon completing the service, the service provider may return a value to the client. Call & Return style is used when the order of computation is fixed. Call-and-return control flow AP2.1 Main Program/Subroutine The main program and subroutines architecture consists of a main program that acts as a controller (or executive) and one or more subroutines that perform specific functions when called by the main program. This architecture is based on the definition use relationship, which imposes a single thread of control. The correct eration of the main program and any subroutine is directly dependent on the correct eration of the subroutines it calls. Ref: Stephen H. Kaisler: Software Paradigms, ch 13, Wiley, 2005 far@ucalgary.ca 33 far@ucalgary.ca 34 Main Program/Subroutine Subroutines main Ref: Stephen H. Kaisler: Software Paradigms, ch 13, Wiley, 2005 Call/return controller far@ucalgary.ca 35 Main Program/Subroutine: Essentials Hierarchical decomposition: Based on definition-use relationship Single thread of control: Supported directly by programming languages Subsystem structure implicit: Subroutines typically aggregated into modules Hierarchical reasoning: Correctness of a subroutine depends on the correctness of the subroutines it calls far@ucalgary.ca 36

7 Main Program/Subroutine: Advantages & Disadvantages Advantages: Simple to visualize and easy to learn. A single thread of control works its way through the various subroutines. Disadvantages: Correctness of any job depends on all subroutines called. Tendency to devolve into spaghetti code: several subroutines may do similar job due to similar requirements added at different times in the application s lifetime. Scalability & configuration control: one can lose visibility of the flow of control over several subroutines Master Slave Architecture Variant of the main program/subroutines architecture. Definition: A coordinating process that distributes job to one or more slave processes. When a slave process finishes its job, it asks the master process for more job. Requirement: the master must know location, configuration and capabilities of the slaves. far@ucalgary.ca 37 far@ucalgary.ca 38 Client Server & P2P Systems Both variant of the main program/subroutines architecture. The primary difference is the assumption that the client and server are located on different computer systems. The client is an entity that makes a request for a service. The server is an entity that can provide that service upon request. Requires existing implementation of protocols between client and server that may restrict the flexibility of the interaction between the two. Client Server & P2P Systems Client/Server 3-tier: Functionality is equally divided into three logical partitions: application, business, and data services. Fat Client: More functionality is placed on the client. Fat Server: More functionality is placed on the server. Distributed Client/Server Peer-to-Peer: Any process or node in the system may be both client and server. far@ucalgary.ca 39 far@ucalgary.ca 40 Client A Client/Server Architectures Application Services Engine Client B Thinner client, thicker server Application DCOM CORBA Beans ADO/R Business COM Object Server MTS Beans ETS Services Engine Client C Web HTML Server CGI WWW Browser ASP Services Engine Java Client/Server: 3-Tier Style Application Services Application services, primarily dealing with GUI presentation issues, tends to execute on a dedicated deskt workstation with a graphical, windowing erating environment. Business Services Client B Application DCOM CORBA Beans ADO/R Business COM Object Server MTS Beans ETS Services Engine Data services tend to be implemented using database server technology, which tends to execute on one or more highperformance, high-bandwidth nodes that serve hundreds or thousands of users, connected over a network. Business services are typically used by many users in common, so they tend to be located on specialized servers as well, though they may reside on the same nodes as the data services. Database Server(s) Data Services Database Server(s) far@ucalgary.ca 41 far@ucalgary.ca 42

8 Client/Server: Fat Client Client/Server: Web Appli Style The client is Fat since nearly everything runs on it (except in a variation, called the two-tier architecture, in which the data services are located on a separate node). Application Services, Business Services and Data Services all reside on client computers. The database server is usually on another computer. Application Services Business Services Client A Application Services Application Services Business Services Client C Web HTML Server CGI WWW Browser ASP Services Java Here the client is simply a Web Browser running a set of HTML pages and Java applets, Java Beans or ActiveX components, there is very little application there at all. Nearly all work takes place on one or more Web servers and data servers. Engine Engine Data Services Database Server(s) Data Services Database Server(s) far@ucalgary.ca 43 far@ucalgary.ca 44 Peer-to-Peer Style Distributed Client-Server: CORBA Application Services Business Services Data Services Application DCOM CORBA Beans ADO/R COM MTS Beans ETS Services Engine Peer-to-peer systems tend to be complex, and there is a greater need to be aware of issues such as deadlock, starvation between processes, and fault handling. Application DCOM CORBA Beans ADO/R COM MTS Beans ETS Services Engine IDL defines components boundary, i.e., interface with other components All components on ORB use IDL as their interface Every object (distributed object) is a component C C++ Java Ada C C++ Java IDL IDL IDL IDL IDL IDL IDL IDL Client ORB Server Ada far@ucalgary.ca 45 far@ucalgary.ca 46 Distributed Client-Server: CORBA Static and Dynamic methods Two types of client-server invocation: static and dynamic The server is not aware whether the invoked method is static or dynamic Dynamic invocation Client Client IDL stubs ORB Object Implementation Server IDL Skeletons + Object Adapter Type of Connection Connectionless communication: e.g. via UDP (User Datagram Protocol), implements unreliable delivery of messages. Clients should use connectionless communication when the application service handles errors and participates in broadcast or multicast service, or performance requirements cannot tolerate virtual circuit overhead delays. Connection-oriented communication: e.g. via TCP/IP (Transfer Control Protocol/Internet Protocol), implements reliable delivery of messages. Connection oriented communication makes programming easier because the protocol includes mechanisms for detecting and handling errors and an acknowledgment mechanism between client and service. far@ucalgary.ca 47 far@ucalgary.ca 48

9 Stateless vs. Stateful Servers State information: Information a server maintains about its clients. A server may or may not retain this information. State information may be required if the information exchange between the client and the application consists of multiple messages. State information may reduce the size of succeeding messages and may allow the server to respond more quickly. State information can become useless if messages are lost, duplicated, or delivered out-of-order, or if the server crashes and must be rebooted. Stateless servers rely on the application protocol to assume the responsibility for reliability of delivery and service. Thus, the application gives the same response no matter how many times a request arrives. Stateful designs can lead to complex application protocols and error handling mechanisms. Client Server: Issues In designing client-server systems the following issues must be considered: Authentication: Verifying the identity of the client and its rights/privileges. Clients may be restricted to the systems they can access when multiple servers are available. Authorization: Verifying the rights/privileges of the client. Clients may be restricted in the kinds of commands they may issue, the applications they can run, or the data they can retrieve. Data Security: Protecting the data stored on the server. Servers must provide protection to prevent unauthorized release or modification of the data stored on them. Protection: Protecting the system itself from errant applications. Servers must provide mechanisms for trapping errant applications and preventing them from damaging the system and its resources. Middleware: selecting the right middleware for the task. far@ucalgary.ca 49 far@ucalgary.ca 50 Data Abstraction Style Data Abstraction (Object-Oriented) style is a special case of the main program/subroutines architecture. key differences: Objects are encapsulated so that communication occurs through a message-passing or procedure call mechanism. Object systems also support inheritance and/or delegation mechanisms not necessarily available in program/subroutines architecture. Data Abstraction or Object- Oriented Systems Interaction obj obj is an object is an invocation obj obj obj obj obj obj obj far@ucalgary.ca 51 far@ucalgary.ca 52 ADT & OO-Systems: Essentials Encapsulation: Manager is responsible for preserving integrity of a resource Restricted access to certain information Inheritance: Share one definition of shared functionality Dynamic binding: Determine actual eration to invoke at runtime Management of many objects: Provide structure on large set of definitions Reuse and maintenance: Exploit encapsulation and locality ADT & OO Systems: Advantages Data hiding easy maintenance of objects without affecting the clients that use these objects Supporting concurrent execution Natural problem decomposition collection of interacting objects far@ucalgary.ca 53 far@ucalgary.ca 54

10 ADT & OO Systems: Drawbacks Layered Systems Main issue: In order for one object to interact with another it must know the identity of that other object If identity of an object changes, it is necessary to modify all other objects that explicitly invoke it Potentially side-effect problems: if A uses object B and C also uses B, then C s effects on B look like unexpected side-effects to A, and vice versa Note: both problems can be limited if discipline is used in implementation! A hierarchically layered system consists of a large software application that is partitioned into layers. Each layer acts as a virtual machine for the layers above it, providing services to those layers. In turn, it acts as a client to the layers below it. Communication between layers occurs through well-defined APIs Application Subsystems Business Specific Middleware System Software Specific functionality General functionality far@ucalgary.ca 55 far@ucalgary.ca 56 Layering Considerations Visibility Dependencies only within current layer and the next lower layer Volatility Upper layers affected by requirements changes Lower layers affected by environment changes Generality More abstract model elements in lower layers Number of layers Small system: 3-4 layers Complex system: 5-7 layers Goal is to reduce coupling and to ease maintenance effort Layering Defects A sample layering Layer Definitions and rationale defined Examine the layers of the system using the following criteria: 1. There are no more than seven (plus or minus two) layers. 2. The rationale for each layer definition is clearly presented and consistently applied. 3. Layer boundaries are respected within the design. 4. Layers are used to encapsulate conceptual boundaries between different kinds of services and provide abstractions to make the design easier to understand. far@ucalgary.ca 57 far@ucalgary.ca 58 Modeling Architectural Layers Layers Example /1 Architectural layers can be modeled using stereotyped packages <<layer>> stereotype Layers can be represented in Rose as packages with the <<layer>> stereotype. The layer descriptions can be included in the documentation field of the specification of the package. Since a layer can be modeled as a package it can appear in a class diagram or a use-case diagram. <<layer>> Package Name far@ucalgary.ca 59 <<layer>> Presentation Logic <<layer>> Business Logic <<layer>> Middleware Base Reuse global Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI The Middleware layer provides utilities and platform-independent services. The Base Reuse package contains some common, generic reusable design elements and patterns. far@ucalgary.ca 60

11 Layers Example /2 Avoiding Circular Dependency The Presentation Logic layer contains the design elements that are specific to the presentation of the application. We expect that multiple applications will share some key abstractions and common services. These have been encapsulated in the Business Logic layer, which is accessible to the Presentation Logic layer. The Business Logic layer contains business-specific elements that can be used in several applications, not necessarily just this one. <<layer>> Presentation Logic <<layer>> Business Logic A B C A B Hierarchy should be acyclic Circular dependencies make it impossible to reuse one package without the other A A' B C far@ucalgary.ca 61 far@ucalgary.ca 62 OOAD + Architecture Involving architecture in OOAD is also a layered practice! Layered System: Example /1 Access to a certain types of relational database from a certan applications Access to several types of relational database from several applications far@ucalgary.ca 63 far@ucalgary.ca 64 Layered System: Example /2 Access via Java Database Connectivity (JDBC) Class library for access to SQL databases; package java.sql SQL commands are sent to a database as a string with help of JDBC methods The database performs the SQL commands and delivers the requested data and success or failure messages Data delivered from the database is read again through JDBC methods Layered System: Example /3 Access via Type-1 Driver (JDBC-ODBC Bridge) Used for the communication with the ODBC-Driver available to the database Advantage: Same Type-1 JDBC driver can communicate with every database system, for which a ODBC driver is available Disadvantages: ODBC driver used by the JDBC driver depends on the erating system on which the database application runs and on the database system used If the same JDBC application is deployed on another erating system, an ODBC driver for this erating system needed. far@ucalgary.ca 65 far@ucalgary.ca 66

12 Layered System: Example /4 Access via Type-2 Driver Access to communication with the database on a programming interface provided by the database manufacturer (e.g., Oracle Call Interface, Informix- CLI) Advantage: The JDBC Driver can be adapted by the database manufacturer to the specific capabilities of the database Disadvantages: Type-2 JDBC drivers can only communicate with the database system, for which it was programmed Layered System: Example /5a Access via Type-3 Driver (net-protocol all-java) The JDBC driver does not communicate directly with a database system, but with an application server over a database-independent protocol Application server translates messages of the client into messages that can be processed by a specific database system Application server can run either on the client computer, the server computer or on a third computer (Three Tier Architecture) Advantage: The driver is programmed 100% in Java and therefore works with every erating system, on which Java programs can be run. The driver uses a database-independent communication protocol and can therefore be used together with every database system, supported by a given application server. Disadvantages: The driver works together exclusively with application server of the particular middleware manufacturer. Only database systems supported by the application server can be used. far@ucalgary.ca 67 far@ucalgary.ca 68 Layered System: Example /5b Layered System: Example /6a Access via Type-4 Driver (Native Protocol all-java) The driver is 100% programmed in Java and therefore works with every erating system, on which Java programs can be run. The driver communicates direct with the database system over the communication protocol of the database manufacturer. Advantages: OS dependent ODBC driver or CLIs not needed on the client. Performance losses caused by the conversion of JDBC calls to other programming interfaces (e.g. Types 1/2) or from one communication protocol to another (e.g. Type 3) are avoided. Disadvantages The driver can only communicate with the database system, for which it was develed. When changing to another database system a new driver is needed. Not all database manufacturers offer Type-4 drivers. far@ucalgary.ca 69 far@ucalgary.ca 70 Layered System: Example /6b Layered Systems: Summary Each layer provides certain facilities hides part of lower layer provides well-defined interfaces Serves various functions kernels: provide core capability, often as set of procedures shells, virtual machines: support for portability Various scing regimes Opaque versus translucent layers far@ucalgary.ca 71 far@ucalgary.ca 72

13 Layered Systems: Advantages Support designs based on increasing levels of abstraction allows designer to partition a complex problem into a sequence of incremental steps Support maintenance each layer interacts with at most the layers below and above Support reuse: like ADTs allow for different implementations of the same layer to be used interchangeably possibility to standardize layer interfaces; e.g., APIs, OSI ISO model Layered Systems: Disadvantages Not all systems can be easily structured in a layered fashion; sometimes users need to access functionality in all layers Example: Oscillosce case study at Tektronix (Garlan/Shaw book) Even if a system can logically be structured in layers, considerations of performance may require closer coupling between logically high-level functions and their lower-level implementations Example: Telecom industry had problems with mapping their protocols to the OSI ISO standard because many of those protocols bridge several layers far@ucalgary.ca 73 far@ucalgary.ca 74 Architectural Styles Architectural Style Data flow systems Call-and-return systems Independent components Virtual machines Data-centered systems Architectural Idiom Batch sequential Pipes and filters Main program and subroutines Client server systems Object-oriented systems Hierarchical layers Communicating processes Event-based systems Interpreters Rule-based systems Database systems Blackboards Event Based Systems Event-driven means that processing only occurs when the event happens. The event may be a data point changing, an alarm going off, a timer timing out or a user clicking on an icon or a graphic object. There is no flow of control. Event system control flow Ref: Stephen H. Kaisler: Software Paradigms, ch 16, Wiley, 2005 far@ucalgary.ca 75 far@ucalgary.ca 76 Why Event Based Systems? Older models of computation: algorithms transform input (sequences) to output (sequences) Newer model of computation: Computers are interaction machines (reactive systems) that continuously interact with their environment and that evolve with their environment far@ucalgary.ca 77 Event Systems: Underlying Idea Different from explicit invocation: call-return systems Implicit Invocation Instead of invoking a procedure directly, a component (event source) can announce one or more events Other components (event handlers) in the system register an interest in an event by associating a procedure with it When the event is announced, the system (event manager) invokes all procedures that have been registered with it Example Event Systems: IDE ( tool integration) GUI ( separate presentation of data from applications that manage the data) Syntax-directed editors ( incremental semantic checking) far@ucalgary.ca 78

14 Event Systems: Essentials Components: procedures (or methods) Interface defines a set of incoming procedure calls Interface also defines a set of outgoing events Connections: event-procedure bindings Procedures are registered with events Components communicate by announcing events at apprriate times When an event is announced the associated procedures are invoked ( implicit invocation / in contrast to explicit invocation in call-and-return-systems) Order of invocation is non-deterministic Events at Different Levels of Abstraction far@ucalgary.ca 79 far@ucalgary.ca 80 Example: Events in Win32 Win32 is the Windows 98/2K/XP Operating System API (application programming interface) Applications call the erating system create, delete, modify resources (windows, files, connections, devices,...) The erating system creates events to notify the applications user input occurred (mouse, keyboard) messages from the network arrived,... time-out happened,... application ened, system will be shut down,... Applications may communicate with each other via events dispatched by the erating system: en / close / print / cy / paste far@ucalgary.ca 81 Example: GUI Event Processing far@ucalgary.ca 82 Event Systems: Advantages Essential concept for reactive systems: Suited for user input / network communication Returning results from asynchronous execution Strong support for reuse: Any component can be introduced into a system simply by registering it for the events of the system Easing system evolution: Components may be replaced by other components without affecting the interfaces of the other systems Event Systems: Disadvantages Components do not have control over the computations performed by the system: When a component announces an event, it cannot assume other components will respond to it. Moreover, even it does know what other components are interested in the events it announces, it cannot rely on the order in which they are invoked. Exchange of data: Sometimes data can be passed with an event, but in other situations event systems must rely on a shared repository for interaction. In these cases global performance and resource management can become critical issues. Reasoning about correctness can become problematic: The meaning of a procedure (method) that announces events will depend on the context of bindings in which it is invoked ( overloading, polymorphism). This is in contrast to traditional reasoning about procedure calls, which need only consider a procedure s pre- and post-conditions when reasoning about the functional behavior of its invocation. far@ucalgary.ca 83 far@ucalgary.ca 84

15 Architectural Styles Architectural Style AP1: Data flow systems AP2: Call-and-return systems AP3: Independent components AP4: Virtual machines AP5: Data-centered systems Architectural Idiom Batch sequential Pipes and filters Main program and subroutines Client server systems Object-oriented systems Hierarchical layers Communicating processes Event-based systems Interpreters Rule-based systems Database systems Blackboards Virtual Machines A virtual machine (VM) is an emulator that executes on t of a hardware or software platform. Such a machine provides the familiar functions and services expected by computer programs but does so using software rather than hardware. Ref: Stephen H. Kaisler: Software Paradigms, ch 15, Wiley, 2005 far@ucalgary.ca 85 far@ucalgary.ca 86 Virtual Machines: Examples Programming Languages: Close the gap between the computing engine expected by the semantics of the program and the computing engine available in hardware Command language processors Programming language runtime environment Rule-based Systems: Provide a means of codifying the problem-solving skills of human experts Experts tend to capture problem-solving techniques as sets of situation-action rules Typically, execution / activation of rules is sequenced in response to the conditions of the problem-solving computations rather than by a predetermined scheme Because situation-action rules are not directly executable by computers, systems for interpreting such rules must be provided (alternative: logic programming PROLOG) Computation (State Machine) Rule-based Systems Inputs Outputs Working memory Rule interpreter Memory Selected rule Selected data Knowledge base Rule base Fact memory Rule and data-element selection far@ucalgary.ca 88 far@ucalgary.ca 89 Virtual Machines Advantages: Virtual machine concept provides complete protection of system resources since each virtual machine is isolated from all other virtual machines. This isolation, however, permits no direct sharing of resources. A virtual machine is an ideal platform for research and develment of new software concepts because it insulates the R&D environment from the erational environment and does not disrupt normal eration. Disadvantages: The virtual machine concept is difficult to implement due to the effort required to provide an exact duplicate of the underlying machine. Architectural Styles Architectural Style AP1: Data flow systems AP2: Call-and-return systems AP3: Independent components AP4: Virtual machines AP5: Data-centered systems Architectural Idiom Batch sequential Pipes and filters Main program and subroutines Client server systems Object-oriented systems Hierarchical layers Communicating processes Event-based systems Interpreters Rule-based systems Database systems Blackboards far@ucalgary.ca 90 far@ucalgary.ca 91

16 Data Centered Style Data-centered systems use a central data store (e.g., database, blackboard, repository, etc.) to store all problem-related information. Blackboard System A blackboard is a database into which a process can insert, retrieve, or remove data. Direct access ks1 ks2 Computation ks8 ks7 Blackboard (shared data) ks3 ks4 Data store is not necessarily a relational database! ks: knowledge source ks6 ks5 Memory Ref: Stephen H. Kaisler: Software Paradigms, ch 17, Wiley, 2005 far@ucalgary.ca 92 far@ucalgary.ca 93 Blackboard System: Essentials Blackboard (cont d) Blackboard approaches allow multiple processes (or agents) to communicate by reading and writing requests and information to a global data store. Each participant agent has expertise in its own field, and has a kind of problem solving knowledge (knowledge source) that is applicable to a part of the problem, i.e., the problem cannot be solved by an individual agent only Agents communicate strictly through a common blackboard whose contents is visible to all agents When a partial problem is to be solved, candidate agents that can possibly handle it are listed up A control unit is responsible for selecting among the candidate agents to assign the task to one of them Blackboard Blackboard partial solutions tasks Control Data Control Unit Knowledge source Knowledge source Knowledge source Processes/Agents What makes it different from independent components, then? far@ucalgary.ca 94 far@ucalgary.ca 95 Blackboard (cont d) Advantages: Suitable when there are diverse sources of input data Suitable for physically distributed environments Suitable for scheduling and postponement of tasks and decisions Suitable for team problem-solving approaches as it can be used for posting problem subcomponents and partial results Drawbacks: Expensiveness Difficult to determine partitioning of knowledge Control unit can be very complex Example: Compiler System A compiler based on blackboard style: compare with the compiler example in the pipe & filter system. Ref: Stephen H. Kaisler: Software Paradigms, ch 17, Wiley, 2005 far@ucalgary.ca 96 far@ucalgary.ca 97

17 Data Centered Style: Advantages Data Integrity: Data is entered once, at any time; erroneous, duplicated data is not possible. Design Reuse: Accurate, reliable data are available when needed. View-Generation: Alternate views of the data are facilitated by a single source of data, which means the same data is always displayed. Process Flexibility: The data management process is not constrained to application usage or sequence. Data Interaction Independent of Application: Data can be accessed by the user through multiple applications. Scalability: The database can grow with application and domain needs. Ref: Stephen H. Kaisler: Software Paradigms, ch 17, Wiley, 2005 far@ucalgary.ca 98 Chapter 5 Other Architectural Styles far@ucalgary.ca 99 Architectural Pattern: M-V-C Model-View-Controller pattern for interactive applications with a flexible human/computer interface. Problem: User interface is especially prone to change requests. Changing requirements, erating systems, and changing interfaces can result in a change to the user interface. Therefore, user interface must be flexible but separated from the system functionality that does not change as frequently. Forces: One way to handle this is using layers Same information can be presented differently in different windows. Display and behavior of the application must reflect data changes immediately. Changes to user interface should be simple, and if possible, made at run-time. Different user interface styles should not affect the code at the core of the application. far@ucalgary.ca 100 Architectural Pattern: M-V-C Database Solution: Structure the application into three areas, i.e. processing, input, and output. The model encapsulates application functionality and data. The model is independent on output representation or input behavior. The view displays information to the user. The view obtains its data from the model. The controller receives input, usually as events that are translated to service requests for either the view or model. far@ucalgary.ca 101 MVC Pattern vs. Analysis Classes MVC is closely related to analysis classes Entity class = Model Boundary class = View Control class = Controller An entity class is a class used to model information that has been stored by the system, and the associated behavior. The model contains the functional core of the application. A boundary class is a class used to model communication between the system's environments and its inner workings. A view component displays information to the user. A control class is a type of class used to model control behavior specific to one or a few use cases. Control objects (instances of control classes) often control other objects. Therefore, they behave as coordinators. A controller receives input and translates that input into requests for the model or the view. far@ucalgary.ca 102 Typical Approach for M-V-C The model component contains the core functionality of the system, and it encapsulates the data of the system. Model <<subscribe>> // Encapsulates application data() // Responds to state queries() // Exposes application functionality() // Notifies view of changes() <<subscribe>> View Observer // Render the models() // Request updates from models() // Send user gestures to controller() // Allows controller to select view() Different views present information to users in different ways. Controller // Defines application behavior() // Maps user actions to model updates() // Selects view for response() // One for each use-case() The controller calls functionality on the model on behalf of the user. far@ucalgary.ca 103

18 Chapter 5 Case Study Comparison of Architectures Case study: Mobile Robotics Set of Requirements (simplified) Four prosed solutions: Control-lo paradigm Layered architecture Implicit invocation Blackboard architecture Comparison/Evaluation (ad-hoc) Remember evaluation technique presented here is informal far@ucalgary.ca 104 far@ucalgary.ca 105 Mobile Robotics: Requirements (1) Requirement 1: The architecture must accommodate both deliberate and reactive behavior. The robot must coordinate the actions it undertakes to achieve its designated objective (e.g., collect a rock sample) with the reactions forced on it by the environment (e.g., avoid an obstacle). Requirement 2: The architecture must allow for uncertainty. The circumstances of a robot s eration are never fully predictable. The architecture must provide a framework in which the robot can act even when faced with incomplete or unreliable information (e.g., contradictory sensor readings) Mobile Robotics: Requirements (2) Requirement 3: The architecture must account for dangers inherent in the robot s eration and its environment. By considering fault tolerance, safety, and performance, the architecture must help maintain the integrity of the robot, its erators, and its environment. Problems like reduced power supply, dangerous vapors, or unexpectedly ening doors should not lead to disaster. Requirement 4: The architecture must give the designer flexibility. Application develment for mobile robots frequently requires experimentation and reconfiguration. Moreover, changes in tasks may require regular modification. far@ucalgary.ca 106 far@ucalgary.ca 107 Mobile Robotics: Solution 1 (1) Lozano s control los [LP90] Actuators Controller Active component of robot Environment Sensors + / / - + / - Mobile Robotics: Solution 1 (2) Req1: Simplicity of the closed-lo paradigm is positive; but it expects continuously changing environment (more probable: discrete events) Req2: control-lo knows only one paradigm for handling uncertainty: iteration with trial-and-error Req3: Due to its simplicity, the architecture makes duplication easy ( supports fault tolerance & safety); other strategies are not supported Req4: Major components (supervisor, sensors, motors) are separated and can be replaced independently; details tbd. inside the modules far@ucalgary.ca 108 far@ucalgary.ca 109

19 Mobile Robotics: Solution 2 Elfes layered organization [Elf87]: basis for architecture of Terregator and Neptune mobile robots Supervisor Global Planning Control Navigation Real-world Modeling Sensor integration Sensor interpretation Robot control Environment Mobile Robotics: Solution 3 Implicit Invocation: embodied in the Task-Control- Architecture (TCA) [Sim92], used in many mobile robots Gather rock Lift rock Task Task Tree (with temporal constraints) Task Message Dispatched Message Grab rock Move left Exception Networ k Go to position Task parent Move forward Task Wiretap Task child far@ucalgary.ca 110 far@ucalgary.ca 111 Mobile Robotics: Solution 3 Blackboard: Implemented in the NAVLAB Project, as part of the CODGER System [SST86] Lookout Captain Map navigator Blackboard Perception Subsystem Pilot Mobile Robotics: Evaluation (1) Closed-lo paradigm: Seems most apprriate for simple robotic systems that must handle only a small number of external events and whose tasks do not require complex decomposition. Layered organization: Makes organization of components easy, because the abstraction levels provided are precise about the roles of each layer Major drawback: difficult to implement; the communication patterns in a robot are not likely to follow the orderly scheme implied by the architecture far@ucalgary.ca 112 far@ucalgary.ca 113 Mobile Robotics: Evaluation (2) Implicit Invocation: TCA offers a comprehensive set of features for coordinating the tasks of a robot while respecting the requirements for quality and ease of develment The richness of the scheme makes it most apprriate for more complex robot projects. Blackboard: Capable of flexibly modeling the coeration of tasks, both for coordination and resolving uncertainty Slightly less powerful than TCA s equivalent capabilities Mobile Robotics: Evaluation (3) Control Lo Layers Implicit Invocation Blackboard Req1: Task + / Coordination Req2: Dealing with - + / - + / - + Uncertainty Req3: Fault tolerance, + / - + / Safety, Performance Req4: Flexibility + / far@ucalgary.ca 114 far@ucalgary.ca 115

20 Mobile Robotics: Literature [LP90] Tomas Lozano-Perez: Preface, Autonomous Robot Vehicles. Springer-Verlag, New York, [Elf87] Alberto Elfes: Sonar-based real-world mapping and navigation. IEEE Journal of Robotics and Automation, (3): , [Sim92] Reid Simmons: Concurrent planning and execution for autonomous robots. IEEE Control Systems, (1): 46-50, [SST86] Steven A. Shafer, Anthony Stentz, and Charles E. Thorpe: An architecture for sensor fusion in a mobile robot. In Proceedings of the IEEE International Conference on Robotics and Automation, pp , San Francisco, California, April Conclusion We ve talked a lot about several architectural styles What is still missing Models for software architecture description other than box-and-line! Methodologies to evaluate architecture Techniques to connect it to design and code Architecture decisions are fundamental decisions and changing them has significant ripple effects! CODE architecture design implementation far@ucalgary.ca 116 For details read Ch of Software Paradigms book far@ucalgary.ca 117 The Actual Picture Business Model Architecture Design Implementation Business Models Computer Software CODE System Computer Software System Models Next Chapter Software Architecture Views: Module View far@ucalgary.ca 118 far@ucalgary.ca 119