系统分析及设计new第5章

第五章系统分析Copyright◎南京邮电大学经管学院系统分析4.需求建模

2.事件和事物的描述1系统分析概述3.对象及其关系和属性

Copyright◎南京邮电大学经管学院5.1系统分析概述◆系统分析的用户视图◆模型驱动的分析方法◆系统分析中使用的逻辑模型Copyright◎南京邮电大学经管学院系统分析的用户视图

系统分析阶段数据、功能和交互行为板块的用户视图

Copyright◎南京邮电大学经管学院系统分析的用户视图

系统分析阶段建立的文档库（UML类图）

模型驱动的分析方法以UML为代表的面向对象系统分析方法是典型的模型驱动的分析方法，即建立起由功能模型、对象模型和动态模型构成的分析模型。其中，功能模型由用例图表示，对象模型由类图表示，动态模型由状态图和顺序图表示Copyright◎南京邮电大学经管学院模型驱动的分析方法用例图：功能视图功能模型：模型对象模型：模型动态模型：模型状态图：功能视图类图：数据视图顺序图：功能视图分析模型：模型系统分析中的逻辑模型系统分析阶段的目标是通过建立模型来“定义系统需求”这些模型定义了系统需求，但并不局限于某一具体技术，称之为逻辑模型。Copyright◎南京邮电大学经管学院系统分析中使用的逻辑模型事件和事件表以商务过程中的事件为关注点，将用户所描述的事件用更简洁的语句列举出来，以便下一步找出这些事件的触发原因、消息来源、所完成的动作、所做出的响应和事件要达到的目的，形成完整的事件列表数据流定义将事件中涉及到的要传递的数据集合明确表示出来，并给出数据集合的名称。数据元素定义在数据流中分解出各个数据项，给出其描述，如名称、类型、范围以及相应的说明等。数据流图表示系统逻辑功能和信息联系，并且独立于硬件、软件、数据结构和文件组织的一种图形，只用四个基本部件组成：外部实体、数据处理、数据存储和数据流。实体-关系图又叫做E-R图，表示系统要素之间关系的一种图形，主要用于数据库系统的概念设计。在UML中，实体-关系图常常被类图、对象图以及用例之间的关联图所替代。系统分析中使用的逻辑模型Copyright◎南京邮电大学经管学院系统分析中使用的逻辑模型数据流图及其简单的例子

Copyright◎南京邮电大学经管学院类图(对象图)类和对象在UML中是离散的概念，类是具有相同结构、行为和关系的一组对象的描述符号，对象是类的实例，我们认为对象具有可激发的行为。类和对象都拥有身份、状态、行为和关系，类和对象是面向对象系统组织结构的核心。用例图用例是外部可见的系统功能单元，这些功能单元由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。UML系统分析中使用的逻辑模型Copyright◎南京邮电大学经管学院系统分析中使用的逻辑模型用例图和用例之间的关系Copyright◎南京邮电大学经管学院协作图

协作图与顺序图是可以方便地相互转化的，协作图用来快速地浏览相互协作以支持一个特定场景的所有对象，强调的是对象之间的关系组织，而不是对象之间消息传递的时间性。为了克服这一缺点，协作图中要求将消息名称前面加上顺序号，表示消息发生的先后顺序。状态图

状态图描述一个对象的状态变化，从其对象属性值的变化中看出状态的变化。状态图说明的是这种“事件-响应-对象状态的变化”的过程。注意，状态图表现的是一个对象对待外部事件刺激的内部变化，所以常常是对象属性值的改变。系统分析中使用的逻辑模型Copyright◎南京邮电大学经管学院系统分析中使用的逻辑模型顺序图顺序图用来显示场景或用例的事件表中所发生的交互，它侧重于对消息时序的描述，所以又称为时序图。Copyright◎南京邮电大学经管学院系统分析中使用的逻辑模型包含了嵌套的状态图激活预热冷却闲置准备/开关合上温度达到过热(所要温度)加热过冷(所要温度)温度达到过热(所要温度)过冷(所要温度)Copyright◎南京邮电大学经管学院系统分析中使用的逻辑模型活动图活动图是状态机的另一种形式，它表现的是与一组事件相连的多个对象的状态变化，强调的是计算过程中顺序的和并发的步骤，我们把它称为工作流。活动图作为状态机的一个要素是活动状态（动作状态），表示工作流中各个动作的执行，比如一个计算或者真实世界中不间断的操作；而状态机的另一个要素转换则由这个动作的完成来触发。在状态内部处理以后，至少有一个输出来完成转换，也就是说，活动状态应当是原子状态，即它们不会被转换中断。状态图和活动图本质上都是状态机。Copyright◎南京邮电大学经管学院系统分析中使用的逻辑模型带有泳道的活动图

