L08: Software Architecture Flashcards

1
Q

What are the typical software artefacts?

A
  • (Business Plan)
  • Requirements specification
  • Software architecture specification
  • Software design documents
  • Software
  • Tests
  • … (possibly backlogs in agile processes)
  • Artefacts specific to development process
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What are the features of a web request-response cycle for a web application?

A

Front-end
- Client accesses web browser
- Web browser sends request to web server

Back-end
- Web server receives requests
- Business logic that handles request
- Logic may access data from storage
- Handled request is sent back to web server, then web browser, then client

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

What are the features of a client-server architecture?

A

Layered architecture

Client
- Browser

Server
- Presentation: how to present response
- Business logic: does the work for the request
- Data access: controls how the system talks to other things
- Cross-cutting: handles security or logging

Also
- Data sources
- 3rd party integration
- Services

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

What are some types of architecture within CS?

A
  • Network (OSI model)
  • OS
  • Computer
  • Enterprise
  • System
  • Technology/Infrastructure
  • Application
  • Software
  • Information
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What is the scope of an architecture?

A

The scope of an architecture depends on scale of context
- Domain
- Organisation
- Application

Each architecture will include different aspects of a system:
- Software, hardware, processes, policies, standards
- Specified from different perspectives

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

What is enterprise architecture?

A
  • Architecture across a (potentially large) enterprise
  • Long term strategies driven by business vision and desired outcomes
  • Organisation-wide policies and standards: apply to multiple systems

“A coherent whole of principles, methods and models that are used in the design and realisation of an enterprise’s organisational structure, business processes, information systems, and infrastructure”
[Lankhorst, 2017]

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

What is infrastructure architecture?

A
  • How are things put together, and how do they behave together
  • Structure and behaviour of the technology infrastructure of an enterprise or system
  • Includes hardware configurations, infrastructure applications that run on hardware, protocols and networks that connect applications and hardware components (development and deployment)
  • Concerns: resilience, performance, etc.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What is software architecture?

A

Every software system has an architecture
- Planned or not
- Documented or not
- Fit for purpose or not

If planned and designed properly, it can help guide development and maintenance

  • A software system is not monolithic- we want it to work as a single entity, however it is made up of different components with different functionality that need to work together to achieve the overall goal.
  • We must also consider the environment they work in, and the guiding principles are.
  • We need to understand what services each component provides to other components, and what services each component requires from other components

“The fundamental organisation of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution.”
[IEEE 1471 - 2000]

“Structure or structures of the system, which comprise software elements, the externally visible properties of these elements, and the relationships among them.”
[Bass, Clements & Kazman]

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

What is application architecture?

A

Architecture as applied to an application

An application is a social construction, it could mean different things
- A body of code that’s seen by developers as a singe unit
- A group of functionality that business customers see as a single unit
- An initiative that those with the money see as a single budget

Therefore, the size of an application may vary

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

What is system architecture?

A
  • Holistic architecture of a specific system
  • Includes software architecture as well as hardware and communication concerns
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What is information architecture?

A
  • Logical and physical data models
  • Concerns: data storage, management and maintenance

Logical: what kind of information do we need, transactions for this data
Physical: how is this data stored, management and maintenance

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

What are some responsibilities of architecture in software development?

A

Architecture helps us with the following:
- Understanding context
- Making decisions
- Modelling
- Validating
- Delivery

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

What are some uses of architecture? (organisational)

A
  • Communicating high-level decisions to stakeholders
  • Provide context for the system (textual or visual)
  • Planning work allocation and interactions between teams
  • Estimating costs (budget and timeline)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What are some uses of architecture? (technical)

A
  • Focus on meeting significant functional and non-functional requirements
  • Analysing system properties
  • Acting as a blueprint for development and maintenance
  • Improving large scale reuse
  • Facilitating integration with other systems
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

What is software architecture design?

A

Software architecture is designed taking into account functional and non-functional requirements of the system.

  • Typically a stage between requirements engineering and software design (iterative or plan-driven)
  • Software architecture is the basis for detailed design
  • Sometimes boundary between architecture and detailed design is blurred
  • Focus on quality attributes (security, reliability, performance, etc.)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What is the scale of architecture?

A

Architecture in the small
- architecture of individual programs

Architecture in the large
- Architecture of complex enterprise systems
- Can include other systems, programs and components

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

What questions can we ask to guide architecture design?

A
  • Is there a generic application architecture that can be used?
  • How will the system be distributed?
  • What architectural styles are appropriate?
  • What approach will be used to structure the system?
  • How will the system be decomposed into modules?
  • What control strategy should be used?
  • How will the architectural design be evaluated?
  • How should the architecture be documented?
18
Q

What are the inputs of software architecture design?

A
  • Prioritised requirements and constraints
  • Domain, functional and non-functional / user stories
19
Q

What are the processes of software architecture design?

A
  • Iterative process of decomposing system
  • Choice of architecture style to address requirements at each decision point
  • Different perspectives
20
Q

What are the outputs of a software architecture design?

A

Documented (possibly partial) architecture design
Consider different views of a building from a blueprint to illustrate the final product from different perspectives so that it makes sense to different people (experts, stakeholders, users, etc)

21
Q

What will we consider in software architecture design?

A

Inputs, processes, outputs

22
Q

What is mapping in design decisions?

A
  • characteristics of system as specified by significant requirements
  • structure and behaviour (including interactions) as defined by
    architecture decisions
  • tradeoffs may be required

