最近结合公司的项目,在读《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:在公司中,有几个关键用例比较重要,经过一个多星期的讨论,居然发现这些关键用例中的某些步骤是行不通的,如果当时发现不了这些问题,那么风险会很大。下个星期打算和其他部门再次讨论。
书中描述了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。
如果这个角色是系统,那么可以清晰的描述出系统和系统之间的关系。
该书中对用例的看法是:别太过于注重用例之间的关系,对于用例来说,关键的是用例的文字描述,而不是用例图。用例图
该书中对于分析和设计的过度很平滑,给我印象比较深刻的是分析阶段的SSD图和设计阶段的Controller模式之间的关系,以及分析阶段的Domain Model的建立和设计阶段的类图之间的关系等。
PS:在公司中,有几个关键用例比较重要,经过一个多星期的讨论,居然发现这些关键用例中的某些步骤是行不通的,如果当时发现不了这些问题,那么风险会很大。下个星期打算和其他部门再次讨论。