Software Architecture, Process and Management ... · SAPM Presentation-Abstraction-Control Pattern...

Software Architecture, Process and ManagementArchitectural Patterns

Allan Clark

School of InformaticsUniversity of Edinburgh

http://www.inf.ed.ac.uk/teaching/courses/sapmSemester Two 2012-13

SAPM

Guest Lecture

I There are a couple of lecture slots free at the end of the course

I Anyone who feels they would like to lecture to the class onsome important (or trivial) topic related to the course, emailme.

I It doesn’t have to be 50 minutes long, you can aim for half alecture, a third or a lecture, or ten minutes

I Obviously if you’re aiming for less than the full hour let meknow and I’ll either group students together or prepare somematerial myself

SAPM

Software Metrics, Rules and Parking Tickets

SAPM

House Issues

SAPM

SAPM Course Issues

https://github.com/allanderek/SAPM-course/issuesLinked to from the course web pagehttp://www.inf.ed.ac.uk/teaching/courses/sapm/

https://github.com/allanderek/SAPM-course/issues

http://www.inf.ed.ac.uk/teaching/courses/sapm/

SAPM

Architectural Patterns

approx 60% hopefully approx 100%

I searched IKEA for a rabbit hutch but apparently they do not sell one

SAPM

Architectural Patterns

I The fundamental problem to be solved with a large system ishow to break it into chunks manageable for humanprogrammers to understand, implement, and maintain

I Large-scale patterns for this purpose are called architecturalpatterns

I Architectural patterns are related to design patterns, buthigher level and larger scale, and generally more abstract

I For more details http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)

http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)

http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)

SAPM

Architectural Pattern ExamplesI Architectural patterns covered here:

I High level decompositions:I Layered AbstractionsI Pipes and filtersI Blackboard

I Interactive systems:I Model-view-controllerI Presentation-abstraction-control

I Adaptable/reusable systems:I MicrokernelI SOA, Mashups, Cloud computingI Scripted components (next lecture)

I There are of course others, for example distributed systemsoften make use of a broker pattern or a multi-tier pattern

SAPM

Layered Abstractions Pattern

SAPM

Layered Abstraction: Problem Solution Advantages Liabilities

I System has different levels of abstraction

I Typical: Requests go down, notification goes back upI Generally:

I a lower-level is simpler to implementI a higher-level is simpler to use and/or more powerful

I It is possible to define stable interfaces between layers

I Want to be able to change or add layers over time

SAPM


I Start with the lowest level

I Build higher layers on top

I Same level of abstraction within a layer

I No component spreads over two layers

I Specify interfaces for each layerI Try to keep lower layers leaner

I a bug in a lower-level generally means there is a bug in everyhigher-level

I Try to handle errors at lowest layer possible

SAPM

Layers: Example TCP/IP

SAPM

Many Other Examples

I Layers is probably the most prevalent architectural pattern inuse in computer/software systems

I In particular it is used for “projects” which span multipleteams with no or little communication/cooperation

I Generic computer systems are built as a series of layeredabstractions upon one another:

I Physical ElectronicsI Machine codeI Assembly languageI Systems language and Operating SystemI High-level language run-time (typically in a systems language)I High-level language libraries and frameworksI User applications

SAPM


I Reuse of layers

I Standardisation of tasks and interfaces

I Only local dependencies between layers

I Programmers and users can ignore other layers

I Different programming teams can handle each layerI The choice of layer can say something about what is not

appropriateI For example if you choose UDP then there should be a reason

that you are not using TCPI This can help as the basis for a document recording design

decisions

SAPM


I Cascades of changing behaviourI Hence it can be difficult to fix behaviour at a lower-level

without breaking something which depends upon the brokenbehaviour

I Lower efficiency due to:I A higher-level being unable to fully utilise a lower-levelI Translations which occur at each level

I Difficult to choose granularity of layers

I Difficult to understand entire systemI Attempts at improvement at one level fail due to a

misconception of an underlying levelI Most commonly, optimisations at a higher-level fail because

the higher-level operations ignore lower-level detailsI Cache behaviour is a notorious example of this

