29、类图演变与软件开发阶段解析

最新推荐文章于 2025-11-10 11:09:30 发布

android

最新推荐文章于 2025-11-10 11:09:30 发布

阅读量46

点赞数

CC 4.0 BY-SA版权

分类专栏：构建阶段的最佳实践文章标签：类图演变分析类图设计类图

本文链接：https://blog.youkuaiyun.com/android/article/details/153446368

构建阶段的最佳实践专栏收录该内容

29 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

类图演变与软件开发阶段解析

在软件开发领域，类图是一种强大的工具，用于可视化和理解软件系统的结构。类图主要分为分析类图、设计类图和实现类图，它们各自聚焦于不同的问题。理解这三种类型类图的差异，对于开发者来说至关重要。

三种类型类图的区别

分析类图 ：展示了必须构建的内容，重点在于描述系统需要实现的功能，而不涉及具体的实现方式。在面向对象分析阶段，通常只关注类的行为，而将属性的定义留到设计阶段。
设计类图 ：展示了如何构建软件，涉及到类的具体设计，包括类的属性、方法以及它们之间的关系。
实现类图 ：精确展示了软件的实际构建方式，包含了实现所需的详细信息。

以银行系统为例的类图演变

我们以虚构的美国卡尔达西亚执政官银行（ABC）的账户和货币类为例，详细说明这三种类型类图的演变过程。

分析类图

分析类图通常不分配属性给类，这是因为在分析阶段，我们的目标是描述需要构建的内容，而不是如何构建。例如，在ABC银行的账户分析类图中，类最初没有属性，只关注类的行为。

然而，如果在分析类图中包含属性，就可能会过早地做出设计决策。例如，在一个替代的分析类图中，为账户类分配了余额属性，并确定了其类型为Float。但这种做法存在问题，因为它不仅涉及了设计层面的决策，还对实现语言做出了假设。如果选择了无类型语言（如Smalltalk），这种做法就会成为一个大错误。因此，在分析阶段识别属性的做法是值得商榷的。

设计类图

设计类图展示了如何将分析类图中的类进行规范化和重构。在ABC银行系统的设计类图中，最初的两个分析类被规范化和重构为四个设计类（不包括PersistentObject类）。PersistentObject类使得其子类的实例能够保存到持久化机制（如关系数据库或文件）中。

在设计类图中，还需要考虑类之间的关联关系。例如，账户和货币之间的关联是单向的，即账户实例知道对应的货币对象，但货币对象不知道与之关联的账户对象。这是因为没有要求货币对象了解账户对象，也不存在合理的场景需要它们这样做。

此外，设计类图还对方法进行了优化。例如，convertTo()方法取代了分析模型中的convertToUS()和convertFromUS()方法，通过接受一个CurrencyType对象作为额外参数，提供了更通用的解决方案。同时，convertTo()方法现在返回完整的Currency实例，而不仅仅是浮点数，采用了更面向对象的方法。

设计类图还遵循了Peter Coad的“Item - Item Description”模式，将CurrencyType分离出来，负责维护汇率和货币名称。这样，当汇率发生变化时，只需要更新一个对象，而不是为每个使用该货币的账户更新。

在设计类图中，属性的访问器方法（getters和setters）也有其独特的设计。通常，所有访问器方法都设为公共的做法是一个常见的错误，因为这会削弱它们的信息隐藏优势。这里采用了setAttributeName和getAttributeName的命名标准，对于布尔类型的getter方法，使用isAttributeName的格式。

另外，在USCurrencyType类中使用了单例模式。由于ABC银行选择美元作为基础货币，该类封装了一些独特的属性。例如，getExchangeRate()方法始终返回1.0，setExchangeRate()方法无需执行任何操作；isUSCurrency()方法始终返回true；getName()方法返回字符串“U.S. dollars”，setName()方法不做任何操作。这些小的性能优化在大多数账户使用美元的情况下会积累起来，提高系统的整体性能。

