What Is Software Architecture? Key Concepts, UML Views, and Practical Rules

Opening Statement

Since this is a personal summary of the technologies I have studied, errors are inevitable. I share it with a spirit of technical exchange, hoping readers can point out mistakes, benefit from the content, and improve together.

What Is Software Architecture

Software architecture can be simply described as the relationships of composition, interaction, and inheritance among a series of components. While this abstract definition is understandable, it is still too vague for practical use.

According to the ANSI/IEEE standard, software architecture is the part of a software‑intensive system that decisively influences its implementation and deployment.

The key point of software architecture is to meet the goals of project stakeholders, covering both functional and non‑functional requirements.

Architecture design must be determined early in the development process, as it is a critical decision that cannot be changed later.

If an architecture cannot satisfy stakeholder goals, the solution is infeasible. The diagram below shows the relationship among system, architecture, and stakeholders as defined by the ANSI/IEEE standard.

The tools for describing system architecture include UML and IBM’s Rational Rose; UML has become the international standard.

UML class diagrams describe relationships between classes.

Use‑case diagrams depict usage scenarios.

Component diagrams illustrate reusable parts of the system and their mapping to binaries.

Using UML tools allows deeper, multi‑angle descriptions of system architecture.

Currently there is no automatic way to verify whether an architecture meets stakeholder goals; validation relies on multiple testing levels.

For example, unit tests verify individual functions, integration tests assess system compatibility, and acceptance tests evaluate user satisfaction and required functionality.

Besides UML, IBM’s Rational Rose offers several view modes, illustrated below.

System Architecture

No system is indivisible; the more agile the development method, the larger the space left for developers to implement the architecture.

The process of decomposing a system by a system architect ultimately produces a detailed design specification for developers, whose content and format depend on the development methodology.

What Is an Architecture

Architecture mainly manifests in decisions that are hard or costly to change, yet someone must make those decisions.

System analysts determine what the system does; architects design how to achieve it.

Architects act as the bridge between requirements and detailed specifications.

An architect’s responsibilities include participating throughout development: analyzing requirements, designing architecture, implementing, testing, inheriting, and deploying.

According to ISO, an architect is the person, team, or organization responsible for the system architecture.

Microsoft classifies system architects into four types:

Enterprise architect

Infrastructure architect

Specialized technology architect

Solution architect

Final Summary of Some Development Rules

1. Adding personnel to a lagging project only pushes the schedule further behind.

2. Program complexity will keep increasing until maintainers feel overwhelmed.

3. Architects and developers write code differently; if architects follow developers’ construction methods, the result becomes a historical failure.