BIS301

An Awesome Introduction to
System Analysis and Design

Some contents of the lecture notes

are taken from
Ian Sommerville

Software Architecture © BIS301 2023

Software architecture

© BIS301 2023
 Software architecture

• To create a reliable, secure and efficient product, you need to pay

attention to architectural design which includes:
• its overall organization,

• how the software is decomposed into components,

• the server organization

• the technologies that you use to build the software.The architecture of a software
product affects its performance, usability, security, reliability and maintainability.

• There are many different interpretations of the term ‘software

architecture’.
• Some focus on ‘architecture’ as a noun - the structure of a system and others
consider ‘architecture’ to be a verb - the process of defining these structures.

Software Architecture © BIS301 2023 3

 Table 4.1 The IEEE definition of software architecture

Architecture is the fundamental organization of a software system embodied in its

components, their relationships to each other and to the environment, and the
principles guiding its design and evolution.

Software Architecture © BIS301 2023 4

 Software architecture and components

• A component is an element that implements a coherent set of

functionality or features.
• Software component can be considered as a collection of one or more
services that may be used by other components.
• When designing software architecture, you don’t have to decide how an
architectural element or component is to be implemented.
• Rather, you design the component interface and leave the
implementation of that interface to a later stage of the development
process. ‫ ﺑﻌﻣل اﻟواﺟﮭﺔ او ﯾﻌﺗﺑر اﻟﺗﻔﺎﻋل ﻣﺎ ﺑﯾﻧﮭم‬,‫ﯾﻌﻧﻲ اﻧﺎ ﻣش ﺑﺣدد ازاي ﯾﺗﻌﻣﻠوا ﺑس ﺑدﻻ ﻣن ذﻟك‬
‫واﻟﺗﻧﻔﯾذ ﻓﻲ اﻻﺧر‬

Software Architecture © BIS301 2023 5

 Figure 4.1 Access to services provided by software components
Figure 4.1 Access to services provided by software components

Services accessed through

the component API

Services accessed directly

API
by other components

S1 S2 S3 S4 S5 S6

Component 1 Component 2

Software Architecture © BIS301 2023 6

 Why is architecture important?

• Architecture is important because the architecture of a system has a

fundamental influence on the non-functional system properties, shown in
Table 4.2. ‫ اﻧﮭﺎ ﺑﺗﺄﺛر ﻋﻠﻰ اﻟﺣﺎﺟﺎت اﻟﻠﻲ ﻣش اﺳﺎﺳﯾﺔ‬,‫اھم ﺟﻣﻠﺔ ﻓﻲ اﻟﺷﺎﺑﺗر‬
• Architectural design involves understanding the issues that affect the
architecture of your product and creating an architectural description that
shows the critical components and their relationships.
• Minimizing complexity should be an important goal for architectural
designers.
• The more complex a system, the more difficult and expensive it is to understand
and change.

• Programmers are more likely to make mistakes and introduce bugs and security
vulnerabilities when they are modifying or extending a complex system..

Software Architecture © BIS301 2023 7

 Table 4.2 Non-functional system quality attributes

Responsiveness
Does the system return results to users in a reasonable time?
Reliability
Do the system features behave as expected by both developers and users?
Availability
Can the system deliver its services when requested by users?
Security
Does the system protect itself and users’ data from unauthorized attacks and
intrusions?
Usability
Can system users access the features that they need and use them quickly and
without errors?
Maintainability
Can the system be readily updated and new features added without undue costs?
Resilience
Can the system continue to deliver user services in the event of partial failure or
external attack?

Software Architecture © BIS301 2023 8

 Table 4.3 The influence on architecture of system security

A centralized security architecture

