Software Architecture Design: Modeling with UML and Key Design Practices

Preliminary Thinking

Many developers aspire to become architects; imagine being assigned architecture work at the early stage of a project. How should you start, present your results, verify that the design meets user needs, ensure the final software satisfies requirements, and help every engineer understand their responsibilities?

How to carry out the work?

How to express the outcomes?

How to confirm the design satisfies user requirements?

How to guarantee the delivered software meets the specifications?

How to make every team member clear about their scope and work efficiently?

How to perform software design?

What are the deliverables of software design?

How to communicate during software upgrades?

How to satisfy functional, non‑functional, and cost requirements simultaneously?

How to enable developers, testers, and operations engineers to understand the overall architecture, module boundaries, key technologies, and core domain models so that the development process stays controllable and the future blueprint is clear?

Core Key Points

Two Objective Existences

The solution to these questions lies in two objective entities: software modeling (the abstract model of the software) and textual description , which together form the design documentation.

One objective existence is the domain problem we need to solve—for example, an e‑commerce site must handle product management, order processing, user shopping, payment, etc. Abstracting these gives us functional entities, relationships, and business processes.

The other objective existence is the software system that will be built. The software system itself is also an objective entity.

What are the main components of the software?

How are these classes organized into components?

What are the dependencies among core components?

How many servers are needed at runtime and how are they invoked?

How do servers communicate?

These two objective existences are abstracted into a software model. Analyzing and abstracting the domain problem and the software system constitutes software modeling and design , which then drives the implementation process.

UML Tools

Many modeling tools exist, the most common being the Unified Modeling Language (UML). Modeling means abstractly designing both the domain problem and the software system, and a single tool can cover both objective entities.

UML serves two purposes: communication among stakeholders during the design phase, and personal thinking support when no external communication is needed.

UML also has dialects; different teams may adopt slight variations as long as they avoid ambiguity.

7 Software Models

The software modeling and design process can be divided into requirement analysis, high‑level design, and detailed design. The main UML artifacts are:

Class Diagram

Class diagrams describe static relationships among classes (name, attributes, methods) and include six relationship types: association, dependency, aggregation, composition, inheritance, and generalization. They are mainly used in detailed design, but simplified versions can also appear in requirement analysis.

Sequence Diagram

Sequence diagrams show dynamic interactions among participants via lifelines and messages, useful for describing object or component interactions at any design stage.

Component Diagram

Component diagrams model larger design elements (packages, JARs, DLLs) and their static dependencies. They can also be extended with component‑sequence diagrams to show dynamic calls.

Deployment Diagram

Deployment diagrams depict the final physical deployment: number of servers, placement of key components, and relationships with existing or third‑party systems. They are created early (high‑level design) to reach consensus among stakeholders and to estimate hardware costs.

Use‑Case Diagram

Use‑case diagrams capture functional requirements by showing actors (people or external systems) and the system’s use cases, often accompanied by textual descriptions.

State Diagram

State diagrams illustrate the lifecycle of a single object, describing possible states and transitions (e.g., account states: created, active, frozen, delinquent). They help avoid inconsistencies in complex domain objects.

Activity Diagram

Activity diagrams describe process logic and business flows, similar to flowcharts, using start/end circles, rounded rectangles for activities, diamonds for decisions, and swimlanes to separate responsibilities.

Summary

Model diagrams themselves are simple to learn, but the challenge lies in selecting the right UML model for the right scenario, producing a coherent set of software models, and turning them into a design document that guides development and aligns the team.

Requirement Analysis

Use case diagrams for functional description, activity diagrams for key business processes, and simplified class diagrams for core domain objects. State diagrams are added for objects with complex lifecycles.

High‑Level Design

Deployment diagrams show the physical blueprint; component diagrams and component‑sequence diagrams define major modules and their interactions; component activity diagrams describe module‑level workflows.

Detailed Design

Class diagrams and class‑level sequence diagrams become the primary artifacts, with activity diagrams for complex method logic. Tools range from heavyweight (e.g., Enterprise Architect) to free online options (e.g., ProcessOn).