搜索
企业业务建模介绍&讨论吴晓明课程内容一．企业业务建模二．使用UML进行业务建模三．需求管理与用例建模技术一、企业业务建模定义、目的、框架、业务规则、业务模式、业务架构、软件架构企业业务建模定义企业业务建模，也称企业建模或业务建模，是一种全新的企业经营管理模式，它为企业提供一个框架结构，以确保企业的应用系统与企业经常改进的业务流程紧密匹配。企业业务建模目的对企业进行更好的理解和提供公共一致的表示形式重用企业中现有的知识和技能分析企业的某些特性以持续的改进企业性能管理企业系统的复杂性提高企业信息系统的模型驱动设计水平企业业务建模的几种框架Zachman框架ARIS集成信息系统架构EPMS业务过程建模方法CIM-OSA方法IDEF方法DEM动态企业建模方法Zachman框架What（数据）How（行为）Where（地点位置）Who（角色）When（时间）Why（动机）ARIS集成信息系统架构eERMeERM-attribute定位图关系图特性设置图图表数据视图机构图网络拓扑结构网络图组织视图功能树枝图目标图应用系统分类图应用系统样本图功能视图信息流图功能定位图增值链图eEPC，PCD访问图访问图表（具体的）控制视图ARIS集成信息系统架构组织视图：组织结构的静态模型。包括：层次组织结构的人员资源，生产资源（设备，运输等）以及计算机、通信网络结构等。数据视图：业务信息的静态模型。包括：数据模型，知识结构，信息载体，技术术语和数据库模型等。功能视图:业务流程任务的静态模型。包括：功能层次，业务对象，支持系统和应用软件等。控制视图：动态模型，展示流程运转情况，并能够将业务流程与流程相关的资源、数据以及功能等联系起来。包括：事件驱动过程链、信息流、物流、通信图、产品定义、价值增值图等。业务规则业务规则是组织用于做出运作决策的原则业务规则是对如何操作业务的各种要求。他们可以是业务需要遵守的法律或规范，也可以是业务范围政策以及计算方法和公式、风险阈值和正式授权分类：约束规则：规定了限制对象结构和行为的策略和条件推导规则：规定了从一些事实经过推理和计算得到其他事实的策略和条件。业务规则管理业务规则管理（BRM）将控制运作决策的逻辑从单独的应用程序中解放出来。在单个应用程序中，这些逻辑一般是被封锁在编程代码内的。这种方式就像数据库管理解放了数据库一样。业务规则管理减少了上市时间和总拥有成本，节省了大量应用程序实施成本。业务规则描述对象约束语言(ObjectConstraintLanguage,OCL)OCL表达式以附加在模型元素的条件和限制来表现对该对象的约束，其中包括附加在模型元素上的不变量或约束的表达式、附加在操作和方法上的前置条件和后置条件等。业务模式一个业务模式描述了一个可重用方法来解决一个特别的商业问题，这个商业问题通常是在商业过程范围内例如：资源和规则模式目标模式过程模式BusinessModelingwithUML:BusinessPatternsatWork案例：神州数码的企业业务模型组织结构图公司业务分布网络技术职位序列文化体系服务产品体系业务布局图销售业务流程图业务架构相互之间具有明确关系的元素组成的集合，这些元素一同形成了一个按功能定义的整体。他们代表业务的组织及行为结构，并提供对业务的关键流程与结构的抽象表达。业务架构中的视图业务流程视图包括业务的关键业务流程并对其进行概述，这些流程是业务存在的原因组织结构视图概述业务中的关键角色和职责以及他们的分组情况文化视图说明组织的文化特征，以及为鼓励这些特征而采取的机制人力资源视图讨论为维持和发展组织的人力资源而应用的机制领域视图定义应用于信息结构的关键机制和模式软件架构软件架构包含了软件系统组织结构的重要决策软件系统的组织对组成系统的结构元素及接口的选择在元素间的协作中所详述的行为将结构元素和行为元素组合进逐步增大的子系统指定这种组织的架构样式：静态、动态元素和它们的接口、它们的协作、它们的合成软件架构中的视图用例视图包括用例模型，它代表由它的终端用户所见的该系统想要的功能和环境用作终端用户和开发者之间的一个合同对分析和设计以及测试活动是重要的。包括用例图、用例事件流和补充文档。它也能包括活动图是其它视图的心脏，因为它详述了形成系统架构的动力设计视图支持该系统的功能性需求，即系统应该提供给它的终端用户的服务包括用例实现、类和交互图。它也能包括状态图和活动图注：一组执行业务用例工作的角色个体和作为部分工作而访问并使用的业务对象一起，称为业务用例实现。记录业务用例实现的首选方法就是绘制活动图，还可以使用序列图，类图等。进程视图包括构成该系统的并发性和同步机制的线程和进程包含了形成系统并发与同步机制的线程和进程该视图主要针对性能、可伸缩性和系统的吞吐量。对单处理环境是不必要的实现视图根据包装、分层和配置管理描述静态的软件模块（源代码、数据文件、组件、可执行文件等）。关注开发容易性、软件资产管理、重用、子合同等问题部署视图只用于分布式系统显示各种各样的可执行文件和运行时组件如何被映射到潜在的平台和计算节点关注部署、安装和性能等问题显示一张部署图业务模型和软件模型的融合业务用例模型业务分析模型业务模型=用例模型分析模型设计模型实现模型测试模型业务建模需求分析和设计实现测试基于用例的建模用例是组织需求的一种推荐方法用例不是使用一个需求列表组织需求，用例使用某人可以如何使用系统的方式来组织需求通过用例，需求更完整和更一致，并且可以从用户的角度更好的理解需求的重要性二、使用UML进行业务建模见IBM原版教材三、需求管理与用例建模技术传统软件过程面临的问题分析与用户存在语义分歧对问题域缺乏全面的认识多变的需求导致效率低下设计无法预知和降低风险设计决定用户难以理解与实现难以平滑衔接实现周期过长与分析设计脱节版本之间管理混乱测试测试成本过高无法做到回归测试维护成本过高产品质量不可靠寿命短重用性低可维护性差兼容性差文档混乱造成软件项目失败的根本原因不好的需求管理模糊和不精确的交流脆弱的架构未检测出需求、设计和实现之间的不一致测试的不足对于项目状况的评估过于主观为解决存在的风险无法控制变化的产生和传播自动控制不做软件工程的六条最佳实践迭代的开发软件管理需求应用基于组件的架构为软件建立可视化的模型持续的验证软件质量控制软件的变更软件工程的六条最佳实践迭代开发控制变更管理需求使用基于组件的架构可视化建模质量验证架构为中心迭代和增量开发用例驱动什么是需求用户为了达到某个目标而解决某个问题时所必需的一种软件能力系统或系统组件为满足某个合约、标准、规格说明或其它正式文档所必须达到或拥有的软件能力什么是需求管理描述、组织和文档化需求的过程为系统的需求进行启发、组织、建档的系统方法，一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程从用户需求到软件需求需求分类涉众要求（Request）或涉众需求（Need）关于涉众对系统期望的描述，与具体的解决方案无关特性（Feature）为了满足涉众需要，系统提供的外部可见的服务软件需求（SoftwareRequirement）功能性需求非功能性需求约束（Constraint）设计系统及流程设计的约束条件需求举例涉众要求（Request）或涉众需求（Need）可以快速找到系统中的所有岗位信息特性（Feature）使用树形结构显示系统提供的岗位信息软件需求（SoftwareRequirement）功能性需求用户选择“注册”功能，系统提供空白注册界面非功能性需求提供24*7小时服务约束（Constraint）用户通过互联网访问；系统使用java技术为什么需求管理困难因为需求有如下特征：总是不显而易见来源多种多样不容易用文字清晰表达与其他需求和软件工程过程中的其他交付物关联容易变化需求数量增加时难以控制需求管理的目标在预算内按时开发出符合客户真正需要的高质量产品帮助项目成功问题分析理解问题取得涉众同意清晰表达业务目标需求描述指明谁将使用系统（Actor）描述系统如何被使用（UseCase)需求管理详细说明需求管理需求、变更和错误控制范围蔓延团队成员参与项目团队参与需求开发人员、测试人员以及文档编写人员帮助需求管理的实行监控需求是否被实现文档化需求参与需求评价参加变更控制组（CCB）评价跟踪结果验证质量、易测性和完备性软件需求的质量特性正确完备一致无二义可验证可排序（重要性和稳定性）可修改可跟踪可理解RUP中的需求管理RationalUnifiedProcess是一个软件过程框架，它为开发组织提供了分配任务及责任的规程和方法RUP概览需求规程的工作流详述需求规程的目标需求规程的目的:与客户和其他项目涉众就应用系统应该有什么取得一致意见，并维护这种一致性帮助系统开发人员更好的了解系统需求定义系统的边界为规划迭代的技术内容提供基础定义系统的用户界面，主要关注用户的需要和目标要实现这些目标，首先要理解尝试使用该系统解决的问题的定义和范围，这一点很重要。确定项目涉众并引发、收集和分析涉众需求。然后将开发需求工作产品来描述系统（系统要做什么）以便将所有项目涉众（包括客户和潜在客户）视为除了系统需求以外的重要信息来源角色和工件需求管理涉及的主要工件远景（Vision）问题定义涉众列表环境和平台补充规约非功能性需求UseCase规约功能性需求术语（Glossary）公共术语涉众需要涉众的需要和请求我们在哪里？分析问题的目标开发之前对要解决的问题有一个更好的理解有的时候，解决一个特定的问题仅仅需要改变业务流程，而不是需要一个新系统。比如，建立管理生产流程，提供其他的变通方法。作为解决问题的人，我们有义务在建立新系统之前先去考察一些可能的替代解决方案分析问题的步骤识别涉众涉众指能被系统或项目的结果造成实际影响的人理解问题在问题定义上达成一致识别系统或项目的约束确定并验证解决根本问题的方案确定系统边界远景文档远景文档是从客户的角度撰写的，它关注系统的主要特性和可以接受的质量等级。远景应该描述将要包括的特性以及那些已考虑到但没有包括进来的特性。它还应该指定操作容量（卷、响应时间、精确度）、用户概要文件（谁将使用系统）以及与系统边界外的实体之间的互操作界面（如果适用）。远景文档提供正在开发的软件系统的完整远景，并支持出资方与开发组之间的约定。每个项目都需要一个来源，以记录项目涉众的期望值。远景文档提纲简介定位涉众和用户描述产品概述产品特性约束质量范围优先顺序和优先级其他产品要求记录要求功能属性识别约束环境政策经济技术系统可行性识别约束约束源约束理由操作性销售订单数据必须在系统中保持一年时间数据丢失风险太大系统及操作系统这个程序在服务器上应该占用少用20M的空间服务器上空间有限设备预算必须使用已有的服务器和主机成本控制已经设备维护人员预算固定的人力资源：无外部资源现有预算紧张技术要求应该才用OO技术相信这种技术可以增加生产效率并增加可靠性Actor帮助定义系统边界可以简单认为，解决方案的世界分为两个部分我们要开发的系统与我们系统进行交互的事物这种交互的事物我们称为我们系统的参与者。可以通过以下问题来帮助寻找谁会对系统提供信息、使用信息、删除信息谁将操作系统谁是维护者系统在哪儿被使用系统从哪儿得到信息哪些外部系统要和系统进行交互捕捉公共词汇定义项目中的术语帮助减少误解我们在哪里？需求的来源PartnersCustomerUsersProblemDomain可能遇到的问题涉众对解决方案有先入为主的想法不知道自己真正想要什么不能正确描述自己想要的东西