1. © Ian Davis
Winter 2016
(c) Ian Davis

2. Essential Software Architecture 2nd EditionBy
Ian Gorton
Winter 2016
(c) Ian Davis

3. 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

4. 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

5. 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

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

7. 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

8. 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

9. 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

10. 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

11. 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

12. Winter 2016
(c) Ian Davis

13. Winter 2016
(c) Ian Davis

14. Winter 2016
(c) Ian Davis

15. Mobile Architecture
Winter 2016
(c) Ian Davis

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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 s
Winter 2016
(c) Ian Davis

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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