下载掌阅APP，畅读海量书库
立即打开
有经验的分析员和建模者了解以下这条建模的秘诀：
建模（构建UML草图……）的目的主要是为理解，而非文档。
也就是说，建模的真正行为能够并且是应该能够对理解问题或解决方案空间提供更好的方式。从这个角度而言，“实行UML”（其真正含义为“实行OOA/D”）的目的并不是指设计者创建大量详细的UML图并递交给编程者（这其实是非敏捷的和面向瀑布的思维方式），而是指为良好的OO设计快速探索可选的方案和途径。
在“Agile Modeling”[Ambler02]一书中，将这种观点及与之一致的敏捷方法称为敏捷建模（agile modeling）。这其中包含了以下许多实践和价值：
·采用敏捷方法并不意味着不进行任何建模，这是个错误理解。Feature-Driven Development、DSDM和Scrum等许多敏捷方法，一般都包含重要的建模期。正如Ambler（XP方法和敏捷建模的专家）所言，即便是XP（可能是最少强调建模的最为知名的敏捷方法）的奠基人也认可敏捷建模，并且多年来有大量建模者都在实践中采用了敏捷建模。
·建模和模型的目的主要用于理解和沟通，而不是构建文档。
·不要对所有或大多数软件设计建模或应用UML。可以将简单的设计问题推延到编程阶段，在编程和测试过程中解决这些问题。只需对设计空间中不常见、困难和棘手的一小部分问题建模和应用UML。
·尽可能使用最简单的工具。建议使用支持快速输入和改变的“低能耗”创造力增强型的简易工具。同时，选择支持大可视空间的工具。例如，最好在白板上草画UML，使用数码相机捕获图形。
·这里并不是说UML CASE工具或字处理软件不可取或毫无价值，但是对于创造性工作来说，在白板上画草图更为流畅并便于修改。关键的规则是简单和敏捷，而不论使用何种技术。
·不要单独建模，而是结对（或三个人）在白板上建模，同时要记住建模的目的是发现、理解和共享大家的理解。小组成员要轮流画草图，以使每个人都参与其中。
·并行地创建模型。例如，在一块白板上勾勒UML动态视图的交互图，同时在另一白板上勾画补充性的UML静态视图的类图。同时开发这两种模型（视图），并不断交替。
·在白板上用笔画草图时，应使用“足够好”的简单表示法。UML细节是否精准并不重要，关键是建模者能够互相理解。坚持使用简单、常用的UML元素。
·要知道所有模型都可能是不准确的，最终代码或设计会与模型有差异，甚至具有极大的差异。只有测试过的代码才能证实真正的设计；先前绘制的模型图都是不完整的，最好只是将其视为一次探索。
·开发者应该为自己进行OO设计建模，而不是创建模型图后交给其他编程者去实现——这是非敏捷的面向瀑布的方法。
在白板上通过绘制UML草图来建模是我（和众多开发者）多年来所热衷的方式。然而，本书中大多数UML图给人的印象并非如此，因为这些图是为了提高可读性而使用工具精心绘制的。为了让大家感受真实的情况，本书有时会使用在白板绘制的UML草图的数码快照。这样虽然易读性差一些，但是可以提醒读者敏捷建模是很有用的，并且这种方式是案例研究所使用的实际工作方式。
例如，图2-5是我所指导的项目中创建的一个未编辑过的UML草图。绘制这幅图花了20分钟，并且周围有四个开发人员参与其中。我们目的是理解系统内部的协作。这种一起绘图的方式为参与者提出自己的观点和达到一致的理解提供了环境。通过该图可以感受一下敏捷建模者是如何应用UML的。