面向对象分析 讲稿课件

《面向对象分析 讲稿课件》由会员分享，可在线阅读，更多相关《面向对象分析 讲稿课件（71页珍藏版）》请在金锄头文库上搜索。

1、第十章 面向对象分析,面对的问题,当开发一个新的产品或系统时，我们如何从遵循OO软件工程的方式来刻画它？ 什么是相关的对象？他们如何相互关联？ 对象如何在系统的范围内工作？ 应如何对问题刻画或建模以使得可有效地进行设计？,10.3 建立对象模型,对象模型通常有五个层次。典型的工作步骤是，首先确定对象类和关联（因为它们影响系统整体结构和解决问题的方法），对于大型复杂问题还要进一步划分出若干个主题；然后给类和关联增添属性，以进一步描述它们；接下来利用适当的继承关系进一步合并和组织类。而对类中操作的最后确定，则需等到建立了动态模型和功能模型之后，因为这两个子模型更准确地描述了对类中提供的服务的需求。

2、,1031 确定类对象 1找出候选的类对象 对象是对问题域中有意义的事物的抽象，它们既可能是物理实体，也可能是抽象概念。具体地说，大多数客观事物可分为下述五类 （1）可感知的物理实体，例如，飞机、汽车、书、房屋等等。 （2）人或组织的角色，例如，医生、教师、雇主、雇员、计算机系、财务处等等。 （3）应该记忆的事件，例如，飞行、演出、访问、交通事故等等。 （4）两个或多个对象的相互作用，通常具有交易或接触的性质，例如，购买、纳税、结婚等等。 （5）需要说明的概念，例如，政策、保险政策、版权法等等。,另一种更简单的分析方法，是所谓的非正式分析。这种分析方法以用自然语言书写的需求陈述为依据，把陈述中

3、的名词作为类对象的候选者，用形容词作为确定属性的线索，把动词作为服务（操作）的候选者。 认真阅读上面给出的需求陈述，从陈述中找出下列名词，可以把它们作为类对象的初步的候选者： 银行，自动取款机（ATM），系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。,2筛选出正确的类对象 接下来应该严格考察每个候选对象，从中去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。 筛选时主要依据下列标准，删除不正确或

4、不必要的类对象： （l）冗余 如果两个类表达了同样的信息，则应该保留在此问题域中最富于描述力的名称。 以ATM系统为例，应该去掉“用户”、“磁卡”、“副本”等冗余的类，仅保留“储户”和“现金兑换卡”这两个类。,（2）无关 仅需要把与本问题密切相关的类对象放进目标系统中。 以ATM系统为例，因此，应该去掉候选类“成本”、“市”、“街道”、“营业厅”和“储蓄所”。 （3）笼统 在需求陈述中常常使用一些笼统的、泛指的名词，虽然在初步分析时把它们作为候选的类对象列出来了，但是，要么系统无须记忆有关它们的信息，要么在需求陈述中有更明确更具体的名词对应它们所暗示的事务，因此，通常把这些笼统的或模糊的类去掉

5、。 以ATM系统为例，应该去掉“银行”、“网络”、“系统”、“软件”、“信息”、“访问”等候选类。,（4）属性 在需求陈述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类一一对象中去掉。 在ATM系统的例子中，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对待。 （5）操作 在需求陈述中有时可能使用一些既可作为名词，又可作为动词的词，应该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是作为类中定义的操作。,（6）实现 在分析阶段不应该过早地考虑怎样实现目标系统。因此，应该去掉仅和实现有关的候选的类

6、对象。 在ATM系统的例子中，应该暂时去掉“事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们。,10.3.2 确定关联 多数人习惯于在初步分析确定了问题域中的类对象之后，接下来就分析确定类对象之间存在的关联关系。 两个或多个对象之间的相互依赖、相互作用的关系就是关联。分析确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些尚未被发现的类&对象。,1初步确定关联 在需求陈述中使用的描述性动词或动词词组，通常表示关联关系。因此，在初步确定关联时，大多数关联可以通过直接提取需求陈述中的动词词组而得出。通过分析需求陈述，还能发现一些在陈述中隐含的关联。 以ATM系统为例，经过分析初步确

