Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Architectural Patterns.

Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Architectural Patterns

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2 What is a Pattern? “ Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice …” Christopher Alexander

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3 Taxonomy of Patterns & Idioms TypeDescriptionExamples Idioms Restricted to a particular language, system, or tool C++ list and array processing. Design patterns Capture the static & dynamic roles & relationships in solutions that occur repeatedly Active Object, Bridge, Proxy, Façade, Visitor, Factory,… Architectural patterns Express a fundamental structural organization for software systems that provide a set of predefined subsystems, specify their relationships, & include the rules & guidelines for organizing the relationships between them Layers, Pipe- Filter, Blackboard, MVC, Client Server, Broker, Dataflow, Rule Based system,… Optimization principle patterns Document rules for avoiding common design & implementation mistakes that degrade performance Avoid memory leaks with counting pointers

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4 C++ idioms: Array - Tabel Find an element in a list C++ idiom: for(int i = 0; i < N; i++) Typical mistake: array index overrun Linked List Add or delete an element to a list. C++ idiom: for(link t=x; t !=0; t=t->next) Typical mistake : null pointers, memory leaks.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5 Design Patterns Elements of Reusable Object-Oriented Software E. Gamma, R. Helm, R. Johnson, J. Vlissides (the “Gang of Four”) Addison-Wesley, 1995 ISBN: 0-201-63361-2

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6 Design Patterns … “Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context” Gang of Four

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7 Design Pattern example : Strategy searcher SearchAlgorithm searchFor(String, Text) SearchAlgorithm2 searchFor(String, Text) SearchAlgorithm1 searchFor(String, Text) TextProcessor text search(String) 1 Use the Strategy pattern when Many related classes that differ only in their behaviour You need different variants of an algorithm An algorithm uses data that clients should not know about A class defines many behaviours

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8 ArchitecturalDesign From Mud to Structure Layers Pipes and filters Blackboard Broker Distributed systems Pipes and filters Microkernel Interactive systems MVC PAC Adaptable systems Microkernel Reflection Structural decomposition whole-part Organization of work master-slave Access control proxy Management command processor view handler Communication Publisher-subscriber Forwarder-Receiver Architectural patterns can be used at the beginning of coarse grained design, when specifying the fundamental structure of an application (cf. first iteration(s) of the ADD method) Design patterns are applicable towards the end of coarse-grained design when refining and extending the fundamental architecture of a software system. Design patterns are also applicable in the detailed design stage for specifying local design aspects (e.g. multiple implementations of a component)

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9 Architectural patterns & ADD 1. Choose the module to decompose Start with entire system Inputs for this module need to be available  Constraints, functional and quality requirements 2. Refine the module Choose architectural drivers relevant to this decomposition Choose the architectural patterns that satisfies these drivers Instantiate modules and allocate functionality from use cases representing using multiple views. Define interfaces of child modules. Verify and refine use cases and quality scenarios. 3. Repeat for every module that needs further decomposition

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10 Architectural Style and Patterns Architectural Styles are recurring organisational patterns and idioms. A style consists of key features and rules for combining those features so that the architectural integrity is maintained. Benefits of Style: Reuse: well understood solutions applied to new problems Common vocabulary leads to understandability of organisation. (e.g. Client Server,broker,…) Style specific analysis.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11 Architectural Integrity

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12 What Makes a Architectural Pattern?  Context A situation giving rise to a problem General context : developing software with a flexible human-computer interface Specific context : managing the change- propagation in a flight simulator or avionics system Specifying the correct context for a pattern is difficult : Impossible to determine all situations List known context situations for a pattern can give valuable guidance ContextProblemsSolution

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13 What Makes a Architectural Pattern?  Problem The recurring problem arising in that context Requirements the solution must fulfill : e.g. Peer-to-peer inter- process communication must be efficient Constraints you must consider : e.g. That inter-process communication must follow a particular protocol, client has to run on smart phones Desirable properties the solution should have : e.g. changing software should be easy In the context of ADD these are quality requirements. Constraints can be found in the feature description Desirable properties are almost always related to modifiability and reuse ContextProblemsSolution

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14 What Makes a Architectural Pattern?  Solution Structure with components and relationships Run-time behavior A pattern is a mental building block. After applying a pattern architectures should include a particular structure that provides for the roles specified by the pattern, but adjusted and tailored to the specific needs of the problem at hand.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15 Software Architecture Pattern is: component A set of component types  process, data repository, procedure Topological Topological layout of the components  configuration rules, relations semantic A set of semantic rules and constraints:  compositions have well defined meanings connectors A set of connectors for communication, coordination and co-operation between components  subroutine call, sockets, message queues

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16 Architectural Style Catalogue Data Centered BlackboardRepository Independent Components Communicating Processes Event Based Systems Call & Return LayeredObject Oriented Virtual Machines InterpreterRule based Data Flow Pipes & Filters Batch Sequential

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17 Data Flow Architectures Key feature: Dominated by motion of data through the system  datastreams Pipes and Filters  Filters are independent entities (components)  incremental: output begins before input is consumed  example : Unix shell programs, compiler

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18 Architectural Pattern: Pipes and Filters (Data Flow) ContextProblemsSolution Processin g data streams Motion of data through the system Future system enhancements should be possible Small processing steps Non-adjacent processing steps do not share information Different sources of input data exist Present or store final results in various ways Explicit storage of intermediate results for further processing You may not want to rule out multi-processing the steps Apply the Pipes and Filters architectural pattern: the tasks of a system are divided into several sequential processing steps, connected by the data flow through the system

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19 Example : Multimedia

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21 Data-Centered Architectures Key Feature: Dominated by a complex central data store, manipulated by independent components. Repository Repository  Passive data store: file, database Blackboard Blackboard  Active data store: sends events to the subscribers –Artificial Intelligence –Speech and Pattern recognition

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22 Architectural Pattern: Blackboard (Data Centered) ContextProblemsSolution Experimental domain in which no closed approach to a solution is known or feasible, different approaches for the problem are opportune There are different algorithms that solve partial problems Employing disjoint algorithms induces potential parallelism. If possible you should avoid a strictly sequential solution Apply the Blackboard architectural pattern: a collection of independent programs that work cooperatively on a common data structure Blackboard (shared data) Vocabulary Hypothesis Abstraction level Control Knowledge Source Knowledge Source Knowledge Source

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23 Architectural Pattern: Blackboard 1.Define the problem 2.Define the solution space for the problem 3.Divide the solution process into steps 4.Divide the knowledge into specialized knowledge sources with certain subtasks 5.Define the vocabulary of the blackboard 6.Specify the control of the system 7.Implement the knowledge sources Example HEARSAY II used a blackboard architecture to recognize human speech. In this case the raw data was acoustical data which was to be transformed into a database query. Contributors/knowledge sources existed for transforming acoustical data (level 0, wave forms) into phonetic data (level 1, phonemes), phonetic data into lexical data (level 2, words), lexical data into syntactical data (level 3, phrases), and syntactical data into queries (level 4).

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24 Architectural Pattern: Blackboard +  Modifiability Individual knowledge sources, the control algorithm and the central data structure are strictly separated Reusable knowledge sources The blackboard provides tolerance of noisy and uncertain conclusions as all results are just hypotheses Experimentation -  Testability Hypotheses are part of the solution process  Performance Computational overhead No support for parallelism Difficult to establish a good control strategy

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26 Call and Return Architectures Key Feature Dominated by order of computation Examples Abstract data types Object Oriented Layered Call based Client/Server

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 27 The Evolution of Middleware There are multiple COTS middleware layers & research/business opportunities Historically, mission-critical apps were built directly atop hardware Tedious, error-prone, & costly over lifecycles Standards-based COTS middleware helps: Control end-to-end resources & QoS Leverage hardware & software technology advances Evolve to new environments & requirements Provide a wide array of reusable, off-the- shelf developer-oriented services There are layers of middleware, just like there are layers of networking protocols Hardware Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware & OS Operating Systems & Protocols Applications

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28 Architectural Pattern: Layers ContextProblemsSolution Large system that requires decomposition Parts of the system should be exchangeable Reuse low-level issues No standard component granularity Group similar responsibilities System will be build by separated teams of programmers Layered architectural pattern: structure your system into an appropriate number of layers and place them on top of each other StructureDynamics

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 29 Architectural Pattern: Layers Communication protocols Ethernet IP TCP FTP Class Collaborator Layer J Layer J-1 Responsibility Provides services used by Layer J+1 Delegates subtasks to Layer J-1 1.Define the abstraction criterion 2.Determine the number of abstraction levels 3.Name the layers and assign tasks to each of them 4.Specify the services 5.Refine the layering 6.Specify the interfaces for each layer 7.Structure individual layers 8.Specify the communication between adjacent layers 9.Decouple adjacent layers

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30 Architectural Pattern: Layers +  Modifiability  Localize changes  Prevention of ripple effect  Defer binding time  Testability  Manage input/output  Usability  Separate user interface Reuse of layers Support for standardization Dependencies are kept local Exchangeability -  Performance Unnecessary work Lower efficiency  Modifiability Cascades of changing behavior  Difficulty of establishing the correct granularity of layers

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 31 Model-View-Controller ContextProblemsSolution Interactive applicatio ns with flexible human- computer interface The same information is presented differently Display and behavior of the application must reflect data manipulations immediately Changes to the user interface should be easy, and even possible at run-time Supporting different ‘look and feel’ standards or porting the user interface should not affect code in the core application Apply the Model-View- Controller architectural pattern: The Model contains the core functionality and data. Views display information to the user, Controllers handle user input. Views and controllers together comprise the user interface.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 32 MVC structure

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 33 Architectural Pattern: Model-View-Controller

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 34 MVC analysis +  Modifiability ‘Pluggable’ views and controllers Exchangeability of ‘look and feel’  Usability Separate user interface ‘Pluggable’ views Multiple synchronized views of the same model Framework potential -  Performance Inefficiency of data access in view Potential excessive number of updates Increased complexity, sometimes without gaining much flexibility:  Modifiability An additional encapsulation of platform dependencies may be required Close coupling of views and controllers to a model Difficulty of using MVC with modern user-interface tools

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 36 Independent Components Key Features Dominated by communication patterns. Components communicate through messages. not  They send data; not control. Examples Event systems  Implicit invocation  Announcers of events do not know which components will be affected by the event Communicating processes Shaw and Garlan Software Architecture in Practice

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 37 Broker: Broker Forwarding Pattern ContextProblemsSolution Distributed and possible heterogeneo us system with independent cooperating components Components should be able to access services provided by others through remote, location-transparent service invocations Need to exchange, add, or remove components at run-time The architecture should hide system- and implementation-specific details from the user of components and services Apply the Broker architectural pattern: an intermediate component that is responsible for coordination communication, such as forwarding requests, as well as for transmitting results and exceptions Client Server 1: clientRequest 4: forwardedReply 2: forwardedRequest 3: serverReply Broker

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 38 Broker Components: CRC Client Server Broker

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 39 Architectural Pattern: Broker 1.Define an object model 2.Decide which kind of component-interoperability the system should offer 3.Specify the API’s the broker component provides for collaborating with client and server 4.Use proxy objects to hide implementation details from clients and servers 5.Design the broker component in parallel with steps 3 and 4 Specify protocol, message buffers, directory service, dynamic method invocation, IDL compiler… CORBA IBM SOM/DSOM Microsoft’s OLE 2.x World Wide Web: hypertext browers such as Netscape act as brokers and WWW servers play the role of service providers

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 40 Architectural Pattern: Broker +  Modifiability Location transparency Changeability and extensibility of components Portability of a broker system (in combination with proxy/bridge) Interoperability between different broker systems Reusability  Testability An application developed from tested services is more robust and easier to test -  Performance Restricted efficiency  Availability Lower fault tolerance  Testability Many components involved

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 41 Broker Handle Pattern B2: serviceHandle Client Server B1: clientBrokerRequest R2: registrationAck R1: registerService B3: clientServiceRequest B4: serverReply Direct communication: same protocol or proxy Here the proxy takes some of the broker’s responsibilities for handling most of the communication activities Broker

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 42 Design Pattern: Proxy ContextProblemsSolution The configuration of components in distributed systems is often subject to change as requirements evolve Low-level message passing (e.g., using sockets) is error-prone & fraught with accidental complexity Remote components should look like local components from an application perspective i.e., ideally clients & servers should be oblivious to communication mechanisms & locations Apply the Proxy design pattern: provide an OO surrogate through which clients can access remote objects Proxy service Client Service service 11 AbstractService service : Service: Proxy : Client service pre-processing: e.g.,marshaling post-processing: e.g., unmarshaling Structure Dynamics

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 43 Design Pattern: Proxy +  Performance Enhanced efficiency and lower cost  Modifiability Decoupling clients from the location of server components Separation of housekeeping code from functionality -  Performance Less efficiency due to indirection (additional layer of indirection, usually negligible compared with the cleaner structure of clients and the gain of efficiency through caching or lazy construction…) Overkill via sophisticated strategies, they do not always pay Examples: Firewall proxy, cache proxy, … World Wide Web proxy describes aspects of the CERN HTTP server that typically runs on a firewall machine. It gives people inside the firewall concurrent access to the outside world. Efficiency is increased by caching recently transferred files (combination of different proxy types!!!)

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 44 Example: Java RMI Remote Method Invocation (RMI) is a Java mechanism similar to RPCs. RMI allows a Java program on one machine to invoke a method on a remote object.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 45 Stub &skeleton implementation.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 46 Broker Proxies

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 47 Broker Pattern Revisited: Proxy message exchange * marshal unmarhal receive_result service_p Client Proxy calls * * call_service_p start_task Client 1 marshal unmarshal dispatch receive_request Server Proxy calls * start_up main_loop service_i Server 1 1 main_loop srv_registration srv_lookup xmit_message manage_QoS Broker 1 Structure

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 48 Broker Pattern Revisited: Proxy Dynamics operation (params) connect send_request marshal unmarshal dispatch operation (params) result marshal receive_reply unmarshal result start_up register_service assigned port : Broker: Client Proxy : Server Proxy : Client: Server

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 49 Event Based Systems Publish Individual components announce data that they wish to share with other components: Publish. Subscribe Other components can register an interest in a class of data: Subscribe. Typically involves a message manager that controls communication between components Example: debuggers, databases, brokers MessageManager Publish Subscribe

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 50 ContextProblemsSolution I/O driven message based application Complex dependencies Real-time constraints Hard to schedule Expensive to evolve Scalability Apply the Publisher- Subscriber pattern to distribute periodic, I/O-driven data from a single point of source to a collection of consumers Publisher-Subscriber attachSubscriber produce pushEvent event pushEvent consume detachSubscriber : Event : Subscriber : Event Channel : Publisher Dynamics Event * Subscriber consume createsreceives Event Channel attachPublisher detachPublisher attachSubscriber detachSubscriber pushEvent Filter filterEvent Publisher produce Structure

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 51 Publisher-Subscriber: Avionics example Considerations for implementing the Publisher-Subscriber pattern for mission computing applications include: Event notification model Push control vs. pull data interactions Scheduling & synchronization strategies e.g., priority-based dispatching & preemption Event dependency management e.g.,filtering & correlation mechanisms Airforce fighter jet uses the Publisher-Subscriber pattern to decouple sensor processing from mission computing operations Anonymous publisher & subscriber relationships Group communication Asynchrony

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 52 Publisher-Subscriber: example VME 1553 1: Sensors generate data Board 2 2: I/O via interrupts 4: Event Channel pushes events to subscribers(s) 5: Subscribers perform avionics operations GPS IFF FLIR HUD NAV WTS Air Frame Publishers Subscribers push(event) Event Channel 3: Sensor publishers push events to event channel Board 1

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 54 Virtual Machine Key Features Characterized by translation of one instruction set into another. Examples Interpreters  Style that simulates functionality that is not native to the hardware. Rule based systems  A means of codifying problem solving know-how of human experts.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 55 Interpreter Components are the interpretation engine, memory that contains the program, the control state of the engine and state of the program. Example : Java Virtual Machine portability GOAL: achieve portability Performance cost due to additional computations Interpretation Engine Data (program state) Program (being interpreted) Internal State Input Output Program Instruction Selected Instruction Selected Data State Data DataUpdates

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 56 Rule Based Architecture RuleInterpreter Working Memory Rule Base Rule and Data Selection Inputs Outputs Knowledge Base Selected Rule Selected Data State Data DataUpdates Fact Memory Components are essential the same as in the interpreter style. Execution and sequence of rules is not predetermined but condition driven -> interpreter. Makes heavy use of pattern matching. Example: Flight simulator

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 57 Exercise: Medical Imaging Problem Having each client call a specific server is inefficient & non-scalable A “polling” strategy leads to performance bottlenecks Work lists could be spread across different servers More than one client may be interested in work list content Context In large-scale electronic medical imaging systems, radiologists may share “work lists” of patient images to balance workloads effectively Image Database Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 58 Decoupling Suppliers & Consumers Decouple suppliers (publishers) & consumers (subscribers) of events: An Event Channel stores/forwards events Publishers create events & store them in a queue maintained by the Event Channel Consumers register with event queues, from which they retrieve events Events are used to transmit state change info from publishers to consumers For event transmission push-models & pull- models are possible Filters can filter events for consumers Event * Subscriber consume createsreceives Event Channel attachPublisher detachPublisher attachSubscriber detachSubscriber pushEvent Filter filter Publisher produce Solution Apply the Publisher-Subscriber architectural pattern (P1) to decouple image suppliers from consumers Solution Apply the Publisher-Subscriber architectural pattern (P1) to decouple image suppliers from consumers

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 59 Applying the Publisher-Subscriber Pattern Event * Radiologist consume createsreceives Event Channel attachPublisher detachPublisher attachSubscriber detachSubscriber pushEvent Filter filter Modality produce Image Database Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Radiology Client Event Channel Event Channel Radiologists can subscribe to an event channel to receive notifications produced when modalities publish events indicating the arrival of new images & studies This design enables a group of distributed radiologists to collaborate effectively in a networked environment

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 60 Pattern: Inter-relationships  In many cases patterns are NOT atomic  Applying a pattern creates new contexts  Applying a pattern creates new problems and trade-offs  Applying a pattern creates new solutions In many cases several patterns need to collaborate in order to solve a problem  E.g. the broker pattern (distributed system) typically leads to the introduction of the proxy pattern (access control) and bridge pattern (service variation) If the ADD method is applied appropriately it should be clear which pattern to use when and where: System  subsystem  module  submodule e.g. Broker  proxy/bridge  …

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 61 Pattern Systems – No Pattern is an Island Patterns have to be organized in patterns systems Patterns exist in mane ranges of scales and abstraction Can be applied in different phases of software development Address a variety of different problems Exhibit different relationships with each other A patterns system is an organized set of patterns Describes all patterns uniformly Supports a useful overview Supports selection by means of appropriate search strategy Provides a set of guidelines Supports its own evolution

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 62 Heterogeneous Architecture Style Filter Pipe Subscribe RDBMS RPC Objects Method Call Layered Component

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 63 ArchitecturalDesign From Mud to Structure Layers Pipes and filters Blackboard Broker Distributed systems Pipes and filters Microkernel Interactive systems MVC PAC Adaptable systems Microkernel Reflection Structural decomposition whole-part Organization of work master-slave Access control proxy Management command processor view handler Communication Publisher-subscriber Forwarder-Receiver Architectural patterns can be used at the beginning of coarse grained design, when specifying the fundamental structure of an application (cf. first iteration(s) of the ADD method) Design patterns are applicable towards the end of coarse-grained design when refining and extending the fundamental architecture of a software system. Design patterns are also applicable in the detailed design stage for specifying local design aspects (e.g. multiple implementations of a component)

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 64 Pattern Systems: The architect’s toolbox ! The architecture – design pattern system is useful in the context of ADD Even the most comprehensive pattern system will not cover every problem area of a software architecture Pattern systems evolve constantly, based on the experience of the architect The pattern system for a software architect, active in concurrent and networked systems will be totally different (e.g. half-sync/half-async or leader/followers concurrency patterns aren’t mentioned here…) The pattern system should be a toolbox in function of the application domain that the architect is working in

Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Architectural Patterns.

Similar presentations

Presentation on theme: "Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Architectural Patterns."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Architectural Patterns.

Similar presentations

Presentation on theme: "Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Architectural Patterns."— Presentation transcript:

Similar presentations

About project

Feedback