UML业务建模与需求分析

UML业务建模与需求分析第1页/共156页参加本次培训，您有什么目标/目的？明确学习目标SMART原则:Specific- 具体的目标Measurable- 可衡量的目标Attainable- 可实现的目标Realistic- 和本次培训相关的目标Time-based- 两天内的目标2023/3/182第2页/共156页需求工程介绍中国科学院软件研究所许舒人shuren@32023/3/18第3页/共156页4软件需求的基本概念IEEE的软件需求定义用户解决问题或达到目标所需的条件或能力（Capability）。系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。一种反映上面⒈或⒉所描述的条件或能力的文档说明。RUP的软件需求定义需求用于说明系统必须符合的条件或具备的功能。它可以直接来自于用户需要，或在合同、标准、规约或其他正式规定的文档中阐明。FURPS+模型（Functionality、Usability、Reliability、Performance、Supportability）功能性、可用性、可靠性、性能和可支持性“+”：设计约束、实施需求、接口需求和物理需求2023/3/18第4页/共156页需求的层次——软件需求各组成部分之间的关系5业务需求项目范围业务用例模型、业务对象模型、业务规则业务需求说明书用户需求涉众需求特性前景（项目建议书、任务委托书）功能需求用例模型、用例说明、补充需求（FURPS+）逻辑模型软件需求规格说明书（系统、子系统、构件）问题空间解空间2023/3/18第5页/共156页业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求。业务用例模型（businessuse-casemodel）业务既定功能的模型。业务用例模型被用作一种基本输入，用于确定组织的各个角色和可交付工件。业务对象模型（businessobjectmodel）说明业务用例实现的对象模型。业务规则（businessrule）在业务之中必须满足的策略或条件的声明。62023/3/18第6页/共156页用户需求（userrequirement）描述了用户使用产品必须要完成的任务。前景（vision）用户或客户的待开发产品的视图，它是在关键涉众需要和系统特性的层次上指定的。72023/3/18第7页/共156页8功能需求（functionalrequirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。2023/3/18第8页/共156页需求管理定义CMU/SEI1995需求管理需要“建立并维护在软件工程中同客户达成的契约”。RUP的定义一种系统化的方法，用来获取、组织和记录系统的需求，还要使客户和项目团队在系统变更需求上达成并保持一致。92023/3/18第9页/共156页10需求工程关注的问题软件开发的目标是在预算内及时开发出满足用户需求的软件项目的成功取决于有效的需求管理需求错误是最常见的系统开发错误，并且修改代价最高一些关键的技巧可以大大减少需求错误，并因此改善软件质量分析问题理解涉众需求定义系统管理范围精炼系统定义建造正确系统

