研讨课汇报

研讨课汇报

1. 谈一谈在第十三次作业绘制 UML 类图过程中是如何表达自己的设计的（例如如何选择关联关系）？有没有遇到什么设计或 StarUML 使用中的困难？遇到的问题后来又是如何解决的？

主要讨论了困难。

1. 内联在book里面的枚举类，在别的类中的使用无法被检测，只能单独提取出来。
2. 若是先进行UML架构设计，可能会出现：

• 架构的时候很模糊，架构与实现分离。
• 设计了一些没有必要的类或者方法（因为没有进行实际编程不好判断一个类的存在价值）

2. 有的人认为系统架构设计与当下流行的敏捷开发是矛盾的。如何理解二者之间的关系？

   系统架构设计与敏捷开发之间看似存在矛盾，但实际上二者可以相辅相成，关键在于如何理解和实施这两种方法。下面是对二者关系的详细探讨：

   系统架构设计

   系统架构设计涉及对系统整体结构、组件及其交互方式的规划。主要目的是确保系统的可扩展性、可靠性、安全性和可维护性。传统上，架构设计常常在项目初期进行，目的是在开发之前解决所有潜在的技术难题和设计问题。

   敏捷开发

   敏捷开发是一种迭代和增量的开发方法，强调快速交付、持续反馈和适应变化。其核心理念是通过短周期的迭代（如Scrum中的冲刺），不断交付可工作的软件，并根据反馈进行调整。

   二者之间的关系

   1. 大设计前期（Big Design Up Front, BDUF） vs. 适应性设计
      • BDUF：传统方法往往在项目初期完成详细的架构设计，假设能够预测所有的需求和挑战。然而，这种方法在面对需求和技术快速变化时可能显得僵化。
      • 适应性设计：敏捷开发提倡逐步设计（Emergent Design），即在开发过程中逐步完善系统架构。这种方法强调灵活性和适应性，可以更好地应对变化。
   2. 文档化 vs. 面向功能的实现
      • 文档化：传统的架构设计通常伴随大量的文档，详细记录每个组件和接口。然而，过多的文档可能会拖慢开发速度。
      • 面向功能的实现：敏捷开发重视可工作的软件胜过详尽的文档。

   实践中的平衡

   1. 最小可行架构（Minimum Viable Architecture, MVA）：在项目初期设计出一个最小可行架构，既能支持早期开发需求，又具有足够的灵活性以适应未来的变化。
   2. 架构Spikes：在当今的快速变化的社会中，业务需求和技术也都快速变化着，在软件过程前期花费30%（甚至更多）的时间进行架构设计，要么开发出来的软件不符合市场需求，要么就是一旦需求变动，造成较大的改动成本。在敏捷冲刺中安排专门的时间（spikes）来探索和验证架构决策，确保在不影响整体进度的情况下处理复杂的架构问题。