构建正确系统：从需求到实现的全面指南

# 构建正确系统：从需求到实现的全面指南 ## 1. 构建系统的挑战与方法 在开发系统时，从解决方案的定义到最终构建出满足利益相关者需求的系统，这一步是最具挑战性的，并且会消耗大量的资源。很多项目在快速从需求进入开发阶段后，看似进展顺利，但最终客户却未能得到期望的系统。为避免这种情况，我们需要一种逻辑清晰、循序渐进的方法，从理解需求到设计并实现满足这些需求的系统，确保“正确地构建正确的系统”。 同时，随着时间推移，开发项目难免会面临需求变更。我们需要探究需求变更的来源和影响，并讨论如何应对和控制变更，使项目保持在正确的轨道上。 ## 2. 从用例到实现的问题与解决方案 ### 2.1 需求映射设计与代码的情况 部分需求可以较为容易地从设计映射到代码实现。例如，“支持最多八位浮点输入参数”或“向用户显示编译进度”这类需求，在代码中查找、检查和验证实现这些需求的代码相对直接。这种情况下，需求与实现代码有合理的相关性，我们可以使用需求到模块的测试方法对大部分代码进行测试。 ### 2.2 正交性问题 然而，有些需求与设计和实现的相关性较低，存在正交性问题。比如“系统每小时应处理多达100,000笔交易”或“用户可以根据系统管理员设置的用户权限编辑每个突出显示的字段”这类需求，需求形式与设计和实现形式不同，难以进行一对一映射。具体原因如下： - **语言差异**：需求描述的是现实世界的事物，如引擎和薪水支票，而代码使用的是栈、队列和计算算法等概念，两者是不同的语言。 - **性能需求**：某些需求，如性能需求，与代码的逻辑结构关系不大，而与过程结构、代码交互方式、运行速度等有关，难以在实现中找到对应的逻辑结构。 - **功能分布**：一些功能需求需要多个系统元素交互才能实现，需求的实现可能分散在整个代码中，查看部分代码无法了解整体情况。 - **设计优化**：良好的系统设计并非以优化需求验证的便利性为驱动，而是考虑更重要的因素，如优化稀缺资源的使用、复用已验证的架构模式、复用代码或应用购买的组件等。 ### 2.3 面向对象技术的作用 面向对象（OO）技术在很大程度上改善了正交性问题。通过应用OO概念，我们构建的代码实体更符合问题领域，提高了系统的健壮性。这不仅得益于OO的抽象、信息隐藏、继承等原则，还因为现实世界实体的变化频率低于交易和数据，使得代码变更也相应减少。例如，40年来人们一直领取薪水支票，但支付形式从纸质变为电子形式。 然而，即使使用OO技术，也不能完全消除与需求的正交性。因为OO技术的基本原理是描述满足系统关键需求的少量机制，形成一组协作的类，产生比各部分之和更大的行为，并非需求与代码的一对一映射。 ### 2.4 用例作为需求的优势 需求的“逐项”性质会加剧正交性问题，单个需求难以让我们从整体上查看系统行为是否正确。用例通过提供系统与用户之间的一系列操作，而不是单个逐项需求，显著改善了这个问题。用例能更好地描述系统按顺序执行的行为，包括替代方案和异常情况，还能为设计过程提供起点。例如： - 客户插入ATM卡。 - 系统提示输入PIN码。 - 客户输入PIN码。 ### 2.5 管理过渡 虽然OO方法和用例不能完全解决正交性问题，但我们可以利用现有的资源和新技术来应对。通过增加需求与代码之间的相似性，我们可以更合理地根据需求驱动系统设计，更轻松地在不同领域之间进行转换，提高系统设计和整体质量。在这之前，我们需要了解系统建模和软件架构的相关知识。 ## 3. 软件系统建模 ### 3.1 建模的必要性 如今的非平凡软件系统极其复杂，包含数百万行代码，且可能嵌入其他复杂系统，存在复杂的交互。没有人或团队能完全理解每个系统的细节和交互。因此，将系统抽象为简化模型是一种有用的技术，它可以去除系统的细节，让我们以更易理解的方式看待系统。 ### 3.2 模型的选择与注意事项 选择合适的模型至关重要。我们希望模型能帮助我们正确理解系统，但要避免因错误或抽象导致的误导。例如，早期以地球为中心的太阳系模型导致了许多错误理论，而以太阳为中心的模型则带来了更好的理解。 模型是推理复杂问题和获取有用见解的强大工具，但我们必须清楚模型并非现实，要不断检查确保模型没有误导我们。例如，早期的太阳系模型虽然为科学家提供了推理和提出数学理论的基础，但与实际观测结果并不完全匹配，爱因斯坦相对论的早期验证就体现在水星轨道的异常现象上。 ### 3.3 系统多方面建模 系统的许多方面都可以建模，如应用程序并发、系统逻辑结构等。这些模型之间的交互也可以建模，它们共同帮助我们从整体上理解系统架构。 ## 4. 软件系统架构 ### 4.1 软