Copyright◎南京邮电大学经管学院5.2事件和事物的描述◆事件和系统需求◆事件的类型◆识别事件◆事件列表

Copyright◎南京邮电大学经管学院事件和系统需求事件指发生在确定的时间和地点、可以描述、并应该被系统记录下来的事实。之所以称其“应该”，是因为建模过程是对现实的一个抽象的过程,系统中发生的事件很多，有的与系统的功能没有关系或者关系不大，不值得记录。主事件直接激发系统行为的事件子事件后序事件Copyright◎南京邮电大学经管学院事件和系统需求影响电话订货系统内外部事件的例子

Copyright◎南京邮电大学经管学院外部事件即系统之外发生的事件.外部事件的发生是由外部实体或者动作参与者所引发。所谓外部实体或者外部参与者是指系统外部的组织或者人员，他为系统提供数据或者从系统获取数据。考查外部事件的关键点是：1、外部实体对系统的数据输入2、由外部实体的需要而触发的系统内部的事务处理3、外部实体想要获取某些信息4、外部实体的变化引发系统内部数据需要更新。外部事件一般不因起北部元素组成的变化，而在特殊条件下也能导致组成变化；属性变化也能引起组成变化。事件的类型-(externalevent)（补）外部事件在系统之外发生，通常是由外部的人或组织激发的事件，这些人或组织是数据的提供者和接收者。比如图书馆流通系统中的读者外部事件能够导出系统需要处理的关键事务（补）寻找外部事件首先要确定外部实体，然后再分析。外部实体需要一个事务处理比如读者借书外部实体需要系统提供某些信息比如读者查阅书目某些数据改变了，系统需要更新它们比如书籍的位置改变管理过程需要某些信息比如制订新的采购计划需要流通统计情况Copyright◎南京邮电大学经管学院定时事件指的是时间点所触发的事件，即由于到达了某一时刻系统内部自动发生的事件。信息系统应当在预定时间间隔中产生一些输出结果。定时事件在正常情况下不引起内部组成结构的变化，只有在异常状态下才会出现；而异常状态也只能由定时事件触发。定时事件与外部事件最大的不同点在于不需要触发事件的实体，是系统自动引发所需要的处理，产生信息或其他输出结果。

事件的类型-(temporalevent)

（补）定时事件当系统时间到达某一刻时发生的事件，这些事件通常要求系统能定时自动地完成某些输出或处理。如：图书馆流通系统中的按月发布逾期催还名单。如：每天晚上12：00定时转换归档医疗图像。注意命名时必须包含所要完成的处理和规定期限事件的类型-(stateevent)状态事件是系统内部由于某个要素状态的改变而触发其他要素状态改变的事件。按照预先定义，系统内部要素应当由一个状态转移到另一个状态，这样才能完成系统的功能。状态事件无法定义发生的时刻。识别临时事件和状态事件的关键点是：1、内部处理需要的临时输出结果2、系统应当对外给出的结果3、系统内部相关要素的状态依赖关系（补）状态事件系统内部的变化触发系统对某个处理的需要，这种情况的发生称为状态事件比如：销售系统中库存数一旦低于控制点就产生订货单状态事件一般是外部事件的结果，它的发生是不定时的Copyright◎南京邮电大学经管学院识别事件客户走向银行的柜台客户询问能否用现金缴纳电费柜员回答只能用信用卡缴纳电费客户将电卡和信用卡交给柜员柜员将电卡号码输入电费缴纳系统柜员将信用卡插入读卡机客户输入密码柜员将缴费发票和两张卡还给客户客户离开1、准确区分事件、条件、响应和行为。2、列出事件的时间顺序3、技术选择和系统控制（补）识别事件的规律区分事件与具体响应过程

