Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors Software Architecture Lecture 7.

Similar presentations


Presentation on theme: "Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors Software Architecture Lecture 7."— Presentation transcript:

1 Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors Software Architecture Lecture 7

2 Foundations, Theory, and Practice Software Architecture 2 What is a Software Connector? Architectural element that models u Interactions among components u Rules that govern those interactions Simple interactions u Procedure calls u Shared variable access Complex & semantically rich interactions u Client-server protocols u Database access protocols u Asynchronous event multicast Each connector provides u Interaction duct(s) u Transfer of control and/or data

3 Foundations, Theory, and Practice Software Architecture 3 Where are Connectors in Software Systems? Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

4 Foundations, Theory, and Practice Software Architecture 4 Implemented vs. Conceptual Connectors Connectors in software system implementations u Frequently no dedicated code u Frequently no identity u Typically do not correspond to compilation units u Distributed implementation Across multiple modules Across interaction mechanisms

5 Foundations, Theory, and Practice Software Architecture 5 Implemented vs. Conceptual Connectors (cont’d) Connectors in software architectures u First-class entities u Have identity u Describe all system interaction u Entitled to their own specifications & abstractions

6 Foundations, Theory, and Practice Software Architecture 6 Reasons for Treating Connectors Independently Connector  Component u Components provide application-specific functionality u Connectors provide application-independent interaction mechanisms Interaction abstraction and/or parameterization Specification of complex interactions u Binary vs. N-ary u Interaction protocols

7 Foundations, Theory, and Practice Software Architecture 7 Treating Connectors Independently (cont’d) Localization of interaction definition Extra-component system (interaction) information Component independence Component interaction flexibility

8 Foundations, Theory, and Practice Software Architecture 8 Benefits of First-Class Connectors Separate computation from interaction Minimize component interdependencies Support software evolution u At component-, connector-, & system-level Potential for supporting dynamism Facilitate heterogeneity Become points of distribution Aid system analysis & testing

9 Foundations, Theory, and Practice Software Architecture 9 An Example of Explicit Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

10 Foundations, Theory, and Practice Software Architecture 10 An Example of Explicit Connectors (cont’d) ? Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

11 Foundations, Theory, and Practice Software Architecture 11 Software Connector Roles Locus مكان of interaction among set of components Protocol specification (sometimes implicit) that defines its properties u Types of interfaces it is able to mediate u Assurances about interaction properties u Rules about interaction ordering u Interaction commitments التزام (e.g., performance) Roles u Communication u Coordination u Conversion u Facilitation

12 Foundations, Theory, and Practice Software Architecture 12 Connectors as Communicators Main role associated with connectors Supports u Different communication mechanisms e.g. procedure call, RPC, shared data access, message passing u Constraints on communication structure/direction e.g. pipes u Constraints on quality of service Separates communication from computation May influence non-functional system characteristics u e.g. performance, scalability, security

13 Foundations, Theory, and Practice Software Architecture 13 Connectors as Coordinators Determine computation control (support transfer of control among components). Control delivery of data Separates control from computation Orthogonal to communication, conversion, and facilitation u Elements of control are in communication, conversion and facilitation Ex: function calls

14 Foundations, Theory, and Practice Software Architecture 14 Connectors as Converters Enable interaction of independently developed, mismatched components Mismatches based on interaction u Type u Number u Frequency u Order Examples of converters u Adaptors u Wrappers

15 Foundations, Theory, and Practice Software Architecture 15 Connectors as Facilitators Enable interaction of components intended to interoperate u Mediate and streamline interaction Govern access to shared information Ensure proper performance profiles u e.g., load balancing Provide synchronization mechanisms u Critical sections u Monitors

16 Foundations, Theory, and Practice Software Architecture 16 Connector Types Procedure call Data access Event Stream Linkage Distributor Arbitrator Adaptor

17 Foundations, Theory, and Practice Software Architecture 17 A Framework for Classifying Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

18 Foundations, Theory, and Practice Software Architecture Procedure Call Connectors Model the flow of control among components through various invocation techniques. They are thus coordination connectors. Perform transfer of data among components through the use of parameters and return values. They are thus communication connectors. These connectors are most widely used and best understood. 18 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

19 Foundations, Theory, and Practice Software Architecture Procedure Call Connectors Ex: object-oriented methods, fork, call-back invocation in event-based systems. The following diagram shows the space of options available to a software engineer for constructing procedural call connectors. 19 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

20 Foundations, Theory, and Practice Software Architecture 20 Procedure Call Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

21 Foundations, Theory, and Practice Software Architecture 21 Event Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Affect the flow of control among components. They are thus coordination connectors. Once the event connector learns about the occurrence of an event, it generates messages (notifications) for all interested parties and yield control to the components for processing those messages. Messages can be generated upon the occurrence of a single event or a specific pattern of events. They are communication connectors.

22 Foundations, Theory, and Practice Software Architecture 22 Event Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Answer: Virtual connectors are formed between components interested in the same topics, and those connectors may appear and disappear dynamically depending on the components changing interests. Events based systems rely on the notion of time and ordering of actions. So dimensions as causality and synchronicity are critical in these connectors.

23 Foundations, Theory, and Practice Software Architecture 23 Event Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Example: Windowing application, where GUI inputs serve as the events that activate the system. Some events, such as interrupts, are triggered by hardware and then processed by software. The following diagram shows the space of options available to a software engineer for constructing event connectors.

24 Foundations, Theory, and Practice Software Architecture 24 Event Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

25 Foundations, Theory, and Practice Software Architecture 25 Data Access Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Data access connectors allow components to access data maintained by a data store component. Therefore, they provide communication services. Data access connectors may perform translation of information being accessed, when there is a difference in the format of the required data and the format in which data is stored and provided. Therefore, they provide conversion services.

