Architectural Design, Modelling, and Styles

Question 1

What is system / software architecture?

Answer 1

System / Software Architecture (SA):
- Defines how the system is organized
- Breaks the entire system into a set of
communicating modules
- Creative process

Key is to satisfy extra functional requirements!

Question 2

What is the Architecture in the small vs Architecture in the large?

Answer 2

Architecture in the small:
- At the “single system” level
- Defines how a large system is broken
down into subsystems
Architecture in the large:
- At the “system of systems” level
- Defines how a system of systems is
broken down into individual systems

Question 3

What is the goal and the output of the Architectural design process?

Answer 3

Goal: design the overall structure of the software system
* how to break the system to be developed into modules?
* how to organize these modules?
* how should they interact?
* Output: architectural model
* describes how the system is organized as a set of
communicating components

Question 4

What are the Functional architecture basics?

Answer 4

Software system:
- Performs a userlevel task
- Decomposed into
subsystems
Subsystem:
- Performs a logical
subtask of the system
- Decomposed into
components
Component:
- Performs a logical subtask of
a subsystem
- Decomposed into files

see slide 7 for visual

Question 5

What is the usage of the architectural models?

Answer 5

1) Encourage discussions about the system design:
High-level architectural view of a system
-> intuitive / all stakeholders can relate to them
-> useful for communication.
=> Informally modeled using block diagrams
(= boxes and arrows)

2) Document the implemented architecture:
Complete system model, detailed architecture description
-> low-level but more abstract than the program
-> helps making informed decisions / system analyses
=> Block diagrams too informal and abstract
-> need more rigorous descriptions
-> using description languages

Question 6

What is the problem with lightweight models?

Answer 6

Lightweight models:
- Not very specific
- Arrows can mean multiple things
- Blocks can be quite vague
- For example, where are blocks located
with respect to processes?

Question 7

What is the multifaceted nature of software architecture?

Answer 7

System architecture needs to express:
- The decomposition into subsystems
- Process interactions
- The distribution of subsystems across
networked devices

Question 8

Why is specifying all system characteristics in one architectural model is impractical?

Answer 8

Too many perspectives
for one diagram:
- If we attempt to model
everything in one
diagram, it becomes a
mess!

Question 9

What is an interface?

Answer 9

Interface:
* collection of business methods
* visible externally (can be called)

Question 10

Tradeoffs of block vs formal achitectural models?

Answer 10

Criterion Block Formal
Understandable Yes No
by laypeople
Cost to produce Cheap Costly
Rigorous enough for
formal documentation No Yes

Question 11

Why do we need an architecture?

Answer 11

Communication:
- Aid for system-level design
System analysis:
- If not discussed, implicit architecture may
be suboptimal, causing big problems later
Large-scale reuse:
- Systems with similar requirements can
reuse architectural components (e.g.,
subsystems, components)

Question 12

What are the SE processes?

Answer 12

Waterfall (plan driven process) -> software design process
Agile -> accepted to design the overall architecture in an
early stage
o incremental development of architecture is not usually
successful
o refactoring components = easy
o refactoring architecture -> adapting all components = expensive

Question 13

What is Architectural design?

Answer 13

more a collection of decisions than a process
(sequence of activities)
* decisions -> how to organize the system
o depend on the functional and non-functional requirements
An appropriate architecture is the key to satisfy
nonfunctional requirements
o components implement functional requirements
obut architectureaffects performance,
maintainability, robustness …

Question 14

How to maximize non-functional system charactristics with architectural design?

Answer 14

Criterion Maximized by
Performance Creating a small number of large
subsystems

Security Hiding critical assets behind
layered subsystems

Safety Minimizing subsystems with
access to critical operations

Availability Injecting redundant
subsystems that are hot-
swappable (updates,
emergencies)

Maintainability Creating a large number of
small, independent
subsystems

Question 15

How to balance tradeoffs in architectural design?

Answer 15

Criterion Maximized by
Performance Creating a small number
of large subsystems
Maintainability Creating a large
number of small,
independent
subsystems
Performance and maintainability are in conflict with one another!

Question 16