事件响应中的一系列交互过程是完整具体的实现，而不是独立的一个事件。例如：拿信用卡交费跟踪关键业务的整个生命周期来发现事件

跟踪读者实现从图书馆借书的全部过程暂时忽略技术性依赖事件和系统控制事件

如管理员登录系统，修改口令，每天的备份事件列表事件列表包括行和列，行代表事件，列代表事件的详细信息。事件列表便于区分事件和由事件所引起的系统的其他的行为和响应。事件名；触发器；来源；动作；响应；目的地事件列表触发器：使得系统知道事件发生的触发消息。是事件与系统的接口。动作：事件发生了的消息传递给系统后，系统引发的一系列动作和行为。相应：系统对所发生事件的输出结果（一个或一系列）。目的地：系统产生结果的送达地。事件列表绘制网上订单系统的事件列表（1）客户希望检查产品可订量（2）客户建立一个订单（3）客户改变或作废订单（4）客户和管理层检查订单状态（5）为订单发货（6）客户退货（7）未来客户需要目录（8）客户更新基本信息（9）市场部给客户发送促销材料（10）调整产品目录（11）每日交易汇总（12）每周订单汇总事件名称触发点事件源活动响应结果事件目的地客户希望检查产品可订量产品的查询请求客户查询产品的可用量产品可用量详细情况客户客户建立一个订单新订单客户建立新订单实时连接订单确认订单细节交易信息信用卡处理系统客户发装部门银行客户改变或作废订单修改订单的请求客户更新订单修改确认订单修改细节交易信息客户发装部门银行客户和管理层检查订单状态订单状态的查询请求客户或管理部门查询订单的状态订单状态的详细情况客户或管理部门为订单发货订单发货通知发装部记录订单的执行客户退货订单退货通知客户建立退货记录退货确认交易信息客户银行网上订单系统的事件表事件名称触发点事件源活动响应结果事件目的地未来客户需要目录产品目录的查询请求未来客户提供产品目录信息产品目录未来客户客户更新基本信息客户信息修改通知客户更新客户基本信息市场部给客户发送促销材料促销产品细节市场部分发促销单促销单客户和未来客户调整产品目录产品目录更新细节销售部更新产品目录每日交易汇总每天末产生交易汇总报告交易汇总报告财务部每周订单汇总每周末产生订单汇总报告订单汇总报告管理部门网上订单系统的事件表Copyright◎南京邮电大学经管学院5.3事物、对象及其关系和属性

◆事物的类型◆对象之间的关系

◆对象的属性Copyright◎南京邮电大学经管学院事物的类型Copyright◎南京邮电大学经管学院

对象之间的关系一对一的关系

在每个端点上都有一个重数1。两个类之间是一对一的关系，意味着在每个类的实例间恰好只存在一个连接，例如，一个电子钱包只对应一个客户账号。一对多的关系

在一个端点有一个重数1，而另一个端点有一个重数0..n（也可以用*表示）或者1..n。两个类之间的一对多关系表示前一个类的一个实例对应于后一个类的好几个实例。例如，一个客户可以在不同银行申办电子钱包，而这些电子钱包只对应于这一个客户。多对多的关系

在每个端点上都有一个重数0..n(或者*)，两个类之间的多对多关系表示这两个类的实例之间可能存在着任意数目的连接。例如，多个银行都可对客户配发电子钱包。多对多的关系是关系中最复杂的类型。Copyright◎南京邮电大学经管学院对象之间的关系重数的例子

Copyright◎南京邮电大学经管学院对象之间的关系关系类型UML符号功能和示例依赖关系（使用）两个模型元素之间的关系，一个元素需要别的元素提供适当的功能如，汽车使用汽油聚集关系（有一个）整体与部分的关联如，汽车有一个发动机如，汽车有车轴（中空的菱形代表只有参考部分，实心的菱形表示整个实体对象的全部）关联关系类实例间连接的描述如，汽车由交通管理部门发放牌照泛化关系（是一个（isakindof）更概括的描述和更具体的种类之间的描述如，汽车是一种机动车

