第六章_面向对象分析.ppt

ATM系统的基本系统模型 6.6.2 画出功能级数据流图 把基本系统模型中的单一的处理框分解成若干个处理框，以描述系统加工、变换数据的基本功能，就得到功能级数据流图。 ATM系统的功能级数据流图 6.6.3 描述处理框功能 把数据流图分解细化到一定程度后，应该描述图中各个处理框的功能。注意，应该着重描述每个处理框所代表的功能，而不是实现功能的具体算法。 6.7 定义服务 一个服务就是收到一条信息之后所执行的处理。服务进一步细化了现实的抽象表示，它表明某个类的对象能提供何种行为。 为建立完整的对象模型，既要确定类中应该定义的属性，又要确定中应该定义的服务。然而在前面已经指出，需要等到建立了动态模型和功能模型之后，才能最终确定类中应有的服务，因为这两个子模型更明确的描述了每个类中应该提供那些服务。 事实上，在确定类中应有的服务时，既要考虑该类实体的常规行为，又要考虑在本系统中特殊需要的服务。 6.7 定义服务 1. 常规操作 在分析阶段可以认为，类中定义的每个属性都是可以访问的，也就是说，假设在每个类中都定义了读、写该类每个属性的操作。 但是，通常无须在类图中显式表示这些常规操作。 6.7 定义服务 2. 从事件导出的操作 状态图中发往对象的事件也就是该对象接收到的消息，因此该对象必须提供由消息选择符指定的操作，这个操作修改对象状态(即属性值)并启动相应的服务。 例如，在ATM系统中，发往ATM对象的事件“中止”启动该对象的服务“打印账单” ；发往分行的事件“请分行验卡”启动该对象的服务“验证卡号”；而事件“处理分行事务”启动分行对象的服务“更新账户”。 所启动的服务通常就是接受事件的对象在相应状态的行为。 6.7 定义服务 3.与数据流图中处理框对应的操作 数据流图中每个处理框都与一个对象（也可能是若干个对象）上的操作相应。应该仔细对照状态图和数据流图，以便更正确地确定对象应该提供的服务。 例如，在ATM系统中，从状态图中看出分行对象应该提供“验证卡号”服务，而在数据流图上与之对应的处理框是“验卡” ，根据实际应该完成的功能看，该对象提供的服务应该是“验卡” 。 6.7 定义服务 4. 利用继承减少冗余操作 应该尽量利用继承机制以减少所需定义的服务数目。 只要不违背领域知识和常识，就尽量抽取出相似类的公共属性和操作，以建立这些类的新父类，并在类等级的不同层次中正确地定义各个服务。 6.8 三个模型建模思想总结 三个模型既是一种软件建模思想，又是一种建模方法，它不但告诉人们应该在什么时候、用什么方法、去建立什么模型，而且告诉人们这三个模型之间的关系，以及如何利用这三个关系去解决实际问题。 6.8 三个模型建模思想总结 6.8.1三个模型建模思想的优点 1.符合中国人的心理 2. 符合客观事物的发展规律 3. 符合将复杂问题简单化和抓主要矛盾的哲学思想 4. 符合“简单、方便、直观”的原则 5. 符合节省成本降低费用的经济效益目标 6. 三个模型的建模思想与建模方法，对面向过程方法建模、面向对象方法建模、面向元数据方法建模都适合，对应用软件建模、系统软件建模也适合。 7. 三个模型从根本上满足了B/A/S 6.6.2 三个模型建模思想的缺点 1.三个模型的建模只能覆盖需求分析和设计两个阶段，不能覆盖整个生命周期 2.动态模型表述不规范 3.功能模型表述不规范 * * * * * * 6.4.5 识别继承关系 确定了类中应该定义的属性之后，就可以用继承去组织类以共享公共结构。继承关系的建立实质上是知识抽取的过程，它反映出一定深度的领域知识，因此必须有领域专家的密切配合才能完成。 可以使用下述两种方法建立继承关系： (1)自底向上：抽象出现有类的共性(公共属性)泛化出父类，这模拟了人类的演绎思维过程。 例如，在ATM系统中，“远程事务”和“柜员事务”是类似的，可以泛化出父类“事务”；类似地，可以从“ATM”和“柜员终端”泛化出父类“输入站”。 6.4.5 识别继承关系 自底向上也称为从特殊类发现一般类。 公司职员 股东 姓名 身分证号码 …… 股份 …… 职员 工资 …… …… …… …… 股东 姓名 身分证号码 股份 …… …… 职员 姓名 身分证号码 工资 …… …… ？ 6.4.5 识别继承关系 (2)自顶向下：把现有类细化成更具体的子类，这模拟了人类的演绎思维过程。 利用多重继承可以提高共享程度，但是同时也增加了概念上以及实现时的复杂程度。使用多重继承机制时，通常应该指定一个主要父类，从它继承大部分属性和行为；次要父类只补充一些属性和行为。 6.4.5 识别继承关系 自顶向下也称为从一般类发现特殊类。 公司职员 股东 姓名 身分证号码