SAPM

Pipes and Filters Pattern

I When processing a stream of data, each processing step isdone by a filter and the filters are connected by pipes carryingdata

I Connecting filters in different combinations gives differentways of processing the data streams

I Often related to the layered approach in that each filter isreducing the data to a lower level

SAPM

Pipes and Filters Problem Solution Advantages Liabilities

I Data stream processing which naturally subdivides into stages

I May want to recombine stages

I Non-adjacent stages do not share informationI May desire different stages to be on different processors

I In this way the pipeline can work just as a pipeline in a CPU oran assembly line in a factory

I There can be as many segments of data being simultaneouslyprocessed as there are stages in the pipeline

I Throughput is thusly increased

I Helpful: Standardised data structure between stages

SAPM


I Filter may consume/deliver data incrementally

I Filters may be parameterisable (e.g. UNIX filters)

I Input from data source (e.g. a file)

I Output to a data sink

I Sequence of filters from source to sink gives a processingpipeline

SAPM

Pipes and Filters: Example

SAPM


I Can replace filters easilyI Can achieve different effects by recombination

I thus hopefully increasing long-term usefulnessI at least of some components

I If data stream has a standard format, filters can be developedindependently

I They need not be developed in the same language

SAPM


I Difficult to share global data

I Parallelisation is less useful than it may seem

I Expensive if there are many small filters and a high datatransfer cost

I Difficult to know what to do with errorsI especially if filters are incremental

SAPM

Blackboard Pattern

I A central, “blackboard” data store is used to describe apartial solution to a problem

I A variety of knowledge sources are available to work on partsof the problem and these may communicate only with theblackboard, reading the current partial solution or suggestingmodifications to it via a control component

SAPM

Blackboard Problem Solution Advantages Liabilities

I Immature or poorly specified domain

I No deterministic or optimal solution known for problem

I Solutions to different parts of problem may require differentrepresentational paradigms

I May be no fixed strategy for combining contributions ofdifferent problem solvers

I May need to work with uncertain knowledge

SAPM


I Problem solvers work independently (and opportunistically) onparts of the problem

I Share a common data structure (the blackboard)

I A central controller manages access to the blackboard

I The blackboard may be structured (e.g. into levels ofabstraction) so problem solvers may work at different levels

I Blackboard contains original input and/or partial solutions

SAPM

Blackboard: Solution

SAPM


I Allows problem solvers to be developed independently

I Easy (within limits) to experiment with different problemsolvers and control heuristics

I System may (within limits) be tolerant to broken problemsolvers, which result in incorrect partial solutions

SAPM


I Difficult to test

I Difficult to guarantee an optimum solution

I Control strategy often heuristic

I May be computationally expensive

I Parallelism possible but in practice we need muchsynchronisation

SAPM

Model-View-Controller Pattern

I Interactive system arranged around a model of the corefunctionality and data

I View components present views of the model to the user

I Controller components accept user input events and translatethese to appropriate requests to views and/or model

I A change propagation mechanism takes care of propagation ofchanges to the model

SAPM

M-V-C Problem Solution Advantages Liabilities

I Users care a lot about interfaces and demand changes often

I Different users ask for different changes

I The underlying GUI technologies also change rapidlyI You may want to support different “look and feel” standards

I Most obviously the size of the screen can have a huge impacton the way users wish to view the model

I The same interface on a desktop is rarely appropriate for asmart-phone

I You typically have important core code that can be separatedfrom the interfaces

SAPM


I Develop a core model which is independent of style ofinput/output

I Define different views needed for parts/whole model

I Each view component retrieves data from the model anddisplays it

I Each view component has an associated controller componentto handle events from users

I The model component notifies all appropriate viewcomponents whenever its data changes

SAPM

M-V-C: Example

SAPM

M-V-C: Example

MODEL

VIEW CONTROLLER

MANIPULATES

SEES

UPDATES

USERUSES

USES

SAPM


I Multiple views of the same model

I View synchronisation

I View components can be plugged in

I Changes to interfaces without touching the modelI The controller and the model become reusable outside of the