UML描述关系类型用的四种主要结构

Copyright◎南京邮电大学经管学院对象之间的关系关系的一个例子

Copyright◎南京邮电大学经管学院对象的属性

类和对象除了具有名称以外，还要有其特征的描述，这些特定的信息称为属性，属性是与类（对象）结合在一起并勾画出类（对象）基本特性的数据字段。在这些字段中最重要的、能唯一标识该类和对象特点的属性称为关键属性（关键字），或者标识符。选取对象属性的时候应当问下面两个问题：1对目标系统中的一个对象真正需要了解和记住的是哪些事情？2这些事情真正能显现出对象的特性吗？Copyright◎南京邮电大学经管学院5.4需求建模◆需求的概念◆需求描述的工具◆功能分析Copyright◎南京邮电大学经管学院需求的概念系统分析阶段主要从概念上刻画目标系统包括对分析系统的需求，以用例模型的方式描述系统的功能需求，以及对目标系统的内部结构和行为进行描述。

需求的概念Copyright◎南京邮电大学经管学院需求的概念需求应当包括从用户角度（系统外部行为）和从系统开发者的角度（一些内部特性）描述的“用户为解决某个问题或为实现某一目标，要求软件必须满足的条件或能力”。用面向对象方法描述需求的最大好处，是在于考虑问题的思路是从现实世界的人类思维习惯出发的，也就是采用我们在现实生活中习惯的思维方式，从人类考虑问题的角度出发，用某种特定的、规范的表达方式把用户解决问题（即需求）的思维方式逐步翻译成机器能够理解的思维方式的过程。通过这一步步的翻译的过程，逐步设计好了所需要的软件条件和能力。信息系统的需求可以分为约束条件、功能需求与非功能需求。

Copyright◎南京邮电大学经管学院需求的概念信息系统需求的层次

Copyright◎南京邮电大学经管学院需求描述的工具◆建立领域模型◆建立业务模型◆需求说明的补充UML需求描述=事件表+类图+用例图+交互图（顺序图、协作图）+状态图Copyright◎南京邮电大学经管学院建立领域模型建立领域模型是从事件表转化到类图的工作。领域模型能捕获系统环境中最重要的对象类型，描述对象类型之间的关系，所以领域模型主要的表现形式是UML类图（以及对象图）。领域对象代表了系统工作的环境中存在的事情和发生的事件。

建立领域模型

领域中一般有三种对象类：现实世界的对象，表示现实世界中要通过系统处理的事物，如货物、地点等；业务对象，表示业务中需要进行操作的事务，如订单、合同、账户等；发生和将要发生的事件，表示能够引发系统工作或对系统产生影响的事实，如货物抵达、申请递交等。Copyright◎南京邮电大学经管学院建立领域模型从事件到系统的领域模型Copyright◎南京邮电大学经管学院建立业务模型有助于理解组织中业务过程，同时它还有助于组织业务过程的改善和提高。业务模型的建立除了要用到类图和对象图以外，还应当画出用例图、活动图、顺序图和状态图。

建立业务模型建立业务模型—用例图用例图从使用的角度来描述系统，概括了系统如何向用户和向哪些用户提供有价值的功能。用例模型侧重于从功能的角度来描述组织所包含的业务过程信息，能以清晰的方式表达组织中各个业务过程的各个功能的组成部分，并确定业务的参与者所使用的业务用例。Copyright◎南京邮电大学经管学院建立业务模型—用例图一个电话订货系统的用例图

注意用例图不显示系统的流入流出及其内部的信息。（这些内容利用顺序图和协作图等交互图表示）顺序图重点放在消息本身细节上，强调信息的时间关系协作图强调的是所涉及的对象状态图刻画了对象本身执行功能的状态转移Copyright◎南京邮电大学经管学院用例图、类图、顺序图和状态图之间的关系

建立业务模型关于活动图可以从两个角度来描述业务过程1，描述不同业务用例之间的协作和交互过程，重点在不同用例之间的关系和执行，包括任何从一个起始点开始，通过一系列业务用例的交互来完成组织的特定功能2，描述每个业务用例的细节过程，即描述单个用例的整个执行过程和用例中不同业务活动之间的协调和交互。Copyright◎南京邮电大学经管学院建立业务模型创建和确认订单的活动图

