Introduction to Software Architecture The top level... (and design revisited) 1
What are we doing? System Software Architecture Top-level design software system architecture We use system architecture or simply architecture as a short name for system software architecture The high level/low level boundary is fluid Architecture guides code Code realizes architecture 2 Software construction
The BIG questions for us at this stage in the course What is architecture? What do we have to do to create an architecture? How much architecture is enough? 3 3
What is Architecture? 4 4
The purpose of architecture Architecture provides coherency, understanding Architecture acts as a guide for subsequent construction Architecture acts as the skeleton of a system. There is no single right architecture, but there are more or less suitable skeletons for the job. Choose your architecture well to achieve what you need to. Architecture influences quality attributes eg security, usability, latency, or modifiability. Quotes from [Fairbanks, Just enough Software Architecture, 2010] 5 5
What is an architecture Very general definition: An architecture is a model that defines the component parts of a system, and how they work with each other to meet both functional and non-functional requirements! It should help us think about Delivery of quality attributes Technology choices Where the challenges in implementation are 6 6
How do we express an architecture? We produce a model of the system to be built, expressed with Text Boxes and lines, possibly arrows Relatively formalised boxes and lines Unified Modeling Language (UML) Phillipe Kruchen s 4+1 architecture Walking skeletons Depicts both structure and dynamic behaviour One of the most effective guidelines is not to get stuck on a single approach. If diagramming the design in UML isn't working, write it in English. Write a short test program. Try a completely different approach. McConnell, 5.3 7 7
The output of system architecture The key output of system architecting is a shared (and shareable) understanding of the structure and dynamic behaviour of the system and the relation of structure to critical qualities An understanding of the architecture should facilitate communication support predictions about the system guide planning Architecture is good to the degree it is graspable and that grasping works 8 8
Architecture provides constraints on the (subsequent) design space Eg you want to address maintainability and extensibility Separation of concerns aids maintainability and extensibility So you decide to separate code into three blocks, for UI, business logic and persistence This is a 3 tier architecture Localisation of these 3 kinds of code into the 3 layers is now a constraint on your system http://weblogs.asp.net/fredriknormen/ using-web-services-in-a-3-tierarchitecture 9 9
Architecture provides constraints on the (subsequent) design space Eg you need to ensure security of data for a financial application, so adopt Database encryption Transport Layer Security (TLS aka SSL) Example constraint, all data accesses to persistent data must now go through an encryption/decryption layer For all services that you add to process data Similarly all HTTP-based communications are encruypted using TLS! 10 10
Different uses for the same architecture Architecture is [mostly] orthogonal to functionality. [Fairbanks, Just enough Software Architecture, 2010] Within limits, you can use the same architecture to implement systems with different functionality Eg, the basic web architecture is used for millions of different systems browser <---HTTP---> server <----> db 11 11
Different architecture for the same use / end-user functionality Systems implemented with different architectures may supply the same functionality Eg I could construct a single-user FileMaker-like application that runs locally using A brain-dead program in C that uses a database A Smalltalk-implemented system that uses the Model-View-Controller architecture and no database An in-browser implementation that uses JavaScript and browser-based persistence mechanisms 12 12
Different architecture for the same use / end-user functionality Different architectures providing the same functionality may (previous slide) have different external properties Eg where the system runs What limitations there are on the UI How performant it is And different internal properties How the system is structured How maintainable and extensible it is 13 13
The effect of competencies and organisational structure A team that has worked with a given architecture May find it more understandable May have tools and practices that support it This is an advantage Conway s Law states that architectural form is influenced by the structure of the organisation that is developing the architecture This may be a disadvantage 14 14
What do we have to do? 15 15
Architecture is essentially about Interconnecting functional blocks And how these blocks then interact to provide functionality 16 16
The conventional advice Evaluate a few different architectures to see how they support your desired quality attributes Within the available resource profile for the project! The smart CTO chooses an architect who has already performed this kind of evaluation for the target system, and can start without an evaluation phase Being able to do architecture well depends on how many system you have seen Faster with knowledge of architectural patterns 17 17
Design, a reminder Characteristics of design Relies on domain knowledge in two kinds of domain The application domain The technical domain Informed by knowledge and insight Based on past experience Multi-faceted at variable levels of detail Knowing what to take account of Knowing what to ignore Making motivated choices Making tradeoffs while making choices 18 18
No magic box to do design 19 19
But there may be some strategies Strategy: A way of going about doing something Strategies are high-level (Tactics are low level) We consider these in a few slides time 20 20
Easy architectural design Sometimes it s relatively easy Similar to our last two systems, which have been proven to work well Adoption of a presumptive architecture Realistically constrains the solution to a space of architectures known to work What if there is some aspect to the system that is overlooked and that has a profound effect? No brainer architecture Variant of well understood problem E.g., straightforward web site Good technology and team support 21 21
But by and large, it s hard For any significant system architecture is likely to be hard to design Some of the things that conspire to make architecture hard are Functional and non-functional requirements Time-to-market minimisation Project resourcing constraints, cost and available HR resources Unknown performance of the architecture when implemented in real life settings 22 22
Some approaches to architecture We know that The architecture expresses those things that it will be too expensive to change later in the system development The architecture satisfies quality attributes / non-functional requirements Yeah, so what? How does this help us design an architecture? Let s examine two strategies, top-down and bottom-up design 23 23
Direction of Design Top down Start with the general problem Break it into manageable parts Each part becomes a new problem Bottom up Decompose further Bottom out with concrete code Start with a specific capability Implement it Repeat until confident enough to think about higher level pieces 24 System Software Architecture 24 Software construction
Opportunistic focus Top down and bottom up aren t exclusive Thinking from the top Focuses our attention on the whole system Thinking from the bottom Focuses our attention on concrete issues Being able to choose where you focus your attention opportunistically is a great help Eg working at the top level, yu may wonder will this really work, so you consider realisation at a lower level of detail Will have to rework the top level if doesn t work at a greater level of detail 25 25
Technology and architecture The technology you choose influences architecture, so you may want to find out about it, or prove something Typically we do a spike (a short experiment in the use of technology) when we want to find out something specific for our architecture A prototype is really an exploration of or proof of concept of all or some part of a system We build a walking skeleton if we want to provide a loose proof for our architecture 26 26
Spikes Spike Very small program to explore an issue Scope of the problem is small Often intended to determine risk Is this technology workable? No expectation of keeping 27 27
Prototype Can have some small or large scope Intended to demonstrate something, rather than just find out about technology (a spike) Mock ups through working code! Prototypes get thrown away 28 28
Walking Skeleton Small version of complete system tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel. - Alistair Cockburn! Walking skeletons are meant to evolve into the software system 29 29
Scoping architecture We can ground architectural decisions in different ways e.g., Priorities we need to address Risks we need to ameliorate Technologies we want to use These give us ways of determine what our architecture needs to accommodate 30 30
Priority-based architecture Identify priorities Things which are not priorities can run the risk of being discarded (business and tech decision) Design toward those priorities Identify costs <a> is a priority, so we choose architectural design <b>, while accepting downsides <c, d,... > We may have many of these (pattern instantiations) for priorities a1, a2, a3,... You need to end up with compatible b1, b2, b3... 31 31
Risk-based architecture Identify risks Estimate the following for each risks 1. Advantages in ameliorating each risk 2. Disadvantages in not ameliorating 3. Cost of ameliorating (implementation cost: HR resource, time,, cost of delay-to-market) 4. Cost of not ameliorating (cost to business) Prioritise risks On the basis of 1-4 above MoSCoW partitioning (for risk amelioration) 32 32
Technology-based architecture A technology is something that is used to implement something else Eg Ruby on Rails is a technology that is used to implement Web apps Identify technologies These may be fixed You must use Java and Swing Identify the architectural implications of the tech Technologies often are biased wrt architecture Determine fit 33 33
How much architecture is needed? 34 34
When to stop Confidence that we have catered for the core, that adding to the core will not involve inappropriate costs Ie, nailed the risks to a sufficient extent to start development When the architecture exhibits a suitable response to desired quality attributes When the architecture embodies the capabilities to develop the desired features 35 35
Different problems; different needs McConell, 5.4 36 36
When is architecture most important? Small solution space, where the solution has to be just right High cost to failure Eg: Medical systems, nuclear plant control, sensitive personal data Difficult quality attributes, eg Always available / failsafe In 2012 Skype reached a high of 45M concurrent users, with quality of service an important attribute P2P architecture, now superseded (thanks to a further requirement, mobile support) 37 37
When is architecture most important? New domain You need a guide to what you are doing Product line, a shared architecture aids development of individual products, eg ios, Mettler Toledo Safeline. Previous page and above this page [Fairbanks, Just enough Software Architecture, 2010] Large-scale and/or multiple-team activity, especially with distributed teams - for co-ordination of activities 38 38
BDUF vs evolutionary architecture Big Design Up Front Old style Often used in waterfall type developments Danger of doing too much work Work in the wrong direction that gets thrown away Evolutionary architecture Newer style Evolves as the project progresses Adapts to current requirements In practice always some architecture up-front Foolish to do otherwise 39 39
Case study 40 40
For reading? http://www.aosabook.org/en/distsys.html 41 41