In the Star Wars prequel Rogue One (https://en.wikipedia.org/wiki/Rogue_One),
the evil Empire have stored the plans for all of their equipment in a single, highly
secure, well-guarded, remote location. This is called a centralized security
architecture. It is based on the principle that if you maintain all of your information
in one place, then you can apply lots of resources to protect that information and
ensure that intruders can’t get hold of it.

Unfortunately (for the Empire), the rebels managed to breach their security. They
stole the plans for the Death Star, an event which underpins the whole Star Wars
saga. In trying to stop them, the Empire destroyed their entire archive of system
documentation with who knows what resultant costs. Had the Empire chosen a
distributed security architecture, with different parts of the Death Star plans
stored in different locations, then stealing the plans would have been more
difficult. The rebels would have had to breach security in all locations to steal the
complete Death Star blueprints.
‫ﻣش ﻣﮭم ﺑﺎﻗﻲ اﻟﺻﻔﺣﺔ‬

Software Architecture © BIS301 2023 9

 Centralized security architectures

• The benefits of a centralized security architecture are that it is easier to

design and build protection and that the protected information can be
accessed more efficiently.
• However, if your security is breached, you lose everything.
• If you distribute information, it takes longer to access all of the
information and costs more to protect it.
• If security is breached in one location, you only lose the information that
you have stored there.

Software Architecture © BIS301 2023 10

 Maintainability and performance

• Figure 4.2 shows a system with two components (C1 and C2) that share
a common database.
• Assume C1 runs slowly because it has to reorganize the information in the
database before using it.

• The only way to make C1 faster might be to change the database. This means
that C2 also has to be changed, which may, potentially, affect its response time.

• In Figure 4.3, a different architecture is used where each component has

its own copy of the parts of the database that it needs.
• If one component needs to change the database organization, this does not
affect the other component.

• However, a multi-database architecture may run more slowly and may

cost more to implement and change.
• A multi-database architecture needs a mechanism (component C3) to ensure
that the data shared by C1 and C2 is kept consistent when it is changed.

Software Architecture © BIS301 2023 11

 Figure 4.2 Shared database architecture
Figure 4.2. Shared database architecture

User interface

C1 C2

Shared database

Software Architecture © BIS301 2023 12

 Figure 4.3. Multiple database architecture
Figure 4.3. Multiple database architecture

User interface

C1 C2

C1 database C2 database

C3

Database reconciliation
Software Architecture © BIS301 2023 13
 Figure 4.4 Issues that influence architectural decisions

Figure 4.4 Issues that influence architectural decisions

Nonfunctional
product characteristics

Software Product
compatibility lifetime
Architectural
influences

Number of Software
users reuse

Software Architecture © BIS301 2023 14

 Table 4.4 The importance of architectural design issues

Nonfunctional product characteristics

Nonfunctional product characteristics such as security and performance affect all users. If
you get these wrong, your product will is unlikely to be a commercial success.
Unfortunately, some characteristics are opposing, so you can only optimize the most
important.
Product lifetime
If you anticipate a long product lifetime, you will need to create regular product revisions.
You therefore need an architecture that is evolvable, so that it can be adapted to
accommodate new features and technology.
Software reuse
You can save a lot of time and effort, if you can reuse large components from other
products or open-source software. However, this constrains your architectural choices
because you must fit your design around the software that is being reused.
Number of users
If you are developing consumer software delivered over the Internet, the number of users
can change very quickly. This can lead to serious performance degradation unless you
design your architecture so that your system can be quickly scaled up and down.
Software compatibility
For some products, it is important to maintain compatibility with other software so that users
can adopt your product and use data prepared using a different system. This may limit
architectural choices, such as the database software that you can use.

Software Architecture © BIS301 2023 15

 Trade off: Maintainability vs performance

• System maintainability is an attribute that reflects how difficult and

expensive it is to make changes to a system after it has been released to
customers.
• You improve maintainability by building a system from small self-contained
parts, each of which can be replaced or enhanced if changes are required.

• In architectural terms, this means that the system should be decomposed

into fine-grain components, each of which does one thing and one thing
only.
• However, it takes time for components to communicate with each other.
Consequently, if many components are involved in implementing a product
feature, the software will be slower.
‫ﺑﺎﻟظﺑط زي اﻟﻣﺎﯾﻛرو ﺳﯾرﻓس ﺑﺎﻟظﺑط ﺑﺗﺗﻘﺳم‬
‫ﺣﺎﺟﺎت ﺻﻐﯾرة ﺑس ﺑﺗﻘﺎﺑﻠﻧﻲ ﻣﺷﻛﻠﺔ ﻓﺎﻟﺗواﺻل‬
‫ﻣﺎ ﺑﯾﻧﮭم وده ﺑﯾـﺄﺛر ﻋﻠﻰ اﻻداء طﺑﯾﻌﻲ ﺑﯾﺧﻠﯾﮫ‬
‫اﺑطﺄ‬

Software Architecture © BIS301 2023 16

 Trade off: Security vs usability

• You can achieve security by designing the system protection as a series

of layers (Figure 4.5).
• An attacker has to penetrate all of those layers before the system is
compromised.

• Layers might include system authentication layers, a separate critical

feature authentication layer, an encryption layer and so on.
• Architecturally, you can implement each of these layers as separate
components so that if one of these components is compromised by an
attacker, then the other layers remain intact.

Software Architecture © BIS301 2023 17

 Figure 4.5 Authentication layers
Figure 4.5 Authentication layers

IP authentication

Application authentication

Feature authentication

Encryption

Protected asset such as a

database of users’ credit cards

Software Architecture © BIS301 2023 18

 Usability issues

• A layered approach to security affects the usability of the software.

• Users have to remember information, like passwords, that is needed to
penetrate a security layer. Their interaction with the system is inevitably slowed
down by its security features.

• Many users find this irritating and often look for work-arounds so that they do
not have to re-authenticate to access system features or data.

• To avoid this, you need an architecture:

• that doesn’t have too many security layers,

• that doesn’t enforce unnecessary security,

• that provides helper components that reduce the load on users.

Software Architecture © BIS301 2023 19

 Trade off: Availability vs time-to-market

• Availability is particularly important in enterprise products, such as

products for the finance industry, where 24/7 operation is expected.
• The availability of a system is a measure of the amount of ‘uptime’ of that
system.
• Availability is normally expressed as a percentage of the time that a system is
available to deliver user services.

• Architecturally, you achieve availability by having redundant components

in a system. ‫ﻣﮭﻣﺔ ﺟدا اﻟﺟﻣﻠﺔ دي ﺗﺣدﯾدا ھﻧﺎ‬
• To make use of redundancy, you include sensor components that detect failure,
and switching components that switch operation to a redundant component
when a failure is detected.

• Implementing extra components takes time and increases the cost of

system development. It adds complexity to the system and therefore
increases the chances of introducing bugs and vulnerabilities.

Software Architecture © BIS301 2023 20

 Architectural design questions

• How should the system be organized as a set of architectural

components, where each of these components provides a subset of the
overall system functionality?
• The organization should deliver the system security, reliability and performance
that you need.

• How should these architectural components be distributed and

communicate with each other?
• What technologies should you use in building the system and what
components should be reused?

Software Architecture © BIS301 2023 21

 Component organization

• Abstraction in software design means that you focus on the essential

elements of a system or software component without concern for its
details.
• At the architectural level, your concern should be on large-scale
architectural components.
• Decomposition involves analysing these large-scale components and
representing them as a set of finer-grain components.
• Layered models are often used to illustrate how a system is composed of
components.

Software Architecture © BIS301 2023 22

 Figure 4.6 An architectural model
Figure 4.6 An of a document
architectural model of aretrieval
documentsystem
retrieval system

Web browser

User interaction Local input Local printing

validation

User interface management

Authentication and Form and query Web page
authorization manager generation

Information retrieval

Document Rights
Search Payments Accounting
retrieval management

Document index

Index Index
Index querying
management creation

Basic services

Database Query User account

Logging
query validation management

Databases

DB1 DB2 DB3 DB4 DB5

Software Architecture © BIS301 2023 23

 Architectural complexity

• Complexity in a system architecture arises because of the number and

the nature of the relationships between components in that system.
• When decomposing a system into components, you should try to avoid
unnecessary software complexity.
• Localize relationships
If there are relationships between components A and B, these are easier to
understand if A and B are defined in the same module.

• Reduce shared dependencies

Where components A and B depend on some other component or data,
complexity increases because changes to the shared component mean you
have to understand how these changes affect both A and B.

• It is always preferable to use local data wherever possible and to avoid

sharing data if you can.

Software Architecture © BIS301 2023 24

 Figure 4.7 Examples of component relationships
Figure 4.7 Examples of component relationships
localize data relationship
C1 is-part-of C2 C1 uses C2 C1 is-located-with C2

C1
C2 C1
C1 C2
C1
calls

C2

C1 shares-data-with C2

C1 data C2

‫ﺑﯾزود ال‬ shared data

complexity dependencies

Software Architecture © BIS301 2023 25

 Figure 4.8
Figure 4.8 Architectural Architectural
design guidelines design guidelines

Separation of concerns
Organize your architecture
into components that focus on
a single concern

Design
guidelines

Stable interfaces Implement once

Design component Avoid duplicating
interfaces that are coherent functionality at different
and that change slowly places in your architecture

Software Architecture © BIS301 2023 26

 Design guidelines and layered architectures

• Each layer is an area of concern and is considered separately from other

layers. seperation of concern
• The top layer is concerned with user interaction, the next layer down with user
interface management, the third layer with information retrieval and so on.

• Within each layer, the components are independent and do not overlap
in functionality. seperation of concern
• The lower layers include components that provide general functionality so there
is no need to replicate this in the components in a higher level. implement ones

• The architectural model is a high-level model that does not include

implementation information. stable interfaces
• Ideally, components at level X (say) should only interact with the APIs of the
components in level X-1. That is, interactions should be between layers and not
across layers.

Software Architecture © BIS301 2023 27

 Cross-cutting concerns

• Cross-cutting concerns are concerns that are systemic, that is, they
affect the whole system.
• In a layered architecture, cross-cutting concerns affect all layers in the
system as well as the way in which people use the system.
• Cross-cutting concerns are completely different from the functional
concerns represented by layers in a software architecture.
• Every layer has to take them into account and there are inevitably
interactions between the layers because of these concerns.
• The existence of cross-cutting concerns is the reason why modifying a
system after it has been designed to improve its security is often difficult.
‫ده ﻷﻧﮭﺎ ﺑﺗﺄﺛر ﻋﻠﻰ ﻛل اﻟطﺑﻘﺎت وﺑﺎﻟﺗﺎﻟﻲ ﻟو ﺻﻣﻣت وﻋﻣﻠت اﻟﺑرﻧﺎﻣﺞ وﺟﯾت ﻋﺎﯾز ازود اﻻﻣﺎن ھﯾﺑﻘﻰ‬
‫ﺻﻌب ﺟدا ﻻﻧﮫ ﺑﯾﺄﺛر ﻋﻠﻰ ﻛل اﻟطﺑﻘﺎت طﺑﻌﺎ‬

Software Architecture © BIS301 2023 28

 Figure 4.9 Cross-cutting concerns
Figure 4.9 Cross-cutting concerns

Security Performance Reliability

User interface

Application

Infrastructure

Operating system

Hardware

Software Architecture © BIS301 2023 29

 Table 4.5 Security as a cross-cutting concern

Security architecture
Different technologies are used in different layers, such as an SQL database or a
Firefox browser. Attackers can try to use of vulnerabilities in these technologies
to gain access.
Consequently, you need protection from attacks at each layer as well as
protection, at lower layers in the system, from successful attacks that have
occurred at higher-level layers.

If there is only a single security component in a system, this represents a critical

system vulnerability. If all security checking goes through that component and it
stops working properly or is compromised in an attack, then you have no reliable
security in your system.

By distributing security across the layers, your system is more resilient to attacks
and software failure (remember the Rogue One example earlier in the chapter).

Software Architecture © BIS301 2023 30

 Figure 4.10
Figure 4.10 A generic
A generic layeredlayered architecture
architecture for a web-basedfor a web-based application
application

Browser-based or mobile user interface

Authentication and user interaction management

Application-specific functionality

Basic shared services

Transaction and database management

Software Architecture © BIS301 2023 31

 Table 4.6 Layer functionality in a web-based application

Browser-based or mobile user interface

A web browser system interface in which HTML forms are often used to collect user
input. Javascript components for local actions, such as input validation, should also
be included at this level. Alternatively, a mobile interface may be implemented as
an app.

Authentication and UI management

A user interface management layer that may include components for user
authentication and web page generation.

Application-specific functionality
An ‘application’ layer that provides functionality of the application. Sometimes, this
may be expanded into more than one layer.

Basic shared services

A shared services layer, which includes components that provide services used by
the application layer components.

Database and transaction management

A database layer that provides services such as transaction management and
recovery. If your application does not use a database then this may not be required.

Software Architecture © BIS301 2023 32

 Table 4.7 iLearn architectural design principles

Replaceability
It should be possible for users to replace applications in the system with
alternatives and to add new applications. Consequently, the list of applications
included should not be hard-wired into the system.

Extensibility
It should be possible for users or system administrators to create their own
versions of the system, which may extend or limit the ’standard’ system.

Age-appropriate
Alternative user interfaces should be supported so that age-appropriate
interfaces for students at different levels can be created.

Programmability
It should be easy for users to create their own applications by linking existing
applications in the system.

Minimum work
Users who do not wish to change the system should not have to do extra work so
that other users can make changes.

Software Architecture © BIS301 2023 33

 iLearn design principles
• Our goal in designing the iLearn system was to create an adaptable,
universal system that could be easily updated as new learning tools
became available.
• This means that it must be possible to change and replace components and
services in the system (principles (1) and (2)).

• Because the potential system users spanned an age range from 3 to 18, we
needed to provide age-appropriate user interfaces and to make it easy to choose
an interface (principle (3)).

• Principle (4) also contributes to system adaptability and principle (5) was included
to ensure that this adaptability did not adversely affect users who did not require
it. minimum work
‫ﻟو ﻋﻣﻠت ﺣﺎﺟﺔ ﻋﻧدي ﻣﺗﺄﺛرش ﻋﻠﻰ ﻏﯾري‬

Software Architecture © BIS301 2023 34

 Designing iLearn as a service-oriented system

• These principles led us to an architectural design decision that the iLearn

system should be service-oriented.
• Every component in the system is a service. Any service is potentially
replaceable and new services can be created by combining existing services.
Different services delivering comparable functionality can be provided for
students of different ages.
• Service integration
• Full integration Services are aware of and can communicate with other services
through their APIs.
• Partial integration Services may share service components and databases but are
not aware of and cannot communicate directly with other application services.

• Independent These services do not use any shared system services or databases
and they are unaware of any other services in the system. They can be replaced by
any other comparable service.

Software Architecture © BIS301 2023 35

 Figure 4.11 A layered architectural model of the iLearn system
Figure 4.11. A layered architectural model of the iLearn system
User interface

Web browser iLearn app

User interface management

Interface creation Forms management Interface delivery Login

Configuration services
Group Application Security User interface Setup
configuration configuration configuration configuration service

Application services

Archive access Word processor Video conf. Email and User installed
Blog Wiki Spreadsheet Presentation Drawing messaging applications

Integrated services

Virtual learning Authentication and

Resource discovery User analytics environment authorization

Shared infrastructure services

Authentication Logging and monitoring Application interfacing

User storage Application storage Search

Software Architecture © BIS301 2023 36

 Distribution architecture

• The distribution architecture of a software system defines the servers in

the system and the allocation of components to these servers.
• Client-server architectures are a type of distribution architecture that is
suited to applications where clients access a shared database and
business logic operations on that data.
• In this architecture, the user interface is implemented on the user’s own
computer or mobile device.
• Functionality is distributed between the client and one or more server
computers.

Software Architecture © BIS301 2023 37

 Figure 4.12 Client-server architecture

Figure 4.12 Client-server architecture

Client 1
request
response

request
Client 2
response

request

Client 3
response
request
Servers

Client ... Load

response
balancer

Software Architecture © BIS301 2023 38

 Figure
Figure 4.13. The 4.13 The model-view-controller
model-view-controller pattern pattern

CLIENT

Browser

User inputs Page to display

User changes
Controller View

View update Change View refresh

request notification request

Model

SERVER

Software Architecture © BIS301 2023 39

 Client-server communication

• Client-server communication normally uses the HTTP protocol.

• The client sends a message to the server that includes an instruction such as
GET or POST along with the identifier of a resource (usually a URL) on which
that instruction should operate. The message may also include additional
information, such as information collected from a form.

• HTTP is a text-only protocol so structured data has to be represented as

text. There are two ways of representing this data that are widely used,
namely XML and JSON.
• XML is a markup language with tags used to identify each data item.

• JSON is a simpler representation based on the representation of objects in the

Javascript language.

Software Architecture © BIS301 2023 40

 Figure 4.14 Multi-tier client-server architecture
Figure 4.14 Multi-tier client-server architecture

Client 1

Client 2

Application Database
Web server
server server

Client 3

Client ...

Software Architecture © BIS301 2023 41

 Service-oriented architecture

• Services in a service-oriented architecture are stateless components,

which means that they can be replicated and can migrate from one
computer to another.
• Many servers may be involved in providing services
• A service-oriented architecture is usually easier to scale as demand
increases and is resilient to failure.

Software Architecture © BIS301 2023 42

 Figure 4.15 service-oriented architecture

Figure 4.15 Service-oriented architecture

s1
Client 1

s2

Client 2 s3
Service
Web server gateway
s4
Client 3
s5

Client ... s6

Services

Software Architecture © BIS301 2023 43

 Issues in architectural choice

• Data type and data updates

• If you are mostly using structured data that may be updated by different system
features, it is usually best to have a single shared database that provides
locking and transaction management. If data is distributed across services, you
need a way to keep it consistent and this adds overhead to your system.

• Change frequency
• If you anticipate that system components will be regularly changed or replaced,
then isolating these components as separate services simplifies those changes.

• The system execution platform

• If you plan to run your system on the cloud with users accessing it over the
Internet, it is usually best to implement it as a service-oriented architecture
because scaling the system is simpler.

• If your product is a business system that runs on local servers, a multi-tier

architecture may be more appropriate.

Software Architecture © BIS301 2023 44

 Table 4.8 Technology choices

Database
Should you use a relational SQL database or an unstructured NOSQL database?

Platform
Should you deliver your product on a mobile app and/or a web platform?
Server
Should you use dedicated in-house servers or design your system to run on a
public cloud? If a public cloud, should you use Amazon, Google, Microsoft, or
some other option?

Open source
Are there suitable open-source components that you could incorporate into your
products?

Development tools
Do your development tools embed architectural assumptions about the software
being developed that limit your architectural choices?

Software Architecture © BIS301 2023 45

 Database

• There are two kinds of database that are now commonly used:
• Relational databases, where the data is organised into structured tables

• NoSQL databases, in which the data has a more flexible, user-defined

organization.

• Relational databases, such as MySQL, are particularly suitable for

situations where you need transaction management and the data
structures are predictable and fairly simple.
• NoSQL databases, such as MongoDB, are more flexible and potentially
more efficient than relational databases for data analysis.
• NoSQL databases allow data to be organized hierarchically rather than as flat
tables and this allows for more efficient concurrent processing of ‘big data’.

Software Architecture © BIS301 2023 46

 Delivery platform

• Delivery can be as a web-based or a mobile product or both

• Mobile issues:
• Intermittent connectivity You must be able to provide a limited service without
network connectivity.
• Processor power Mobile devices have less powerful processors, so you need to
minimize computationally-intensive operations.
• Power management Mobile battery life is limited so you should try to minimize
the power used by your application.
• On-screen keyboard On-screen keyboards are slow and error-prone. You should
minimize input using the screen keyboard to reduce user frustration.
• To deal with these differences, you usually need separate browser-based
and mobile versions of your product front-end.
• You may need a completely different decomposition architecture in these
different versions to ensure that performance and other characteristics are
maintained.

Software Architecture © BIS301 2023 47

 Server

• A key decision that you have to make is whether to design your system
to run on customer servers or to run on the cloud.
• For consumer products that are not simply mobile apps I think it almost
always makes sense to develop for the cloud.
• For business products, it is a more difficult decision.
• Some businesses are concerned about cloud security and prefer to run their
systems on in-house servers. They may have a predictable pattern of system
usage so there is less need to design your system to cope with large changes in
demand.

• An important choice you have to make if you are running your software
on the cloud is which cloud provider to use.

Software Architecture © BIS301 2023 48

 Open source

• Open source software is software that is available freely, which you can
change and modify as you wish.
• The advantage is that you can reuse rather than implement new software, which
reduces development costs and time to market.

• The disadvantages of using open-source software is that you are constrained by

that software and have no control over its evolution.

• The decision on the use of open-source software also depends on the

availability, maturity and continuing support of open source components.
• Open source license issues may impose constraints on how you use the
software.
• Your choice of open source software should depend on the type of
product that you are developing, your target market and the expertise of
your development team.

Software Architecture © BIS301 2023 49

 Development tools

• Development technologies, such as a mobile development toolkit or a

web application framework, influence the architecture of your software.
• These technologies have built-in assumptions about system architectures and
you have to conform to these assumptions to use the development system.

• The development technology that you use may also have an indirect
influence on the system architecture.
• Developers usually favour architectural choices that use familiar technologies
that they understand. For example, if your team have a lot of experience of
relational databases, they may argue for this instead of a NoSQL database.

Software Architecture © BIS301 2023 50

 Key points 1

• Software architecture is the fundamental organization of a system

embodied in its components, their relationships to each other, and to the
environment, and the principles guiding its design and evolution.
• The architecture of a software system has a significant influence on non-
functional system properties such as reliability, efficiency and security.
• Architectural design involves understanding the issues that are critical for
your product and creating system descriptions that shows components
and their relationships.
• The principal role of architectural descriptions is to provide a basis for the
development team to discuss the system organization. Informal
architectural diagrams are effective in architectural description because
they are fast and easy to draw and share.
• System decomposition involves analyzing architectural components and
representing them as a set of finer-grain components.

Software Architecture © BIS301 2023 51

 Key points 2

• To minimize complexity, you should separate concerns, avoid functional

duplication and focus on component interfaces.
• Web-based systems often have a common layered structure including
user interface layers, application-specific layers and a database layer.
• The distribution architecture in a system defines the organization of the
servers in that system and the allocation of components to these servers.
• Multi-tier client-server and service-oriented architectures are the most
commonly used architectures for web-based systems.
• Making decisions on technologies such as database and cloud
technologies are an important part of the architectural design process.

Software Architecture © BIS301 2023 52