Studying for the System Architect Software Exam

These notes are organized around the core knowledge points of the exam syllabus, with code examples and memory mnemonics — good for a final sprint review. (The exam is China’s “Soft Exam” — Computer Technology and Software Professional Qualification — System Architect level.)

1. Laws, Regulations, and Standardization

1.1 Copyright

Copyright ownership rules:

• Whoever develops it owns it
• An employee develops it using company resources → belongs to the company
• A work-for-hire with no contract → belongs to the corporate legal entity
• An adaptation → the copyright belongs to the adapter

⚠️ The processing procedure (algorithmic logic) is not a subject of software copyright protection; only the expression of the code is protected.

Time-limited rights (50 years): publication, distribution, exhibition, reproduction
Permanently protected rights: attribution, modification, integrity of the work

1.2 Other intellectual property

• Trademark rights: enjoyed only after registration is complete; the subject is the software’s registered trademark
• Patent rights: enjoyed only after patent registration is complete

2. Software Engineering

2.1 Comparison of software development models

Waterfall phases:
Requirements analysis → system design → detailed design → coding → testing → maintenance
(each phase completes before entering the next)

The four quadrants of the spiral model:
① Make plans  ② Risk analysis
③ Engineering ④ Customer evaluation

2.2 Comparison of agile methods

SCRUM’s three meetings: daily standup, sprint planning, retrospective

2.3 The RUP-based software process

RUP = Rational Unified Process

Four phases:
┌──────────┬──────────┬──────────┬──────────┐
│ Inception │ Elaboration│ Construction│ Transition│
│ project scope│ refine architecture│ development│ test & deliver│
│ business model│         │          │ acceptance │
└──────────┴──────────┴──────────┴──────────┘

Nine core workflows:

• 6 process workflows: business modeling, requirements, analysis & design, implementation, testing, deployment
• 3 supporting workflows: configuration & change management, project management, environment

Development approach: use-case driven + architecture-centric + iterative and incremental

2.4 Types of software maintenance

📊 Effort share: Perfective > Adaptive > Corrective > Preventive

2.5 Capability Maturity Model (CMMI)

Level 1 Initial     → all on people, no process, heroics
Level 2 Repeatable  → basic process, old experience reusable
Level 3 Defined     → org-wide standardized process
Level 4 Managed     → quantitative management, data-driven decisions
Level 5 Optimizing  → continuous improvement, proactive iteration

Mnemonic (Chinese): 初重定管优 (Initial, Repeatable, Defined, Managed, Optimizing)

2.6 Reverse engineering

Levels of information abstraction (high to low):

• Restructuring: transform the form of description at the same abstraction level
• Design recovery: abstract design information from an existing program
• Reengineering: produce a new version based on reverse-engineering results
• Search and transform can derive: the implementation level and the structure level

2.7 Service-Oriented Architecture (SOA)

SOA’s four core technologies:

WSDL  → service description (what the service does, the interface doc)
         Web Service Description Language

SOAP  → service communication (how to package and send requests, the XML envelope)
         Simple Object Access Protocol

UDDI  → service registration and discovery (where to find the service)
         Universal Description, Discovery and Integration

BPEL  → service orchestration (chain multiple services into a business process)
         Business Process Execution Language

Analogy for memory:

Go to the UDDI yellow pages to find a service → read the WSDL manual to understand the interface → send the request in a SOAP envelope → orchestrate the whole business flow with BPEL

ESB (Enterprise Service Bus): an infrastructure implemented with middleware technology that supports SOA, responsible for service routing, protocol conversion, and message transformation.

2.8 Correspondence between software testing and development phases

Requirements analysis ←→ acceptance testing (user acceptance)
High-level design     ←→ system testing (system integration)
Detailed design       ←→ integration testing (module integration)
Coding phase          ←→ unit testing (basis: detailed design)

2.9 Cleanroom software engineering

Goal: zero defects, based on function theory and sampling theory

Core elements: formal specification → box-structure design → correctness verification → incremental statistical control → statistical testing for reliability

Prevent errors rather than fix them; suited to high-reliability systems (aerospace, medical)

2.10 Components

Component characteristics (key differences from classes/objects):

• Not an instance unit, has no unique identity
• Has no externally visible state (a container can manage it)
• One component can contain multiple class elements
• Only one copy can exist in the same environment

Component classification methods:

• Keyword classification: tree hierarchy
• Faceted classification: multi-dimensional description (facets), the most flexible
• Hypertext organization: browser-style search

Three key properties of components: independent deployability, shareability, composability