What is an architectural pattern?

Answer 16

Architectural patterns/styles:
- Descriptions of tried-and-tested solutions
to common system problems
- Should describe when it is a good idea to
use and when it should be avoided

Question 17

What is the Model-View-Controller?

Answer 17

Desc: Separates presentation and interaction from the system data. The system is
structured into three logical components that interact with each other. The Model
component manages the system data and associated operations on that data. The
View component defines and manages how the data is presented to the user. The
Controller component manages user interaction (e.g., key presses, mouse clicks,
etc.) and passes these interactions to the View and the Model. See Figure 6.3.

When
used:
Used when there are multiple ways to view and interact with data. Also used when
the future requirements for interaction and presentation of data are unknown.

Pros:
Allows the data to change independently of its representation and vice versa.
Supports presentation of the same data in different ways with changes made in one
representation shown in all of them.

Cons: Can involve additional code and code complexity when the data model and
interactions are simple.

Question 18

What is a layered architecture pattern?

Answer 18

User interface management
Authentication and authorization
———————-
Core business logic/application functionality
System utilities
———————
System support (Os, database etc.)

Name Layered architecture

Desc. Organizes the system into layers with related functionality associated with each layer.
A layer provides services to the layer above it so the lowest-level layers represent core
services that are likely to be used throughout the system.

When
used:
Used when building new facilities on top of existing systems; when the development is
spread across several teams with each team responsibility for a layer of functionality;
when there is a requirement for multi-level security.

Pros: Allows replacement of entire layers so long as the interface is maintained. Redundant
facilities (e.g., authentication) can be provided in each layer to increase the
dependability of the system.

Cons In practice, providing a clean separation between layers is often difficult and a highlevel layer may have to interact directly with lower-level layers rather than through the
layer immediately below it. Performance can be a problem because of multiple levels
of interpretation of a service request as it is processed at each layer.

Question 19

What is a repository arch pattern?

Answer 19

Name Repository
Desc All data in a system is managed in a central repository that is accessible to all system
components. Components do not interact directly, only through the repository.

When
used:
You should use this pattern when you have a system in which large volumes of
information are generated that has to be stored for a long time. You may also use it in
data-driven systems where the inclusion of data in the repository triggers an action or
tool.

Pros: Components can be independent—they do not need to know of the existence of
other components. Changes made by one component can be propagated to all
components. All data can be managed consistently (e.g., backups done at the same
time) as it is all in one place.

Cons: The repository is a single point of failure so problems in the repository affect the whole
system. May be inefficiencies in organizing all communication through the repository.
Distributing the repository across several computers may be difficult.

Question 20

What is the client server arch pattern?

Answer 20

Name Client-server

Desc In a client–server architecture, the functionality of the system is organized into
services, with each service delivered from a separate server. Clients are users of
these services and access servers to make use of them.

When used:
Used when data in a shared database has to be accessed from a range of
locations. Because servers can be replicated, may also be used when the load
on a system is variable.

Pros:
The principal advantage of this model is that servers can be distributed across a
network. General functionality (e.g., a printing service) can be available to all
clients and does not need to be implemented by all services.

Cons:
Each service is a single point of failure so susceptible to denial of service attacks
or server failure. Performance may be unpredictable because it depends on the
network as well as the system. May be management problems if servers are
owned by different organizations.

Question 21

What is the Pipe-and-filter arch pattern?

Answer 21

Name Pipe and filter

Desc The processing of the data in a system is organized so that each processing
component (filter) is discrete and carries out one type of data transformation. The
data flows (as in a pipe) from one component to another for processing.

When
used:
Commonly used in data processing applications (both batch- and transaction-based)
where inputs are processed in separate stages to generate related outputs.

Pros:
Easy to understand and supports transformation reuse. Workflow style matches the
structure of many business processes. Evolution by adding transformations is
straightforward. Can be implemented as either a sequential or concurrent system.

Cons:
The format for data transfer has to be agreed upon between communicating
transformations. Each transformation must parse its input and unparse its output to
the agreed form. This increases system overhead and may mean that it is impossible
to reuse functional transformations that use incompatible data structures.