用例和方面的应用案例(1)

本人将在去年10月在西安程序员聚会上讲座内容整理出来，供大家参考和讨论

 

第一讲：用例和方面的应用案例 Part 1  The Application Case of  Use-case and Aspect 本讲座分为4个部分: 要解决的问题使用方面解决问题现在用例技术未来用例技术

引言：

软件开发为什么这么难?大家能列举多少?Key--太多的事情需要密切关注 A、从人和成本的角度，你不得不关注时间、预算、资源、技能等问题



Solution1：迭代开发，加上我们对RUP、CMMI、XP、PMP裁剪

 


B、作为一个需求分析人员，对如何有效的标识、组织、管理用户的需求感到十分困惑，冗长的“需求分析”并不能起到它该起的作用，更谈不上使用户和开发团队之间建立更好的需求沟通

 Solution2：用例驱动

1）使我们站在“用户的视觉”来观察“将要开发的系统” 2）通过对零散的需求进行合并； 3）抽象出参与系统的不同参与者（Actor） 4）将一系列的使用场景抽象形成“用例”从而勾勒出系统的框架模型

 


 

 




C、做为开发团队中的一员，你的直接boss经常会指派你承担比自己所能承担的还要多的任务，你可能要付出200%的努力。

D、作为一个开发人员，你必须理解应用、领域知识、以及平台的特性。

E、当你设计系统时，必须处理和平衡许多困难的关注点：系统如何达到其预期的功能、如何达到性能和可靠性的要求，如何处理平台的特性等。

F、你在编写类、操作的代码时，发现程序必须实现更多的内容，便导致出空心粉式的代码。

G、无论你作什么，都会发现系统中很多地方需要完成日志、验证、留存、除错、跟踪、分布式、异常处理等方面任务的代码段。

Solution3：需要来改进我们的设计，使其更模块化，更好的对关注点进行分离。AOP（面向方面编程）

H、如果你是一个设计师，一直对UML中从“用例描述”到“顺序图”、“活动图”的转换感到力不从心。

Solution4：UML抛弃的“Robustness分析方法”，通过控制类、边界类，以及简明随意的Robustness图让这种转换变得更“Streamline（流线型）” I、当你在实际系统分析和设计实践中，你突然发现类、组件与用例之间的对应关系是交错的：一个用例涉及到很多类和组件，一个类和组件同时有参与到多个用例，我们在用例上实现了“松耦合”，但是具体到类、实现的环节又再次“耦合”在一起。

Solution5：使用一种用例技术：“用例切片”进行分离，并把“用例切片”的实现代码分离出来，并模块化成组件，同时提供一种组合机制，使得在编译时甚至在运行时将这些组件组合到预期的操作和类中去，从而使我们的设计变得更加顺畅，易于理解和维护。

 通过对以上问题的解决,形成Aspect-Oriented Programming  Extension Software Development( AOPESD)技术

那么AOPESD是什么?

1、是以上solution1-5的合理组合

2、使我们的系统更好的模块化

3、从需求到分析和设计、实现和测试全过程的面向方面软件开发的整体方案

4、与CMMI、XP、RUP、PMP裁剪形成的项目管理和研发管理配合，形成一套完整的软件开发及管理的系统方案

5、AOPESD不仅仅是AOP，它包括帮助你实现更好的模块化的一系列技术，它包括面向对象、基于组件的开发（如JavaEE,.NET等之类的组件框架技术）、设计模等,它不是一种与现有技术竞争的技术，而是基于这些技术的改进提高

 

一、要解决的问题
 
大家都知道,软件变的越来越复杂.
 
那么怎么办呢？第一个任务是“解决软件复杂性”问题，我们可以把系统分解成一个个小的部分，并每次解决其中的一部分 这样就形成了“模块化思想”，因为“模块化思想”便形成了各种各样的“对象和组件技术”，现在的软件开发者们已经实践了各种不同的模块性技术。
 
作为现在一个框架师，大家必须清楚OO技术，那么你们能否非常熟练的使用以下知识内容？如果不能，那么，你是无法设计出一个称为“软件”项目的，而且，就算很熟练，你的项目一样很糟糕，因为它没有办法去扩展，一个需求的改动都会让你很恼火，甚至到崩溃。那么这些内容是以下东西：
需要支持多平台：Windows,Linux,Unix
SOA、ESB—连接组件拥有大量组件
重用、MDA—快速、廉价集成组件
响应日益复杂的业务操作：EA（连通软件与业务的鸿沟）、PLE（处理产品线可变性）、反向工程（重用遗留系统）框架：J2EE、.NET等独立与厂商的组件描述语言--UML

那么，怎么使用组件构建一个系统：我在CMU的CMMI小组的一些标准流程给大家：

step1、 理解系统需要实现什么？客户关注点是什么？需求是什么？

step2、 探究和标识组成系统的子部分（或称为组件）

step3、 完成需求域于组件域的映射（需求域远远大于组件域 ）

step4、 标识一组与需求相符的候选组件

step5、  检查另外部分现有组件与需求匹配性，修改需求满足现有组件（需求的功能与性能对系统影响小，但必须说服客户）

step6、再依次修改剩余组件与需求匹配

step7、 再开发自己不拥有的组件与客户需求匹配（与客户直接交互的组件，您的成本就很低）

•

step8、 需求的组件都已经找到，将他们连接在一起就可以获得预期的系统.
理论是这样的，但是我们同样需要付出很高额的成本去设计这个系统。

以一个酒店管理系统-HMS为例，该系统提供了客户和酒店员工所需使用的房间预定、登记入住、结帐离店等功能  ，如下图，



看看我们设计这个简单系统复杂性吧：







那么大家看出设计这个简单系统复杂性了？可以指出它的缺点，留言给我，解决复杂性问题，后续文章将给出！谢谢大家！