Mastering Software Analysis & Design: Logic, Methods, and Real‑World Cases

System Analysis and Design Logical Framework

In everyday development the terms “software analysis” and “software design” are common, yet their essence is hard to grasp because they rely heavily on experience and lack standardized steps. This article clarifies the logical nature of analysis and design, showing that, like writing, they follow underlying principles and methods.

Analysis and design share strong logic; without it, work becomes vague. The article presents a panoramic logical diagram of software analysis and design.

1.1 Method

1.1.1 Analysis Phase

Software analysis and design are not mysterious; fundamentally they aim to solve real problems, similar to a doctor diagnosing a disease or a chef cooking a dish. A method guides the work, and the first step is to define the problem clearly.

Defining the problem is akin to medical tests: without a clear problem definition, choosing middleware or frameworks is misguided.

Requirements analysis focuses on uncovering the true user needs, which are expressed through use cases that describe user goals and viewpoints.

Use cases are high‑level narratives that must be refined into scenarios, each representing an interaction between participant and system (e.g., order success or failure). Analysis aims to understand the current state, goals, and system components without considering implementation.

1.1.2 Design Phase

After knowing what to build, design explores how to implement it. Two concerns arise: how to break down functionality and how to achieve a better implementation. Quantitative evaluation metrics include cost, performance, reliability, and efficiency; qualitative metrics include openness and user experience.

The core of design is identifying the key technical issues: user‑centric design (usability, understandability) and system‑centric design (reusability, extensibility, stability). Good design hides complexity from users while keeping the system flexible.

1.2 Tools

The method is supported by UML diagrams:

Activity Diagram – models business activities and their flow.

Use‑Case Diagram – captures user goals, actors, and results.

Sequence Diagram – shows interactions between users and the system.

Timing Diagram – expresses how a function is realized and checks responsibility distribution.

Class Diagram – describes attributes, responsibilities, and hierarchy.

1.3 Principles

Three core design principles are emphasized: reuse, changeability, and cognitive complexity. Good design embeds these principles to achieve “fast, good, cheap” outcomes.

Reuse reduces cost; changeability supports future extensions; managing cognitive complexity keeps the system understandable from high‑level to low‑level layers.

Two Practical Cases

2.1 Logging Framework

2.1.1 Analysis

Logging records key information to aid troubleshooting. Essential fields include timestamp, class, method, line number, and message.

The conceptual model separates storage destination (Appender) and format (LayoutPattern), with a façade Logger for simple usage.

2.1.2 Design

From the user perspective, the design abstracts storage destination as Appender and format as LayoutPattern , with Logger as the façade. From the system perspective, a LogRecord class captures log details.

The Appender follows a template method: obtain formatted data from LayoutPattern, then write to the target. Performance considerations include file size management, memory‑mapped I/O, and asynchronous writing.

2.2 Task Scheduling Framework

2.2.1 Analysis

Scheduling tasks (e.g., periodic emails) requires executing a job at a specified time. The model includes a Job (execute method), a Trigger (when to run), and a Scheduler façade for submission.

2.2.2 Design

System‑side design introduces a JobQueue storing JobDetail (Job + Trigger). A SchedulerThread scans the queue, executing jobs whose time has arrived. The class diagram is shown below.

Efficient execution relies on suitable data structures: a min‑heap for quick retrieval of the next job, or a time‑wheel (as used by XXL‑Job) for periodic tasks.

Conclusion

Effective technical solution design hinges on identifying key technical problems from both user‑centric and system‑centric perspectives. Whether designing a logging framework or a task scheduler, considerations such as performance impact, algorithm choice, and reuse versus changeability guide the creation of robust, maintainable software.