Introduction to Software Architecture

The top level.... (and design revisited)

1

What are we doing?

• 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

System Software Architecture

Software construction2

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

7

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

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

9

http://weblogs.asp.net/fredriknormen/using-web-services-in-a-3-tier-

architecture

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 • Decompose further • Bottom out with concrete code

• Bottom up • Start with a specific capability

• Implement it • Repeat until confident enough

• to think about higher level pieces

24

System Software Architecture

Software construction24

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 detail25

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

36

McConell, 5.4

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 attributeP2P 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 otherwise39

39

Case study

40

40

For reading?

• http://www.aosabook.org/en/distsys.html

41

41