ECSAD04(13)-2电商

1、ZZU 电子商务系统分析与设计第四章 电子商务系统分析ZZU4 4 电子商务系统分析电子商务系统分析概述系统分析的主要工具详细调查和分析基于UML的需求分析提出系统逻辑方案系统分析报告| 5/27/2022 |Page 1ZZU4.4 4.4 基于基于UMLUML的需求分析的需求分析 n 面向对象与面向过程u面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。u面向对象以 数据（属性）为导向，将具有相同一个或者多

2、个属性的物体抽象为“类”，将他们包装起来；而有了这些数据（属性）之后，我们再考虑他们的行为（对这些属性进行什么样的操作），面向过程以 功能（行为）为导向，按模块化的设计，在你在脑袋中也许也有一个类似“类”的概念，但是表现出来的是属性与行为的分离 2ZZU4.4 4.4 基于基于UMLUML的需求分析的需求分析 n 面向过程其实是最为实际的一种思考方式，就是面向对象的方法也是含有面向过程的思想。可以说面向过程是从上往下步步求精。所以面向过程最重要的是模块化的思想方法。对比面向对象，面向对象主要是把事务给对象化。n 当系统规模不是很大时，面向过程的方法还会体现出一种优势，因为系统和程序的的流程很清

3、楚，按着模块与函数的方法可以很好的组织。n 比如拿学生早上的事情来说过程，粗粗的可以将过程拟定为：起床，穿衣，洗脸刷牙，吃饭，去上课 3ZZU4.4 4.4 基于基于UMLUML的需求分析的需求分析 n UML概述n UML主要内容n 需求的面向对象描述n UML建模 4ZZU54.4.1 UML4.4.1 UML概述概述ZZU4.4.1 UML4.4.1 UML概述概述n 什么是UMLuUML是一种Language（语言）uUML是一种Modeling（建模）LanguageuUML是Unified（统一）Modeling Languageu已进入全面应用阶段的事实标准u应用领域正在逐渐扩展

4、，包括嵌入式系统建模、业务建模、流程建模等多个领域u成为“产生式编程”的重要支持技术：MDA、可执行UML等 6ZZU4.4.1 UML4.4.1 UML概述概述n UML特点u统一的标准u面向对象u可视化u独立于过程u易于使用 7ZZU4.4.1 UML4.4.1 UML概述概述n UML发展历程 8ZZU4.4.1 UML4.4.1 UML概述概述n 什么是模型：模型是对现实的简化 9ZZU4.4.1 UML4.4.1 UML概述概述n 为什么使用UML建模uUML是一种统一的、标准化的建模语言 uUML是一种应用面很广泛的建模语言 10ZZU4.4.1 UML4.4.1 UML概述概述n

5、 UML可以建立什么模型 11模型的种类模型的用途业务模型对业务过程、工作流、组织的建模需求模型对捕获的需求进行整理和分析的工具，辅助开发人员与用户进行沟通设计模型包含高层设计（架构模型）和详细设计模型，用于统一开发人员、沟通设计信息数据库模型设计数据库的结构、表结构以及与应用系统的交互实现模型用来理清软件的组成、部署方案，为安装与维护人员的工作提供指导ZZU4.4.1 UML4.4.1 UML概述概述n 谁应该建模u业务建模：以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与u需求模型：以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与u设计模型：高层

6、设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。详细设计模型则以资深开发人员为主，架构师提供指导。u实现模型：以资深开发人员（设计人员）为主，架构师提供总体指导。u数据库模型：以数据库开发人员为主，架构师提供指导，资深开发人员（设计人员）予以配合。 12ZZU4.4.2 UML4.4.2 UML主要内容主要内容n UML定义包括语义和表示法两类uUML语义 描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明，使开发者能在语义上取得一致，消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型

7、的扩展定义。uUML表示法 定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型，在语义上它是UML元模型的实例。UML的重要内容可以由下列五类图（共10种图）来定义： 13ZZU4.4.2 UML4.4.2 UML主要内容主要内容 14ZZU4.4.2 UML4.4.2 UML主要内容主要内容 15ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 用例图概要u用例图是被称为参与者的外部用户所能观察到的系统功能的模型图。u用例图列出系统中的用例和系统外的参与者，并显示哪个参与者参与了哪个

8、用例的执行 (或称为发起了哪个用例)。u用例图多用于静态建模阶段(主要是业务建模和需求建模)。u用例图能描述系统、子系统、或类的行为。它将系统功能划分成对参与者有用的需求。站在用户的角度看待系统、定义系统 ；使用用户能够看懂的语言来表述。表示处于同一系统中的参与者和用例之间的关系的图。 16ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 用例图概要u用例模型是把应满足用户需求的基本功能集聚合起来表示的强大工具u对于正在构造的新系统用例描述系统应该作什么u对于已构造完毕的系统用例则反映了系统能够完成什么样的功能u表示法：用例图是包括参与者、由系统边界（一个矩形）封