Architectural mismatch:

Component mismatch  → various facilities and models don't match
Connector mismatch  → interaction protocols, data formats, intermediate transport don't match

3. System Analysis and Design

3.1 UML diagrams

The five models and their diagrams

UML relationships quick reference

Association  ─────►  ordinary "knows about" relationship (solid arrow)
Dependency   - - -►  temporary "uses" relationship (dashed arrow)
Generalization ───▷  inheritance (hollow triangle)
Aggregation  ◇────  whole contains part, part can exist independently (hollow diamond)
Composition  ◆────  life-and-death bound, part can't exist independently (solid diamond)

Use-case diagram relationships

⚠️ The only relationship between use-case actors is inheritance (generalization) — there’s no aggregation.

3.2 Design patterns

Creational patterns

// Builder pattern example (Lombok @Builder)
@Builder
public class UserQuery {
    private String name;
    private Integer age;
    private String city;
}

// Usage
UserQuery query = UserQuery.builder()
    .name("Zhang San")
    .age(25)
    .city("Shanghai")
    .build();

// Singleton (double-checked locking)
public class RedisClient {
    private volatile static RedisClient instance;

    private RedisClient() {}

    public static RedisClient getInstance() {
        if (instance == null) {
            synchronized (RedisClient.class) {
                if (instance == null) {
                    instance = new RedisClient();
                }
            }
        }
        return instance;
    }
}

Structural patterns

// Proxy pattern (the essence of Spring AOP)
@Aspect
@Component
public class LogAspect {
    @Around("@annotation(Log)")
    public Object around(ProceedingJoinPoint pjp) throws Throwable {
        long start = System.currentTimeMillis();
        Object result = pjp.proceed();
        log.info("took: {}ms", System.currentTimeMillis() - start);
        return result;
    }
}

// Decorator pattern example
InputStream is = new FileInputStream("data.txt");
InputStream bis = new BufferedInputStream(is);     // add buffering
InputStream gis = new GZIPInputStream(bis);        // add decompression

Behavioral patterns

// Strategy pattern example (payment methods)
public interface PayStrategy {
    void pay(BigDecimal amount);
}

@Component("alipay")
public class AliPayStrategy implements PayStrategy {
    public void pay(BigDecimal amount) { /* Alipay logic */ }
}

@Component("wechat")
public class WechatPayStrategy implements PayStrategy {
    public void pay(BigDecimal amount) { /* WeChat Pay logic */ }
}

// Chain of Responsibility (Spring Security filter chain)
public class AuthFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest req,
            HttpServletResponse res, FilterChain chain)
            throws ServletException, IOException {
        // pre-processing
        verifyToken(req);
        // pass to the next filter
        chain.doFilter(req, res);
    }
}

3.3 The seven principles of object-oriented design

3.4 Coupling and cohesion (ordered low to high)

Coupling (low → high):

No direct coupling → data coupling → stamp coupling → control coupling →
external coupling → common coupling → content coupling

(The original Chinese mnemonic is 飞鼠标恐外公内, a phonetic device.)

Cohesion (low → high):

Coincidental → logical → temporal → procedural →
communicational → sequential → functional

(The original Chinese mnemonic is 欧罗驶过通顺宫, a phonetic device.)

Design goal: high cohesion, low coupling

3.5 The 4+1 architecture views

        Scenario view (use-case view)
              ↑
    ┌─────────────────────┐
    │ Logical view │ Development view │
    │ (function/class) │ (code packaging) │
    ├──────────────┼──────────────────┤
    │ Process view │ Physical view │
    │ (runtime processes) │ (deployment) │
    └─────────────────────┘

4. System Architecture Design

4.1 Overview of architectural styles (22 kinds)

Dataflow styles

# Typical Unix pipe-and-filter example
cat access.log | grep "ERROR" | awk '{print $4}' | sort | uniq -c
#   data source    filter 1       filter 2         filter 3   filter 4

Call-and-return styles

Independent-component styles (event/message)

Virtual-machine styles

Repository styles (data-centric)

Closed-loop control style

Process-control style: sensor collects → controller computes → actuator responds; note the closed-loop feature.

Sensor → Controller → Actuator
   ↑__________________feedback______________________|

4.2 Quality attributes and architecture evaluation

Six major quality attributes

Runtime quality attributes:

MTTR = Mean Time To Repair → smaller is better
MTTF = Mean Time To Failure → larger is better
MTBF = Mean Time Between Failures → larger is better
MTBF = MTTF + MTTR