context of the interfaceI For example they can be scriptedI A compiler separated from the IDE can be scheduled to run for

nightly buildsI Scientific software can run experiments not thought of by the

interface designer

SAPM


I Too complex for simple interface problems

I Frequent events may strain simple change propagationmechanisms

I Views and controllers are sometimes not modular in practiceI Changing the model is expensive if there are many views

I Though when there are as many views as to make this an issueit is difficult to see how it could have been otherwise done

SAPM

Presentation-Abstraction-Control Pattern

I A system implemented as a hierarchy of cooperating agentsI Each agent is responsible for a specific aspect of functionality,

and consists of:I A presentation component responsible for its visible behaviourI An abstraction component which maintains the data model for

the agentI A control component which determines the dynamics of agent

operation and communication

I Similar to M-V-C, the difference is there are many m-v-c-liketriple, which communicate with each other only through thecontrol component of each triple

SAPM

P-A-C Problem Solution Advantages Liabilities

I Interactive system viewed as a set of cooperating agents,often developed independently

I Some agents specialise in HCI; others maintain data; othersdeal with error handling, etc.

I Some notion of levels of responsibility in the system

I Changes to individual agents should not affect the wholesystem

I Many web applications are labelled as Model-View-Controllerbut are in fact closer to Presentation-Abstraction-Control

SAPM


I Define top-level agent with core functionality and data model,to coordinate the other agents and (possibly) also coordinateuser interaction

I Define bottom-level agents for specific, primitive semanticconcepts and/or services in the application domain

I Connect top and bottom levels via intermediate agents whichsupply data to groups of lower level agents

I For each agent separate core functionality from HCI

SAPM

P-A-C: ExampleI A typical web application has:

I The user interaction agent consisting of:I The abstraction in the form of the HTMLI The presentation, in the form of CSSI The controller which is the web browser

I The web service to which the user agent connects:I The abstraction in the form of the database/modelI The presentation in the form of the service API or available

web addressesI The controller which services requests to modify/pull from the

model

I May have other agents which deal with, for example scheduledjobs, data integrity checks etc.

SAPM


I Separation of different concepts as individual agents that canbe maintained separately

I Changes to presentation or abstraction in an agent does notaffect other agents

I Easy to integrate/replace agents

I Suits multi-tasking

I Suits multi-user applications

SAPM


I Can be difficult to get control right while maintainingindependence of agents

I Long chains of communication may be inefficientI Can have too many, too simple bottom-level agents

I Essentially almost any architecture could be labelled as aninstance of P-A-C with lots of tiny agents

SAPM

Microkernel Pattern

I For systems which must be easily adaptable to changingrequirements, separate minimal functional core from extendedfunctionality and customer-specific parts

I Provide sockets in the microkernel for plugging in theseextensions and coordinating them

SAPM

Microkernel Problem Solution Advantages Liabilities

I Software systems with long life spans must evolve as theirenvironment evolves

I Such systems must be adaptable to changes in existingplatforms and must be portable to new platforms

I There may be a large number of different but similar platforms

I To conform with standards on different platforms it may benecessary to build emulators on top of the core functionality

I Thus the core should be small

SAPM


I Build a microkernel component which encapsulates all thefundamental services of your application

I The microkernel:I Maintains system-wide resources (e.g. files)I Enables other components to communicateI Allows other components to access its functionality

I External servers implement their own view of the microkernel,using the mechanisms available from the microkernel

I Clients communicate with external servers using thecommunication facilities of the microkernel

SAPM

Microkernel: ExampleI Operating system for desktop computers:

I Must be portable to relevant hardware platforms and adapt asthese evolve

I The microkernel has just enough functionality in order to allowother services (such as the file system) to operate andcommunicate with each other

I The other services then run as user-programs offering serviceswhich other servers and applications may utilise, via thecommunication provided by the microkernel

SAPM


I Porting to a new environment normally does not need changesto external servers or clients

I Thus external servers or clients can be maintainedindependently of the kernel

I Can extend by adding new external servers

I Can distribute the microkernel to several machines, increasingavailability and fault tolerance

SAPM


