Introduction to Software Architecture The top level.... (and design - - PowerPoint PPT Presentation

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 construction

2

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
• f 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

• n 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 

• f 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

• n 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]

• rthogonal 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

• rganisational 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
• verlooked 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 construction

24

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,

• r 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 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