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

introduction to software architecture
SMART_READER_LITE
LIVE PREVIEW

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

Introduction to Software Architecture The top level.... (and design revisited) 1 System Software What are we doing? Architecture Top-level design software system architecture We use system architecture or simply


slide-1
SLIDE 1

Introduction to Software Architecture

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

1

slide-2
SLIDE 2

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

slide-3
SLIDE 3

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

slide-4
SLIDE 4

What is Architecture?

4

4

slide-5
SLIDE 5

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

slide-6
SLIDE 6

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

slide-7
SLIDE 7

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

slide-8
SLIDE 8

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

slide-9
SLIDE 9

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

slide-10
SLIDE 10

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

slide-11
SLIDE 11

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

slide-12
SLIDE 12

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

slide-13
SLIDE 13

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

slide-14
SLIDE 14

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

slide-15
SLIDE 15

What do we have to do?

15

15

slide-16
SLIDE 16

Architecture is essentially about

  • Interconnecting functional blocks
  • And how these blocks then interact to provide

functionality

16

16

slide-17
SLIDE 17

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

slide-18
SLIDE 18

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

slide-19
SLIDE 19

No magic box to do design

19

19

slide-20
SLIDE 20

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

slide-21
SLIDE 21

‘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

slide-22
SLIDE 22

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

slide-23
SLIDE 23

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

slide-24
SLIDE 24

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

slide-25
SLIDE 25

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

slide-26
SLIDE 26

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

slide-27
SLIDE 27

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

slide-28
SLIDE 28

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

slide-29
SLIDE 29

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

slide-30
SLIDE 30

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

slide-31
SLIDE 31

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

slide-32
SLIDE 32

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

slide-33
SLIDE 33

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

slide-34
SLIDE 34

How much architecture is needed?

34

34

slide-35
SLIDE 35

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

slide-36
SLIDE 36

Different problems; different needs

36 McConell, 5.4

36

slide-37
SLIDE 37

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

slide-38
SLIDE 38

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

slide-39
SLIDE 39

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

slide-40
SLIDE 40

Case study

40

40

slide-41
SLIDE 41

For reading?

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

41

41