论文写作.doc

中文摘要 论文首先介绍了XX系统的研究背景，对所需要解决的问题进行了概述，讨论了项目的研究意义与重要性，阐述了系统开发方法和相关技术；论文提出了系统的设计目标，对系统进行了详细的需求分析，包括业务需求、功能需求、数据需求和非功能需求，给出了系统的业务流程图、用例图和概念类图，进行了用例描述；在系统设计中，对系统进行了总体设计与模块设计，包括XX等功能模块，给出了模块设计的功能结构图（包图）、类图、顺序图（协作图）和处理流程图，详细阐述了设计内容，进行了界面设计，并使用实体类图、E-R图和数据库表结构对数据库进行了详细设计；论文最后对研究的内容进行了总结，阐述了本人的主要工作，指出了论文存在的不足，并对进一步的工作进行了展望。关键词：XXXX；UML建模；数据建模Abstract Keywords: 目录 目录中文摘要3Abstract4目录5第1章引言81.1项目背景与问题概述81.1.1项目背景81.1.2问题概述81.2研究的意义和重要性81.2.1研究的意义81.2.2研究的重要性81.3研究的内容和主要工作81.3.1研究的内容81.3.2本人主要工作81.4论文结构8第2章相关研究综述102.1研究对象的管理模式102.2软件工程开发模型102.2.1传统瀑布模型102.2.2改进的螺旋模型112.2.3面向对象的喷泉模型122.3UML建模技术142.3.1UML语言和要素142.3.2常用的UML模型图142.4数据库技术152.4.1数据库范式162.4.2数据建模16第3章需求分析183.1业务部门及管理角色分析183.1.1.业务部门183.1.2.管理角色183.2业务需求183.2.1业务描述183.2.2业务流程193.3功能需求233.3.1业务功能233.3.2管理功能343.4数据需求393.5非功能需求423.5.1环境需求423.5.2性能需求433.5.3安全需求43第4章系统设计454.1总体设计454.1.1系统设计的原则454.1.2系统体系结构设计464.1.3系统功能架构设计474.2功能模块设计484.2.1商品选购484.2.2货款支付544.2.3商品发货614.2.4退货处理674.2.5用户管理724.2.6日志管理764.2.7商品信息管理794.3数据库设计834.3.1概念设计834.3.2主要数据库表设计86第5章总结与展望925.1总结925.2进一步的工作92附录93参考文献94第1章 引言1.1 项目背景与问题概述1.1.1 项目背景1.1.2 问题概述1.2 研究的意义和重要性1.2.1 研究的意义1.2.2 研究的重要性1.3 研究的内容和主要工作1.3.1 研究的内容1.3.2 本人主要工作1.4 论文结构本文由五章内容组成，其中：第一章介绍了本文的研究背景，对所需要解决的问题进行了概述，讨论了项目的研究意义与重要性，阐述了论文的主要内容以及本人的主要工作。第二章阐述的是本文所涉及到的开发方法及相关技术，包括：软件工程开发模型、UML建模技术、数据库技术等。第三章是本文的核心内容之一，针对系统的业务需求、功能需求、数据需求和非功能需求等进行了详细分析，给出了主要的业务流程图和用例图，并对核心用例进行了详细描述，同时进行了基础数据的概念设计。第四章是本文的重点，在进行了系统总体设计的基础上，采用UML的包图、类图、顺序图和活动图等对系统的子模块进行了功能性详细设计，并给出了主要功能的界面设计，同时通过实体类图、E-R图和数据库表结构对数据库进行了详细设计。第五章总结了本文所做的工作，同时对进一步的工作进行了展望。第2章 相关研究综述2.1 研究对象的管理模式2.2 软件工程开发模型2.2.1 传统瀑布模型瀑布模型(也称为线性顺序模型)，由温斯顿罗伊斯在1970年提出，在20世纪80年代以前，瀑布模型一直都是唯一被广泛采用的软件开发模型。这个模型中，软件生命周期中的制订计划，需求分析，软件设计，程序编写，软件测试和运行维护依次由上至下顺序展开，如同瀑布流水，逐级下落，最终得到软件产品。理想化的瀑布模型是单边逐一而下的，认为人在工作过程中不可能犯错误。实际的瀑布模型是带有反馈逐一而下的，当后一阶段发现前一阶段的错误时，可以修正前一阶段的错误继续完成后一阶段的任务。图2.1瀑布模型 周苏,王文.软件工程学教程M. 科学出版社，2003.瀑布模型的优点：l 促进软件开发工程化，为项目提供了按阶段划分的检查点l 降低软件开发的复杂度，当前一阶段完成后，只需去关注后续阶段l 可以在增量模型中使用瀑布模型瀑布模型的缺点：l 缺乏灵活性不适应用户需求的变化，项目的各个阶段之间极少有反馈l 如果软件需求不明确或者经常变更需求，最终可能导致开发出的软件与用户预期的软件不符，往往会导致大量的返工，有时甚至会给开发人员带来灾难性的后果，而这一点又常常在项目生命期的后期才有所觉察。2.2.2 改进的螺旋模型螺旋模型由巴利玻姆于1988年正式发表了软件系统开发的“螺旋模型”，它是将瀑布模型与演化模型相结合，并且增加了两者所忽略的风险分析，弥补了两者的不足之处，该模型通常用来指导大型软件项目的开发软件项目的开发，。软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。软件风险驾驭的目标主要是在造成危害之前及时对风险进行识别，分析，采取对策进而消除或者减少风险的损害。螺旋模型将开发划分为制订计划，风险分析，实施工程，客户评估四类活动。沿着螺旋线每旋转一圈，表示开发出一个更完善的新的软件版本，如果开发风险过大，开发机构和客户无法接受，项目就有可能就此终止。多数情况下，会沿着螺旋线继续下去，自内向外逐步延伸，最终得到满意产品。螺旋模型开发的成败很大程度上依赖于风险评估的成败。沿着螺旋线旋转，在笛卡尔坐标的四个象限上分别表达了四类活动：制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。风险分析：分析所选方案，考虑如何识别和消除风险。实施工程：实施软件开发。客户评估：评价软件功能和性能，提出修改建议。 图2.2螺旋模型 齐治昌,谭庆平,宁洪.软件工程(第二版)M.高等教育出版社，2004螺旋模型的优点：l 设计上的灵活性,可以在项目的各个阶段进行变更。 l 以小的分段来构建大型系统,使成本计算变得简单容易。l 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。l 随着项目推进,客户始终掌握项目的最新信，从而他或她能够和管理层有效地交互。l 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。螺旋模型的缺点：l 很难让用户确信这种演化方法的结果是可以控制的。l 建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。 2.2.3 面向对象的喷泉模型在面向对象的方法中，提出了于瀑布模型相对应的喷泉模型，该模型的主要特点是认为软件生命周期的各个阶段是相互重叠和多次反复的，它是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。喷泉一词本身就体现了迭代和无间隙的特性。图2.3喷泉模型1喷泉模型的优点：软件项目开发效率高，节省开发时间，适应于面向对象的软件开发过程。喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。喷泉模型的缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。形式化方法模型包含了一组活动，他们导致了计算机软件的数学规约。形式化方法使得软件工程师们能够通过应用一个严格的数学符号体系来规约、开发、和验证基于计算机的系统。在开发中使用形式化方法时，它们提供了一种机制，能够消除使用其它软件过程模型难以克服的很多问题。二义性、不完整性、不一致性能被更容易地发现和纠正，而不是通过专门的评审，是通过对应用的数学分析。 形式化方法提供了可以产生无缺陷软件的承诺。2.3 UML建模技术2.3.1 UML语言和要素UML（Unified Modeling Language）统一建模语言,是用来对软件密集型系统进行可视化建模的一种通用语言。UML被广泛应用于数据建模，业务建模，对象建模，组件建模等。UML与具体的程序设计语言无关，它只是一种建模语言而不是一种方法学，和其它的计算机语言一样，也是由基本词汇和语法两个部分构成。UML定义了一些建立模型、表达某种特定含义所需要的基本元素，这些元素称为元模型，相当于语言中的基本词汇，例如用例、类等。在此基础上，还定义了这些元模型互相之间关系的规则，以及如何用这些元素和规则绘制图形以建立模型来映射现实世界，这些规则和图形称为UML模型表示法或图示。UML正处于不断演化和完善过程之中，最初的UML标准只是作为一种面向对象辅助的工具而设计的，即为软件的设计意图提供一种非形式化的捕获和表达手段和工具。因此，早期UML版本中存在着的一些因UML工具厂商不同而引入的分歧和模糊定义，正随着UML标准的演化而被逐步消除，让其向着成为一种形式化建模语言规范的方向不断演化。与此同时，UML也正在变得越来越庞大，但当我们只是运用UML来进行面向对象设计时，并不需要用到所有的UML内容，而是可以学习和使用UML那些最适合的部分。2.3.2 常用的UML模型图2.2.2.1 用例图用例图用来描述软件需求模型中的系统功能，通过一组用例可以描述软件系统能够给用户提供的功能。用例图可以作为整个系统开发过程中的开发依据，指导和驱动其他模型。2.2.2.2 类图类图(Class Diagram)是由类、相关建模元素及其关系构成的图，用来描述类之间的静态关系。类图在系统中处在核心位，也是UML中最为重要的一种图。在系统的不同开发阶段，类图可以具有不同的抽象程度。随着开发的深入，类图应该越来越详细、具体。类图可以分为：界面类、控制类和实体类。l 界面类位于系统与外界的交界处，承担系统与外界的信息功能。界面类处在用例图中参与者与用例的关联处，可以根据用例图发现界面类。在界面类的设计中主要关注属性和消息方法；l 控制类承担着事务处理，控制调控的控制作用。一个用例中最少会有一个控制类，用来控制用例中的事件顺序，也可以在多个用例之间协调用例之间的联系。在控制类的设计中主要关注类的方法。l 实体类对应着现实中的客观实物，用来保存信息，一般对应着数据表、文件等。在实体类的设计中主要关注类的属性；2.2.2.3 交互图交互图 用来描述对象之间,以及对象与参与者之间的动态协作关系以及协作过程中行为次序的图形文档。交互图的类型包含顺序图和协作图，其作用是分析为了实现一个用例的功能所参与的对象，以及这些对象相互之间的动态消息联系。2.2.2.4 活动图活动图是UML的动态视图之一，用来描述事物或对象的活动变化流程。活动图可以用来：l 描述工作流或者业务流程；l 描述工程组织过程；l 描述算法流程。2.4 数据库技术2.4.1 数据库范式关系数据库中的关系必须满足一定的要求，即满足不同的范式。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式（3NF）就行了。第一范式（1NF）。所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。第二范式（2NF）。第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是属性完全依赖于主键。第三范式（3NF）。满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。简而言之，第三范式就是属性不依赖于其它非主属性。2.4.2 数据建模因为数据模型的内容是问题域和解域所共享的知识模型，所以可以用问题域的语言来描述它，也可以用解域的语言来描述它，还可以用介于二者之间的语言来描述，故产生了以下三种常用的数据模型：1） 概念数据模型3 王珊, 陈红. 数据库系统原理教程. 清华大学出版社，1998.。它反映了人们对现实世界的认知与理解，是从现实世界到人类大脑的映射。故它以问题域的语言解释数据模型，由一系列应用领域的概念组成。2） 物理数据模型。它是以解域的语言解释数据模型，是面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有起对应的物理数据模型。3） 逻辑数据模型。这是用户从数据库所看到的模型，是具体的DBMS所支持的数据模型，如网状数据模型(Network Data Model)、层次数据模型(Hierarchical Data Model)等等。此模型既要面向用户，又要面向系统，主要用于数据库管理系统（DBMS）的实现。第3章 需求分析软件需求过程是整个软件开发初始阶段，对软件的品质具有决定性的作用。软件需求工程研究如何理解和说明用户对所开发软件的要求和期望。需求就是以一种清晰、简明、一致且无二义性的方式对一个待开发系统中的各个方面有意义的陈述的集合4 Jackson M. Software Requirements & Specifications ： A Lexicon of Practice, Principles and Prejudices. Harlow： Addison-Wesley,1995.。需求必须是完整的，足以使设计师和工程师来开发一个使客户满意的软件制品。IEEE软件工程标准词汇表(1997年)中定义需求为5IEEE STD. IEEE Recommended Practice for Software Requirements Specifications. IEEE STD 830-1998(Jun 25),P2063.：（1） 用户解决问题或达到目标所需的条件或能力(Capability)；（2） 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力；（3） 一种反映上面(l)或(2)所描述的条件或能力的文档说明。软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）6 Gerald Kotonya and Ian Sommerville.Requirements Engineering:Process and Techniques.John Wiley&Sons,1998.。3.1 业务部门及管理角色分析3.1.1. 业务部门3.1.2. 管理角色表3-1 系统的角色及对应职责角色职责或功能管理和维护整个系统的用户组织结构，负责对部门、用户、角色、用户级别的增、删、改、查，界面配置管理，流程管理，系统日志管理，可以分配部门管理员，以实现分级管理。3.2 业务需求业务需求(business requirement)是客户对软件制品目标的高层次要求。3.2.1业务描述描述系统当前的主要业务问题，进一步阐述通过计算机软件要达到哪些目标，解决哪些主要问题等。示例：（一） 能够实现商品展示、商品检索、商品选择、网上订货、网上支付和商品发货等功能，对网上购物的全过程进行管理（二） 实现对网上购物过程中产生的所有业务数据的管理，如订货单、支付记录、发货信息的管理与维护（三） 具有配套的系统后台管理维护功能，能够对商品信息、用户信息、系统日志等信息进行管理与维护，并能够进行对应的权限管理（四） 响应速度合理，安全性较高（五） 系统运行稳定，并且应易于维护3.2.2业务流程使用UML的活动图描述系统的主要业务流程等。示例：3.2.2.1商品展示活动图图3-1 商品展示活动图3.2.2.2网上订货活动图图3-2 网上订货活动图3.2.2.3货款支付活动图图3-3 货款支付活动图3.2.2.4发货活动图图3-4 商品发货活动图3.2.2.5退货处理活动图图3-5 退货处理活动图3.3 功能需求功能(function)是刻画系统行为、特别是系统与环境关系的重要概念。用户需求(User Requirement)描述了待开发的软件必须完成的任务。功能需求(Functional Requirement)定义了必须实现的软件功能，使得用户通过这些功能完成他们的任务，从而满足业务需要。3.3.1 业务功能从系统的使用者的角度使用UML的用例图描述系统的用例，并给出每一个用例的用例描述。3.3.1.1商品选购图3-6 商品选购用例图描述项说明用例名称商品选购标识符*YL01用例描述描述了买家使用本系统销售管理子系统进行商品选购的整个过程参与者表客户（买家）优先级1状态*进行中前置条件用户已登录系统后置条件系统给出操作成功提示基本操作流1.用户在系统主页上选择商品分类，进入商品列表查看界面或在搜索框中要购买商品关键信息进行检索，提取符合条件的商品列表；2.找到所需商品后点击“查看详细信息”按钮，进入商品详细信息查看页面；3.确定购买后，设置购买数量，点击界面上的“放入购物车”按钮；4.根据需要，点击“继续购物”按钮，返回主界面继续选购其他商品；可选操作流1用户将选购商品放入购物车后，不继续选购其他商品，进入购物车中确认商品信息，确认无误后，点击结算按钮，进入支付界面被泛化用例表该用例的特化用例列表被包含用例表商品检索被扩展用例表无修改历史记录*暂无问题*暂无决策*暂无频率*暂无3.3.1.2货款支付图3-7 货款支付用例图描述项说明用例名称货款支付标识符*YL02用例描述描述了买家使用本系统销售管理子系统进行货款支付的整个过程参与者表客户（买家）优先级1状态*进行中前置条件用户已登录系统后置条件系统给出操作成功提示基本操作流1.用户点击“购物车”标签页进入购物车管理操作页面；2.在购物车中勾选需要进行结算的商品，在选择完毕后，点击界面最下方的“结算”按钮，进入结算付款界面；3.在结算付款界面中选择付款方式，系统会根据买家的选择链接到相关银行或其他可信第三方的支付界面；4.在支付完成后，系统自动跳转会系统结算界面，页面中有两个选项：“已完成付款”和“付款遇到问题”，如付款成功，点击“已完成付款”，完成付款。可选操作流1.如在第三方网站上付款不成功，点击“付款遇到问题”按钮，进行重新付款，或暂时搁置；2.在付款前，用户可随时退出系统或跳转至其他界面；被泛化用例表无被包含用例表无被扩展用例表无修改历史记录*暂无问题*暂无决策*暂无频率*暂无3.3.1.3商品发货图3-8 商品发货用例图描述项说明用例名称商品发货标识符*YL03用例描述描述了卖家使用本系统销售管理子系统进行商品发货处理的整个过程参与者表客户（买家）优先级1状态*进行中前置条件用户已登录系统后置条件系统给出操作成功提示基本操作流1.用户点击“订单管理”标签页进入订单管理操作页面；2.查看所有状态为“买家已付款”的订单，点击“确认发货”按钮进行发货确认；可选操作流无被泛化用例表无被包含用例表无被扩展用例表无修改历史记录*暂无问题*暂无决策*暂无频率*暂无3.3.1.4退货处理图3-9 退货处理用例图描述项说明用例名称退货处理标识符*YL04用例描述描述了卖家、买家使用本系统进行退货处理的整个过程参与者表买家、卖家优先级1状态*进行中前置条件用户已登录系统后置条件系统给出操作成功提示基本操作流1买家点击“订单管理”标签页进入相应操作页面；2.找到需要进行退货的订单后，点击进入查看订单详情；3.在订单详情查看页面选择“申请退货”按钮，进入退货申请处理界面；4.在界面上输入退货理由和相关证据，输入完毕后，点击提交按钮可选操作流1.卖家收到退货申请后进行核实，如反映属实则给予退款；被泛化用例表无被包含用例表无被扩展用例表无修改历史记录*暂无问题*暂无决策*暂无频率*暂无3.3.1.5网上订货图3-10 网上订货用例图描述项说明用例名称网上订货标识符*YL05用例描述描述了买家和卖家使用本系统销售管理子系统进行网上订货操作的整个过程参与者表买家、卖家优先级1状态*进行中前置条件用户已登录系统后置条件系统给出操作成功提示基本操作流1.用户手动浏览或者根据关键自检索所需商品；2.将所购买商品放入购入车，然后继续购物或进行结算；3.在购物车中点击结算按钮，进入货款支付界面，后连接至网银或其他第三方支付中心进行付款；4.付款后，返回至订单查看页面，查看当前订单；5.卖家确认用户付款后，进行发货；6.买家收到货物后进入系统订单处理界面，确认收货；7.卖家由第三方处收到货款，交易结束。可选操作流1.如买家对商品不满意，可以申请退货，详见退货处理用例被泛化用例表无被包含用例表商品选购、货款支付、商品发货、退货处理、订单管理被扩展用例表无修改历史记录*暂无问题*暂无决策*暂无频率*暂无3.3.1.6订单管理图3-11 订单管理用例图描述项说明用例名称订单管理标识符*YL06用例描述描述了买家和卖家使用本系统进行订单管理的整个过程参与者表买家、卖家优先级1状态*进行中前置条件用户已登录系统后置条件系统给出操作成功提示基本操作流1.用户点击“订单管理”标签页进入相应理操作页面；2.点击页面上的“查看完成订单”和“正在进行的订单”对订单进行过滤；3.点击“查看详情”按钮，进入订单详情查看页面；4.在收到货物后，点击“确认收货”按钮进行收货操作；可选操作流1.如果是卖家需要更改订单状态，需要在发货后，进入订单详情查看页面，将订单状态置为“已发货”被泛化用例表无被包含用例表无被扩展用例表无修改历史记录*暂无问题*暂无决策*暂无频率*暂无3.3.1.7发货信息管理图3-12 发货信息管理用例图描述项说明用例名称发货信息管理标识符*YL07用例描述描述了卖家、买家和货运公司使用本系统进行发货信息管理的整个过程参与者表买家、卖家和货运公司优先级1状态*进行中前置条件用户已登录系统后置条件系统给出操作成功提示基本操作流1.用户点击“订单管理”标签页进入相应操作页面；2.找到需要查看的订单后，点击进入查看订单详情；3.在订单详情查看页面选择“查看发货信息”按钮，页面上弹出当前订单的发货基本信息和物流信息可选操作流被泛化用例表无被包含用例表无被扩展用例表无修改历史记录*暂无问题*1.货运公司需要提供相关订单的物流信息提取接口，由被系统通过服务调取决策*暂无频率*暂无3.3.2 管理功能从系统管理员的角度使用UML的用例图描述系统的用例，并给出每一个用例的用例描述。用例描述的模板如上所示。3.3.2.1用户管理图3-13 用户管理用例图描述项说明用例名称用户管理标识符*YL08用例描述描述了系统管理员使用本系统进行用户管理，用户进行帐号注册的整个过程参与者表系统管理员和用户优先级1状态*进行中前置条件用户已登录系统后置条件系统给出操作成功提示基本操作流用户注册帐号：1.用户点击“用户管理”标签页进入相应操作页面；2.点击新增按钮，进入用户添加页面；3.根据提示输入用户id，名称，密码，收货地址，联系电话等信息；3.所有信息输入完毕后，点击保存按钮管理员进行用户管理：1.管理员找到需要进行维护（更新和删除）的用户，然后点击相应按钮执行更新和删除操作可选操作流1.当用户输入有误时（如用户id重复），系统给出相应的错误提示信息，退回用户添加页面，已填写的数据予以保存；2.如要进行用户删除或维护操作，现在用户列表中找到该用户然后点击删除或维护按钮进行操作，在进行维护时，管理员可对该用户的所有信息进行更改；被泛化用例表无被包含用例表无被扩展用例表无修改历史记录*暂无问题*暂无决策*暂无频率*暂无3.3.2.2日志管理图3-14 日志管理用例图描述项说明用例名称日志管理标识符*YL09用例描述描述了系统管理员使用本系统进行日志管理的整个过程参与者表系统管理员优先级1状态*进行中前置条件用户已登录系统后置条件符合条件的日志记录已列表形式展现在界面上基本操作流1.用户点击“日志管理”标签页进入相应操作页面；2.选择要查看的日志种类(操作日志或登录日志)；3.设置过滤条件，检索到需要的日志记录进行查看；可选操作流无被泛化用例表无被包含用例表无被扩展用例表无修改历史记录*暂无问题*暂无决策*暂无频率*暂无3.3.2.3商品信息管理图3-15 商品管理用例图描述项说明用例名称商品信息管理标识符*YL10用例描述描述了卖家使用本系统销售管理子系统进行商品展示的整个过程参与者表卖家优先级1状态*进行中前置条件用户已登录系统后置条件所添加的商品出现在系统前台指定类别的商品展示列表中基本操作流1.用户点击“商品信息维护”标签页进入商品信息维护操作页面；2.点击“添加商品”按钮，进入商品基本信息录入界面；3.根据界面提示输入商品名称、价格、库存量、描述信息、商品照片等信息；4.点击“确认添加”按钮，完成添加操作；可选操作流1.卖家还可以对已添加商品的信息进行维护，操作方式如下：在商品列表中选择要进行维护的商品，点击“更新”按钮进入商品信息录入界面或点击“删除”按钮删除该商品被泛化用例表无被包含用例表无被扩展用例表无修改历史记录*暂无问题*暂无决策*暂无频率*暂无3.4 数据需求根据用例图给出类图的概念设计，包含界面类、控制类和实体类，不要求展开类的属性和方法，采用类图的简化表示或缩略表示，例如：（一）商品选购图3-16 商品选购类图缩略表示（二）货款支付图3-17 货款支付类图缩略表示（三）商品发货图3-18 商品发货类图缩略表示（四）退货处理图3-19 退货处理类图缩略表示（五）用户管理图3-20 用户管理类图缩略表示（六）日志管理图3-21 日志管理类图缩略表示（七）商品信息管理图3-22 商品信息管理类图缩略表示3.5 非功能需求非功能需求7 Chung L, Nixon BA, Yu.E and Mylopoulos.J. Non-functional requirements in software engineering. Boston：Kluwer Academic,2000.包括产品必须遵从的标准、规范和合约；外部界面的具体细节和性能要求；设计或实现的约束条件及质量属性。3.5.1环境需求 3.5.2性能需求1. 可维护性维护方法：系统能真正做到使自身在数据损坏、丢失等情况下将备份数据倒回，实现数据的恢复。提供对系统自身的集中操作维护的功能。2. 易操作性界面设计：系统应提供美观实用，方便和直观的图形用户管理界面，充分考虑员工的习惯，简单易学，操作方便，所有菜单驱动的处理和各种快捷键，一键功能以确保多数达到。3. 可扩展性功能扩展：系统从系统结构、功能设计、管理对象等各方面的功能扩展来考虑，以满足用户今后系统扩充和扩大使用范围的要求。软硬件升级：系统应采取的硬件和软件平台，软件和硬件的负载平衡机制的可扩展性充分考虑。系统要具有灵活的扩展能力，来适应关键的软件和硬件的开发及管理能力的上升。 4. 开放性系统的数据格式应符合国家相关标准及行业标准，以此确保应用程序具有良好的互操作性和移植的可能。3.5.3安全需求1. 容错性当用户输入或误操作导致非法数据产生时，系统应具有一定的容错机制。在这种情况下，系统应给出友好的提示，提示用户重新输入或者进行自动的修复校正。2. 系统的外在环境安全安全系统要以充分考虑网络的高级别，多层次的安全性措施为前提，包括系统的备份，防火墙，用户权限和其他措施，以确保数据安全和机密信息不被泄露；考虑到系统的硬件和软件故障恢复等应急措施，以保障网络的安全和处理安全性。形成相对独立的安全机制，以防止来自系统外的未经授权的访问。 3. 系统内部安全确保外部系统安全的同时，该系统还必须确保授权用户的合法使用。4. 系统运行安全从逻辑上讲，该系统应具有抵抗非法入侵的能力；在物理方面，该系统应确保没有潜在的单点故障，并提供资源的数据备份功能。系统支持定期自动和手动数据备份，能够在数据损坏或数据丢失的情况下找回数据，实现一定程度的数据恢复。第4章 系统设计任何工程项目，在生产之前必须要作设计，软件工程项目也一样，在软件编码前也必须先进行软件设计。软件设计是软件开发的关键步骤，直接影响软件的质量。如果说在软件需求分析阶段已经完全弄清楚了软件的各种需求，就较好地解决了所开发的软件“做什么”的问题，并已在软件需求说明书中详尽和充分地阐明了这些需求，那么下一步就要着手对软件系统的功能结构、数据结构和用户界面等进行设计，即软件设计阶段要解决“怎么做”的问题，并最终通过“设计模型图”来反映设计的结果。4.1 总体设计4.1.1 系统设计的原则在充分考虑到本系统的总体规划目标，以及系统的应用环境前提下，本系统的设计将严格遵循以下的设计原则：1） 实用性原则。网上购物系统是ERP的典型代表，它的好坏直接影响到企业的经营效益。所以在进行该系统的设计时，我将系统的实用性要求放在了首位。本系统力求能够紧密切合企业和用户的实际业务需求，以求彻底解决传统购物方式的效率低的通病。2） 先进性原则。在强调实用性的同时，我们还要考虑系统的先进性。今时今日，信息化的发展速度令世人惊叹，每一次技术上的更新与进步都会推动信息化建设的跳跃式发展。所以，为了与时俱进，有一个较高的起点，在本系统的设计过程中我采用目前较为先进和成熟的技术和理念，使系统在性价比上拥有一定的优势。3） 规范性原则。系统中的所有设计都遵循现有的国家标准、行业标准，符合软件工程中的设计原则与规范。所有文档的书写都遵照国标软件需求说明书（GB856T88）要求。4） 安全性原则。系统提供安全机制以防止非法授权操作，为各子系统提供严格灵活的用户和权限划分，对于数据库管理，建立起完备的数据备份恢复机制。对关键的信息的操作提供日志记录。5） 易于集成的原则。出于对xxx单位信息化建设的全盘考虑和整体规划，本系统要能够与其他业务系统进行集成。本系统为其他系统预留有应用接口和数据传输规范，方便其他系统与我系统间的信息交互。本系统在数据库设计上同样遵循此原则，在数据访问层以WebServices的方式提供数据访问服务。6） 可扩展性原则。出于对后续升级工作的考虑，系统的所有功能模块的设计都预留了扩展接口。因为人们对网上购物系统的需求和应用目标会随着技术进步和商业模式的变换而发生转变，在设计初期就考虑到可能发生的变化，是十分必要的。4.1.2 系统体系结构设计浏览器-服务器( Browser/Server， B/S)体系结构如下图所示。图4-1B/S体系结构B/S体系结构主要是利用Web技术，结合浏览器的脚本解释能力，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本和维护成本。在B/S体系结构中，除了数据库服务器外，应用程序以静态或动态网页的形式存放于Web服务器上，用户运行某个应用程序时只需在客户端上的浏览器中输入相应的网址。调用Web服务器上的应用程序并对数据库进行操作完成相应的数据处理工作，最后将结果通过浏览器显示给用户。可以说，在B/S体系结构的应用系统中，应用程序在一定程度上具有集中特征。基于B/S体系结构的软件系统，安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可以运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。B/S体系结构出现之前，管理信息系统的功能主要是组织内部。B/S风格的“零客户端”方式，使组织的供应商和客户(这些供应商和客户有可能是潜在的，也就是说可能是事先未知的)的计算机方便地成为管理信息系统的客户端，进而在限定的功能范围内查询组织相关信息，完成与组织的各种业务往来的数据交换和处理工作，扩大了组织计算机应用系统的功能覆盖范围，可以更加充分地利用网络上的各种资源，同应用程序的工作量也大大减少。另外，B/S体系结构的应用系统与Internet的结合也使一些新的企业计算机应用(如电子商务、云计算)的实现成为可能。4.1.3 系统功能架构设计系统功能架构设计定义软件系统各主要部件及成分之间的关系。可以通过UML的包图来表示，系统功能一般对应需求分析中的用例，例如：图4-2 系统总包图4.2 功能模块设计针对4.1.1节的总体功能架构，逐项功能展开设计。4.2.1 商品选购4.2.1.1 功能结构设计使用UML包图给出子功能架构，例如图4-3 商品选购包图4.2.1.2 类图设计(一) 界面类在界面类的设计中主要关注用户界面的属性和消息（方法），要求给出具体的界面设计。图4-4 商品选购界面类图类描述：表4-1 商品选购界面类描述商品选购界面类类的描述： 商品选购界面主功能类方法描述AddIntoShoppingCartBtnClicked ()放入购物车按钮响应事件GetGoodsList ()获取商品列表DeleteFromShoppingCartBtnClicked()从购物车中删除商品按钮响应事件界面设计：图4-5 商品选购界面截图(二) 控制类在控制类的设计中主要关注类的方法，可以包含子控制类的设计。图4-6 商品选购控制类图类描述：表4-2 ShoppingCartManage类描述ShoppingCartManage类类的描述： 购物车管理主功能类方法描述AddShoppingCartRecord ()添加购物车记录DeleteShoppingCartRecord ()删除购物车记录UpdateShoppingCartRecord()更新购物车记录GetShoppingCartById()根据购物车记录Id获取购物车记录实体SettleAccounts()进行结算付款GetShoppingCartListByOwnerId ()根据用户Id获取该用户的所有购物车记录列表表4-3 GoodsInfoManage类描述GoodsInfoManage类类的描述： 商品信息管理主功能类方法描述AddGood ()添加商品DeleteGood ()删除商品GetGoodById ()根据商品Id获取商品对象实体UpdateGood ()更新商品GetAllGoods获取所有商品GetGoodsByCategory根据商品类别提取商品列表SearchByKeyword ()根据关键字检索商品(三) 实体类在实体类的设计中主要关注类的属性；图4-7 商品选购实体类图类描述：表4-4 GoodInfo类描述GoodInfo类类的描述： 商品信息实体类属性描述Id商品IdName商品名称Price单价Amount库存量Description商品描述信息Photo商品照片Category商品类别Status商品状态表4-5 GoodCategory类描述GoodCategory类类的描述： 商品类别实体类属性描述CategoryId商品类别IdCategoryName商品类别名称表4-6 ShoppingCart类描述ShoppingCart类类的描述： 购物车实体类属性描述Id购物车记录IdOwnerId购物车所有者IdGoodId商品IdQuantity购买数量CreateDate创建日期Money商品金额4.2.1.3 动态图设计使用顺序图或协作图描述该功能（用例）所参与的对象，以及这些对象相互之间的动态消息联系；使用状态图用来描述一个特定的对象所有可能的状态,以及由于各种事件的发生而引起的状态之间的转移和变化。示例：图4-8 商品选购顺序图4.2.1.4 处理流程设计使用活动图描述该功能及其子功能核心的处理流程。图4-9 商品选购活动图4.2.2 货款支付4.2.2.1 功能结构设计图4-10 货款支付包图4.2.2.2 类图设计(一)界面类图4-11 货款支付界面类图类描述：表4-7 货款支付界面类描述货款支付界面类类的描述： 货款支付界面主功能类方法描述GetPaymentStyle ()获取支付方式ConfirmPaymentBtnClicked ()确认支付按钮响应事件GetMoneyAccount()获取支付金额GetGoodsListInShoppingCart ()获取购物车中待结算商品列表界