GoV Patterns for Software Architecture-Patterns in Software Engineering-Lecture 7 Slides-Computer Engineering, Slides of Software Engineering

Download GoV Patterns for Software Architecture-Patterns in Software Engineering-Lecture 7 Slides-Computer Engineering and more Slides Software Engineering in PDF only on Docsity! Patterns in Software Engineering Lecturer: Raman Ramsin Lecture 7 GoV Patterns – Architectural P t 1 Department of Computer Engineering 1 Sharif University of Technology ar Patterns in Software Engineering – Lecture 7 GoV Patterns for Software Architecture A di t B h t lccor ng o usc mann e a .: A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing the constituent components The responsibilities and relationships of the components the ways in which the components collaborate. Department of Computer Engineering 2 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Architectural Patterns: Categories From Mud to Structure Support a controlled decomposition of a system task into cooperating subtasks. Layers, Pipes and Filters, and Blackboard Distributed Systems Deal with the infrastructure of distributed applications . Broker; also Microkernel and Pipes and Filters, which only consider distribution as a secondary concern. Interactive Systems Support the structuring of systems that feature human-computer interaction. Model-View-Controller and Presentation-Abstraction-Control Ad t bl S tap a e ys ems Support extension of applications and their adaptation to evolving technology and changing functional requirements. Reflection and Microkernel Department of Computer Engineering 5 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Architectural: From Mud to Structure Layers: Helps to structure applications that can be decomposed into groups of subtasks. Each group of subtasks is at a particular level of abstraction. Pipes and Filters: Provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Recombining filters allows you to build families of related systems. Blackboard: Useful for problems for which no deterministic solution strategies are known. Several specialized subsystems assemble their knowledge to build a possibly partial or approximate solution. Department of Computer Engineering 6 Sharif University of Technology Patterns in Software Engineering – Lecture 7 From Mud to Structure: Layers Helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction. Department of Computer Engineering 7 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Layers: Dynamics Scenario I: Top-down communication initiated by a client. Scenario II: Bottom-up communication, when a chain of actions starts at Layer 1; for example when a device driver detects input. Scenarios III and IV: Requests only travel through a subset of the layers. III: A top level request may only go to level N 1 lf this level can satisfy - - the request; e.g. when level N-1 acts as a cache. IV: A bottom-level request may only travel through the next few upper- level layers. Scenario V: involves two stacks of N layers communicating with each other Department of Computer Engineering 10 Sharif University of Technology . Patterns in Software Engineering – Lecture 7 Layers: Consequences Reuse of layers Support for standardization Dependencies are kept local Exchangeability d f h b hCasca es o c anging e avior Lower efficiency Potential for unnecessary work Difficulty of establishing the correct granularity of layers Department of Computer Engineering 11 Sharif University of Technology Patterns in Software Engineering – Lecture 7 From Mud to Structure: Pipes and Filters Provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Department of Computer Engineering 12 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Pipes and Filters: Structure – Filters and Pipes Filter: processing unit of the pipeline. Enriches, refines or transforms its input data. Its activity can be triggered by several events: subsequent pipeline element pulls output data from the filter (passive). The previous pipeline element pushes new input data to the filter (passive). Most commonly, the filter is active in a loop. Pipe: connection between filters. If two active components are joined, the pipe synchronizes them. This synchronization is done with a first-in- first-out buffer. Department of Computer Engineering 15 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Pipes and Filters: Structure – Sources and Sinks The data source represents the input to the system, and provides a f d t l f th t t tsequence o a a va ues o e same s ruc ure or ype. Examples of such data sources are a file consisting of lines of text, or a sensor delivering a sequence of numbers. Th d t i k ll t th lt f th d f th i lie a a s n co ec s e resu s rom e en o e p pe ne. Department of Computer Engineering 16 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Pipes and Filters: Dynamics – Scenario I Push pipeline in which activity starts with the data source. Filter activity is triggered by writing data to the passive filters. Department of Computer Engineering 17 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Pipes and Filters: Dynamics – Scenario IV All filters actively pull, compute. and push data in a loop. Department of Computer Engineering 20 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Pipes and Filters: Consequences No intermediate files necessary, but possible Flexibility by filter exchange and recombination Reuse of filter components Rapid prototyping of pipelines Efficiency by parallel processing Sharing state information is expensive or inflexible Efficiency gain by parallel processing is often an illusion Data transformation overhead Error handling is difficult Department of Computer Engineering 21 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Architectural: Distributed Systems Broker: Used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions. Microkernel: Separates a minimal functional core (microkernel) from extended functionality and customer-specific parts. Applies to software systems that must be able to adapt to changing system requirements. Microkernel systems employ a Client-Server architecture in which clients and servers run on top of the microkernel component. Pipes and Filters: Provides a structure (possibly distributed) for systems that process a stream of data. Department of Computer Engineering 22 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Broker: Structure – Brokers and Bridges Brokers are messengers that are responsible for the transmission of requests from clients to servers and , responses and exceptions back to the client. Bridges are optional components used for hiding implementation details when two brokers interoperate . Department of Computer Engineering 25 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Broker: Structure – Clients and Servers Servers implement objects that expose their functionality through interfaces that consist of operations and attributes. Clients are applications that access the services of at least one server. Department of Computer Engineering 26 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Broker: Structure – Proxies Proxies represent a layer between clients/servers and the broker. This additional layer provides transparency, in that a remote object appears to the client/server as a local one. Department of Computer Engineering 27 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Broker: Dynamics – Scenario III interaction of different brokers via bridge components. Department of Computer Engineering 30 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Broker: Consequences Location Transparency Changeability and extensibility of components Portability of a Broker system Interoperability between different Broker systems Reusability Restricted efficiency L f lt t lower au o erance Testing and Debugging Department of Computer Engineering 31 Sharif University of Technology Patterns in Software Engineering – Lecture 7 Reference Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M., Pattern-Oriented Software Architecture: A System of Patterns, Vol. 1. Wiley, 1996. Department of Computer Engineering 32 Sharif University of Technology