读《Applying UML and patterns》第三版

最近结合公司的项目，在读《Applying UML and patterns》第三版一书，该书是OOAD中经典巨著之一，现在读到第32章，感觉确实和一般的书不同。这本书是以软件过程UP为主线来介绍各个阶段中的OO分析和设计。该书不同于专门介绍UP的书，书中向UP中加入了Agile的思想，使得UP在实践中更容易操作；该书也不同于介绍UML语法的书，而是融入了OOAD的思想。
书中描述了UP中的四个软件开发阶段，分别是Inception、Elaberation、Construction和Transition，其中主要介绍了前两个阶段。
在Inception阶段，主要是对项目的需求有一个大致的了解，知道哪些用例是重要的，需要在Elaberation阶段细化的。搞清楚这些关键用例，能够降低软件风险。在该阶段主要是开始写Use-Case Model，Vision，Supplementary Specification，Glossary。该阶段完成的是影响整个软件架构的Use-Case描述和主要用例的主场景的描述，这些用例大概占整个项目的10%左右，其他用例只是大致描述一下即可。

在Elaberation阶段，一般需要多次迭代才能度过该阶段。在此阶段中，要对Inception所定义的关键用例进行设计、实现和测试；对其他用例来说，不断的细化这些用例，但不进行设计与实现。因此该阶段对于关键用例来说，形成的是Domain Model，这是OO分析的产物，而形成的Design Model、SW Architecture Document、Data Model等是OO设计的产物。对于其他用例来说，补充Inception阶段形成的几个文档。
在Construction阶段主要是对所有用例的实现，在Transition阶段主要是对项目的测试和部署。当然每个阶段都有分析、设计、编码和测试，正是体现了迭代开发的过程。而该书中侧重的是OOAD，因此对后两个阶段的介绍一带而过。

该书中强调的是“add Value”，即加入能够对项目有价值的文字。就是说不要求一次迭代就能够产生完整的、正确的文档，而是要在不断的迭代过程中，对这些分析和设计文档进行补充，而补充的文字是对项目有价值的。那些为追求文档完美、完整的而对分析和设计没有价值的文字不能加入分析和设计文档中。

该书中给出的一些Tips很有启发意义。例如：

在分析阶段，为什么描述Actor和用例之间的关系？
因为如果Actor是人的话，那么可以通过参与该项目的人，来找到真正的需求。别太过于注重这些人所描述的关于UI方面的需求，某个人需要一个登录界面，描述界面要有什么东西，那么他关心的可能不是登录界面，而是身份认证。现在他可能不知道指纹识别是一个可以用于身份鉴别的方法，所以当你写好这个程序后，才发现他想要先进的指纹识别来做这个项目。因此要善于发现the root goal of the goal。
如果这个角色是系统，那么可以清晰的描述出系统和系统之间的关系。
该书中对用例的看法是：别太过于注重用例之间的关系，对于用例来说，关键的是用例的文字描述，而不是用例图。用例图的描述是为了给那些不懂计算机设计的人看的。往往有许多开发人员花了很长时间，在讨论用例之间是include、exclude、generation中的哪个关系，这是没必要的。

该书中对于分析和设计的过度很平滑，给我印象比较深刻的是分析阶段的SSD图和设计阶段的Controller模式之间的关系，以及分析阶段的Domain Model的建立和设计阶段的类图之间的关系等。

PS：在公司中，有几个关键用例比较重要，经过一个多星期的讨论，居然发现这些关键用例中的某些步骤是行不通的，如果当时发现不了这些问题，那么风险会很大。下个星期打算和其他部门再次讨论。

 

这本书确实对开发过程有很好的指导意义，对系统分析、系统设计很有帮助，甚至间接地对项目管理也有帮助

居然有第三版啦~~俺家的是第2版的老书

给LZ挑挑问题啊：


这里不同意LZ的理解，书中的意思应该是用例的文字描述更重要，是因为文字能更加清晰、准确地表达用户的需求。而用例图过于简略。用例图的描述不是为了给不懂计算机设计的人看的（用例文字更应该给他们看啊），和用例相关的人都应该看（分析设计开发测试等）。

文章改了一下，“用例图是为了给那些不懂计算机设计的人看的”，这句话表达的不太清楚。这里是说，用例图主要给那些参与需求分析的客户看的，往往他们是不懂得计算机的。简单的用例图，使得他们更容易的参加到需求分析中来，并且有利于找到潜在的需求。

第三版本一直想买，居然发现英文版本第一章居然是中文，不知道出版社干什么的

第三版的第一章是被翻译了，感觉太不对读者负责了。我是在网上下载了英文的原版，然后把第一章打印出来看的。