1. Architectural patterns1

2. 2 Patterns Architectural patterns –Fundamental structural organization for software systems. –High-level subdivision of the system. –Highest level of pattern Design patterns –Organization of classes –Intermediate level of pattern Idioms –Organization within a single class or a few classes –Lowest level of pattern Some architectural patterns –Layers –Pipes and filters –Broker –Model-View-Controller (MVC)

3. Architectural patterns3 Categories of architectural patterns From mud to structure –Patterns: Layers, “Pipes and filters” Distributed systems –Patterns: Broker Interactive systems –Patterns: Model-View-Controller (MVC)

4. Architectural patterns4 Layers Decompose overall system task into cooperating subtasks. Examples –TCP/IP, and other protocol stacks –Java application, JVM, OS, physical machine –Information systems: Presentation, Controller, Model, Data Upper layer asks lower layer for service Interfaces between layers must be stable –Standardization: Public or proprietary –Java: “interface” is a keyword of the language –Error handling Exceptions Special values for signaling errors, like null or -1

5. Architectural patterns5 Layers consequences Benefits –Reuse of layers –Support for standardization A network protocol specifies a layer, but does not implement it! –Dependencies are kept local –Exchangeability An implementation of a layer can be exchanged with another implementation –With the same interface Liabilities –Lower efficiency –Difficult to establish correct granularity of layers Layers inside layers might help

6. Architectural patterns6 Pipes and filters System process a stream of data. –Each processing step is encapsulated in a filter component. Examples –A shell in an operating system, like Linux/UNIX or MS-DOS find “a” data.txt | sort | more Find all lines with “a” in data.txt | sort the lines | show the lines, one screen at a time –Compilation of a Java program Lexical analysis | syntax analysis | semantic analysis | code generation –Generally Data source | filter | … | filter | data sink The vertical bar | is called a “pipe”. Implementation –Cooperating processes No shared memory: Uses standard input (System.in) and standard output (System.out) –Cooperating threads Shared memory: Bounded buffers Example: The bounded buffer exercise

7. Architectural patterns7 Pipes and filters, consequences Benefits –Flexibility by filter exchange Plug-in a new filter, and you have another application –Flexibility by recombination –Reuse of filter components –Useful for prototyping –Efficient in parallel processing Liabilities –Sharing information is hard –Data transformation overhead Data must be adapted to the next filter –Error handling

8. Architectural patterns8 Distributed systems A layered system can be distributed –Each layer running on a separate computer –Called “multi-tiered” system A “pipes and filters” system can be distributed –Each filter running on a separate computer –Pipes are network connections

9. Architectural patterns9 Broker Coordinates communication between distributed components Decouples clients and servers Broker features –Register / deregister servers –Locate servers –Forward messages Examples –CORBA Common Object Request Broker Architecture –Some chat / messenger systems

10. Architectural patterns10 Broker, consequences Benefits –Location transparency Clients do not need to know where servers are. Servers can be moved to other computers. –Changeability and extensibility Servers can be changed –Keep the same interface –Reusability Components can be reused in other application Liabilities –Efficiency –Fault tolerance Broker is not working => nothing is working

11. Architectural patterns11 Interactive systems Interaction with the user –Through graphical user interfaces –System responds to events (user inputs) Functional core of the system must be kept independent of the user interface –You must be able to add a new user interface to the system. –A single system can have many user interfaces PC interface Web interface PDA interface Mobil phone interface

12. Architectural patterns12 Model-View-Controller (MVC) Divides an application into 3 parts –Model Core functionality and data –View Displays information to the user Same model component can have many views –Controller Handles user input –User interface = View + controller –Changes in the model are automatically propagated to the view Use observer-observable design pattern

13. Architectural patterns13 Model-View-Controller in Java The Java GUI frameworks Swing (and AWT) uses a modified version of MVC –Each Swing component has Model –Holding the state of the component View –The visual part Controllers –Are attached by programmers –Example: JButton Model: ButtonModel getModel() View: ButtonUI getUI() Controllers: addActionListener(…), addItemListener(…), attChangeListener(…) –Example, JavaBeans: AccountConstrained (Model) + AccountFrame (View + controller)

14. Architectural patterns14 Model-View-Controller, consequences Benefits –Multiple views for the same model –Synchronized views –“Pluggable” views and controllers –Exchangeability of “look and feel” Port to a new windowing platform does not change the model. Liabilities –Increased complexity –Excessive number of updates –Intimate connection between view and controller –Close coupling of (view, controller) and model Both view and controller make calls to model

15. Architectural patterns15 Distributed systems Advantages –Resource sharing Printers, files (HTTP), etc. –Openness Using standard protocols –Scalability –Fault tolerance Replication Disadvantages –Complexity –Security –Manageability –Unpredictability

16. Architectural patterns16 Client-server vs. distributed objects Client-Server –Clients and servers are treated differently Distributed objects –Interacting objects –Location is irrelevant (taken care of by middleware) –Build on top of client/server Like distributed library –Java RMI –CORBA

17. Architectural patterns17 Service-oriented architecture SOA Web services –HTTP for transportation –SOAP structured data exchange –UDDI for discovery –WSDL for description –XML used everywhere Service registry Service provider Service requestor

18. Architectural patterns18 References Buschmann et al. Pattern-Oriented Software Architecture, Volume1, Wiley 1996 Martin Fowler Patterns of Enterprise Application Architecture, Addison Wesley 2003 Ian Sommerville Software Engineering, 7 th edition, Addison Wesley 2004 11. Architectural Design 12. Distributed System Architectures Lethbridge & Langaniere Object- Oriented Software Engineering, 2 nd edition, McGraw-Hill 2005 9. Architecting and designing software