Software Design and Modeling: Key Concepts, UML Diagrams, and Design Process

Preliminary Thinking

Many software developers aspire to become architects; imagine being assigned architecture design before project development. Questions include how to start the work, how to present the results, how to verify that the design meets user needs, whether the final software will satisfy requirements, and how to ensure every engineer understands their responsibilities.

Core Key Points

Two Objective Existences

The solution is software modeling: an abstract model of the software combined with textual description forms the design document. There are two objective existences in software development:

The domain problem to be solved (e.g., e‑commerce business processes, product management, order handling, payment, etc.).

The final software system that will be built.

From these, we derive the software model, which includes questions about main components, component organization, dependencies, runtime deployment, and server communication.

UML Tools

UML (Unified Modeling Language) is the most common modeling language. It serves both communication among stakeholders and personal design thinking. Different teams may adopt their own dialects as long as they avoid ambiguity.

7 Types of Software Models

The following seven UML diagram types are used in the three design phases (requirement analysis, conceptual design, detailed design).

Class Diagram

Class diagrams describe static relationships among classes, showing class name, attributes, and methods. Six static relationships are represented: association, dependency, aggregation, composition, inheritance, and generalization. They are mainly used in detailed design, while simplified versions appear in requirement analysis.

Sequence Diagram

Sequence diagrams depict dynamic interactions between objects or components, using lifelines and messages to show the order of calls. They can be applied at any design stage to illustrate object or component interactions.

Component Diagram

Component diagrams model larger design elements (logical or physical components such as JARs, DLLs). They mainly show static dependencies; dynamic interactions can be expressed with component sequence diagrams. They are useful early for module design.

Deployment Diagram

Deployment diagrams illustrate the final physical deployment: number of servers, placement of key components, and communication between servers. They are created in the conceptual design stage to discuss architecture feasibility and cost.

Use‑Case Diagram

Use‑case diagrams capture functional requirements by showing actors (people or external systems) and their interactions with the software. They are usually accompanied by textual descriptions to form a requirements document.

State Diagram

State diagrams describe the lifecycle states of a single object and the transitions between them, useful for domain objects with complex state changes such as orders, accounts, or coupons.

Activity Diagram

Activity diagrams model process logic and business workflows, similar to flowcharts. They use start/end circles, rounded rectangles for actions, diamonds for decisions, and swimlanes to separate responsibilities.

Summary

Model diagrams are easy to learn, but the difficulty lies in selecting the appropriate UML model for the right scenario, thereby producing a coherent software model that guides development and aligns the team.

We reorganize software design stages and recommend suitable models:

Requirement Analysis: Use‑case diagrams for functionality, activity diagrams for key processes, sequence diagrams for integration, simplified class diagrams for core domain objects, and state diagrams for objects with complex states.

Conceptual Design: Deployment diagrams for physical blueprint, component and component‑sequence diagrams for module relationships, component activity diagrams for inter‑component flow.

Detailed Design: Class diagrams and class‑level sequence diagrams as primary outputs; activity diagrams for complex method logic. Tools range from enterprise solutions like EA to free online tools such as ProcessOn.

Requirement Analysis

Use‑case diagrams describe system functions and usage scenarios; activity diagrams illustrate important business flows; sequence diagrams can model interactions with existing subsystems; simplified class diagrams capture core domain objects; state diagrams handle objects with intricate state transitions.

Conceptual Design

Deployment diagrams present the final physical architecture; component diagrams (and component sequence diagrams) define module boundaries and dependencies; component activity diagrams describe the workflow between components.

Detailed Design

Class diagrams and class‑level sequence diagrams are the main deliverables; activity diagrams may be used for complex method logic. Both heavyweight commercial tools (e.g., EA) and lightweight free tools (e.g., ProcessOn) can be employed.

---

Follow the public account and reply "Architecture" or "Architecture Clean" to receive a surprise gift package.

Join the top‑architect community group by adding the editor’s WeChat (mention name, company, and position).

Copyright statement: Content sourced from the internet, copyright belongs to the original author. If any infringement is found, please notify us for immediate removal.