典型的电子商务系统基本(需求)功能模型

12.3典型的电子商务系统基本(需求)功能模型1）B2C电子零售系统的基本功能2）B2B电子商务系统的基本功能3）企业信息门户的基本功能4）物流配送系统的功能21）B2C电子零售系统的基本功能用户管理需求的功能客户需求功能销售商需求功能用户注册注册用户信息管理电子目录：帮助用户搜索、发现需要的商品；产品比较：帮助用户进行购买决策；商品评估：购物车下订单撤消和修改订单通过网络付款订单状态跟综客户注册信息检索；客户订单处理；客户选购产品的结算及付款处理；电子拍卖；商品信息发布；网络广告的发布及管理；库存商品管理；产品销售情况跟综；与物流配送系统接口；与银行之间接口；客户关系管理；售后服务32）B2B电子商务系统的基本功能用户：买方企业卖方企业中介（如：银行）物流企业政府机构信息：–产品与服务–买卖企业–供应商–运输企业–仓储企业42）B2B电子商务系统的基本功能会员管理产品目录管理审批流程订单管理交易定价拍卖与投标采购网络支付会员身份管理会员资料管理权限控制目录管理；目录视图；目录查找53）企业信息门户的基本功能企业基本信息发布企业动态与新闻企业产品与服务搜索与索引电子邮件与客户反馈用户访问统计网站访问分析与统计个性化服务电子社区相关链接64）物流配送系统功能合约议定仓储管理货物追踪运输管理客户管理费率管理帐务管理报表管理72.4电子商务系统的分析与设计工具结构化分析与设计方法Jackson分析与设计方法面向对象的分析与设计方法---面向对象建模语言UML82.4.1结构化需求分析方法结构化分析方法的基本出发点是：一个计算机处理系统是由数据流和一系列的处理转换过程构成的，处理转换过程将输入数据流转化为输出数据流，即计算机数据处理过程可以归结为“输入数据（Input）处理转换（Process）输出数据（Output）”这样的IPO过程，所以结构化分析方法将分析的重点集中与数据及其处理过程。结构化分析方法采用数据流图（DFD：DataFlowDiagram）作为刻画数据流及其处理转换的工具，通过一些图形符号表述数据源、数据流向、处理转换等；此外结构化分析方法采用数据字典（DD：DataDictionary）来表示各类数据；可以通过判定表、决策树的方式描述处理转换的过程的细节；9结构化需求分析方法——DFD数据流图以直观的形式描述系统中数据的流动和数据的变化。需要注意的是数据流图和程序设计中的程序流程图（FlowChat）是不同的，数据流图关心的是企业业务系统中的数据处理加工的客观过程，并不关心未来电子化处理的加工过程；数据流图中流动的只是数据，并没有控制过程，但在程序流程图当中，必须有控制逻辑。取款人账目非法提单数据实体数据存储数据流合法性检查合法的取款单处理转换取款单10结构化分析方法——DFD例子顾客汽车配件数据订货单发货单顾客汽车配件数据汽车配件数据暂存订单顾客数据发给供应商的订单供货商订货单订货要求发货单发货单订货处理编辑订单开发货单汇总处理核发订单11一个销售管理系统的DFD图1213142.4.2面向对象的建模语言UML1.面向对象的基本观点前面几种方法的不同在于如何看待一个系统。结构化分析方法把系统看作一系列的功能节点，节点间的联系通过数据流来实现；Jackson方法把系统看作一系列进程，进程间通过数据流和状态向量发生关系；面向对象方法认为系统由一系列彼此独立却又相互联系的实体---对象组成，对象间通过消息传递和数据关联（数据流）来实现相互联系。对象（类）既可是一个实体，也可是一项活动，或一个抽象的东西。152.4.2面向对象的建模语言UML1990s,面向对象分析与设计方法逐渐走向实用，一些专家对系统分析和设计工作的步骤、方法、图形工具等进行了详细的研究，提出了许多不同的实施方案。其中有P.Coad和E.Yourdon方法；Booch方法；J.Rambough的OMT方法；UML方法（集Booch,OMT等方法的优点于一身）。面向对象方法流行的关键在于：1）面向对象看待现实世界的方式和现实世界的组织方式是一致的，它能够直接将问题域结构咉射到系统模型中；2）面向对象方法支持软件重用，可降低成本，提高质量；3）对象具有“自治”特点，扩展性、可维护性大大提高。162.4.2面向对象的建模语言UML2）面向对象的概念类及对象(Class、Object)类是一个封装了数据抽象和过程抽象的单元，该单元能够描述现实世界客观实体的状态和行为。类的属性赋于类状态保持的能力，这就使类能够“生存下去”，同时类的操作使类能够主动变化，实现状态变迁，这样类就又获得了“发展”的能力。这样类就能胜任描述客观世界中的有机实体。继承（Inheritance,泛化）:类的继承可用来表达现实世界中实体的相似性。继承机制使类具有继承和被继承的能力，也就是具有重用和被重用的能力（即具有“进化能力”）类名属性操作父类子类类名属性操作类名属性操作17关联关联用以表明类与类之间所具有的除继承、聚合以外的一种相关性的关系。作者计算机程序员计算机1..*1..1ClassAuthor{public:….Computer*[]pc1;//Author类对象的删除不会删除Computer类对象};18聚合（Aggregation）聚合是类之间的一种整体与部分的特殊关联关系，如汽车包括四个轮子，一台发动机等。舰队舰只组织人论文摘要参考一般聚合共享聚合组成聚合(强聚合)***ClassA1{……A2*pa1;//整体删除//部分不会删除};ClassA1{……A2a1;//整体删除A3a2;//部分应删除};19消息(Message)消息是类(对象)间实现通信的手段，一个类就是通过消息来申请另一个类提供的服务，因此消息中通常会标明要求操作的名称和相应的参数。类受到消息请求后先分析请求的合法性和消息的合法性，然后再操作。消息连接用一条带箭头的线段表示：消息名20多态性（polymorphism）--------良好的可维护性和扩展性多态性是指对象的某个行为具有多种形态的特性。一个行为的多种形态从外界看来具有相同的行为名称（也即相同的消息名），标识一种行为。Move(distant)Move(destination)Move(routine)21面向对象（objectoriented)Coad和Yourdon认为：面向对象=对象+分类+继承+通过消息的通信即：只有应用了对象（属性、操作、行为的封装）去对问题空间的实例进行抽象，并应用分类技术来管理对象，应用继承机制管理对象之间的相似性，并且通过对象间的消息连接来实现对象间通信的方法可称为面向对象方法。222.4.2面向对象的建模语言UML3)UML统一建模语言(UnifiedModelingLanguage)1997.11.17,UML被OMG(ObjectManagementGroup)接收为标准；UML是在Booch,OMT等方法的基础上引入一些新的理论和描述方法，如：模板类型、标记值、限制、线程、进程、分布、并发、模式/合作、活动图、精练、接口、组件、对象约束语言等；UML本身是一个完整的建模语言，支持系统开发的不同阶段，从需求分析----系统测试；需求分析阶段：UML通过用例图（有时也需一些简单的类图、活动图）来捕获用户需求，描述对系统感兴趣的外部角色和他们对系统的功能要求；系统分析阶段：主要关心问题域的概念和实体，并得到与问题域直接相关的类和对象，以及它们之间的关系（类图、顺序图、协作图、状态图、活动图）；设计阶段：需要定义一些与技术实现相关的类，如：用户接口、数据库、通信和并行等问题，UML提供了强大的静态和动态建模机制（类图、顺序图、协作图、状态图、活动图、组件图、实施图）实现阶段：类----语言代码；单元测试阶段：依据类图和类的规格说明集成测试阶段：测试人员依据构件图和合作图；系统测试阶段：测试人员主要依据用例图来验证系统的行为；23UML提供了五类图共九种图形：第一类：用例图（UsecaseDiagram）第二类：类图、对象图、包图第三类：行为图（活动图+状态图）第四类：交互图（顺序图+合作图）第五类：实现图（构件图+配置图）支持UML的开发工具：RationalRoseUML_Designer24用例图用例图=用例+系统边界+角色+角色与用例间的关联用例：它定义和描述了系统的外部可见行为功能，刻画了系统的完整功能需求，它和角色之间必须要有I/O消息；角色：它不属于系统，但与系统有交互，负责驱动与之关联的系统用例的执行；它可能是一类人、事物、硬件或其他系统的抽象（是一个类，而不是一个实例）；实例A角色A实例B角色B25角色的识别与描述谁使用系统的主要功能？谁需要系统的支持以完成其日常工作任务？谁负责维护、管理并保持系统正常运转？系统需要应付（处理）哪些硬设备？系统需要和哪些外部系统交互？谁对系统的结果感兴趣？角色：角色职责：角色识别问题：26角色识别示例：考虑一个ATM系统谁使用系统的主要功能？储户谁需要系统的支持以完成其日常工作任务？出纳员？谁负责维护、管理并保持系统正常运转？ATM系统工程师、银行人员系统需要应付（处理）哪些硬设备？储户身份、帐户标识卡（信用卡）系统需要和哪些外部系统交互？不清楚谁对系统的结果感兴趣？银行会计、储户角色：储户、银行人员、信用卡、银行会计角色：储户角色职责：插入信用卡输入口令输入交易金额角色识别问题：(1)使用系统主要功能(2)对系统运行结果感兴趣27用例识别与描述用例定义：用来描述角色可以感受到的完整的功能，在UML中定义为：“由系统执行的一个动作(action)序列，并能产生可观察的结果值给某个特定的角色”；特征：用例通常由某个角色来驱动执行；用例把执行结果的值反馈给角色；用例在功能上具有完整性；每个用例都必须从输入开始，直至产生结果值输出给角色(这一点与数据流图中的分解后的功能不一样)；同时具有相对完整的功能；在功能执行的过程中可能还会产生诸多变化情况、错误情况、异常情况等；用例在本质上是一个类，因此用例和角色之间的连接用关联（Association）来实现28命名规则：根据其在系统内的职责和所具有的功能来命名，如：填单据、订货；识别方法：用例识别是应用UML进行面向对象分析的关键一步，是其它后续工作的基础。用例识别首先在需求分析的基础上，弄清系统中的问题域、业务流程、系统功能需求等，再结合已经识别出的角色来识别用例。为便于识别，可借助于以下问题：某个角色要求系统为其提供什么功能？角色需要做哪些工作？角色需要阅读、创建、销毁、更新或存储系统中的某些信息？系统中的事件一定要告知角色吗？角色需要告诉系统一些什么吗？系统内部的事件从功能的角度代表什么？系统需要什么样的I/O?从哪里来，到哪里去？现行系统存在哪些主要问题？29用例之间的二种关系：扩展与使用都是继承的关系，但扩展强调的是一般类与特殊类的关系（可重载或覆盖）；而使用是指几个类之间的相似之处而抽象出的类（只增加专属自己的行为，无须重载或覆盖）。一般讲，一个角色与一个用类有关联关系时，则与它的扩展用类都有关联，但与它的使用用例并不一定有关联；《extends》《uses》《uses》用例扩展用例使用30用例描述：使用用例模板；用例：编号、名称；特征信息：用例在系统中的目标（用例目标描述）范围（当前考虑的是哪个系统）级别（概要任务/首要任务/子功能）前后条件（用例执行前系统应具有的状态）成功后续条件（用例成功执行后应具有的状态）失效后续条件（用例没有完成目标时的状态）首要角色（与该用例关联的首要角色）触发（启动该用例执行的系统动作）主要执行步骤步骤编号动作描述功能扩展编号扩展条件：动作或另一个用例变异编号变异