Development-time quality attributes: maintainability, extensibility, testability, reusability, portability, modifiability, interoperability

Availability tactics

Fault detection: heartbeat, ping-echo, exception monitoring
Fault recovery: active redundancy (hot standby), passive redundancy (cold standby), election (Raft/Paxos)
Fault prevention: transactions, process monitoring, predictive models

Modifiability tactics

• Decouple with middleware
• Separate interface from implementation
• Abstraction
• Information hiding

⚠️ Variability is not a concern of modifiability

4.3 Architecture evaluation methods

ATAM focuses on four quality attributes: performance, security, availability, modifiability

The six elements of a quality attribute (scenario template):

Source (who triggers) → Stimulus (what happens) → Environment (in what state)
→ Artifact (which part is affected) → Response (what the system does) → Response measure (the standard to meet)

Three architecture-evaluation concepts:

• Architectural risk: hidden dangers from architectural decisions with potential problems
• Sensitivity point: a characteristic of a component for achieving a certain quality attribute
• Tradeoff point: a characteristic that affects multiple quality attributes (a sensitivity point for several attributes)

4.4 ABSD (Architecture-Based Software Development)

Drivers: business needs + quality attributes + functional requirements

Development process: requirements → design → documentation → review → implementation → evolution

The top-level conceptual architecture is decomposed into conceptual subsystems, ultimately producing software components and classes

4.5 DSSA (Domain-Specific Software Architecture)

Three roles:

• Domain analyst → produces the domain model
• Domain designer → develops the DSSA, obtaining the architecture
• Domain implementer → takes the DSSA to concrete implementation

Three references: reference model + reference requirements + reference architecture

4.6 Big-data architecture: Lambda vs Kappa

Lambda architecture:
Raw data → ┬─ Batch layer (Spark/MapReduce) → batch view  ─┐
           │                                                ├→ Serving layer (Hive/Impala)
           └─ Speed layer (Flink/Spark Streaming) → real-time view ┘

Kappa architecture:
Raw data → Kafka (message queue) → Flink (stream compute) → ClickHouse/Doris (query)

4.7 Microservice architecture vs monolithic architecture

The Spring Cloud microservice tech stack:

Registry:        Nacos / Eureka
Config center:   Nacos / Apollo
Gateway:         Spring Cloud Gateway
Service calls:   OpenFeign
Circuit break/limit: Sentinel / Resilience4j
Message queue:   Kafka / RabbitMQ
Distributed tx:  Seata

4.8 Cloud computing service models

SaaS (Software as a Service)       → top layer, use the software directly
PaaS (Platform as a Service)       → middle layer, provides a development platform
IaaS (Infrastructure as a Service) → bottom layer, provides hardware resources

5. Database Systems

5.1 Normal forms

Partial functional dependency example (violates 2NF):
Primary key: (student_id, course_id)
Problem: student name depends only on student_id (partial dependency)
Fix: split tables → Student(student_id, name) + Enrollment(student_id, course_id, grade)

Transitive dependency example (violates 3NF):
student_id → department → department head (transitive dependency)
Fix: split tables → Student(student_id, department) + Department(department, head)

5.2 Relational algebra

5.3 Armstrong’s axioms

The three basic axioms:

• Reflexivity: if Y⊆X, then X→Y
• Augmentation: if X→Y, then XZ→YZ
• Transitivity: if X→Y and Y→Z, then X→Z

Three common corollaries:

• Union rule: X→Y, X→Z ⟹ X→YZ
• Decomposition rule: X→YZ ⟹ X→Y, X→Z
• Pseudo-transitivity: X→Y, WY→Z ⟹ WX→Z

5.4 Distributed databases

Four kinds of transparency (high to low):

Fragmentation transparency → unaware of how data is fragmented (highest-level)
Replication transparency   → unaware of which nodes data is replicated to
Location transparency      → unaware of which node data is on
Logical transparency       → unaware of the underlying data model (lowest-level)

Two-Phase Commit (2PC):

Phase 1 (prepare/vote phase):
  Coordinator → all participants: "Are you ready?"
  Participants → coordinator: "Yes/No"

Phase 2 (execute/commit phase):
  All Yes → coordinator → all participants: "COMMIT"
  Any No  → coordinator → all participants: "ROLLBACK"

Distributed database conceptual schema hierarchy:

Global external schema (customer's view)
    ↓
Global conceptual schema (HQ's general ledger)
    ↓
Fragmentation schema (splitting rules)
    ↓
Allocation schema (where fragments are stored)

5.5 The three-level schema structure

External schema (user view / View)  ← the data view users see
Schema (conceptual schema/table structure) ← the global logical structure
Internal schema (physical storage/index) ← how data is stored

5.6 Data warehouse characteristics

Differences from an ordinary database:

• Subject-oriented (rather than transaction-oriented)
• Integrated (multi-source data consolidation)
• Non-volatile (append-only, historical data)
• Time-variant (records time snapshots)

6. Operating Systems

6.1 Process management

The three-state process model:

Ready ──(scheduled/allocated CPU)──→ Running
  ↑                                   │
  └──(time slice up / preempted by higher priority)──┘
       ↑                ↓
       └──(I/O complete)── Blocked/Waiting ──(I/O request)──┘

PCB (Process Control Block) organization:

• Sequential (linear list)
• Linked (linked list)
• Indexed (index table)
• Hashed

Process vs thread:

• Process: the smallest unit of resource allocation and management
• Thread: the basic execution unit of a process (the smallest unit of CPU scheduling)

6.2 Deadlock

The four necessary conditions (all must hold for deadlock):

Banker’s algorithm: predict whether the system stays in a safe state after allocation; refuse if unsafe.

6.3 Disk scheduling

Three elements of physical addressing:
Head number (surface) → cylinder number (track) → sector number (position)

Access time = seek time + rotational latency + data transfer time

Common disk-scheduling algorithms:
FCFS (First-Come First-Served) → fair but inefficient
SSTF (Shortest Seek Time First) → may starve outer tracks
SCAN (elevator) → scans back and forth, more even
C-SCAN (circular scan) → one-directional scan, fairer

6.4 Embedded systems

Real-time OS (RTOS) characteristics:

• Task scheduler: preemptive scheduling
• Hard-real-time scheduling algorithm: Rate Monotonic Scheduling (RMS)
  • Shorter task period → higher priority

Low-power design strategies:

• Compilation optimization techniques
• Hardware-software co-design
• Algorithm optimization (reduce computation)

7. Information Security

7.1 Encryption algorithms

Symmetric encryption

Asymmetric encryption

RSA principle:
Public key encrypts → private key decrypts (encrypted data transmission)
Private key signs → public key verifies (digital signatures)

The full digital-signature flow:
Sender:   plaintext → Hash → message digest → encrypt with private key → digital signature
Receiver: received (plaintext + signature) → decrypt the signature with the public key to get digest 1
                                           → Hash the plaintext to get digest 2
                                           → if digest 1 == digest 2, verification passes

The role of the message digest: prevent tampering
The role of encrypting the digest: prevent repudiation (digital signature)

7.2 Third-party authentication

Kerberos’s mechanism against replay attacks: timestamps

7.3 Common network attacks

7.4 Five levels of information security

Level 1  Discretionary protection
Level 2  System audit protection
Level 3  Security label protection
Level 4  Structured protection
Level 5  Access verification protection (highest)

7.5 Highest level of disaster recovery

• Zero data loss (RPO=0)
• Automatic system failover (RTO≈0)

8. Project Management

8.1 Project time management

PERT expected-time formula:

Gantt chart vs PERT chart:

• Gantt chart: shows task scheduling and progress, intuitive but doesn’t show dependencies
• PERT chart: shows task dependencies and the critical path, can compute earliest/latest finish times

8.2 WBS (Work Breakdown Structure)

Project
├── Phase 1
│   ├── Work package 1.1
│   └── Work package 1.2
├── Phase 2
│   ├── Work package 2.1
│   └── Work package 2.2
└── Phase 3

Tool used for activity definition: WBS

8.3 Configuration management

Three states of a configuration item:

Draft → formally released → under modification

Four configuration-management activities:

• Version control
• Change management
• Configuration status management
• Access and security control

8.4 Requirements management

Change Control Board: CCB

Requirements-change management process:

1. Problem analysis and change description
2. Change analysis and cost estimation
3. Change implementation

Three basic requirements-management activities:

1. Change control
2. Version control
3. Requirements traceability

Appendix: Quick Memory of High-Frequency Points

Summary of core mnemonics

CMMI five levels: Initial, Repeatable, Defined, Managed, Optimizing

Coupling low→high: no-direct, data, stamp, control, external, common, content

Cohesion low→high: coincidental, logical, temporal, procedural, communicational, sequential, functional

Normal forms:
  1NF = atomic, 2NF = full dependency, 3NF = no transitive, 4NF = no multi-valued

Guide to choosing an architectural style

Java-backend-related exam points