9、闭一组用例、参与者和用例之间的关联、用例间的关系以及参与者泛化的图。 17ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 用例图中元素及解释u参与者(Actor)p在系统外部与系统直接交互的人或事物(如另一个计算机系统或一些可运行的进程)。我们需要注意的是：l1.参与者是角色(role)而不是具体的人，它代表了参与者在与系统打交道的过程中所扮演的角色。所以在系统的实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。l2.参与者作为外部用户(而不是内部)与系统发生交互作用，是它的主要特征。l3.在后面

10、的顺序图等中出现的“参与者”，与此概念相同，但具体指代的含义，视具体情况而定。p一个参与者可以执行多个用例，一个用例也可以由多个参与者使用 18ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 用例图中元素及解释u参与者(Actor)pUML表示u用例(Use Case)p系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达 。p用例的用途是在不揭示系统内部构造的情况下定义连贯的行为。p用例的定义包含用例所必需的所有行为p表示法：用例用一个包括用例名的椭圆形来表示 19ZZU4.4.2 UML4.4

11、.2 UML主要内容主要内容- -用例图用例图n 用例图中元素及解释u系统边界p系统边界：描述了系统的边界，以及描述了外部系统与系统之间交互的边界p表示法：p用封闭所有用例的矩形表示 20用例1用例2ZZU21软件解软件解决方案决方案I/OI/O系统边界系统边界?其他系统aActorZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图 22关系解释图参与者与用例之间的关系关联表示参与者与用例之间的交互，通信途径。(关联有时候也用带箭头的实线来表示，这样的表示能够显示地表明发起用例的是参与者。)用例之间的关系包含箭头指向的用例为被包含的用例，称为包含用例；箭头出发的用例为

12、基用例。包含用例是必选的，如果缺少包含用例，基用例就不完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的行为。 include扩展箭头指向的用例为被扩展的用例，称为扩展用例；箭头出发的用例为基用例。扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。 extend参与者之间的关系泛化发出箭头的事物“is a”箭头指向的事物。泛化关系是一般和特殊关系，发出箭头的一方代表特殊的一方，箭头指向的一方代表一般一方。特殊一方继承了一般方的特性并增加了新的特性。ZZU4.4.2 UML4.4.2 UML主要内容主要内

13、容- -用例图用例图n 用例建模u构建用例模型是通过开发者与客户，或最终使用者共同协商完成的。u经过反复讨论需求的规格说明，达成共识，明确系统的基本功能，为后阶段的工作打下基础。u确定系统应具备哪些功能、为系统的功能提供清晰一致的描述、为系统验证工作打下基础、提供跟踪进入系统中具体实现的类和方法，检查其是否正确的能力。 23ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 1识别系统边界和参与者 通过向用户提问来识别角色：u谁使用系统提供的主要功能？（主要参与者）u谁来维护、管理系统？（次要参与者）u谁需要借助于系统完成日常工作任务？u系统需要控制的硬件设备有哪些

14、？u系统需要与其他哪些系统交互？u系统从哪儿得到信息？u对系统产生的结果感兴趣的人或事是哪些？ ！不能把目光只专著于人身上。不能把目光只专著于人身上。 24ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n ATM系统的Actoru1、谁使用ATM系统的主要功能（提款）？u答：储户答：储户u2 2、谁使用、谁使用ATMATM系统的支持以完成日常工作任务？系统的支持以完成日常工作任务？u答：出纳员？还不肯定，先放在这里答：出纳员？还不肯定，先放在这里u3 3、谁来维护、管理并保持系统正常运行？、谁来维护、管理并保持系统正常运行？u答：答： ATMATM系统工程师，银行

15、人员系统工程师，银行人员u4 4、该系统需要和哪些系统交互？、该系统需要和哪些系统交互？u答：目前还不清楚答：目前还不清楚 25ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图u5、ATM系统需要处理哪些设备？u答：信用卡答：信用卡u6 6、谁对、谁对ATMATM系统运行的结果感兴趣？系统运行的结果感兴趣？u答：银行会计、储户答：银行会计、储户n ATM系统的Actor 26?储户?信用卡?银行人员?银行会计ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 2识别用例u首先弄清楚系统的问题域、业务流程，整理出系统的功能需求，在此基础上结