2023/3/18第10页/共156页需求问题StandishGroup从1994年到2001年的CHAOSReports证实，导致项目失败的最重要的原因与需求有关。2001年，StandishGroup的CHAOSReports报导了该公司的一项研究，该公司对多个项目作调查后发现，74%项目是失败的，既这些项目不能按时按预算完成。其中提到最多的导致项目失败的原因就是“变更用户需求”。常见的需求问题：无法跟踪需求变更 71%难以编写 70%特性偏移 67%组织欠佳 54%IBMRational需求管理技术白皮书112023/3/18第11页/共156页12导致不合格需求说明的原因无足够用户参与用户需求的不断增加模棱两可的需求不必要的特性过于精简的规格说明忽略了用户分类不准确的计划2023/3/18第12页/共156页13不同阶段修改错误的代价后期发现缺陷修改代价更高：如果设计或编码1￥，系统测试19￥，产品发布后92￥客户发现与需求相关的错误的修改代价是需求阶段时的68-110倍需求0.1~0.2设计0.5编码1.0单元测试2.0验收测试5.0维护20.02023/3/18第13页/共156页14高质量的需求过程带来的好处最大的好处是在开发和维护的工作大大减少收集需求能使开发小组更好地了解市场市场因素是项目成功的关键因素避免在无用功能上白耗精力弥补用户期望和开发者实际开发之间的“鸿沟（期望差异）”2023/3/18第14页/共156页15优秀需求具有的特性完整性正确性可行性软件工程小组的组员负责检查技术可行性必要性划分优先级无二义性对需求文档的正规审查编写测试用例开发原型设计特定的方案脚本可验证性是否能通过设计测试用例或其它的验证方法2023/3/18第15页/共156页16需求规格说明的特点完整性一致性可修改性可跟踪性2023/3/18第16页/共156页为什么需求获取很困难用户任何系统都会有很多用户，每个用户只知道他如何使用系统，没有任何人知道系统的整个情况用户常常不知道需求是什么，或不知道如何以一种精确的方式描述需求即使有分析人员的帮助，用户也不完全理解系统到底应实现什么功能，直到系统基本完成时才知道自己的需求业务价值更重要的是系统要支持任务，系统是为执行任务而构造的，系统应为业务和客户提供价值很难确定或理解这种价值，有时也不能确保这种价值世界是不断变化的业务、技术、资源等等172023/3/18第17页/共156页需求获取的目的致力于开发正确的系统要足够详细地说明系统需求，使客户和开发人员在系统应做什么、不应做什么方面达成共识必须用客户语言来描述需求需求获取的结果也有助于经理规划迭代和客户版本182023/3/18第18页/共156页需求获取概述每个软件项目都是唯一的，源于系统、客户、开发组织、技术等情况都各不相同，但在大多数情况下一些确定的步骤都是可行的：列举出候选的需求特性：状态、估计实现成本、优先级风险级别理解系统的语境领域建模：领域对象及其之间的连接业务建模：领域模型+支持的业务过程+过程所需的能力业务工程方法是业务应用中用来获取需求的最系统的过程获取功能性需求：用况既获取功能需求，也获取非功能需求获取非功能性需求：不能与用况或现实世界中特定类相联系的非功能需求，归入补充需求192023/3/18第19页/共156页20需求的开发和管理——需求工程域的层次分解需求工程需求开发需求获取需求分析需求规格说明需求验证需求管理变更控制版本控制需求跟踪需求状态跟踪2023/3/18第20页/共156页21需求开发可进一步分为：问题获取（elicitation）、分析（analysis）、编写规格说明（specification）和验证（verification）四个阶段2023/3/18第21页/共156页22需求开发活动确定产品所期望的用户类获取每个用户类的需求了解用户任务和目标以及业务需求区别任务、功能、业务规则、质量属性、建议解决方法和附加信息需求分子系统，分配给软件组件相关质量属性实施优先级的划分编写成规格说明和模型评审，达到共识2023/3/18第22页/共156页23需求管理活动定义需求基线评审提出的需求变更将需求变更融入到项目中使当前的项目计划与需求一致估计变更产生影响以协商新的承诺需求与设计、源代码和测试用例联系跟踪需求状态及其变更情况2023/3/18第23页/共156页24需求开发和需求管理之间的区别2023/3/18第24页/共156页25客户的需求观软件客户：提出要求、支付款项、项目风险承担、或是获得产品所产生的结果的人。业务需求为后继工作建立了一个指导性的框架。对信息系统、合同（contract）或是应用系统的开发，业务需求应来自风险承担者，而用户需求则应来自产品的真正使用、操作者2023/3/18第25页/共156页26客户权利1.要求分析人员使用符合客户语言习惯的表达。2.要求分析人员了解客户系统的业务及目标。3.要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。4.要求开发人员对需求过程中所产生的工作结果进行解释说明。5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度。6.要求开发人员对产品的实现及需求都要提供建议，拿出主意。7.描述产品使其具有易用、好用的特性。8.可以调整需求，允许重用已有的软件组件。9.当需要对需求进行变更时，对成本、影响、得失（trade-off）有个真实可信的评估。10.获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。2023/3/18第26页/共156页27客户义务1.给分析人员讲解业务及说明业务方面的术语等专业问题。2.抽出时间清楚地说明需求并不断完善。3.当说明系统需求时，力求准确详细。4.需要时要及时对需求做出决策。5.要尊重开发人员的成本估算和对需求的可行性分析。6.对单项需求、系统特性或使用实例划分优先级。7.评审需求文档和原型。8.一旦知道要对项目需求进行变更，要马上与开发人员联系。9.在要求需求变更时，应遵照开发组织确定的工作过程来处理。10.尊重需求工程中开发人员采用的流程（过程）2023/3/18第27页/共156页28需求工程的推荐方法知识技能需求获取需求分析需求规格说明需求验证需求管理项目管理2023/3/18第28页/共156页29知识技能培训需求分析人员了解应用领域并有效地应用需求工程中的成熟技术培训软件需求的用户代表和管理人员明白强调需求的重要性，以及忽略需求带来的风险让开发人员了解应用领域的基本概念关于客户业务活动、术语、目标等编写项目术语汇编2023/3/18第29页/共156页30需求获取确定需求开发过程编写项目视图和范围文档将用户群分类并归纳各自特点选择每类用户的产品代表建立起典型用户的核心队伍让用户代表确定使用实例召开应用程序开发联系会议分析用户工作流程确定质量属性和其它非功能需求通过检查当前系统的问题报告来进一步完善需求跨项目重用需求2023/3/18第30页/共156页31需求分析包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方与客户交流以澄清某些易混淆的问题，并明确哪些需求更为重要分析的目的在于开发出高质量和具体的需求，这样你就能作出实用的项目估算并可以进行设计、构造和测试绘制系统关联图创建用户接口原型分析需求可行性确定需求的优先级别为需求建立模型创建数据字典使用质量功能调配将产品特性、属性与对客户的重要性联系起来期望需求、普通需求、兴奋需求2023/3/18第31页/共156页32需求规格说明采用SRS模板指明需求的来源使用实例或其它客户要求更高层系统需求、业务规范、政府法规、标准或别的外部来源为每项需求注上标号记录业务规范创建需求跟踪能力矩阵把每项需求与实现、测试它的设计和代码部分联系起来把功能需求和高层的需求及其它相关需求联系起来了2023/3/18第32页/共156页33需求验证验证是为了确保需求说明准确、完整地表达必要的质量特点客户的参与在需求验证中占有重要的位置审查需求文档以需求为依据编写测试用例编写用户手册确定合格的标准2023/3/18第33页/共156页34需求管理建立起良好的配置管理方法是进行有效需求管理的先决条件确定需求变更控制过程建立变更控制委员会进行需求变更影响分析跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性使用需求管理工具2023/3/18第34页/共156页35项目管理项目计划建立在功能基础之上，而需求变更会影响这些计划选择一种合适的软件开发方法生存周期基于需求的项目计划发生需求变更时协商项目约定编写文档和管理与需求相关的风险跟踪需求工程所耗的工作量2023/3/18第35页/共156页36统一建模语言UML中国科学院软件研究所许舒人shuren@2023/3/18第36页/共156页37UML图九种图用例图（usecasediagram）顺序图（sequencediagram）协作图（collaborationdiagram）类图（classdiagram）对象图（objectdiagram）状态转移图（statetransitiondiagram）活动图（activitydiagram）构件图（componentdiagram）部署图（deploymentdiagram）UML2.0的新图组合结构图（compositestructurediagram）交互概览图（interactionoverviewdiagram）时序图（timingdiagram）包图（packagediagram）2023/3/18第37页/共156页模型和图UML用多个视图来展示一个系统这组视图成为一个模型模型是一个特定系统的完整描述分类用例图（Use-Case）静态图（Staticdiagram）类图、包图对象图行为图（Behaviordiagram）状态图活动图交互图（Interactivediagram）顺序图协作图实现图（Implementationdiagram）构件图部署图2023/3/1838部署图用例图类图对象图构件图活动图状态图协作图顺序图模型库第38页/共156页UML元素392023/3/18第39页/共156页2023/3/1840体系结构和UML组织：包、子系统动态：交互、状态机逻辑视图构件视图过程视图构件类、接口、协作活动类部署视图节点用例视图用例第40页/共156页RUP工作流间关系41业务建模需求分析设计实现测试业务用例模型业务对象模型用例模型分析模型设计模型实现模型测试模型2023/3/18第41页/共156页42在开发过程中运用UML需求获取发现领域过程→活动图领域分析→高层类图、会谈记录识别协作系统→部署图发现系统需求→细化类图、高层用例将结果交给用户分析理解系统的用法→用例图充实用例→用例说明细化类图→细化类图分析对象状态变化→状态图定义对象间的交互→顺序图、协作图分析与协作系统的集成→部署图、数据模型设计开发和细化对象图→对象图、活动图开发构件图→构件图制定部署图→部署图设计和开发GUI原型→屏幕界面原型测试设计→测试脚本开始编制文档→文档的结构开发编制代码→代码测试代码→测试结果构建GUI和GUI到代码的连接及测试→带有用户界面的功能系统完成文档→文档部署编制备份和恢复计划安装最终系统→部署好的计算机系统测试按装后的系统→测试结果庆祝→新系统JAD：联合应用开发会议2023/3/18第42页/共156页43用例图用例图，从用户角度描述系统行为功能（行为），并指出各功能的操作者参与者（actor）一个人一个系统又称“主角”用例（usecase）参与者使用用例系统（system）硬件和软件的结合体业务问题的解决方案2023/3/18第43页/共156页44系统、参与者、用例2023/3/18第44页/共156页45包含、扩展补货扩展点在填充隔层之前根据销售情况补货打开柜门关闭柜门2023/3/18第45页/共156页46泛化_用例买饮料买一听饮料买一杯饮料2023/3/18第46页/共156页47泛化_参与者厂商代理采购员保管员2023/3/18第47页/共156页48行为图行为图（Behaviordiagram），描述系统的动态模型和组成对象间的交互关系状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动用例行为对象行为2023/3/18第48页/共156页活动图显示工作步骤（活动）、判断点和分支活动起点、终点活动转移判定直接、判定符号条件并发信号输出事件输入事件泳道：明确角色职责对象节点：明确输入和输出;钉处理异常异常句柄活动析构时间流失、流程结束节点约束符号交互概览图活动图和交互图的组合每个活动都是一个独立的交互图492023/3/18第49页/共156页发送和接收事件50：电视显示新频道改变（频道）遥控器键按下（频道）改变（频道）按频道号码看2023/3/18第50页/共156页时间、接收、异常51手动设置时间时间时间时间时间显示时间接收时间校准信号信号中断信号接收时间1秒时间:=时间+1秒3-6分上午2:00-5:00（东部时间）定点2023/3/18第51页/共156页52状态图对象改变了自身的状态以响应事件和时间的流失UML状态图就能捕捉这些状态变化焦点是一个对象的状态变化状态起点、终点状态名活动列表入口动作（entry）出口动作（exit）动作（do）状态转移：触发器事件、无触发器转移组成状态：历史状态（记住子状态、深H*、浅H）子状态：顺序子状态、并发子状态连接点：进入一个状态或退出一个状态的位置2023/3/18第52页/共156页53初始、终止状态2023/3/18第53页/共156页54传真机状态转移发传真entry/输入对方传真号exit/完成传输do/加时间戳空闲entry/传真完成exit/开始传真2023/3/18第54页/共156页55PC状态转移打开PC初始化do/引导工作中屏幕保护[时间到]关机关机中按键或移鼠标2023/3/18第55页/共156页56顺序、并发、历史状态等待用户输入修改显示工作中监视系统时钟[时间到]按键或移鼠标[时间间隔到]输入保存用户输入显示用户输入Ｈ2023/3/18第56页/共156页57入口和出口在书架上[已预约]正在办理借出结束2023/3/18第57页/共156页静态图静态图(Staticdiagram)，包括类图、对象图和包图类图描述系统中类的静态结构（模仿现实世界、客户术语）属性、操作、责任对象图是类图的实例，对象图只能在系统某一时间段存在对象名：类名、：类名包图由包或类组成，表示包与包之间的关系包图用来对一个图的元素进行分组，描述系统的分层结构全限定名：包名::包元素名路径名：包::类关系：泛化、依赖和细化582023/3/18第58页/共156页59类图类（领域知识的词汇）属性：属性名:类型=缺省值操作（型构）操作名(参数:类型)操作名():类型职责类的缺省表示法缺省符：…用构造型来组织属性和操作列表约束：{规则}注释可见性其他类可访问的属性和操作的范围共有：其他类，“+”受保护：子类，“#”私有：类本身，“-”作用域实例：每个实例对象都有自己的属性和操作分类符：所有实例只存在一个属性和操作2023/3/18第59页/共156页60可见性电视+商标+型号……+调音量()-在屏幕上绘图像()#修改里程计数()……2023/3/18第60页/共156页61关系-关联关联关联名字、方向、角色、约束关联类链：对象间的关系多重性一对一、一对多、一对“一或多”、一对“零或一”、……限定关联限定符：ID信息自身关联2023/3/18第61页/共156页62关联上的约束银行出纳员服务{排队}顾客{排队}2023/3/18第62页/共156页63{or}约束高中生选择选择理科文科2023/3/18第63页/共156页64关联类、链球员球队雇员雇主合同总经理商议2023/3/18第64页/共156页65链齐达内：球员踢球法国队：球队2023/3/18第65页/共156页66自身关联司机开车汽车乘坐者乘客2023/3/18第66页/共156页67关系-泛化、依赖继承和泛化基类或根类叶类单继承多继承抽象类依赖使用了另一个类通常是操作的型构中用到另一个类的定义如：displayForm(f:Form)2023/3/18第67页/共156页68泛化哺乳动物马2023/3/18第68页/共156页69依赖系统表格2023/3/18第69页/共156页70关系-聚集、组成聚集整体-部分关联约束组成强类型的聚集每个部分只能属于一个整体组合结构图展示潜入在一个类中的那些类使该类的内部结构变得可见2023/3/18第70页/共156页71聚集膳食汤沙拉主食餐后甜点2023/3/18第71页/共156页72组成茶几桌面腿2023/3/18第72页/共156页73接口和实现接口描述类的部分行为的一组操作提供给其他类使用的一个操作集所有操作的可见性都是共有的用没有属性的类表示，<<interface>>实现一个类和它的接口之间的关系一个类可以实现多个接口一个接口也可以被多个类实现接口和端口2023/3/18第73页/共156页74类和接口洗衣机控制钮2023/3/18第74页/共156页75接口的省略表示法洗衣机控制钮2023/3/18第75页/共156页76接口和类交互洗衣机控制钮人2023/3/18第76页/共156页77球窝洗衣机人2023/3/18第77页/共156页78端口鼠标计算机鼠标口2023/3/18第78页/共156页79交互图交互图（Interactivediagram），描述对象间的交互关系顺序图显示对象之间的动态协作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互消息：发送对象对接收对象的一个请求，要求接收对象完成一个操作时间从上到下延续协作图描述对象间的协作关系，协作图跟顺序图相似，显示对象间的动态协作关系时间顺序用消息前的序号表示2023/3/18第79页/共156页80顺序图对象生命线激活消息调用消息返回消息异步消息时间实例顺序图：描述一个场景一般顺序图：描述所有场景条件if：[表达式]While：*[表达式]最终消息前加上<<transactionover>>在消息序列中创建对象实例对象销毁帧化顺序图sd交互事件ref交互片断组合alt交互片断并发par2023/3/18第80页/共156页创建对象实例81:顾客按键(信用卡号):手机:面板处理顾客信息(信用卡号)显示提示(确认)按键(选择)处理顾客信息(选择)检查可用性(选择)可用:交易记录:售货机释放饮料(选择)接收饮料(选择)2023/3/18第81页/共156页销毁对象实例82:交易记录:面板:交易记录2023/3/18第82页/共156页帧化顺序图83:顾客接受(现金,选择):登记:面板显示提示(“用零钱”):售货机释放饮料(选择)[选择有货]接收饮料(选择)获取顾客输入(现金,选择)[现金>价格]找零(现金,价格)[没零钱]退回现金(现金)《transactionover》[没零钱]检查存货(选择)[售完]显示提示(“售完”)《transactionover》[售完]退回现金(现金)修改(现金,价格)[现金>价格]接收找零(现金,价格)《transactionover》Sd买饮料2023/3/18第83页/共156页帧化交互事件84《transactionover》:顾客接受(现金,选择):登记:面板:售货机释放饮料(选择)[选择有货]接收饮料(选择)获取顾客输入(现金,选择)检查存货(选择)修改存货(现金,价格)Sd买饮料最佳情况有货2023/3/18第84页/共156页复用交互事件85:顾客接受(现金,选择):登记:面板:售货机释放饮料(选择)接收(零钱)获取顾客输入(现金,选择)检查存货(选择)修改存货(现金,价格)Sd买饮料不合适零钱有货找零(现金,价格)2023/3/18第85页/共156页条件执行86:顾客接受(现金,选择):登记:面板显示提示(“用零钱”):售货机释放饮料(选择)[选择有货]接收饮料(选择)获取顾客输入(现金,选择)[现金>价格]找零(现金,价格)[没零钱]退回现金(现金)《transactionover》[没零钱]检查存货(选择)显示提示(“售完”)[售完]退回现金(现金)修改(现金,价格)[现金>价格]接收找零(现金,价格)《transactionover》Sd买饮料[else]《transactionover》2023/3/18第86页/共156页并行执行87:顾客:登记:面板显示提示(“用零钱”):售货机释放饮料(选择)[选择有货]接收饮料(选择)获取顾客输入(现金,选择)《transactionover》[没零钱][售完]显示提示(“售完”)退回现金(现金)[现金>价格]接收找零(现金,价格)《transactionover》Sd买饮料接受(现金,选择)[没零钱]退回现金(现金)[现金>价格]找零(现金,价格)检查存货(选择)修改(现金,价格)《transactionover》[售完]2023/3/18第87页/共156页协作图顺序图与协作图语义等价顺序图强调交互的时间顺序（按时间布局）协作图强调交互的语境和参与交互的对象的整体组织（按空间布局）对象图是一个快照，协作图是一部电影状态变化和消息嵌套3.1:<<become>>互斥保护条件的消息编号[yes]2.1go()<<transactionover>>[no]2.1stop()多对象一叠返回值表示法变量:=操作名（参数[，参数]）主动对象边框加粗同步表示法序号/消息882023/3/18第88页/共156页89实现图实现图（Implementationdiagram），与计算机系统密切相关构件图描述代码构件的物理结构及各构件之间的依赖关系。有助于理解构件间的相互影响部署图定义系统中软硬件的物理体系结构计算机、外设，之间的连接驻留的软件2023/3/18第89页/共156页90构件图软件构件是软件系统的一个物理单元作为一个或多个类的实现构件驻留在计算机中构件定义了一个系统的功能工件是一个构件的实现部署构件、工作产品、执行构件目的使客户能够看到最终系统的结构和功能让开发者有一个工作目标让文档编写者能够理解所写文档是关于哪些方面的内容利于复用（构件重要特征）构件接口只能通过构件的接口来使用构件定义的操作提供接口所需接口替换：只要新构件符合旧构件的接口实现（构件和构件的接口关系）构件图恰好包括构件、接口和关系黑盒、白盒（在构件中列出接口，并用关键字分组）连接点、汇编连接、委托连接2023/3/18第90页/共156页91部署图部署图：展示工件如何在系统硬件上部署，以及各个硬件部件如何相互连接节点：各种计算机资源的统称处理器：能够执行软件构件部署工件设备连接：节点之间的连线2023/3/18第91页/共156页92UML2.0新图组成结构图交互概览览图时序图包图2023/3/18第92页/共156页组合结构图93人灵魂肉体2023/3/18第93页/共156页交互概览图94:用户:用户:用户:图书馆数据库:图书馆员:保安查找()办理借阅请求()拿走书()查证借阅()走出图书馆()到存书位置2023/3/18第94页/共156页时序图95:洗衣机甩干………..漂洗………………….洗涤…………..浸泡…..2023/3/18第95页/共156页包图962023/3/18第96页/共156页97业务建模中国科学院软件研究所许舒人shuren@2023/3/18第97页/共156页2023/3/1898模型在许多学科中，模型是设计者的语言模型是系统要被创建的描述模型是不同的投资者通信的手段可视化模型，蓝图范围模型允许推断真实系统的某些特征第98页/共156页2023/3/1899为什么需要业务模型?建立客观系统软件的开发标准软件客户化业务工程成本核算工作流系统的实施ISO9000质量论证模型目的业务状况-今天(现状)-明天(目标)第99页/共156页2023/3/18100哪些对象能用于描述企业?功能检查信用度，输入客户订单，...数据商品，客户，材料，供应商，...组织单元销售，采购，会计，生产部门，...事件客户订单已到达，发票已寄出，...资源PC，文件，车床，...服务/产品BPR咨询，芯片，电路板，PC，…这些不同对象不是孤立的，存在相互关系。第100页/共156页2023/3/18101怎样描述?文本： “销售部负责核查客户的信用度。”表格：图形：功能组织单元关系核查信用度销售部负责第101页/共156页2023/3/18102形式化描述管理体系形式化描述的含义是：用确定的、无二意的一套表达规则来描述组织管理体系。为什么必须对管理体系进行形式化描述？只有被形式化描述的客观事务才能够被计算机所理解。形式化描述方法的要求：管理的形式化描述是衔接管理体系和管理信息系统桥梁管理体系管理信息系统形式化描述第102页/共156页2023/3/18103业务模型业务拥有或消耗资源具有目的的操作业务模型业务功能的抽象描述业务的简化表述核心概念是业务过程集中表现业务的核心任务及其关键机制业务所有者设定目标分配资源运作业务业务模型构架师建立基础结构设计业务流程分配资源实现业务目标系统开发人员改造、设计或开发配套的信息系统支持业务运作第103页/共156页业务模型作用提高竞争力的需要适应环境竞争者分包商供应商法律、法规客户加强自身内部运作产品和服务改进新市场和用户信息系统作用专注于事物的重要方面促进交流作为其他模型的基础目的理解现行业务关键机制建立信息系统的基石改进现行业务基础展示革新后的业务结构尝试新的业务理念用以确定外部机遇2023/3/18104第104页/共156页2023/3/18105模型组成视图一个业务模型以数个不同的视图表示一个特定观点的抽象描述图表每个视图由多个图表组成每个图表表达了业务结构的特定部分或特定的业务状态这些图表包含并表述了业务状态中的对象、过程、规则、目标和愿景对象和过程对象是业务中的事物过程是业务中的活动模型是由目标推动的第105页/共156页业务建模分类CIM-OSA（ComputerIntegratedManufacturing-OpennessSystemArchitecture）欧共体ARIS（ArchitectureofIntegratedInformationSystem）德国IDEF（ICAM（IntegratedComputer－AidedManufacturing）DEFinition）包含功能模型、信息模型和动态模型等美国GRAI/GIM（GraphwithResultsandActivitiesInterrelated）法国BAAN/DEM（DynamicEnterpriseModeling）BaaN公司UML（UnifiedModelingLanguage）OMG组织扩展UML2023/3/18106第106页/共156页2023/3/18107UML业务建模类图对象图状态图活动图顺序图协作图用例图构件图部署图第107页/共156页2023/3/18108Eriksson-Penker扩展视图业务愿景愿景陈述概念建模目标问题建模业务过程（活动和价值）过程建模装配线图装配线图和用例业务结构（资源结构）资源建模信息建模组织建模业务行为（个体行为和交互）状态建模交互建模图表愿景陈述图概念模型目标模型过程图装配线图用例图资源模型组织模型信息模型状态图交互图系统拓扑图第108页/共156页对应关系愿景陈述图────────文本描述概念模型────────类图目标模型────────对象图过程图────────活动图装配线图────────活动图用例图────────用例图资源模型────────类图组织模型────────类图|对象图信息模型────────类图|对象图状态图────────状态图交互图────────顺序图|协作图系统拓扑图────────类图（包图）2023/3/18109第109页/共156页业务过程1102023/3/18第110页/共156页业务建模元模型1112023/3/18第111页/共156页业务模式1122023/3/18第112页/共156页113RUP业务建模过程评估业务状态描述当前业务确定业务流程改进业务流程设计业务流程实现改进角色和职责研究流程自动化开发领域模型第113页/共156页114业务建模活动第114页/共156页115需求分析中国科学院软件研究所许舒人shuren@2023/3/18第115页/共156页常用的需求分析方法面向数据流的结构化分析方法（SA）面向数据结构的Jackson方法（JSD）结构化数据系统开发方法（DSSD）面向对象的分析方法（OOA）等1162023/3/18第116页/共156页面向数据流的结构化分析业务分析(IPO)范围目标和任务组织机构职能范围与外界联系业务流程业务1业务2…信息系统存在问题对信息系统期望数据分析(DFD)范围任务概述目标用户特点信息系统边界功能分析数据流分析顶层分解业务1业务2…性能分析1172023/3/18第117页/共156页信息传递118日常业务处理业务控制管理控制战略规划分解和具体化综合和抽象化2023/3/18第118页/共156页面向对象分析面向对象分析的目的完成对问题空间的分析建立系统模型具体任务：确定和描述系统中的对象对象的静态特性和动态特性对象间的关系对象的行为约束1192023/3/18第119页/共156页分析原则构造和分解相结合构造：基本对象组装复杂对象分解：对大粒度对象精化抽象和具体化相结合抽象：数据、操作→对象具体化：细节刻画，确定对象，提高模型稳定性封装：独立的外部特性与内部实现细节分开相关静态结构关联：如整体和部分动态结构关联：如消息传递行为约束：静态、动态1202023/3/18第120页/共156页静态结构分析确定对象、对象类对象一种具有简明界面及应用意义的实体的抽象对象类一组具有共同属性、操作和语义特征的对象属性是类中对象的性质操作是类中对象的行为确定对象类之间的关系1212023/3/18第121页/共156页确定对象类之间的关系一般化和特殊化关系高层次的类表达共性，形成父类低层次的类表达个性，形成子类子类通过继承机制来获得父类的属性和操作聚合关系：对象之间的组合构造关系聚合对象：容器对象组成对象：内含对象聚合对象通过组成对象的操作来实现自身的操作关联关系：引用关系和消息传递关系一对一、一对多、多对多1222023/3/18第122页/共156页动态行为分析动态行为分析单个对象自身的生命周期演化整个对象系统中对象间的消息传递和协同工作静态结构限制了对象状态的取值范围对象状态的变化是通过对象操作来完成的事件可以由操作调用来表达对象操作可以是并发的，对象状态的变化也可以是并发的1232023/3/18第123页/共156页开发领域模型确定所有对于业务领域来说比较重要的产品、可交付工件和事件详细说明业务实体的定义正式核实业务对象建模的结果是否符合涉众对业务的看法核心开发团队领域专家2023/3/18124第124页/共156页领域模型领域模型描述领域中系统之间的共同的需求领域模型是逻辑模型，而不是物理模型领域模型是面向问题域的2023/3/18125第125页/共156页领域特定的软件构架领域特定的软件构架（DomainSpecificSoftwareArchitecture）DSSA描述在领域模型中表示的需求的解决方案DSSA不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计DSSA是面向解空间的2023/3/18126第126页/共156页2023/3/18127领域工程与应用工程行为产品领域工程应用工程系统1系统2系统n领域分析领域设计领域实现领域模型DSSA领域构件分析用户需求设计应用系统规约应用系统实现应用系统构架应用系统第127页/共156页领域分析“标识一个特定问题领域中一类相似系统的对象和操作的活动”关心相似系统的共性分析、设计的复用代码的复用借助用户的智能，提高系统的适应性，灵活性1282023/3/18第128页/共156页领域分析的步骤129