7、定出下列关联：,（l）直接提取动词短语得出的关联 ATM、中央计算机、分行计算机及柜员终端组成网络。 总行拥有多台ATM。 分行提供分行计算机和柜员终端。 储户拥有账户。 柜员输入针对账户的事务。 ATM读现金兑换卡。 ATM与用户交互。 ATM吐出现金。 . ATM打印账单。 ,（2）需求陈述中隐含的关联 总行由各个分行组成。 分行保管账户。 总行拥有中央计算机。 系统维护事务日志。 系统提供必要的安全性。 储户拥有现金兑换卡。 （3）根据问题域知识得出的关联 现金兑换卡访问账户。 分行雇用柜员。,2筛选 经初步分析得出的关联只能作为候选的关联，还需经过进一步筛选，以去掉不正确的或不必要的关

8、联。筛选时主要根据下述标准删除候选的关联： （1）已删去的类之间的关联。 如果在分析确定类对象的过程中已经测掉了某个候选类，则与这个类有关的关联也应该删去。,以ATM系统为例，由于已经删去了“系统”、“网络”、“市”、“街道”、“成本”、“软件”、“事务日志”、“现金”、“营业厅”、“储蓄所”、“账单”等候选类，因此，与这些类有关的下列八个关联也应该删去： ATM、中央计算机、分行计算机及柜员终端组成网络。 ATM设在主要街道上。 分行分摊软件开发成本。 系统提供必要的安全性。 系统维护事务日志。 ATM吐出现金。 ATM打印账单。 柜员终端设在分行营业厅及储蓄所内。,（2）与问题无关的或应在

9、实现阶段考虑的关联 应该把处在本问题域之外的关联或与实现密切相关的关联删去。 例， “系统处理并发的访问”并没有标明对象之间的新关联，它只不过提醒我们在实现阶段需要使用实现并发访问的算法，以处理并发事务。 （3）瞬时事件 关联应该描述问题域的静态结构，而不应该是一个瞬时事件。 例，“ATM读现金兑换卡”描述了ATM与用户交互周期中的一个动作，它并不是ATM与现金兑换卡之间的固有关系，因此应该删去。类似地，还应该删去“ATM与用户交互”这个候选的关联。,（4）三元关联 三个或三个以上对象之间的关联，大多可以分解为二元关联或用词组描述成限定的关联。 例，“柜员输入针对账户的事务”可以分解成“柜员输

10、人事务”和“事务修改账户”这样两个二元关联。 （5）派生关联 应该去掉那些可以用其他关联定义的冗余关联。 例如，在ATM系统的例子中，“总行拥有多台 ATM”实质上是“总行拥有中央计算机”和“ATM与中央计算机通信”这两个关联组合的结果。而“分行计算机维护账户”的实际含义是，“分行保管账户”和“事务修改账户”。,3进一步完善 应该进一步完善经筛选后余下的关联，通常从下述几个方面进行改进： （1）正名 好的名字是帮助读者理解的关键因素之一。 （2）分解 为了能够适用于不同的关联，必要时应该分解以前确定的类对象。 例如，在ATM系统中，应该把“事务”分解成“远程事务”和“柜员事务”。 （3）补充

11、发现了遗漏的关联就应该及时补上。 例如，在ATM系统中把“事务”分解成上述两类之后，需要补充“柜员输入柜员事务”、“柜员事务输进柜员终端”、“在ATM上输入远程事务”和“远程事务由现金兑换卡授权”等关联。 （4）标明阶数 应该初步判定各个关联的类型，并粗略地确定关联的阶数。,1033 划分主题 在概念上把系统包含的内容分解成若干个主题（范畴）。 应该按问题领域而不是用功能分解方法来确定主题。此外，应该按照使不同主题内的对象相互间依赖和交互最少的原则来确定主题。 以ATM系统为例，我们可以把它划分成“总行”、“分行”和“ATM”等三个主题，这三个主题的编号分别是l、2和3。,10.3.4 确定属

