Chapter 4: Software Architecture

Software Architecture​

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.​

Component

An element that implements a coherent set of functionality or features. ​

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.​

Non-functional system quality attributes​

• Responsiveness

• Reliability

• Availability

• Security

• Usability

• Maintainability

• Resilience

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?​

Architectural Influences

• Non-Functional Product​

  Characteristics

• Product Lifetime

• Software Reuse

• Number of Users

• Software Compatibility

Non-Functional Product Characteristics

Some characteristics are opposing, so you ​can optimize only the most important.​​

Product Lifetime

If you anticipate a long product lifetime, you need to create regular product revisions.

Software Reuse

You can save a lot of time and effort if you can reuse large components from other products or open-source software.

Number of Users

If you are developing consumer software delivered over the Internet, the number of users can change very quickly.

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.

Abstraction

Focus on the essential elements of a system or software component without concern for its details.​

Decomposition

Analysing large-scale components and representing them as a set of finer-grain components.​

Design Guidelines

• Separation of Concerns

• Stable Interfaces

• Implement Once

Separation of Concerns

Organize the architecture into components that focus on a single concern.

Stable Interfaces

Design component interfaces that are coherent and change slowly.

Implement Once

Avoid duplicating functionality at different places in your architecture.

Cross-Cutting Concerns

Systematic concerns that affect the whole system. ​

Service Integration

The level of overlap there is between multiple services.

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.

Distribution Architecture

Defines the servers in the system and the allocation of components to these servers. ​

Client-Server Architectures

A type of distribution architecture that is suited to applications where clients access a shared database and business logic operations on that data. ​

Design Pattern

A way of reusing abstract knowledge about a problem and its solution.​

Pattern

A description of the problem and the essence of its solution.​

Elements of a Pattern

• Name

• Problem description

• Solution description

• Consequences

Issues in Architectural Choice

• Data type and data updates

• Change frequency

• The system execution platform

Data Type and Data Updates

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

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.

Technology Choices

• Database

• Platform

• Server

• Open Source

• Development Tools

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?

Relational Databases

Data is organized into structured tables​. Suitable for situations where you need transaction management and the data structures are predictable and fairly simple. ​

NoSQL Databases

The data has a more flexible, user-defined organization. ​More flexible and potentially more efficient than relational databases for data analysis. ​

Mobile Issues

• Intermittent connectivity

• Processor Power

• Power management

• On-screen keyboard

Open Source Software

Software that is available freely, which you can change and modify as you wish. ​

GNU General Public License (GPL)

If you use open source software that is licensed under the GPL license, then you must make that software open source. ​

GNU Lesser General Public License (LGPL)

You can write components that link to open source code without having to publish the source of these components.

Berkley Standard Distribution (BSD) License

You are not obliged to re-publish any changes or modifications made to open source code. You can include the code in proprietary systems that are sold.​