UML支持的属性和方法的可见性有三种级别，如下表所示：
| 可见性 | UML符号 | 描述 |
| ---- | ---- | ---- |
| 公共 | + | 属性或方法可被应用程序内的所有对象访问 |
| 受保护 | # | 属性或方法仅可被定义该属性或方法的类的实例或其子类访问 |
| 私有 | - | 属性或方法仅可被定义该属性或方法的类的实例访问，子类不可访问 |

mermaid格式流程图展示从分析类图到设计类图的演变过程：

graph LR
    A[分析类图] --> B[规范化和重构]
    B --> C[设计类图]
    A -->|不分配属性| D[专注行为]
    C -->|关联关系| E[单向关联]
    C -->|方法优化| F[convertTo()方法]
    C -->|模式应用| G[Item - Item Description模式]
    C -->|访问器方法设计| H[getters和setters]
    C -->|单例模式| I[USCurrencyType类]

实现类图

实现类图展示了设计类图中未详细描述的细节。在ABC银行系统的实现类图中，添加了维护类之间关联所需的属性和方法，包括相应的getters和setters。

如果需要支持多对一或多对多关系，会添加集合来存储对“多个”对象的引用，并提供相应的方法来添加和移除对象。例如，客户对象有多个账户对象，因此会为客户类添加一个名为accounts的集合属性，以及addAccount()和removeAccount()方法来维护这种关联。这种方法的优点是实现完全封装，未来可以修改实现方式（如将账户实现为链表而不是数组），而不用担心对其他代码部分产生有害影响。

此外，在Currency类中添加了方便属性USCurrency，用于判断CurrencyType是否为美元。这可以提高货币转换方法的性能。如果账户是美元账户，转换到其他货币只需要进行一次转换；如果不是美元账户，则需要进行两次转换。例如，将加元账户转换为巴西雷亚尔账户，需要先将加元金额转换为美元，再转换为巴西雷亚尔。

实现类图的关键操作步骤如下：
1. 添加维护类之间关联的属性和方法。
2. 对于多对一或多对多关系，添加集合属性和相应的操作方法。
3. 添加方便属性以优化性能。

mermaid格式流程图展示从设计类图到实现类图的演变过程：

graph LR
    C[设计类图] --> J[添加关联属性和方法]
    J --> K[处理多对多关系]
    K -->|添加集合属性| L[accounts集合]
    K -->|添加操作方法| M[addAccount()和removeAccount()]
    J -->|添加方便属性| N[USCurrency属性]
    J --> O[实现类图]

软件开发阶段的关键要点

在软件开发过程中，除了类图的演变，还需要关注不同阶段的目标和要求。

软件配置管理

软件配置管理问题对于项目的成功至关重要。在开发过程中，需要对模型进行版本控制，以确保项目的可追溯性和稳定性。

理解不同类型类图的差异

理解分析、设计和实现类图之间的差异非常重要，因为它们关注的问题不同。在软件开发过程中，需要根据不同的阶段选择合适的类图进行设计和开发。

迭代开发与CASE工具

虽然很多CASE工具声称支持面向对象开发，但实际上很少有工具能够真正满足迭代开发的需求。在迭代开发过程中，模型会不断变化，因此需要能够自动将更改传播到其他类型类图的工具。迭代开发要求开发者和工具制造商具备不同的思维方式，即工作在软件开发过程中不断演变，而不是简单地将工作传递到下一个开发阶段。

软件开发的阶段目标

软件开发通常包括构建、过渡和生产三个阶段，每个阶段都有其特定的目标和要求。

构建阶段

构建阶段的目标是创建一个可以过渡到用户社区的应用程序版本。为了进入过渡阶段，必须通过初始运营能力（IOC）里程碑。要通过这个里程碑，需要满足以下条件：
1. 稳定性 ：产品发布应该足够稳定和成熟，能够发布给用户社区。这意味着软件已经经过内部测试，适用的文档已经编写并初步审查，安装过程已经开发并内部测试。
2. 利益相关者准备就绪 ：项目的利益相关者必须准备好将应用程序过渡到用户社区。利益相关者包括直接用户、高级管理层、用户管理层、项目团队、组织的架构团队，甚至可能包括运营和支持管理层。
3. 决策继续 ：在构建阶段结束时，需要做出继续进入过渡阶段的决策。这通常需要比较实际支出与预期支出，以评估估算的准确性。如果之前阶段的估算偏差为x%，则应假设过渡阶段的估算也会偏差x%。实际工作的结果也会指示是否应该继续（例如，如果应用程序无法正常工作，则可能不应部署）。最后，需要评估组织在系统投入生产后是否能够运营该系统。