12、性 属性是对象的性质，藉助于属性我们能对类对象和结构有更深入更具体的认识。 注意，在分析阶段不要用属性来表示对象间的关系。 一般说来，确定属性的过程包括分析和选择两个步骤。,1分析 属性的确定既与问题域有关，也和目标系统的任务有关。应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。在分析阶段不要考虑那些纯粹用于实现的属性。 2选择 认真考察经初步分析而确定下来的那些属性，从中删掉不正确的或不必要的属性。通常有以下几种常见情况：,（l）误把对象当作属性 如果某个实体的独立存在比它的值更重要，则应把它作为一个对象而不是对象的属性。 例如，在邮政目录中，“城市”是一个属性

13、，而在人口普查中却应该把“城市”当作对象。 （2）把限定误当成属性 限定是一种特殊的链属性。 在ATM系统的例子中，“分行代码”、“账号”、“雇员号”、“站号”等都是限定词。,（4）误把内部状态当成了属性 如果某个性质是对象的非公开的内部状态，则应该从对象模型中规掉这个属性。 （5）过于细化 在分析阶段应该忽略那些对大多数操作都没有影响的属性。 （6）存在不一致的属性 类应该是简单而且一致的。如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。 经过筛选之后，得到ATM系统中各个类的属性，如图105所示。,1035 识别继承关系 可以使用两种方式建立继承（即归纳）关

14、系： （1）自底向上：抽象出现有类的共同性质泛化出父类。例如，在ATM系统中，“远程事务”和“柜员事务”是类似的，可以泛化出父类“事务”； （2）自顶向下：把现有类细化成更具体的子类；,10.3.6 反复修改 仅仅经过一次建模过程很难得到完全正确的对象模型。事实上，软件开发过程就是一个多次反复修改、逐步完善的过程。在建模的任何一个步骤中，如果发现了模型的缺陷，都必须返回到前期阶段进行修改。 下面以ATM系统为例，讨论可能做的修改： 1分解“现金兑换卡”类 把“现金兑换卡”类分解为“卡权限”和“现金兑换卡两个类，将使每个类的功能更单一；,2“事务”由“更新”组成 “更新”虽然代表一个动作，但是它

15、有自己的属性（类型、金额等），应该独立存在，因此应该把它作为类一一对象。 3把“分行”与“分行计算机”合并 应该合并“分行”与“分行计算机”， “总行”和“中央计算机”。,10.4 建立动态模型,对于仅存储静态数据的系统（例如数据库）来说，动态模型并没有什么意义。然而在开发交互式系统时，动态模型却起着很重要的作用。,建立动态模型的第一步，是编写典型交互行为的脚本。虽然脚本中不可能包括每个偶然事件，但是，至少必须保证不遗漏常见的交互行为。接下来从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。第三步，排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描

16、绘它们。最后，比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。,1041 编写脚本 在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。 编写脚本的目的，是保证不遗漏重要的交互步骤，它有助于确保整个交互过程的正确性的和清晰性。 脚本描写的范围并不是固定的，既可以包括系统中发生的全部事件，也可以只包括由某些特定对象触发的事件。脚本描写的范围主要由编写脚本的具体目的决定。,编写脚本时，首先编写正常情况的脚本。然后，考虑特殊情况，最后，考虑出错情况。 对于每个事件，都应该指明触发该事件的动作对象（例如，系统、用户或其他外部事物）、接受事件的目标对象以及该事件的参数。,1042 设想用户界面 大多数交互行为都可以分为应用逻辑和用户界面两部分。通常，系统分析员首先集中精力考虑系统的信息流和控制流，而不是首先考虑用户界面。应用逻辑是内在的、本质的内容，用户界面是外在的表现形式。动态模型着重表示应用系统的控制逻辑。 但是，用户界面的美观程度、方便程度、易学程度以及效率等等，是用户使用系统时最先感受到的，用