软件工程课件：面向对象分析.pptxVIP

面向对象分析;

?知识点

分析工作流，分析模型，功能模型，动态模型，建模技术。

?难点

如何将理论与实践结合。

;

?基于工作过程的教学任务

通过本章学习，了解分析工作流；理解分析模型，学习建立分析包、分析类；通过电梯问题实例研究，学习实体类的提取，理解如何提取实体类；掌握分析工作流，学会如何描述分析对象间的交互，如何测试用例；规划分析工作，进行面向对象分析；通过考勤系统实例研究，学习分析工作流，理解分析过程。;

?统一过程的分析工作流有两个目的。从需求工作流的角度来看，分析工作流的目的是更深刻地理解需求；从设计工作流和实现工作流的角度看，分析工作流的目的是进一步描述需求，使设计和实现更易于进行。在分析阶段，项目小组的成员共同努力，理解需求，建立分析模型。分析模型有助于精化需求，并探究系统的内部，包括内部的共享资源。而且，分析模型提供了更强的表达能力和形式化方法，例如交互图，还有助于组织需求，并能提供一种可维护性的结构，便于应对需求变更和重用。

;

9.1分?析?工?作?流

;

(1)用例必须尽量保持彼此独立。这样，就不会陷入到有关用例之间干扰、并发与冲突的细节中，在用例间竞争系统内部共享资源时，经常出现这类情况。例如，“存款”和“取款”用例要访问同一储户的账户。当一个参与者混合使用多个可能产生无法预测行为的用例时，就可能产生冲突。例如，当一个电话用户使用“预置唤醒呼叫”用例后，接着使用“呼入改向”用例去对另一个电话用户进行电话唤醒呼叫。因此，在需求捕获阶段，用例之间的干扰、并发与冲突问题可能没有得到完全解决。

;

(2)必须用客户语言描述用例。这样，在用例说明中就应该主要使用自然语言，但是，仅使用自然语言会大大削弱表达能力。在需求捕获阶段，许多本来可以用更形式化的图符来精确描述的细节问题，可能因此得不到解决，或只能模糊地描述。

(3)每个用例的构造都是为了构成完整且直观的功能规格说明。这样，就需要对用例进行组??以便直观地反映系统“真实”用例。例如，不能为了消除冗余而将用例设计得太小、太抽象或太不直观，尽管能做到，还必须在用例说明的易理解性与可维护性之间进行权衡。因此，需求间的冗余问题可能无法在需求捕获期间解决。

;

由于存在着上述未解决的问题，分析的主要目的就是通过深入分析需求来使问题得以解决，与捕获需求相比，最主要的差别在于可以用开发者的语言来描述。

因此，在分析阶段更多地探究系统内部，从而解决用例间的干扰以及类似的问题(上述第1条)；还可以采用更形式化的语言对系统需求中的细节问题(上述第2条)进行描述，以“精化需求”；另外，可以以易于理解、易于组织、易于修改、易于重用和易于维护的方式来组织需求(上述第3条)。这样，可以按照不同的详细程度跟踪需求的不同描述，并保持彼此间的一致。实际上，在用例模型中的用例和分析模型中的用例实现之间可以互相跟踪，两类模型之间的区别如表9-1所示。

;;

那么，为什么不在设计和实现系统的同时进行需求分析呢？原因还在于：设计与实现远比分析(即精化和组织需求)复杂，需要分开来考虑。在设计与实现阶段，必须构造系统并确定其表现形式(包括构架)，必须对系统如何处理诸如性能和分布等需求做出决定，并回答诸如“如何优化使执行时间不超过5毫秒？”和“如何在网络上部署代码而不会加重网络的通信负载？”等问题，还有很多其他类似的问题需要处理，例如，如何有效地利用数据库和对象请求代理等已有的构件，如何将这些构件集成到系统构架中，以及如何使用程序设计语言等，这里不一一列举可能出现的问题。

;

最初的细化迭代重点在于分析，分析的焦点如图8-5所示，有助于建立稳定的构架，有利于深入理解需求。之后，在细化阶段的末期与构造阶段，构架已经稳定而且需求明确后，重点便应转移到设计与实现上。

;

在分析阶段，项目小组的成员共同努力，理解需求，建立分析模型，相关人员与结果如图9-1所示。分析模型有助于精化需求，并探究系统的内部结构，包括其内部的共享资源。而且，分析模型提供了更强的表达能力和形式化方法，例如交互图。分析模型还有助于组织需求，并提供一种可维护性的结构，例如具有对需求变化的柔性及重用，这种结构不仅益于需求的维护，而且还可以作为设计和实现活动的输入。但是，分析模型是一个抽象的过程，分析模型中提出的结构不可能一直维持下去，需要在设计与实现期间对其进行处理和折衷，因此，应避免去解决某些问题和处理某些需求，最好是推迟到设计和实现阶段去完成。

;;

9.2分析模型

;;

统一过程是用例驱动的。在分析工作流中，用类来描述用例。统一过程包含三种类型的类：实体类、边界类和控制类。

实体类(EntityClass)用来对持久信息进行建模。就银行软件产品来说，类Ac