26 Foundations, Theory, and Practice Software Architecture 26 Data Access Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. The data can be stored persistently or temporarily, in which case the access mechanisms will vary. Example of persistent data access: query mechanisms, such as SQL for database access. Example of transient data access: heap and stack memory access and information caching. The following diagram shows the space of options available to a software engineer for constructing Data access connectors.

27 Foundations, Theory, and Practice Software Architecture 27 Data Access Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

28 Foundations, Theory, and Practice Software Architecture 28 Linkage Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Linkage connectors are used to tie the system components together. They enable establishment of ducts (channels for communication and coordination) that are then used in higher level connectors. Linkage connectors provide Facilitation services. Ex: links between components and buses.

29 Foundations, Theory, and Practice Software Architecture 29 Linkage Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

30 Foundations, Theory, and Practice Software Architecture 30 Stream Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Streams transfer large amounts of data between processes. Therefore, they provide communication services. Streams can be combined with other types of connectors like data access connectors, event connectors, etc. Examples: Unix pipes.

31 Foundations, Theory, and Practice Software Architecture 31 Stream Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

32 Foundations, Theory, and Practice Software Architecture 32 Arbitrator Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. When components are aware of the presence of other components but cannot make assumptions about their needs and state, arbitrators resolve any conflicts. They provide facilitation services. Arbitrators redirect the flow of control. Therefore, they provide coordination services.

33 Foundations, Theory, and Practice Software Architecture 33 Arbitrator Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Example: multithreaded systems that require shared memory access use synchronization and concurrency control to guarantee consistency of operations. Arbitrators can ensure system trustworthiness by providing safety, security and reliability.

34 Foundations, Theory, and Practice Software Architecture 34 Arbitrator Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

35 Foundations, Theory, and Practice Software Architecture 35 Adaptor Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Adaptor connectors support interaction between components that have not been designed to interoperate. Adaptors provide conversion services. Adaptors employ transformations (i.e table look-ups) to match required services to the available facilities.

36 Foundations, Theory, and Practice Software Architecture 36 Adaptor Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Example: a distributed system may rely on RPC for all interactions among components. If two interacting components are co-located within the same process, RPC may be converted to a local procedural call.

37 Foundations, Theory, and Practice Software Architecture 37 Adaptor Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

38 Foundations, Theory, and Practice Software Architecture 38 Distributor Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Distributor connectors perform the identification of interaction paths and subsequent routing of communication and coordination information among components along these paths. They provide facilitation services. Distributor connectors never exist by themselves, but provide assistance to other connectors. DNS, routing, switching and other network services belong to this connector type.

39 Foundations, Theory, and Practice Software Architecture 39 Distributor Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

40 Foundations, Theory, and Practice Software Architecture 40 Discussion Connectors allow modeling of arbitrarily complex interactions Connector flexibility aids system evolution u Component addition, removal, replacement, reconnection, migration Support for connector interchange is desired u Aids system evolution u May not affect system functionality

41 Foundations, Theory, and Practice Software Architecture 41 Discussion Libraries of OTS connector implementations allow developers to focus on application-specific issues Difficulties u Rigid connectors u Connector “dispersion” in implementations

42 Foundations, Theory, and Practice Software Architecture 42 How Does One Select a Connector? Determine a system’s interconnection and interaction needs u Software interconnection models can help Determine roles to be fulfilled by the system’s connectors u Communication, coordination, conversion, facilitation For each connector u Determine its appropriate type(s) u Determine its dimensions of interest u Select appropriate values for each dimension For multi-type, i.e., composite connectors u Determine the atomic connector compatibilities

43 Foundations, Theory, and Practice Software Architecture 43 Simple Example System components will execute in two processes on the same host u Mostly intra-process u Occasionally inter-process The interaction among the components is synchronous The components are primarily computation-intensive u There are some data storage needs, but those are secondary

44 Foundations, Theory, and Practice Software Architecture 44 Simple Example (cont’d)  Select procedure call connectors for intra-process interaction  Combine procedure call connectors with distributor connectors for inter-process interaction  RPC  Select the values for the different connector dimensions  What are the appropriate values?

45 Foundations, Theory, and Practice Software Architecture 45 Composing Basic Connectors In many systems a connector of multiple types may be required to service (a subset of) the components All connectors cannot be composed u Some are naturally interoperable u Some are incompatible u All are likely to require trade-offs The composition can be considered at the level of connector type dimensions and sub-dimensions

46 Foundations, Theory, and Practice Software Architecture 46 Connector Dimension Inter- Relationships Requires – u Choice of one dimension mandates the choice of another Prohibits – u Two dimensions can never be composed into a single connector Restricts – u Dimensions are not always required to be used together u Certain dimension combinations may be invalid Cautions – u Combinations may result in unstable or unreliable connectors

47 Foundations, Theory, and Practice Software Architecture 47 Dimension Inter-Relationships Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

48 Foundations, Theory, and Practice Software Architecture 48 Well Known Composite Connectors Grid connectors u Procedure call u Data access u Stream u Distributor Peer-to-peer connectors u Arbitrator u Data access u Stream u Distributor Client-server connectors Event-based connectors

49 Foundations, Theory, and Practice Software Architecture 49 Event-based data distribution connectors Composition of four types of connectors: u Event, data access, stream, distributor. Events arrive according to some periodic schedule or at discrete periodic intervals. Event-based distribution connectors often employ an asynchronous best effort delivery method for data. Event-based distribution connectors can access and mutate data at both the consumer and producer ends. Data is typically packaged into streams with bounded packet size and data buffering.


Download ppt "Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors Software Architecture Lecture 7."

Similar presentations


Ads by Google