过渡阶段

过渡阶段的重点是对系统进行测试、后续返工和部署，目的是将系统投入生产。

生产阶段

生产阶段是系统运行和支持的阶段，通常在开发新版本的同时进行。

软件开发、运营和支持是一项复杂的工作，需要优秀的人员、良好的工具、优秀的架构和良好的流程才能取得成功。采用适合组织的最佳实践是提高组织软件生产力的重要一步。现在是从过去的经验中学习，选择成功的时候了。

综上所述，通过对银行系统类图演变的详细分析，我们可以看到不同类型类图在软件开发过程中的重要作用。同时，了解软件开发各阶段的目标和要求，对于确保项目的成功至关重要。开发者需要根据不同阶段的需求，灵活运用各种工具和方法，不断优化软件设计和实现，以提高软件的质量和性能。

类图演变与软件开发阶段解析

软件开发失败率与改进方向

在软件开发行业，存在一个令人担忧的现状：大约 85% 的项目会失败，这意味着成功率仅为 15%。多年来，我们早已熟知软件开发过程的基本原理，像 Fred Brooks 的《人月神话》（1995 年出版，最初于 20 世纪 70 年代中期问世）这类经典著作就有相关阐述。然而，整个行业往往忽视这些基本原理，转而追求那些看似能解决所有复杂问题的华丽新技术，最终导致了如此高的失败率。此外，诸如 Y2K 危机这样的尴尬事件，也清晰地表明我们必须改变现有的开发方式。

如今，各组织应该做出选择，追求成功，采用在实践中被证明有效的技术和方法，遵循成熟的软件过程。以下是一些具体的改进方向：
1. 遵循成熟方法 ：选择经过实践检验的软件开发方法和技术，避免盲目跟风新技术。
2. 重视基础原理 ：回归软件开发的基本原理，确保项目在坚实的基础上进行。
3. 建立质量保障体系 ：在开发过程中建立严格的质量保障体系，确保软件的稳定性和可靠性。

过渡阶段和生产阶段的详细要求

过渡阶段的准备要求

从构建阶段进入过渡阶段，需要通过初始运营能力（IOC）里程碑，具体要求如下表所示：
| 要求 | 详细说明 |
| ---- | ---- |
| 稳定性 | 软件需经过内部测试，相关文档编写并初步审查，安装过程开发并内部测试，确保产品发布稳定成熟，可交付给用户社区 |
| 利益相关者准备就绪 | 包括直接用户、高级管理层、用户管理层、项目团队、组织架构团队、运营和支持管理层等在内的利益相关者，都要做好将应用程序过渡到用户社区的准备 |
| 决策继续 | 比较实际支出与预期支出，评估估算准确性；根据实际工作结果判断是否继续；评估组织在系统生产阶段的运营能力 |

mermaid格式流程图展示进入过渡阶段的流程：

graph LR
    P[构建阶段] --> Q{是否通过IOC里程碑}
    Q -->|是| R[过渡阶段]
    Q -->|否| S[继续改进]
    P -->|满足稳定性要求| T[内部测试完成]
    P -->|利益相关者准备好| U[各方达成共识]
    P -->|决策继续| V[评估支出和运营能力]

过渡阶段的工作重点

过渡阶段主要聚焦于系统的测试、后续返工和部署，以实现将系统投入生产的目标。具体工作步骤如下：
1. 系统测试 ：对系统进行全面测试，包括功能测试、性能测试、安全测试等，确保系统满足用户需求。
2. 后续返工 ：根据测试结果，对系统进行修改和优化，解决发现的问题。
3. 系统部署 ：将经过测试和返工的系统部署到生产环境中，确保系统能够正常运行。