I Performance overhead/bottleneck in that communicationbetween components must be done via the microkernel

I May be difficult to predict which basic mechanisms should bein the microkernel

SAPM

SOA, Mashups, Cloud computingI Trends: further decentralisation, web-based distributed

systems:I Service-oriented architecture Build application from disparate,

loosely coupled set of independently provided services, typicallywith web interfaces

I Mashups Rough, lightweight SOA, focusing on ability ofend-users to reconfigure services on-the-fly to solve a specificproblem or appeal to a particular audience

I Cloud computing Use externally provided, geographicallyscattered, highly decoupled services for storage andcomputation (esp. via virtual machines), rather thanpurchasing and relying on specific physical infrastructure

SAPM

Combining Architectural PatternsI As I have hinted, it is quite common that two or more

architectural patterns are combinedI Or two or more instances of the same architectural pattern

I This can be done globally, but more usually hierarchically

I In this way the component that forms a part of onearchitectural pattern is itself designed to follow anarchitectural pattern

I For example the controller in a model-view-controller mayconsist of sub-components arranged as a sequence of pipesand filters

I Though one should be careful not to “over design” theirsystem

I Part of the benefit of architectural patterns is the constraintsthey enforce upon the developers, which in turn result inreusable components

SAPM

Architectural anti-patterns:Phenomenom Urban Development Software Development

Big ball of Mud Shanty-town Spaghetti CodeThrowaway Temporary PrototypePiecemeal Growth Urban Sprawl Iterative DevelopmentKeep it Working Vitality First do no harmShearing Layers Shearing Layers Component LifetimesUnder the rug House cleaning Pretty faceReconstruction Demolition Total re-write

These are enumerated by Brian Foote and Joseph Yoder in theirarticle “Big Ball of Mud” http://www.laputan.org/mud/

http://www.laputan.org/mud/

SAPM

Architectural vs Design Patterns

I So what are the differences between architectural and designpatterns?

I Design patterns are template solutionsI often something we would wish to formalise in a language

feature but are as yet unable or unwilling to do so

I A major attractive feature of design patterns is thevocabularly they enhance to further aid communicationbetween developers

I Architectural patterns, are about buildingreusable/substitutable components

I Resuable components are good mmm-kayI Reusable and substitutable components generally have the

additional benefit that they can be independently developedI Just as the legs of a table can be indepedently manufactured

I By detailing past successful project structures, architecturalpatterns guide us in structuring new projects

SAPM

A moment of reflection

I Think of your most recently completed project, which mayhave been a coursework assignment

I Which, if any, architecture pattern or anti-pattern did itfollow?

I If none, which should you have followed?

SAPM

Summary

I Architectural patterns allow systems to be broken into chunksthat can be developed (to some degree) and maintainedindependently

I These patterns support large-scale, long-term developmentand maintenance

I Not a recipe, just an approach

I New large-scale patterns continue to appear; Google SOA,Mashups, Cloud computing for more info

I Next lecture: Scripted components architectural pattern

SAPM — Related Reading

I Required ReadingI N.B. Harrison, P. Avgeriou, U. Zdun. Using Patterns to

Capture Architectural DecisionsI Michael Armbrust, Armando Fox, Rean Griffith, Anthony D.

Joseph, Randy Katz, Andy Konwinski, Gunho Lee, DavidPatterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia. Aview of cloud computing

I Suggested ReadingI Mike P. Papazoglou and Willem-Jan Heuvel. Service oriented

architectures: approaches, technologies and research issuesI M. Stal. Using Architectural Patterns and Blueprints for

Service-Oriented Architecture IEEE Software, March/April2006.

I M. Hafiz, P. Adamczyk, R.E. Johnson. Organizing SecurityPatterns

I Brian Hayes. Cloud computingI Buschmann, Meunier, Rohnert, Sommerlad & Stal. A System

of Patterns, Chapter 2

Any Questions

Any Questions?

Software Architecture, Process and Management ... · SAPM Presentation-Abstraction-Control Pattern...

Documents

Transcript of Software Architecture, Process and Management ... · SAPM Presentation-Abstraction-Control Pattern...