© Ian Davis Winter 2016 (c) Ian Davis

Essential Software Architecture 2nd Edition By Ian Gorton Winter 2016 (c) Ian Davis

What does an architecture do Defines structure of a system Specifies connections between components Suggests an implementation strategy Addresses non-functional requirements (Things not addressed by a case study) It is a high level abstraction of the detail Provides the over-arching picture of the whole Winter 2016 (c) Ian Davis

Why is architecture important Decides what are the core rules / goals What should and shouldn’t be allowed Design only says what will happen Impacts design and thus deliverable Largely determines non-functional properties Must trade off non-functional properties Hard to change later So worth paying attention to up front But have to anticipate change / error Winter 2016 (c) Ian Davis

Software Architecture is not About how one develops / designs software About the algorithms used in the software About data structures Might be about data storage Set in stone Plan to throw one away Architectures can evolve Winter 2016 (c) Ian Davis

Architecture Learning cycle Model Design Winter 2016 (c) Ian Davis

Non-functional requirements Requirements about the quality of a deliverable Quality requirements Architectural choice largely driven by Trade off between Quality requirements Driven by needs of the system Winter 2016 (c) Ian Davis

Non-functional Quality requirements For operations Availability (doesn’t fail; MTBF; MTTR) Portability (can be run on most/all platforms) Deployability (installing / uninstalling / provisioning) Security (authorisation; vulnerability – e.g. SQL) When executing Performance (speed of solution) Throughput (response times; latency) Scalability (load/connections/sizes increase) Winter 2016 (c) Ian Davis

Non-functional Quality requirements cont. For developers Simplicity/Readability (design easy to understand) Testability (can be easily tested; fixed; logs, etc) Maintainability (can be easily changed) For architects Integratability (with other software below/above) Extensibility (Plug ins) Flexibility (Many ways of being used) Product lines (Many ways of being created) Winter 2016 (c) Ian Davis

Non-functional Quality requirements cont. Users Usefulness (does it solve a problem) Usability (ergonomics; efficiency; attractiveness) Trustability (confidence that not malicious) Software Providers Risk (failure to deliver; risk of being sued) Budget (cost to develop; risk of overruns) Novelty (can it be sold; to how many) Profit (benefit to company; justification) Winter 2016 (c) Ian Davis

Architectural views Conceptual problem / model Logical view Static high level structure of the application Dynamic Process view Concurrency, messages, threading, replication Physical view What is to run where, on what hardware Development view Class/component level documentation Winter 2016 (c) Ian Davis

Winter 2016 (c) Ian Davis

Winter 2016 (c) Ian Davis

Winter 2016 (c) Ian Davis

Mobile Architecture Winter 2016 (c) Ian Davis

Middleware examples COM, OLE (Dynamic Linking) RPC, CORBA (Synchronous Client/Server) MOM (Message orientated middleware) Asynchronous delivery Delivery options Best effort Persistent Transactional Winter 2016 (c) Ian Davis

Component Object Model (COM) Factory Dynamic Linking of Objects at runtime IUnknown interface QueryInterface(REFIID riid, void **interfacePP) AddRef(void) Release(void) All method invocation is via obtained interface Implementation transparent Winter 2016 (c) Ian Davis

Remote Procedure Calls (RPC) Exports a procedure to a port Communication is via messages Parameters marshalling before transmission Received message unmarshalled Desired function called appropriately Returned results marshalled/unmarshalled Interface produced via generated software Based on provided procedure signatures Proxy design pattern Winter 2016 (c) Ian Davis

Common Object Request Broker (CORBA) Message Brokers Legacy systems talk different languages, store different data, and/or data in different formats Need to integrate legacy systems Brokers provide the needed translation services May also do things like provide security Winter 2016 (c) Ian Davis

