搜索
第三章业务分析与建模周瑞信息与软件工程学院2本章内容•系统分析概述•业务分析与建模•业务建模方法•业务建模案例3.1系统分析概述4什么是系统分析？系统分析是指把要解决的问题作为一个系统，对系统要素进行综合分析，找出解决问题的可行方案。5什么是系统分析?系统分析内容•现有组织管理状况、业务流程、数据处理•数据、业务过程和实现管理功能之间关系•新系统目标、改进要求•用户对新系统的功能需求•新系统解决方案系统分析目标•在系统分析阶段，全面描述系统的功能与性能要求：•完全描述系统功能处理要求•完整描述系统所处理的数据构成•定义系统性能要求•定义系统外部接口6系统分析过程7•业务过程建模表示法–BusinessProcessModelandNotation-BPMN–专门用于对由活动定义的业务过程建模•数据流图–DataFlowDiagram-DFD：功能建模•UML用例建模、活动流程建模系统分析建模技术3.2业务分析与建模9什么是业务分析业务分析（主要目的）是通过对组织机构的社会使命、机构职能、业务范围、业务流程、管理模式等进行深入的调查与分析，建立起反映组织的现行业务活动模型，为业务重组和新信息系统的开发打下基础。业务是指为实现组织（机构）目标和职能，需要开展的工作与任务。如银行的存款、贷款、转帐等业务。101.组织现状调查2.组织目标分析3.组织机构分析4.组织职能分析5.业务流程分析6.实体分析7.管理模型分析业务分析的主要工作111.组织现状调查通过对组织现状和发展规划进行调查，熟悉与了解组织系统，为业务分析收集充足的材料。调查的主要内容如下：•组织目标、规模、机构、职能•组织产品、市场、竞争对手、挑战与机遇•组织技术、设备、信息系统•组织业务、信息、流程、IT基础设施•组织企业管理•人员素质•企业文化业务分析的主要工作122.组织目标分析组织目标是组织的奋斗方向，组织的一切工作都围绕着组织的目标展开。信息系统是直接为组织目标服务的，信息系统建设的目标、规模、应用范围与程度等都应该根据目标而定。因此，在业务分析时，首先应分析组织目标。分析的基本内容如下：•组织的使命和发展方向•组织总目标•组织子目标•组织策略•组织支撑要素业务分析的主要工作133.组织机构分析组织机构是组织的机构组成，为了实现组织目标，根据组织管理与职能的需要，设置组织机构的结构模式。组织机构分析的任务是理清组织的机构和岗位设置，以及各机构之间的所属关系和职能管理范围。组织机构分析的基本内容：•机构分析•职能关系分析•岗位分析业务分析的主要工作144.组织职能分析组织职能是指组织应具有的功能和作用。组织职能是由组织目标确定，具有相对稳定性。梳理清楚组织职能与组织机构之间的关系是业务分析的关键。5.业务流程分析业务本质是指组织实体为完成特定职能任务的有序活动过程。业务是通过对组织职能分解、过程化、活动执行来实现和体现。业务的活动过程称为业务流程。在业务流程中，交织着物流、人流和信息流。要认识组织的职能活动，必须认真分析各业务以及业务流程。业务分析的主要工作156.实体分析实体是指组织中的各种事物对象。组织是由各种实体构成，通过对实体活动和状态分析，可以了解组织的目标和使命是如何实施的。7.管理模型分析组织在管理过程中要运用到多种管理模式，如计划模型、生产模型、经营决策模型、市场预测模型、客户关系模型。信息系统开发，需要深入分析在组织中的各种管理模型。业务分析的主要工作16业务建模（BusinessModeling）是以系统模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，为持续改进业务流程提供基础。业务建模17业务流程的持续改进描述现有业务流程（业务建模）分析现有业务流程规范与改进业务流程（业务建模）建立模型，分析业务流程建立模型，设计业务流程业务流程信息化业务建模流程18功能结构事件接口图数据流图数据接口图推导派生图形•业务组织、职责结构描述•业务流程建模•业务信息内容和处理权限描述业务建模图形业务信息关系图职责执行流程图业务协作流程图组织结构图基本图形业务建模内容19组织机构图组织部门1部门2部门3岗位A岗位B岗位C职责1职责2职责3活动步骤1活动步骤2活动步骤320职责执行流程图开始活动步骤1活动步骤2活动步骤3结束21业务协作流程图交接工作相关业务信息工作交接事件相关业务信息岗位A活动步骤A1活动步骤A2活动步骤A3岗位B岗位C活动步骤B3活动步骤B1活动步骤B2活动步骤C1工作交接事件相关业务信息22业务信息关系图业务信息a栏目a1栏目a2业务信息b栏目b1栏目b223业务模型各要素关系交接工作相关业务信息工作交接事件相关业务信息组织部门1部门2部门3岗位A岗位B岗位C职责1职责2职责3活动步骤1活动步骤2活动步骤3岗位A活动步骤A1活动步骤A2活动步骤A3岗位B岗位C活动步骤B3活动步骤B1活动步骤B2活动步骤C1组织机构图职责执行流程图业务协作流程图业务信息关系图工作交接事件相关业务信息业务信息a栏目a1栏目a2业务信息b栏目b1栏目b2开始活动步骤1活动步骤2活动步骤3结束24主要建模脉络业务领域专家A1业务分析员A2软件开发人员A3确定建模范围!评审模型!建立业务模型!收集业务素材!完善业务模型(包括需求定义),形成关键文档!设计软件...!业务建模人员及分工25采用UML语言及其建模工具，以“业务活动”为核心建立业务模型，主要通过用例图（业务用例图）和活动图描述。典型业务用例图示例业务建模方法3.3业务建模方法•用例图•活动图3.3.1用例图Usecasediagram28UML用例图在早期的面向对象开发方法中，都是以自然语言来描述系统的功能需求。这样的做法没有一个统一的格式，缺乏描述的形式化，随意性较大，容易产生理解上的含混和不准确性。当UML用例图提出后，这些问题得到了很好地解决。29什么是用例图•由参与者、用例以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图•若干用例图组成系统用例模型•用例模型是一种描述系统功能性需求的方法，是对系统的功能需求的建模•从外部用户的角度观察，系统应该完成哪些功能，是对系统功能的宏观描述，详细描述系统与外界环境的交互场景30用例图的组成要素•参与者（角色）•用例：系统提供的服务•关联–参与者与用例之间的关系–参与者之间的关系–用例之间的关系•可选元素–系统边界：系统的范围–包–注释31参与者（Actor）•参与者是指存在于系统外部并直接与系统进行交互的实体，包括人、系统或设备。•在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。•每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。32参与者•参与者和用例之间的关系称为通信关联，表示参与者使用了哪些用例•参与者和用例之间的通信关联可以使用带箭头或者不带箭头的线段：–如果使用带箭头的线段，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者–如果不想强调对话中的主动和被动关系，可以使用不带箭头的线段33参与者之间的关系•由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。•泛化关系表示的是参与者之间的一般/特殊关系•在UML图中，使用带空心三角箭头的实线表示泛化关系。34参与者之间的关系•泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。35用例（Usecase）•用例是从用户角度描述系统的一项功能•一个系统包含若干个相互关联的用例•UML表示：椭圆，用例名称放在椭圆中心或椭圆下方中间的位置•用例名称通常使用动词短语或者动名词组：如选课、授课、存款、取款、登录、查询•任何用例都不能在缺少参与者的情况下独立存在•任何参与者也必须要有与之关联的用例36用例37识别用例•识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者，可以通过以下问题来寻找用例：①参与者希望系统提供什么功能？②参与者是否会创建、读取、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？③参与者是否会将外部的某些事件通知给系统？④系统中发生的事件是否通知参与者？⑤是否存在影响系统的外部事件？38用例的粒度•网站后台管理系统中的会员信息维护，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作•我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是完全一样的39用例的粒度•用例的粒度指的是用例所包含的系统服务或功能单元的多少；•用例的粒度越大，用例包含的功能越多；反之，则包含的功能越少；•如果用例的粒度很小，得到的用例数就会很多；如果用例数目过多会造成用例模型过大和设计困难；•如果用例的粒度很大，那么得到的用例数就会很少；用例的粒度太大，不便于进一步的充分分析。40用例的粒度•用例的粒度的确定需要根据每个系统的具体情况具体分析•对于简单系统，可适当减小用例粒度，增加用例数•对于复杂系统，可适当增大用例粒度，从而减少用例数41用例规约/用例描述•对于每一个用例，我们还需要有详细的描述信息，以便对于整个系统有一个更加详细的了解，这些信息包含在用例规约之中•用例规约应该包含以下内容：①简要描述:对用例作用和目的的简要描述。②参与者：和该用例相关的参与者。③事件流:事件流包括基本事件流和备选事件流。基本事件流描述的是用例的基本流程，是指用例“正常”运行时的场景。④前置条件:执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。⑤后置条件：用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。⑥补充说明:用例的非功能性需求和设计约束等。42用例规约举例：门禁控制用例编号EC_01用例名称EC_EntryAuthentication(进门身份验证)用例说明当用户刷卡时进行身份验证，验证通过后允许其进入实验室。参与者用户、管理服务器前置条件用户完成刷卡动作基本事件流1.门禁控制器通过用户刷卡获取用户信息2.门禁控制器将用户信息上传至管理服务器3.管理服务器进行身份验证4.管理服务器下发验证结果5.门禁控制器显示验证结果6.如果验证通过，门禁控制器控制大门自动开启备选事件流1.基本事件流第3步，如果验证失败，下发验证失败结果2.门禁控制器显示验证失败，用例结束后置条件大门处于开启状态补充说明该用例由门禁控制器和管理服务器共同协作完成1.门禁控制器端负责信息的获取及上传2.管理服务器端负责信息的验证该用例的用例图？43用例之间的关系1.包含（Include）2.扩展（Extend）3.泛化（Generalization）系统分析员也可以利用UML的扩充机制自定义用例的关联44包含关系•包含关系指一个用例可以包含其它用例的行为，并把它所包含的用例行为作为自身行为的一部分。•在UML中，包含关系是通过带箭头的虚线段加include字样来表示，箭头由基础用例(Base)指向被包含用例(Inclusion)。45包含关系•主要有两种情况需要用到包含关系：①多个用例用到同一段行为，则可以把这段共同的行为单独抽象成为一个用例，然后让其它用例来包含这一用例②某一个用例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的46扩展关系•在一定条件下，可以把新的行为加入到已有的用例中，即一个用例的行为扩展了另一个用例的行为•新行为对应的用例叫做扩展用例(Extension)，原有的用例叫做基础用例(Base)。•从扩展用例到基础用例的关系就是扩展关系。•在UML中，扩展关系通过带箭头的虚线段加extend字段来表示，箭头从扩展用例指向基础用例47扩展关系•扩展关系用来说明可选的、只在特定条件下执行的行为•在扩展关系中，基础用例提供一个或者多个插入点，扩展用例为这些插入点提供需要插入的行为•基础用例是独立的，可以在没有扩展用例