系统分析与设计new第5章.pptVIP

第五章 系统分析 模型驱动的分析方法 以UML为代表的面向对象系统分析方法是典型的模型驱动的分析方法，即建立起由功能模型、对象模型和动态模型构成的分析模型。 其中，功能模型由用例图表示，对象模型由类图表示，动态模型由状态图和顺序图表示 系统分析中的逻辑模型 系统分析阶段的目标是通过建立模型来“定义系统需求” 这些模型定义了系统需求，但并不局限于某一具体技术，称之为逻辑模型。 系统分析中使用的逻辑模型 数据流图 表示系统逻辑功能和信息联系，并且独立于硬件、软件、数据结构和文件组织的一种图形，只用四个基本部件组成：外部实体、数据处理、数据存储和数据流。 实体-关系图 又叫做E-R图，表示系统要素之间关系的一种图形，主要用于数据库系统的概念设计。在UML中，实体-关系图常常被类图、对象图以及用例之间的关联图所替代。 （补）外部事件 在系统之外发生，通常是由外部的人或组织激发的事件，这些人或组织是数据的提供者和接收者。 比如图书馆流通系统中的读者 外部事件能够导出系统需要处理的关键事务 （补）寻找外部事件 首先要确定外部实体，然后再分析。 外部实体需要一个事务处理 比如读者借书 外部实体需要系统提供某些信息 比如读者查阅书目 某些数据改变了，系统需要更新它们 比如书籍的位置改变 管理过程需要某些信息 比如制订新的采购计划需要流通统计情况 （补）定时事件 当系统时间到达某一刻时发生的事件，这些事件通常要求系统能定时自动地完成某些输出或处理。 如：图书馆流通系统中的按月发布逾期催还名单。 如：每天晚上12：00定时转换归档医疗图像。 注意命名时必须包含所要完成的处理和规定期限 事件的类型- (state event) 状态事件 是系统内部由于某个要素状态的改变而触发其他要素状态改变的事件。按照预先定义，系统内部要素应当由一个状态转移到另一个状态，这样才能完成系统的功能。状态事件无法定义发生的时刻。 识别临时事件和状态事件的关键点是： 1、内部处理需要的临时输出结果 2、系统应当对外给出的结果 3、系统内部相关要素的状态依赖关系 （补）状态事件 系统内部的变化触发系统对某个处理的需要，这种情况的发生称为状态事件 比如：销售系统中库存数一旦低于控制点就产生订货单 状态事件一般是外部事件的结果，它的发生是不定时的 （补）识别事件的规律 区分事件与具体响应过程 事件响应中的一系列交互过程是完整具体的实现，而不是独立的一个事件。例如：拿信用卡交费 跟踪关键业务的整个生命周期来发现事件 跟踪读者实现从图书馆借书的全部过程 暂时忽略技术性依赖事件和系统控制事件 如管理员登录系统，修改口令，每天的备份 事件列表 事件列表 包括行和列，行代表事件，列代表事件的详细信息。 事件列表便于区分事件和由事件所引起的系统的其他的行为和响应。 事件名；触发器；来源；动作；响应；目的地 事件列表 触发器：使得系统知道事件发生的触发消息。是事件与系统的接口。 动作：事件发生了的消息传递给系统后，系统引发的一系列动作和行为。 相应：系统对所发生事件的输出结果（一个或一系列）。 目的地：系统产生结果的送达地。 事件列表 绘制网上订单系统的事件列表 （1）客户希望检查产品可订量 （2）客户建立一个订单 （3）客户改变或作废订单 （4）客户和管理层检查订单状态 （5）为订单发货 （6）客户退货 （7）未来客户需要目录 （8）客户更新基本信息 （9）市场部给客户发送促销材料 （10）调整产品目录 （11）每日交易汇总 （12）每周订单汇总 需求的概念 建立领域模型 领域中一般有三种对象类： 现实世界的对象，表示现实世界中要通过系统处理的事物，如货物、地点等； 业务对象，表示业务中需要进行操作的事务，如订单、合同、账户等； 发生和将要发生的事件，表示能够引发系统工作或对系统产生影响的事实，如货物抵达、申请递交等。 建立业务模型—用例图 用例图从使用的角度来描述系统，概括了系统如何向用户和向哪些用户提供有价值的功能。 用例模型侧重于从功能的角度来描述组织所包含的业务过程信息，能以清晰的方式表达组织中各个业务过程的各个功能的组成部分，并确定业务的参与者所使用的业务用例。 注意 用例图不显示系统的流入流出及其内部的信息。（这些内容利用顺序图和协作图等交互图表示） 顺序图重点放在消息本身细节上，强调信息的时间关系 协作图强调的是所涉及的对象 状态图刻画了对象本身执行功能的状态转移 关于活动图 可以从两个角度来描述业务过程 1，描述不同业务用例之间的协作和交互过程，重点在不同用例之间的关系和执行，包括任何从一个起始点开始，通过一系列业务用例的交互来完成组织的特定功能 2，描述每个业务