Copyright◎南京邮电大学经管学院需求说明的补充对于非功能需求，一般不用UML的图形表示，这时候可以采用传统的描述手段进行说明，以便和UML的模型一起用于分析与设计。补充的内容包括：可用性是指用户可以使用系统的时间百分比，可用性强的产品能够被用户更容易的理解和掌握，主要包括故障恢复能力、带病工作能力，以及用户使用的方便性，如界面标准、操作简单、运行规范等等。可靠性是指信息系统能否始终一贯地正确运行，可靠性强的产品准确度高、平均无故障时间长、软件缺陷少，以及系统可用性强、抗风险能力强、健壮性好。性能是对信息系统功能所增加的条件，如存贮容量、响应时间、传输带宽、时延等。Copyright◎南京邮电大学经管学院需求说明的补充可支持性表明系统为了保持其可维护性、可扩展性而必须达到的一些条件和要求，例如编码规范和标准、系统的公共类库、版本控制工具、分发渠道等。设计约束是对系统设计所进行的限制，例如扩展能力和维护要求、对遗留系统（老系统）数据的利用要求、开发平台和语言工具、系统架构，甚至软件硬件产品的选择要求等。接口需求与系统相关的外部项目、遗留系统的接口要求，如软件接口、硬件接口、通信接口等。其他需求包括在线帮助、法律条款、所用软件产品的许可权利等。Copyright◎南京邮电大学经管学院功能分析◆识别参与者◆定义系统边界◆识别系统用例◆识别用例间的关系◆建立用例模型◆给出用例的优先级Copyright◎南京邮电大学经管学院参与者（actor）是UML中的一个专门术语，指的是系统外部的一个主动介入系统的实体，可能是人员，也可能是设备或者另外一个系统，用火柴棒小人表示。参与者作为向系统输入和请求系统输出某些事件来触发系统用例执行的角色出现，因此，同样一个实体，在不同系统或者不同用例前面所担负的角色是不同的。识别参与者

识别参与者业务模型建成以后，可以根据业务模型中的业务用例，由分析人员提炼出对应的角色作为参与者。提炼角色可以从介入实际业务过程的工作人员比对产生，步骤为：

1、考虑所有可能的与系统运行有关的人员、设备和其他系统2、确定系统数据的输入输出方面的参与者3、确定系统操作和维护的参与者4、将参与者-用户-角色挂起钩来5、代表扮演触发系统用例执行起来的角色(避免凭空想象的参与者)6、进行合理的组织和合并,减少功能重叠,以便形成参与者和角色的类别7、对参与者命名,名字要有实际意义、易于理解并前后一致Copyright◎南京邮电大学经管学院定义系统边界系统边界标识了什么在系统之内，什么在系统之外，并进而识别系统的职责，UML中用一个大的方框表示，系统职责写在框架内明显的地方，我们把图加上方框，就界定了系统的边界。从不同角度看待整个系统，可能会得到不一样的系统边界范围，这对后续的设计和开发工作会产生影响的。Copyright◎南京邮电大学经管学院识别系统用例识别系统用例

Copyright◎南京邮电大学经管学院识别用例间的关系用面向对象的观点看，用例也是对象，所以对象之间的使用、关联、聚集、泛化等关系在用例之间也可以使用。除此之外，用例之间还有两种更常使用的特殊关系：包含（include）和扩展（extend）。

包含关系表示所触发用例的完成需要调用其他一些描述同样功能的子用例，即后者对于别的用例也是可以调用的，使用包含关系可以降低用例的冗余。扩展关系是减少复杂性的又一个手段，扩展关系表示可以选择的行为集合、特定条件下才发生的行为集合或者不同流程，从而使用例变得更短和更容易理解，开发人员能够分别处理每种功能。区分包含于扩展在逻辑上，包含关系和扩展关系的区别在于相关的程度，扩展关系表示一种可能的需要，而包含关系则表示只要有就必须完成的功能。在结构上，包含和扩展是类似的，其主要差别在关系的方向。在包含关系中，使目标用例启动的条件是在主用例中的，它的作用好像事件流中的事件一样，箭头方向从主