16、合已经识别出来的角色识别、抽象出系统用例，定义并描述它。u针对参与者p某个参与者要求系统为其提供什么功能；该角色需要做哪些工作？p参与者需要阅读、创建、销毁、更新或存储系统中的某些（类）信息？p系统中的事件一定要告知参与者吗？参与者需要告诉系统一些什么？p由于系统新功能的识别，参与者的日常工作被简化或效率提高了？ 27ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 识别用例u针对系统p系统需要什么样的输入和输出？输入来自哪里？输出去往哪里？p该系统的当前状况还存在哪些问题？p改进的方向？ 28ZZU29订票顾客查询车次用户观点处理订票顾客显示车次系统观点用例：1

17、. 呼叫某人2. 接听电话3. 发送短消息4. 记住电话号码。功能：1. 传输/接收2. 电源/基站3. 输入输出（显示、键盘）4. 电话簿管理。ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 用例描述模板 30v 用例编号用例编号v 用例名用例名v 用例描述用例描述v 参与者参与者v 前置条件前置条件v 后置条件后置条件v 基本路径基本路径 1, 1, .X X X X.X X X X 2. 2. .X X X X.X X X Xv 扩展点扩展点 2a. 2a. .X X X X.X X X X 2a1. 2a1. .X X X X.X X X Xv 变异点变

18、异点v 补充说明补充说明ZZU31v 用例编号用例编号:001:001v 用例名用例名:ATM:ATM取款取款v 用例描述用例描述: :储户使用信用卡，在储户使用信用卡，在ATMATM机上取款机上取款v 参与者：储户参与者：储户v 前置条件：前置条件：ATMATM机器处于正常准备状态机器处于正常准备状态v 后置条件：若成功，则储户取出钱，帐户上扣除钱；若失后置条件：若成功，则储户取出钱，帐户上扣除钱；若失败，储户没有取到钱，帐户上钱数不变。败，储户没有取到钱，帐户上钱数不变。v 基本路径基本路径 1, 1, 储户插卡；储户插卡； 2. ATM2. ATM机提示输入用户口令；机提示输入用户口令；

19、 3.3.储户输入口令；储户输入口令； 4.ATM4.ATM机口令验证通过，提示输入钱数；机口令验证通过，提示输入钱数； 5.5.储户输入钱数；储户输入钱数； 6.ATM6.ATM机进行钱数有效性检查，提示操作成功，吐出机进行钱数有效性检查，提示操作成功，吐出卡和钱；卡和钱；ATM取取款款用用例例描描述述ZZU32 7.7.储户取走卡和钱；储户取走卡和钱； 8.ATM8.ATM机屏幕恢复为初始状态。机屏幕恢复为初始状态。v 扩展点扩展点 4a. ATM4a. ATM机验证用户口令不通过机验证用户口令不通过 4a1. ATM4a1. ATM机给出提示信息，并吐出信用卡；机给出提示信息，并吐出信用

20、卡； 4a2. 4a2. 储户取出卡；储户取出卡； 4a3. ATM4a3. ATM机屏幕恢复为初始状态机屏幕恢复为初始状态. . 6a. ATM 6a. ATM验证用户输入钱数超过验证用户输入钱数超过30003000 6a1. ATM 6a1. ATM机给出提示信息，并吐出信用卡；机给出提示信息，并吐出信用卡； 6a2. 6a2. 储户取出卡；储户取出卡； 6a3. ATM6a3. ATM机屏幕恢复为初始状态机屏幕恢复为初始状态. .。v 变异点变异点无无v 补充说明补充说明ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 用例之间的关系u扩展（Extend）p

21、一个用例中加入一些新的动作后则构成了另一个用例，这两个用例之间的关系就是通用化关系，又称扩展关系。p后者通过继承前者的一些行为得来，前者通常称为通用化用例，后者常称为扩展用例。p扩展用例只有在基本用例中的某种条件满足时才能执行，如果没有基本用例的运行，扩展用例不能运行p基本用例执行时,扩展用例不一定执行 33ZZU34顾客签订保险单签订汽车购买合同顾客购买商品下载软件浏览网站ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 用例之间的关系u包含（Include）p一个用例使用另一个用例时，这两个用例之间就构成了include关系。p一般情况下如果若干个用例的某些行

22、为都是相同的，则可以把这些相同的行为提取出来，单独作成一个用例，这个用例称为抽象用例 35送货员填写顾客订单提交顾客订单ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 选课系统建设示例u希望构建信息化的课程注册系统p注册管理员首先设置一个学期课程表p学生可以选择4门主课以及2门选修课p一旦学生们选择了学期课程，计费系统间会提示学生本学期的课程费用p学生们可以在注册后的一定期限内使用系统去添加或者删除所选课程p教师使用系统接受课程学生名单p使用系统的用户需要在登陆时提供密码 36ZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 选课系

