University:
California State University, Northridge
Course:
COMP 684 | Software Architecture and Design
Academic year:

2024
Views:

253

Pages:

16
Author:

as2st98t

Style: Event Systems: Components & Connectors  Component: (active or passive) object, capsule, module Can be an instance of a class, an active class, or simply a module.  Interface provides methods and ports.  Publisher: individual components announce data that they wish to share with their subscribers.  Subscriber: individual components register their interest for published data.  Connector: “connector”, channel, binding, callback.  Offers one-to-one, one-to-many, many-to-one connections;  Asynchronous event broadcast.  Synchronous event broadcast & await reply (call-andreturn)  Event Systems: Key Characteristics  Components do not explicitly invoke each other.  Components generate signals, also called events.  To receive events, objects can  Receive events at ports (statically or dynamically bound).  Register for event notification (e.g. via callback).  Announcers do not know which components will be affected by thrown events  System framework implements signal propagation Event Systems: Strengths  Supports reuse  Only little coupling  Easy system evolution  Introduction of new component simply by registering  Well suited for asynchronous communication Event Systems: Weaknesses  Components don’t have control over computation since they can only generate events; the run-time system handles event dispatching. Thus responses to events are not ordered.  Exchange of data can require use of global variables or shared repository => resource management can become a challenge.  Global system analysis is more challenging.   Asynchronous event handling Contrast to explicit call & use of pre-, post-conditions. (E.g., how to ensure that at least one object has processed an event. Event Systems: Variations  Pure implicit invocation systems are quite rare.  At some point explicit invocation is used among objects. Event Systems: Examples Event Systems: Examples  UIs  Macintosh computers popularized the “main event loop” approach for UI applications.  Other examples include    Constraint satisfaction systems (e.g. some database systems). Daemons. S/W environments that make use of multiple tools: e.g. text editor registers for events from debugger. Style – Repository Repository: Components & Connectors  Components   Data store, Clients, that interact with the store  Connectors  Queries Repository: Key Characteristics  The Architecture is centered on a widely accessed data store  Data store & clients. Two main variants:  Database   Passive data store, active clients that poll the database.  Blackboard  Active data store that notifies each client of data changes of interest to the client.  (Clients also called knowledge sources.) Repository: Strengths  Clients are relatively independent of each other. Data store is independent of the clients.   Scalable (i.e., new clients can be easily added) Modifiable Repository: Weaknesses  Strong dependence on data store… Repository: Variants  There are several variants of DB systems including the main distinction between traditional databases vs. object-oriented databases.  Distributed DB. Repository: Examples Repository: Examples  Programming environments (IDEs)  All applications that use global databases  Modern Compilers Summary  Architectural styles allow us to reason about the high-level design of a system before we start to implement it.  They are applied early in the architectural process.  Architectural styles address many nonfunctional quality characteristics such as performance, reliability, and modifiability.  They help us to decompose our system more effectively.

Event Systems and Repository

Related Documents

Recommended Documents

Description

Related Documents

Free up your schedule!

Take 5 seconds to unlock