Lecture 8 - Software Architecture Flashcards

1
Q

Why study Software Arcitecture?

A

Recognise common paradigms so you can
- understand high level relationships among systems
- build new systems as variations on existing ones

Getting the right architecture is often crucial to the success of a design
- the wrong architecture can lead to disastrous results

Enables principled choices among design alternatives

Architectural system representation is often essential to
analysis and description of high level properties of a complex system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is the common framework of Software Architecture?

A

Components- a software architecture consists of a collection of computational components
Connectors- the interactions between those components (e.g. procedure call, event broadcast, database queries or pipes)
Constraints- A software architecture might have some constraints imposed on it. e.g. topological constraint of having no cycles

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Pipe and Filter Architecture structural pattern Diagram

A

REFER TO SLIDES

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What are the Essential Invariants for Pipe and Filter Architecture

A

Filters must be independent entities
- they do not share state with other filters
Filters do not know the identity of other
upstream and downstream filters
Filter specifications can
- restrict what appears on the input pipes or
- make guarantees about what appears on the output pipes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What are the Pipe and Filter major specializations?

A

Pipeline- topology restricted to linear sequences of filters i.e. no loops
Bounded Pipes- restrict the amount of data that can reside on a pipe
Typed Pipes- data passed between 2 filters must have a well defined type

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What are some Pipe and Filter Architecture Examples?

A

Unix shell pipes
Compilers
Also used for:
- image and signal processing
- functional programming
- distributed systems

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What is Repository Architecture?

A

REFER TO SLIDES

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What are the Repository Architecture Components?

A

Subsystems access and modify data from a single data
structure
Subsystems are loosely coupled (interact only through the
repository)
Two distinct types of component
- central data structure represents current state
- independent components operate on the data store

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

What are the Repository Interactions?

A

Control flow is dictated by central repository (triggers) or by the subsystems (locks, synchronization primitives)
Blackboard architecture interactions
- current state of the central data structure is the main trigger
Traditional database interactions
- input stream of transactions triggers selection of processes to execute

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What are Blackboard Repositories?

A

Knowledge sources- separate, independent parcels of application-dependent knowledge
Blackboard data structure - problem-solving state data organised in an application-dependent hierarchy
Control - driven by the state of the blackboard

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What are some examples of Repository systems?

A

Complex interpretations of signal processing - E.g. speech and pattern recognition
Shared access to data with loosely coupled agents
Some programming environments - collections of tools and shared repository of programs and
program fragments
Database management systems

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What is Layering Architecture?

A

REFER TO SLIDES

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What is a Layered Model?

A

Hierarchical organisation: each layer
- provides a service to the layer above
- acts as a client to the layer below
===
Layers may either be
- partially opaque (some interaction allowed between
non-adjacent layers)
- opaque: inner layers are hidden from all except the adjacent outer layer

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What are the Layered System Advantages?

A

Design based on increasing levels of abstraction
- complex problem becomes sequence of incremental steps
Supports enhancement
- changes to one layer affect at most two other layers
Supports reuse
- different implementations of the same layer can be used
interchangeably provided they support the same interfaces

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

What are the Layered System Disadvantages?

A

Not all systems are easily structured in layers
Performance considerations
- may need close coupling between logically high-level functions and their low-level implementations
Can be difficult to find right level of abstraction
- E.g. protocols which bridge several OSI layers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What is the Client Server Architecture?

A

Client: is typically the presentation of software ie Amazon
Server: Where all the logic is stored

Online games
- Client: movement and basic controls
- Server: all main logic, to avoid cheating

17
Q

What is Process Control Arcitecture?

A

REFER TO SLIDES

18
Q

What is the Purpose of design documentation?

A

Explain your design choices to later developers
Ensure they don’t duplicate research or work you’ve already done

19
Q

What is the Purpose of Design Documentation - EXAMPLE

A

REFER TO SLIDES

20
Q

What is Audience in regards to Design Document?

A

Design documentation records the design choices you made, and reasons for them. It records major choices made about the architecture of the system, and may contain design models (for instance, UML diagrams).
- It is primarily written for architects, developers and maintainers.

21
Q

What other sorts of documentation are there?

A

User documentation. Written for end users and/or system
administrators.
API documentation. Written for internal, and possibly
external, developers.
Cookbooks/examples. Working code examples, written for developers.

22
Q

What are some qualities of bad design documentation?

A

Hard to navigate - hard to find what you need
Out of date - no longer matches up with the current code
Incomplete/too little detail - doesn’t explain major decisions
Too much detail - major decisions are hidden in masses of unimportant detail
Never used - consumed time and effort on the part of the people who wrote it, but was never used
Contradictory - different portions of the documentation say contradictory things
Badly written/unclear - It is difficult for readers to understand what is meant

23
Q

What is Rationale Overview?

A

Rationale is the justification of decisions
Rationale is critical in two areas: it supports
decision making and knowledge capture
Rationale is important when designing or updating
(e.g. maintaining) the system and when introducing new staf

24
Q

How does Rationale help with change?

A

Improve maintenance support
- Provide maintainers with design context
Improve learning
- New staff can learn the design by replaying the decisions that produced it
Improve analysis and design
- Avoid duplicate evaluation of poor alternatives
- Make consistent and explicit trade-offs

25
Q

What are Rationale activies made up of?

A

the issues that were addressed,
the alternative proposals which were considered,
the decisions made for resolution of the issues,
the criteria used to guide decisions and
the arguments developers went through to reach a decision

26
Q

Rationale Exercise

A

REFER TO SLIDES