23、统建设示例u寻找Actorp1、谁使用选课系统的主要功能？答：学生、教授、 注册管理员p2、谁使用选课系统的支持以完成日常工作任务？答：注册管理员p3、谁来维护、管理并保持系统正常运行？答： 注册管理员p4、该系统需要和哪些系统交互？p5、选课系统需要处理哪些设备？p6、谁对选课系统运行的结果感兴趣？答：学生、教授、 注册管理员 37答：计费系统答：无ZZU38与系统交互的与系统交互的ActorActorStudentRegistrarProfessorBilling SystemZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 寻找用例uActors的行为决定了

24、他们的需求p注册管理员：管理和维护课程表p教师：请求学生名单p学生：维护自己的课程安排p计费系统：从注册系统获取费用信息Maintain ScheduleMaintain CurriculumRequest Course RosterZZU4.4.2 UML4.4.2 UML主要内容主要内容- -用例图用例图n 用例图40StudentRegistrarProfessorMaintain ScheduleMaintain CurriculumRequest Course RosterBilling SystemZZU41课程表维护流程示例课程表维护流程示例n 该用例由注册管理员登陆注册系统并输

25、入登陆密码。系统该用例由注册管理员登陆注册系统并输入登陆密码。系统检验密码是正确的（检验密码是正确的（E-1E-1）并提示给注册管理员选择学期（）并提示给注册管理员选择学期（E-2E-2）。注册管理员输入所需要的学期信息。系统给注册管）。注册管理员输入所需要的学期信息。系统给注册管理员提供他所需要的系统操作：增加、删除、审核和退出理员提供他所需要的系统操作：增加、删除、审核和退出。u如果选择了增加活动（S-1）：增加课程自流程被执行；u如果选择了删除活动（S-2）：删除课程自流程被执行；u如果选择了审核活动（S-3）：审核课程表自流程被执行；u如果选择了退出活动（S-4）：用例结束u。ZZU4

26、2用例扩展关系的使用用例扩展关系的使用Register for coursesLogon validationMaintain curriculumZZU实例：航空售票的用例图实例：航空售票的用例图 参与者(actor)：clerk，监督员，信用卡服务商，用户 用例(use case)： Buy tickets， Make charges， Survey sales 参与者Clerk参与(或称发起)Buy tickets。这个用例的事件流都包含Makecharges用例(包含关系)。 系统由：Buy tickets， Make charges， Survey sales组成。 该系统主要包含：

27、Buy tickets， Make charges， Survey sales这几个功能。 该系统主要面向的用户(参与者)：clerk，监督员，信用卡服务商，用户 43 信 息 亭 Clerk Buy tickets Buy Subscription 信 用 卡 服 务 商 Make charges 监 督 员 Survey sales 参 与 者 用 例 Box Office 系 统 关 系 ZZU用例陷阱用例陷阱n 系统边界模糊或者变化无常系统边界模糊或者变化无常n 用例描写来自于系统（并非角色）用例描写来自于系统（并非角色）n 角色名称相互矛盾角色名称相互矛盾n 过多的用例过多的用例n

28、角色和用例的关系连接象蜘蛛网一样（复杂）角色和用例的关系连接象蜘蛛网一样（复杂）n 用例叙述规格过长用例叙述规格过长n 用例规格叙述混乱用例规格叙述混乱n 用例没有正确描述功能用例没有正确描述功能n 用户不可理解用例用户不可理解用例n 用例从来不会结束用例从来不会结束ZZU45如何避免陷阱如何避免陷阱1、定义准确的系统边界2、使用标准化模板书写用例规格3、观察点：只关注目标4、经常检查用例图和用例规格ZZU46本例子是一个球赛售票系统，用户可以查看赛季安排，可在售票厅购买球票，或者打电话订票，还可在使用信用卡支付买票。亭售用户电话用户电话服务员订票信用卡确认系统系统边界？ZZU47上图建模者尝试在同一用例模型中，同时显示业务用户和系统用上图建模者尝试在同一用例模型中，同时显示业务用户和系统用户。电话用户和系统的交互是和其它角色与系统的交互是不同的户。电话用户和系统的交互是和其它角色与系统的交互是不同的n 系统边界为计算机系统时u角色：亭售用户、电话接线员亭售用户电话服务员订票信用卡确认系统计算机系统为系统边界ZZU48n 系统边界为整个企业时u角色：电话用员电话用户订票信用卡确认系统整个企业为系统边界ZZU49不恰当的功能定义不恰当的功能定义亭售用户(from Actors)赛程管理员处理赛程亭售用户(f