1、ECSA,J M U,集美大学工商管理学院信息管理与信息系统教研室,第2讲,电子商务系统分析与设计技术,电子商务需求分析,主要内容,UML概述需求工程一般理论CASE工具,统一建模语言UML,UML概要(Unified Modeling Language) UML由OMG于1997年11月批准为标准建模语言。 UML建立在当今国际上最有代表性的三种面向对象方法（Booch方法，OMT方法，OOSE方法）的基础之上。 UML是一种建模语言而不是一种方法，UML本身是独立于过程的。,标准建模语言UML,UML的设计目标： 运用面向对象概念来构造系统模型 建立起从概念模型直至可执行体之间明显的对应关
2、系 着眼于那些有重大影响的问题 创建一种对人和机器都适用的建模语言,标准建模语言UML,UML为人们提供了从不同的角度去观察和展示系统的各种特征的一种标准表达方式。在UML中，从任何一个角度对系统所作的抽象都可能需要用几种模型图来描述，而这些来自不同角度的模型图最终组成了系统的完整模型。,主要内容,UML概述对象建模CASE工具,主要内容,UML概述 视图 模型 图对象建模CASE工具,UML-视图,设计视图,实现视图,进程视图,部署视图,视图是我们在建模时从不同的视角来描述一个系统：,用例视图,从系统外部的操作者的角度描述系统的功能。,描述系统内部的静态结构和动态行为，即从内部描述如何设计实
3、现系统功能。,描述系统由哪些程序构件所组成。,描述系统的并发性，强调并发系统中存在的各种通信和同步问题。 。,描述系统的软件和各种硬件设备之间的配置关系。,标准建模语言UML-视图,视图是我们在建模时从不同的视角来描述一个系统：系统的用例视图：从系统外部的操作者的角度描述系统的功能。 系统的设计视图：描述系统内部的静态结构和动态行为，即从内部描述如何设计实现系统功能。 系统的实现视图：描述系统由哪些程序构件所组成。 系统的进程视图：描述系统的并发性，强调并发系统中存在的各种通信和同步问题。 系统的部署视图：描述系统的软件和各种硬件设备之间的配置关系。,主要内容,UML概述对象建模CASE工具,
4、主要内容,UML概述 视图 模型 图对象建模CASE工具,标准建模语言UML-模型,模型是我们在建模的产物，是与各个视图相关的信息记录。例如：系统的用例模型，用例视图中的信息。 模型元素：构成模型的基本单位。,主要内容,UML概述对象建模CASE工具,主要内容,UML概述 视图 模型 图对象建模CASE工具,标准建模语言UML,UML模型图（5类，9种）： 用例图 静态图（类图，对象图） 行为图（状态图，活动图） 交互图（顺序图，协作图） 实现图（构件图，部署图）,关于图与模型,图是模型的基本元素之一，是具体的物理表示；模型描述的是逻辑结构，除了图以外，文档也是基本的构成部分。理解图的重点要理
5、解图的语法和语义。,标准建模语言UML （用例图）,从本质上将，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用： 用例描述了用户提出的一些可见的需求； 用例可大可小； 用例对应一个具体的用户目标；,标准建模语言UML （用例图）,用例图描述系统外部的执行者与系统的用例之间的某种联系。 所谓用例是指对系统提供的功能（或称系统的用途）的一种描述； 执行者是那些可能使用这些用例的人或外部系统； 用例和执行者之间的联系描述了“谁使用哪个用例”。,标准建模语言UML （用例图）,用例图着重于从系统外部执行者的角度来描述系统需要提供哪些功能，并且指明了这些功能的执行者是谁； 用例图在UML方法
6、中占有十分重要的地位，人们甚至称UML是一种用例驱动的开发方法。,标准建模语言UML （用例图）,用例图中的图符：用例执行者系统：用于界定系统功能范围，描述该系统功能的用例都置于其中，而描述外部实体的执行者都置于其外。关联：连接执行者和用例，表示执行者所代表的系统外部实体与该用例所描述的系统需求有关。,标准建模语言UML （用例图）,用例图中的图符：使用：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能。扩展：由用例A连向用例B，表示用例B描述了一项基本需求，而用例A则描述了该基本需求的特殊情况。注释体：对UML实体进行文字描述注释连接：将注释体与要描述的实体连接，说明该注释体是针对
7、该实体所进行的描述。,使用,扩展,标准建模语言UML （用例图）,设置边界,风险分析,交易估计,进行交易,超越边界,更新帐目,评价,贸易经理,营销人员,记帐系统,销售人员,使用,使用,扩展,标准建模语言UML （用例图）,用例模型的获取：获取执行者获取用例,思考： 先获取执行者还是用例？,标准建模语言UML （用例图）,获取执行者： 谁使用系统的主要功能（主要使用者）？ 谁需要系统支持他们的日常工作？ 谁来维护、管理系统使其能正常工作（辅助使用者）？ 系统需要控制哪些硬件？ 系统需要与其他哪些系统交互？ 对系统产生的结果感兴趣的是哪些人？,标准建模语言UML （用例图）,获取用例： 执行者要求
8、系统提供哪些功能？ 执行者需要读、产生、删除、修改或存储系统中的信息有哪些类型？ 必须提醒执行者的系统事件有哪些？ 执行者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？,标准建模语言UML （类图）,在面向对象的建模技术中，类、对象和它们之间的关系是最基本的建模元素。对于一个想要描述的系统，其类模型、对象模型以及它们之间的关系揭示了系统的结构。 类图描述了系统中的类及其相互之间的各种关系，其本质反映了系统中包含的各种对象的类型以及对象间的各种静态关系（关联，子类型）。,标准建模语言UML （类图）,类图中的图符：类：表示一个类，其中第一栏是类的名，第二栏是类的属性，第三栏是类 的操
9、作。包：包是一种分组机制，表示一个类图集合。关联：用于表示类的对象之间的关系。其特殊形式有组成关联和聚集关联。,Operations,Attributes,Class,Package,标准建模语言UML （类图示例1 ）,标准建模语言UML （包图）,UML的包把语义上相近的可能一起变更的模型元素（如对象类、接口、组件、图等）组织在同一个包里，便于理解复杂的系统，控制系统结构各部分间的接缝。所有UML的模型元素都可以放入包内。通常，一个包拥有的是对象类或其他包。 包内的模型元素具有较强的内聚性，不同的包的元素之间的耦合性很弱。 包图表示的是系统的静态结构。,标准建模语言UML （包图 示例1）
10、,标准建模语言UML （包图示例2 ）,标准建模语言UML （包图）,何时使用包图： 在大项目中，包图是一种重要工具（有专家建议，只要你不能将整个系统的类图压缩到一张A4纸上，你就应该使用包图）； 包的概念对测试也是特别有用的。,标准建模语言UML （状态图）,状态图 状态图是对类的一种补充描述，它展示了此类对象所具有的可能的状态以及某些事件发生时其状态的转移情况。 在状态图中，状态由圆角矩形表示。状态的改变称作转移，状态转移由箭头表示，箭头旁可以标出转移发生的条件。状态转移可以伴随有某个动作，它表明当转移发生时系统要做什么。,标准建模语言UML （状态图 示例1）,标准建模语言UML （顺序
11、图）,顺序图 顺序图描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。 描述完成某个行为的各个对象类之间所传递的消息的时间顺序，即按时间顺序对控制流建模。,标准建模语言UML （顺序图 示例1）,:Display,:Key Pad,:Card Reader,:Cash Counter,:Client Manager,:Transaction Manager,:Bank Customer,Insert card,Card inserted(ID),Ask for PIN Code,Show request,Specify PIN code,PIN code(PIN),Request
12、 PIN validation(PIN),Ask for amount to withdraw,Show request,Specify amount,Amount(A),Request cash availability(A),Request amount withdraw(A),标准建模语言UML （协作图）,协作图 与顺序图作用相同，协作图也是用来描述系统中对象之间的动态协作关系。合作图侧重于描述各个对象之间存在的消息收发关系（交互关系），而不专门突出这些消息发送的时间顺序。 在协作图中，对象同样是用一个对象图符来表示，箭头表示消息发送的方向，而消息执行的顺序则由消息的编号来表明。,标准
13、建模语言UML （协作图）,：计算机,：打印队列,：打印服务程序,：打印机,1. 打印文件,3. 保存文件打印机忙,2. 打印文件打印机空闲,标准建模语言UML （协作图）,协作图的布局方法能更清楚地表示出对象之间静态的连接关系。 顺序图突出执行的时序，能更方便地看出事情发生的次序。 如果要描述在一个用例中的几个对象协同工作的行为，交互图是一种有力的工具。交互图擅长显示对象之间的合作关系，尽管它并不对这些对象的行为进行精确的定义。 如果想要描述跨越多个用例的单个对象的行为，应当使用状态图；如果想要描述跨越多个用例或多个线程的多个对象的复杂行为，则需考虑使用活动图。,标准建模语言UML （活动图
14、）,活动图 活动图描述系统中各种活动的执行顺序，通常用于描述一个操作中所要进行的各项活动的执行流程。同时，它也常被用来描述一个用例的处理流程，或者某种交互流程。 活动图由一些活动组成，图中同时包括了对这些活动的说明。当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。活动图中还可以方便地描述控制转移的条件以及并行执行等要求。,标准建模语言UML （活动图）,加水到容器中,将咖啡放到 过滤器中,点燃咖啡炉,取出咖啡杯,把过滤器放 到咖啡炉上,冲调咖啡,倒咖啡,找饮料,取一听 可口可乐,喝饮料,人,找到可口可乐,没有可口可乐,没有咖啡,找到咖啡,熄灭咖啡炉,标准建模语言UML （活动图）
15、,活动图最适合支持描述并行行为，这使之成为支持工作流建模的最好工具。活动图最大的缺点是很难清楚地描述动作与对象之间的关系。,标准建模语言UML （活动图）,对于以下情况可以使用活动图： （1）分析用例； （2）理解牵涉多个用例的工作流； （3）处理多线程应用。 在下列情况下，一般不要使用活动图： （1）显示对象间合作； （2）显示对象在其生命周期内的运转情况。,标准建模语言UML （构件图）,构件图 表示系统中的不同物理组件及其联系，表达的是系统代码本身的结构。,标准建模语言UML （构件图）,标准建模语言UML （配置图）,配置图 配置图描述系统中硬件和软件的物理配置情况和系统体系结构。 由
16、节点组成，节点代表系统的硬件，组件在节点上驻留并执行。配置图表示系统的软件组件与硬件之间的关系，表达的是运行系统的结构。 组件图和配置图用于建立系统的实现模型。,标准建模语言UML （配置图）,客户A： 个人电脑PC,客户B： 个人电脑PC,数据库服务器： VAX,服务器：02,TCP/IP协议,TCP/IP协议,DecNet协议,主要内容,UML概述需求工程一般理论CASE工具,关于需求的一段对话,经理,分析员,小吴,我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。,好.,门店用电话自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够
17、随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。,好.我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。,我不是刚告诉你我的需求了吗？,实际上，您只说明了整个项目的概念和目标.我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求,了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。,案例：陈先生早年白手起家于台湾一家传统手工制鞋作坊，经过多年的经营奋斗，1977年在台湾成立专业生产男女真皮皮鞋的集团公司,1989年投资1000万在深圳成立另一公司。后因规模
18、业绩的扩大，1997年继续在江苏投资1200万美元筹建现代化综合性鞋厂,全国各地相继成立18家办事处和近300家专卖店,可以说事业蒸蒸日上。,需求案例2,取得这些巨大的成绩同时，陈感到巨大的竞争压力以及相应的管理上的乏力。于是,他找来与自己并肩作战多年的张先生,请张着手负责企业信息化建设。张是公司的老臣,多年来一直抓公司的缉核工作,具备IT知识，陈对其也是信任有加。 早在1996年时，公司大陆业务刚刚进入正轨，应当时需求自行研发过一套管理系统。但是事过境迁，那套系统已不适合日益增长的业务需要。,此次投入专门资金，打算引进先进系统。为此，张积极展开准备工作：动员IT部大小成员，收集关于企业实施系
19、统的相关资料，并制定了系统导入前的初步培训计划，培养基层种子教员,调动公司上下，大小会议也开了不少，就等着系统的到来了。 软件公司的竞标与调研在准备工作进行两周后开始，来了一家台湾的软件公司和一家大陆公司。 本着上层领导的指示，第一个目标是把公司的销售系统上上去，接着是生产系统。,系统引入,台湾软件公司在台湾市场做得不错，但在大陆尚未听闻其有客户,且最初其专注于服装行业，这次做这个项目势必是其转入另一行业鞋业的第一个案例。该软件公司总裁亲自上阵，把一套营销的理论结合其系统从行销到生产，讲得惟妙惟肖，并作了系统规划，设计出业绩模式的宏伟蓝图。参与观摩演示的人在被其吸引的同时，也加大了张先生引入系
20、统的决心。,另一家大陆的软件商将其系统投影在墙壁，按照所提的业务需求运行了一遍。然而大概由于准备不够充分，中途总出现程序报错。为表明公平性和认可性，张先生等人象征性进行了一次投票，大家一致在台湾软件公司的选项上画上“”。,项目之初，软件公司首先装了一套测试版系统。 由于是由服装版修改过来的，许多界面都保留了服装行业的术语。 在这一阶段，通过多次和业务部磋商，最终制定出一套系统作业流程书和一份系统详细的功能需求表，具体分列了办事处和公司行销总部的系统需求。 软件公司在进度规定时间内基本完成了这份系统需求的功能，为此公司首付给软件公司5万元的二次开发费用。,问题出现,为了看到系统的初步功能，张先生
21、特地陪同软件公司，飞抵北京办事处进行系统运作的模拟测试。当时北京办事处位于该集团公司的办事处之首，销售业绩也居首位，平均每天有2.5万的销售额。当地操作人员在软件公司顾问的辅导下，通过windows2000的终端服务，连接到总部的销售系统主机。操作人员往系统里输入销售、配货、退货以及办事处的调货等资料，然而系统里的叫法却是拨入、拨出等，让操作人员常误解其词，造成数据错误。于是，张先生要求软件公司对操作人员加强辅导工作，讲解这些用词在系统中和实际业务操作中的对照性。,由于系统仍保留繁体版本，操作系统和数据库均是繁体，操作人员很不习惯。系统在北京办事处模拟测试一周后,张先生和软件顾问一同回到总部,
22、针对测试结果,软件公司提出，在办事处迁入宽带，并需购入相应硬件设备。张也相应地提出，将系统改成简体版本，并按软件公司提出的系统要求购买了一台价值20万人民币的服务器，公司各办事处相继迁入宽带。,由于公司有IT部门，软件公司只派了一个项目经理和相关技术人员驻扎在公司,通过培训IT部门成员,再去培训各相关单位作业员，这样一来事半功倍，既培养了种子教员，又在一定程度上做了技术转移的事项。 通过前期的整备工作，大家对上销售系统都有了大概的认识，对其期望也比较高。按照软件公司系统的架构模式，张先生特地从电信局申请了10个固定IP地址，办事处通过windows2000终端服务，输入这些固定的Ip地址，可直
23、接登陆到装有销售系统的服务器，从而进入销售系统，进行各类数据处理。,由于鞋子的款式多、尺码多、季节性强等特性，随着系统上线后，办事处间相互交易的数据量逐渐增多，采用纯手工的作业方式工作量繁重，且容易出错。其实张很早就意识到这点，为此，软件公司又提出了一个新方案，引入PDA(产品数据管理)进行数据采集，并将其采集的数据传输到系统。,听到这个消息，张很是高兴，向软件公司为每个办事处购置了一台PDA。IT部门专门从中抽出一人员,编写使用手册及注意事项。但由于PDA使用激光扫描头,具有宽大的图形画面,耗电量非常大,且PDA所用的是普通的5号双节电池，往往在扫描的途中断电,致使所有扫描的资料全部丢失。张
24、要求软件公司做出改良,然而软件公司只是建议,扫描途中务必保证具有后备电池。对此，张感到十分愤怒，后来才知道,软件公司推出的这款设备虽然具备宽大的界面,能加大使用者的操作视野,但耗电量大，持续作业时间很短。张有种受骗的感觉。,随着业务量的逐渐增多,业务部提出要求,希望能及时获取各办事处的销售等情况。之前由于系统刚上线,业务在查询报表时,并未发觉异常情况。 3个月后,数据量已大于5G,此时查询各类报表需花费很长的时间,有时甚至会死机。张找到软件公司经理,要求解决此类问题。软件公司在第二天提出,需购买另外一台服务器,专门用于统计各类数据,每天晚上8:00结算历史数据,直接得出各类报表数据来源,用户在
25、第二天就可直接查询报表,而不必再花时间计算统计得出报表数据来源。,对此，张先生访问了身边的朋友,也咨询过一些顾问，确实有此类方案。于是,公司又购买了一台价值12万的同类服务器。按软件公司的要求,在此服务器中安装专门的统计程序,并轮流派人勘查运行。运作之初,每次需3小时方可告终，然而,一个月后,该统计程序竟运行了一整夜仍未能结束。软件公司答应改良,但效果不见明显。,各办事处纷纷反映,自己做的资料只能看,却无法从程序里将其存入到自己的电脑,影响工作效率；即使能存数据,但由于繁体的问题,都是乱码,对他们来讲毫无价值；在数据处理过程中,网络传输缓慢,程序经常中断，造成数据丢失。 面对种种问题,软件公司
26、似乎拿不出好的解决办法,双方顿时陷入僵持。直到后来软件公司的项目经理回台湾后,就再也没有回来,只留下一个软件技术人员苦撑着。,在这样的情况下,系统在坎坷中运作了3个月,办事处只是奉命机械地输入数据,而其手头上常用的报表仍采用手工制作。总部的电脑数据和办事处传回数据也相差甚远，虽然软件公司也曾夜以继日地修正，无奈这一问题未能从根本上解决。张先生深感精力憔悴,直到软件从公司撤出，所购置的设备高高挂起，留给公司的就是这半年的折腾的泡影。,事过之后,张先生在深思这个过程中检讨了这样一段话： 我们缺乏对系统架构的认识，另外对于软件公司产品了解不深，对系统实施的风险估计不够，结合实际不够。我希望今后在做类
27、似的项目时，能多和软件公司交流，在充分了解软件公司(包括他的技术力量和产品等)的基础上，做到慎之又慎。你的看法？,问题： A企业在软件选型上出现了什么问题？是否是信息不对称引起了选型失败？如何解决信息不对称的问题？ 能否说A企业信息化的失败主要是选型上的失败？ A企业在信息规划上出现了什么问题？ 是选型的失败还是项目管理的失败？为什么？ 张先生的反思是否到位？你有哪些补充？再给他一个机会，你认为他能成功吗？张是否是合格的CIO？ 为什么？ A企业信息化建设的目标明确吗？为什么？你有哪些对策？ 系统实施上出了哪些问题？ 哪些因素直接决定了信息化过程的成败和最终的效果？,需求工程,需求工程:需求的
28、供需双方采取被证明行之有效的原理,方法,通过使用适当的工具和符号体系,正确,全面地描述用户待开发系统的行为特征,约束条件的过程.需求工程的结果:需求模型,SRS(软件需求规约 ),需求分析内容,需求收集的过程并不是一蹴而就的，往往是一个反复、反复、再反复的过程。是商业需求促成了电子商务这一方法的产生，而不要让技术来引导着电子商务的发展。不光要收集商业需求，与之相关的还有一系列其它的需求。包括系统实现中的约束，已经具有的条件，以及功能性和技术性的需求。,需求收集过程总览,收集需求,准备开发方案,分析开发方案,选择开发方案,完成此阶段,电子商务解决方案评估准备,启动工作框架，进行需求分析,准备需求分析工作框架,提出一个解决方案,理解商业驱动力,The end,Do you have made a progress today ?,