every significant requirement is mapped onto a part of the architecture.

23
Q

How do we document software architecture?

A

Software architecture will be used by many stakeholders
- Technical and non-technical

Needs to be documented in an appropriate way so it can be shared
and understood by all stakeholders

Notations
- Natural language
- Boxes and lines
- UML
- Formal architecture languages

Who do we want to understand our software architecture?

23
Q

What are software architecture views?

A

Difficult to capture all the architecture details of a system in
a single specification / diagram

There is no representation that can visualise how it is deployed, its distribution, or the coordination of activities all in one.

We use a set of viewpoints or perspectives to model the
details of software architecture

A number of different viewpoints are used
- e.g., logical, process, development, physical, deployment

24
Q

How do we validate software architecture?

A

Software architectures should be validated against
requirements

Possible strategies
- Architecture reviews
- Architecture evaluation techniques (get an objective view)
- Proving it by code
- Formal methods

25
Q

Are software architecture and agile compatible?

A

Software architecture and agile development are compatible
- We don’t need to produce a complete architecture at the outset but we do need an overall blueprint
- Refined / updated as development progresses

Future needs and changes should be considered but system should not be over-built

26
Q

What are architecture styles/patterns?

A

Named collections of architectural design decisions
- Applicable to a recurring context
- Constrain decisions that are specific to a particular system in that context
- Elicit beneficial qualities in the target system [Taylor, Medvidovic & Dashofy]

Determine structure and interactions
Can be customised to each system

27
Q

What are design patterns?

A

In contrast to architecture styles ….
- Provide templates for refining subsystems or components of a
software system
- Do not influence the fundamental structure of a software
system
- Help implement architectural patterns
- Whereas architecture styles are broader and more fundamental in scope

Each pattern typically only affects a single subsystem

28
Q

How do we choose an architecture style?

A

Architecture design decisions should factor in the type of system, distribution and interaction of its elements, appropriate styles, etc.

Applicable context
- Components
- Interaction patterns – control and data
- Constraints

Advantages and disadvantages for
- Structure and interaction
- Non-functional or quality requirements

Variations and refinements may be possible

29
Q

What is the benefit of using architecture styles?

A
  • Existing, proven architecture solutions to recurring system
    contexts
  • Shared vocabulary and understanding
  • Reuse of architecture design and code
  • Guide to development and maintenance
  • Partial documentation of system
30
Q

What are some considerations when choosing architecture styles?

A
  • A style will not entirely define an architecture
  • Multiple styles will need to be combined appropriately to design the system
  • Choosing well-known styles might stifle innovation
31
Q

What are some well known architecture styles?

A
  • Client-server
  • Tiered / layered
  • Peer to peer
  • Broker
  • Pipe and filter
  • Microservices
  • Model-view-controller
  • Space-based architecture
32
Q

Briefly describe the client-server architecture.

A
  • There are multiple clients for one server
  • Client sends a request, server provides response
  • Clients do not interact with each other, can only talk to server
  • The client must always initiate contact

The server is a single point of failure- it the server fails, the whole system breaks down.

33
Q

Briefly describe the broker architecture.

A
  • Variation of the client server model, but there is a broker between the client and server
  • Broker directs request to an appropriate server based on service, demand or availability
  • The response goes back through the broker

In this case, the broker is the single point of failure

34
Q

Briefly describe the layered/tiered architecture.

A

Typically 3 tiers
1. Presentation: how the information is presented to the user
2. Business Logic
3. Data Store

If these layers are all deployed on a single device, it is a layered architecture.

If these layers are deployed on different devices, it is a tiered architecture.

35
Q

Briefly describe the peer-to-peer architecture.

A
  • There is no centralised server, control is distributed
  • The system is split into different nodes
  • Each node can be both a client and a server
  • All nodes communicate with other nodes
  • Each node is equal
  • There is no single point of failure
  • Depending on the system, nodes may be able to join and leave dynamically
36
Q

Briefly describe the pipe and filter architecture.

A
  • The functionality is split into different filter components
  • The different functional components are connected by pipes
  • Data flows as a stream through the filter components
  • Processing happens in stages
  • Capable of continuous processing, i.e. when one filter component is finished with one batch of data, it can process the next batch of data
37
Q

Briefly describe the microservices architecture.

A
  • Rather than having a single monolithic service that provides all functionality, it is split up
  • Less prone to having a single point of failure
  • Functionality of the system is split up into individual microservices
  • Each microservice is as autonomous as it can be
  • Each service has its own data store, but the services may communicate with each other
  • To achieve the overall goal of the system, they still have to work together
  • Good for scalability (just add services)
  • Good for robustness, the failure of one services does not affect the other services
  • There is an API gateway that acts as a broker between the services and the client
  • Each microservice needs to be monitored (management/orchestration)
  • While it is a good architecture, it is quite costly
38
Q

Briefly describe the model-view-controller architecture.

A
  • Used for systems with lots of user interactions
  • Fundamental idea is the separation of concerns
  • Used to represent the front-end

Model: has all the data and business logic
View: what is presented to the user
Controller: orchestrates everything that happens

39
Q

Briefly describe the space-based architecture.

A
  • Used for systems where there is distributed data processing
  • Have lots of data that needs to be processed quickly
  • Need scalability
  • There is no centralised database
  • There are multiple processing units
  • Virtualised middleware that controls data synchronisation and coordination between processing units
  • Some or all of the functionality or data may be in the processing units
  • Very quick as data is always in memory