Asynchronous Messaging Peer-to-Peer Peers talk to other Peers one at a time May expect synchronous or asynchronous response Asynchronous handled by a callback (new thread) Publish-Subscribe (one to many messaging) Provider communicates with Topics Servers dynamically subscribe to Topics (Observer design Pattern) Topics may be organised hierarchically Topics forward messages to subtopics/servers Winter 2016 (c) Ian Davis

Application Servers Client/Browser Side (Not part of server) HTML, Javascript, Ajax Web Tier (e.g. Apache, Tomcat) Receives requests Invokes web server-hosted components JSP (Java Server Pages), ASP, PHP, etc. Invokes business component tier JavaBeans, .NET, CORBA Invokes Enterprise Information Systems Tier MySQL, Backend Mainframe, etc Winter 2016 (c) Ian Davis

Enterprise JavaBeans (EJB) Top layer is a Java Virtual Machine This hosts components Session Beans (Synchronous) Stateless (consecutive requests to any instance) Stateful (caller binds to one specific instance for life) Message-driven Beans (Asynchronous) No explicit reply Winter 2016 (c) Ian Davis

Service-oriented Architecture (Web Services) Fix interoperability problems Vendors agree on standards for application integration This provides interoperability across hardware, software, companies and infrastructures Provide internet-scale distributed systems Vendors agree on standards for distributed computing Winter 2016 (c) Ian Davis

SOA design considerations Boundaries are explicit Crossing process, machine, trust expensive Services are autonomous Can change code, language, machine transparently But must preserve backwards compatibility Services simply receive messages and reply Not objects, no interfaces, inheritance etc. Client/server policy part of connecting design Things like message reliability, security, encodings Winter 2016 (c) Ian Davis

Web services A common standard to support SOA Offers Focus on simplicity and interoperability Offers Find out about a service (WSDL) Find an instance of that service (UDDI) Ask a service to do something (SOAP) Assisting standards (e/g. Security) (WS-*) XML based, with HTTP transport layer HTTP is firewall friendly - ergo dangerous Basically implemented as automated emails Winter 2016 (c) Ian Davis

RESTful Web Services Web services only uses HTTP as a transport layer (to fool firewalls) Representational State Transfer (REST) Resources identified by a URL Message passing mechanism GET (Parameters follow URL) POST (Parameters body of HTTP message) PUT (Upload to a named URL) DELETE (Delete now/later something at named URL) Winter 2016 (c) Ian Davis

REST .v. SOAP REST SOAP Simple Familiar interface for most web developers Permits transparency w.r.t. client requests SOAP More flexible Access to rich set of WS-* standards and features Offers better security, reliability, interoperability Winter 2016 (c) Ian Davis

Enterprise Service Bus Customized company message broker Arriving SOA requests Using TCP/IP, SOAP, JMS, FTP etc. protocol Wrapped by ESB layer To provide web based inputs to an organisations legacy business process orchestration technology Something of a “buzz” word Winter 2016 (c) Ian Davis

Semantic Web Effort to give XML entities real semantics Namespaces disambiguate entity names XMLSchema types the contents of an entity RDF describes semantic information as graph RDFS uses RDF to describe objects OWL defines ontological relationships (isa/hasa) SPARQL permits queries about semantics Winter 2016 (c) Ian Davis

Aspect oriented architecture Cross cutting concerns Runtime assertions Tracing (event logging) Profiling (performance issues) Error handling Testing Debugging Reliability (buffer overflow etc) Encryption mechanisms Winter 2016 (c) Ian Davis

Implementation Extend the language to specify aspects So: no need to embed code everywhere Can be implemented statically during compilation And/or dynamically at runtime via request Consider debugging C++ The –g option statically introduces symbol tables The break command in GDB dynamically alters code so that it is interrupted The watch command dynamically watches variables Winter 2016 (c) Ian Davis

Model driven architecture Architecture is formalised in a model Model is computer readable A computer tool produces the implementation Pro’s Consistent mapping from design to implementation Efficient approach to software development Con’s Limited by power of the model and translation tool Hard to test, maintain, and very hard to debug Winter 2016 (c) Ian Davis