概览领域需求

确定领域边界

主题文档分析领域专家交互

确定体系结构领域共性分析抽取领域构件软件进化设计领域知识库设计2023/3/18第129页/共156页需求分析目的与客户和其他相关人员在系统的工作内容方面达成并保持一致使系统开发人员能够更清楚地了解系统需求定义系统边界为计划迭代的技术内容提供基础为估算开发系统所需成本和时间提供基础定义系统的用户界面，重点是用户的需要和目标1302023/3/18第130页/共156页如何看待IT在企业中的作用1CEO：使IT目标和业务目标相一致；借助IT完善业务流程；提高业务有效性；增强企业竞争优势；提高内部客户满意度；控制IT成本。更关注应用新技术建立企业竞争优势，完善供应链。CIO：借助IT完善业务流程；提高业务有效性；使IT目标和业务目标相一致；提高客户满意度；增强企业竞争优势；控制IT成本。更重视IT系统建设及IT成本的控制。1312023/3/18第131页/共156页如何看待IT在企业中的作用2一半的CEO认为IT具有“前瞻性”68%的CIO认为，IT应当“前瞻性”地预测出业务发展时机，并运用技术来实现。只有56%的CEO认同这一观点。44%的CEO认为，IT应当支持并促进企业已划定的业务拓展活动。CEO比较注重CIO和CXO间的关系在培养IT员工的业务和领导技巧方面，CEO认为有效性是3.7，CIO认为是3.2。1322023/3/18第132页/共156页如何看待IT在企业中的作用3CEO对技术性知识技能评价更高技能有：有效沟通，战略制定和实施，熟练掌握业务流程和操作等对于技术性知识技能的评价，CEO所占比重是33%,CIO是19%；在了解行业趋势、市场动向及业务策略的选项上，CEO所占比重是33%，CIO是27%。CEO认为建立竞争优势对企业影响更大CEO把“促进竞争优势的形成”列为第二大贡献，CIO则把它列为第五1332023/3/18第133页/共156页与其他工作流程的关系业务建模业务规则、业务用例模型和业务对象模型分析设计从需求中获取主要输入（用例模型和词汇表）发现用例模型的缺陷；随后将生成变更请求，并应用到用例模型中。测试验证代码是否与用例模型一致用例和补充规约为测试需求提供输入环境需求管理和用例建模中使用的支持性工件管理制定项目计划制定需求管理计划用例模型是计划重要输入1342023/3/18第134页/共156页需求开发过程组织理解要解决的问题理解涉众需求定义系统不断地管理范围和变更精炼系统定义构造正确的系统管理需求过程1352023/3/18第135页/共156页组织团队就将要采用的基本软件过程达成一致用一两页的需求管理计划，从过程和文档的角度，确定如何管理该项目的需求确定这个项目将要采用的软件工具的种类确定代码和需求文档的配置管理计划建立迭代计划，确定基本项目规则和报告制度1362023/3/18第136页/共156页理解要解决的问题执行5步问题分析过程就要解决的问题达成一致，形成文字理解问题的主要原因识别系统中的涉众定义系统边界。写下边界，用系统环境图或初步的用例图标识涉众识别对解决方案的限制约束，形成文字向外部涉众传播问题陈述，并坚持就问题陈述达成一致后才进行下一步工作1372023/3/18第137页/共156页138理解涉众需求用通用的模板建立项目的访谈计划访问已识别的5-15位涉众总结访谈结果：聚合前10-15条用户需求或引用用户自己的词汇精炼用户10-15条需求开始需求金字塔（需求/特性/软件需求）推动项目需求会举行头脑风暴会议，识别或精炼特性完成想法缩减和特性优先顺序用“关键、重要和有用”分类在项目过程中举行一两次需求会提供用户输入格式对所有创新概念建立示意板。给用户演示用例并获得反馈意见确保过程尽早