大学毕业论文-—面向对象方法.doc

分类号 TP31 密级 公开
UDC 编号

硕士研究生学位论文

题 目 XX系统的分析与设计

独创性声明
本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果。除了文中特别加以标注和致谢的地方外，论文中不包含其他人或集体已经发表或撰写过的研究成果，对本文的研究做出贡献的集体和个人均已在论文中作了明确的说明并表示了谢意。

研究生签名： 日 期：

论文使用和授权说明
本人完全了解云南大学有关保留、使用学位论文的规定，即：学校有权保留并向国家有关部门或机构送交学位论文和论文电子版；允许论文被查阅或借阅；学校可以公布论文的全部或部分内容，可以采用影印、缩印或其他复制手段保存论文。
（保密的论文在解密后应遵循此规定）

研究生签名： 导师签名： 日 期：

…………………………………………………………………

本人及导师同意将学位论文提交至清华大学“中国学术期刊（光盘版）电子杂志社”进行电子和网络出版，并编入CNKI系列数据库，传播本学位论文的全部或部分内容，同意按《中国优秀博硕士学位论文全文数据库出版章程》规定享受相关权益。

研究生签名： 导师签名： 日 期：

毕业设计（论文）原创性声明和使用授权说明

原创性声明
本人郑重承诺：所呈交的毕业设计（论文），是我个人在指导教师的指导下进行的研究工作及取得的成果。尽我所知，除文中特别加以标注和致谢的地方外，不包含其他人或组织已经发表或公布过的研究成果，也不包含我为获得 及其它教育机构的学位或学历而使用过的材料。对本研究提供过帮助和做出过贡献的个人或集体，均已在文中作了明确的说明并表示了谢意。
作 者 签 名：　　 　 　　日　 期：　　 　 　　 
指导教师签名：　　 　 　　 日　　期：　　 　 　　

使用授权说明

本人完全了解 大学关于收集、保存、使用毕业设计（论文）的规定，即：按照学校要求提交毕业设计（论文）的印刷本和电子版本；学校有权保存毕业设计（论文）的印刷本和电子版，并提供目录检索与阅览服务；学校可以采用影印、缩印、数字化或其它复制手段保存论文；在不以赢利为目的前提下，学校可以公布论文的部分或全部内容。
作者签名：　　 　 　　 日　 期：　　 　 　　 
学位论文原创性声明
本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所取得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写的成果作品。对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的法律后果由本人承担。

作者签名： 日期： 年 月 日

学位论文版权使用授权书
本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权　　 　 　大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。
涉密论文按学校规定处理。

作者签名： 日期： 年 月 日
导师签名： 日期： 年 月 日

指导教师评阅书

指导教师评价：
一、撰写（设计）过程
1、学生在论文（设计）过程中的治学态度、工作精神
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、学生掌握专业知识、技能的扎实程度
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、学生综合运用所学知识和专业技能分析和解决问题的能力
□ 优 □ 良 □ 中 □ 及格 □ 不及格
4、研究方法的科学性；技术线路的可行性；设计方案的合理性
□ 优 □ 良 □ 中 □ 及格 □ 不及格
5、完成毕业论文（设计）期间的出勤情况
□ 优 □ 良 □ 中 □ 及格 □ 不及格
二、论文（设计）质量
1、论文（设计）的整体结构是否符合撰写规范？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、是否完成指定的论文（设计）任务（包括装订及附件）？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
三、论文（设计）水平
1、论文（设计）的理论意义或对解决实际问题的指导意义
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、论文的观念是否有新意？设计是否有创意？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、论文（设计说明书）所体现的整体水平
□ 优 □ 良 □ 中 □ 及格 □ 不及格
建议成绩：□ 优 □ 良 □ 中 □ 及格 □ 不及格
（在所选等级前的□内画“√”）
指导教师： （签名） 单位： （盖章）
年 月 日

评阅教师评阅书

评阅教师评价：
一、论文（设计）质量
1、论文（设计）的整体结构是否符合撰写规范？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、是否完成指定的论文（设计）任务（包括装订及附件）？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
二、论文（设计）水平
1、论文（设计）的理论意义或对解决实际问题的指导意义
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、论文的观念是否有新意？设计是否有创意？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、论文（设计说明书）所体现的整体水平
□ 优 □ 良 □ 中 □ 及格 □ 不及格
建议成绩：□ 优 □ 良 □ 中 □ 及格 □ 不及格
（在所选等级前的□内画“√”）
评阅教师： （签名） 单位： （盖章）
年 月 日

云南大学硕士研究生论文 XX系统的分析与设计
教研室（或答辩小组）及教学系意见

教研室（或答辩小组）评价：
一、答辩过程
1、毕业论文（设计）的基本要点和见解的叙述情况
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、对答辩问题的反应、理解、表达情况
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、学生答辩过程中的精神状态
□ 优 □ 良 □ 中 □ 及格 □ 不及格
二、论文（设计）质量
1、论文（设计）的整体结构是否符合撰写规范？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、是否完成指定的论文（设计）任务（包括装订及附件）？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
三、论文（设计）水平
1、论文（设计）的理论意义或对解决实际问题的指导意义
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、论文的观念是否有新意？设计是否有创意？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、论文（设计说明书）所体现的整体水平
□ 优 □ 良 □ 中 □ 及格 □ 不及格
评定成绩：□ 优 □ 良 □ 中 □ 及格 □ 不及格
（在所选等级前的□内画“√”）
教研室主任（或答辩小组组长）： （签名）
年 月 日
教学系意见：

系主任： （签名）
年 月 日

摘要
<简单的论文总体描述>
论文首先介绍了XX系统的研究背景，对所需要解决的问题进行了概述，讨论了项目的研究意义与重要性，阐述了系统开发方法和相关技术；论文提出了系统的设计目标，对系统进行了详细的需求分析，包括业务需求、功能需求、数据需求和非功能需求，给出了系统的业务流程图、用例图和概念类图，进行了用例描述；在系统设计中，对系统进行了总体设计与模块设计，包括XX等功能模块，给出了模块设计的功能结构图（包图）、类图、顺序图（协作图）和处理流程图，详细阐述了设计内容，进行了界面设计，并使用实体类图、E-R图和数据库表结构对数据库进行了详细设计；论文最后对研究的内容进行了总结，阐述了本人的主要工作，指出了论文存在的不足，并对进一步的工作进行了展望。

关键词：XXXX；UML建模；数据建模
Abstract
<此处插入英文摘要，就是中文摘要的正确翻译，注意关键词的翻译要准确>
Keywords: <英文关键词，要与中文摘要对应，例如：XXXX, UML, Data Modeling>
目录
<此处插入论文目录>
第一章 引言
1.1 项目背景与问题概述
1.1.1 项目背景
<此处插入论文中所述项目的项目背景，旨在突出社会发展背景、项目的出发点等等。以下是范本请不要照搬！>
随着科学技术的进步和社会经济的发展，信息化进程已经成为一种必然的趋势。近年来，由于信息化在多个领域取得了巨大的成就，为国家的经济建设和社会发展做出了不可估量的贡献。因此，人们认识到，作为国家信息化和社会信息化的重要组成部分之一的商业信息化，已然成为了促进社会经济发展的一个增长点，也是推动商业发展的重要手段。商业信息化已经被越来越多的企业和商家所关注。
网上购物最早在美国出现，1995年美国网上商店亚马逊开业（A），美国第一家安全网络银行（First Security B）实现网上支付。而我国的网上购物系统发展相对较晚，在1998年，中国的第一笔网上交易成功，1999年随着8848等B2C网站的正式开通，中国开始进入购物网站的实际阶段。从起步到现在，十多年来网上购物发展迅速,在1998年，国内最大的商务拍卖网站易趣开始运行。在1999年B2C网站当当投入运营，2000年卓越成立,到2003年B2B网站阿里巴巴投资成立了C2C网站淘宝。网上购物的商家越来越多，同时网上购物的消费者数量也在迅速的发展与增长。截止到2005年上半年，我国的上网人数达到1.03亿，其中网上购物者达到2000万人，网上支付的比例增长到近半数，网上购物成交额已经累计达100亿元。在长达6年的网上购物市场发展过程中，网上购物者渐渐开始接受并习惯新的购物消费方式，随着网民人数增加，网上购物者人数有进一步扩大的趋势。
世界电子商务的快速度发展，同时B2B、B2C、C2C等一系列的结构快速度发展，这些都需要网上商城来支持，少则自己开个商店，大则阿里巴巴等电子商务，这些都成就了商城系统的出现，正因为网上电子商务的安全性与稳定性的要求高，所以对商城系统也需要有一个严格的考验。不少商家、公司只制作一个或几个产品介绍的页面，要修改资料，需要对网页重新修改，客户却又不能在线下定单，需要通过多种步骤才能与商家取得联系，其弊端是显见的，首先是低效率、数据的严重冗余，其次是维护困难。显然由这些简单链接的页面构成的网站在数据的共享性、人机的交互性以及网站维护性上都是很现实的问题。开发一个基于web的动态网上购物系统，对发展电子商务无疑是十分迫切的。
1.1.2 问题概述
<此处插入论文的论点，旨在突出论文讨论解决的问题。>
在信息技术日新月异的今天，随着新技术、新功能的演变，开发一个XXX系统有着多种技术手段来实现。如何根据具体需求采用合适的技术来实现，是很多软件开发者正在考虑的问题。
<展开叙述一些传统技术手段存在的问题>
此外，现有的电子商务系统普遍存在着…….问题，一直得不到解决。
<展开叙述一些传统网上购物系统普遍存在的问题>
1.2 研究的意义和重要性
1.2.1 研究的意义
<此处插入论文的研究意义，应该和1.1.2小节的问题概述相呼应>
1.2.2 研究的重要性
<此处插入研究的重要性，应该和1.1.2小节的问题概述相呼应>
1.3 研究的内容和主要工作
1.3.1 研究的内容
<此处插入研究的内容，也应该和1.1.2小节的问题概述相呼应，简要说明论文中的系统采用了什么样的技术手段，采用了什么样的组织架构，做了些什么研究工作，解决了哪些问题>
1.3.2 本人主要工作
<此处插入作者本人在项目中所负责或者完成的具体工作，应与1.3.1的研究内容相对应，简述作者本人所做的研究工作。此外，如果论文所述项目为集体合作，则应该简略指出作者本人所负责的工作。以下为范本！>
在此项目中，本人做了如下工作：<此处插入所做工作>
在项目开发中，本人主要负责系统需求分析、功能性分析、系统整体数据库设计、主体框架设计搭建、WEB端程序开发，系统文档撰写、系统整体测试以及历史数据导入等工作。
1.4 论文结构
<此处插入该论文的整体结构，简述论文的整体形式结构，并简述每一章的主旨。以下为范本，请勿照搬！>
本文由五章内容组成，其中：
第一章介绍了本文的研究背景，对所需要解决的问题进行了概述，讨论了项目的研究意义与重要性，阐述了论文的主要内容以及本人的主要工作。
第二章阐述的是本文所涉及到的开发方法及相关技术，包括：软件工程开发模型、UML建模技术、数据库技术等。
第三章是本文的核心内容之一，针对系统的业务需求、功能需求、数据需求和非功能需求等进行了详细分析，给出了主要的业务流程图和用例图，并对核心用例进行了详细描述，同时进行了基础数据的概念设计。
第四章是本文的重点，在进行了系统总体设计的基础上，采用UML的包图、类图、顺序图和活动图等对系统的子模块进行了功能性详细设计，并给出了主要功能的界面设计，同时通过实体类图、E-R图和数据库表结构对数据库进行了详细设计。
第五章总结了本文所做的工作，同时对进一步的工作进行了展望。
第二章 系统的开发方法及相关技术
<此处插入系统开发方法的统一概述，旨在简要的解释系统开发的方法和涉及的相关技术。以下为范本，请勿照搬！>
本XXX系统采用基于XXX架构，对应使用XXX技术来展现其表示层，分别对不同需求的用户服务，旨在最大程度满足不同用户的需求。服务层采用XXX技术来提供统一接口，降低其与其他系统间的耦合度，提供安全数据通信，提高系统可扩展性、兼容性以及集成能力。……<此处插入其他所采用的技术手段>。
此外，系统采用增量模型进行开发，以应对不断变化的需求，大量降低项目风险，保证系统核心功能，较快的交付可使用的模块。

<以下几个小节将根据以上统一概述，较为详细的逐一展开进行叙述，每一项具体开发方法或者相关技术的综述独立成为一个小节，每个小节下面具体有多少子小节并无具体规定，只要能讲述清楚明白即可，以下为范本，请勿照搬！>
2.1 软件工程开发模型
2.1.1 传统瀑布模型
瀑布模型(也称为线性顺序模型)，由温斯顿·罗伊斯在1970年提出，在20世纪80年代以前，瀑布模型一直都是唯一被广泛采用的软件开发模型。这个模型中，软件生命周期中的制订计划，需求分析，软件设计，程序编写，软件测试和运行维护依次由上至下顺序展开，如同瀑布流水，逐级下落，最终得到软件产品。理想化的瀑布模型是单边逐一而下的，认为人在工作过程中不可能犯错误。实际的瀑布模型是带有反馈逐一而下的，当后一阶段发现前一阶段的错误时，可以修正前一阶段的错误继续完成后一阶段的任务。

图2.1瀑布模型[1]
瀑布模型的优点：
l 促进软件开发工程化，为项目提供了按阶段划分的检查点
l 降低软件开发的复杂度，当前一阶段完成后，只需去关注后续阶段
l 可以在增量模型中使用瀑布模型
瀑布模型的缺点：
l 缺乏灵活性不适应用户需求的变化，项目的各个阶段之间极少有反馈
l 如果软件需求不明确或者经常变更需求，最终可能导致开发出的软件与用户预期的软件不符，往往会导致大量的返工，有时甚至会给开发人员带来灾难性的后果，而这一点又常常在项目生命期的后期才有所觉察。
2.1.2 改进的螺旋模型
螺旋模型由巴利·玻姆于1988年正式发表了软件系统开发的“螺旋模型”，它是将瀑布模型与演化模型相结合，并且增加了两者所忽略的风险分析，弥补了两者的不足之处，该模型通常用来指导大型软件项目的开发软件项目的开发，。软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。软件风险驾驭的目标主要是在造成危害之前及时对风险进行识别，分析，采取对策进而消除或者减少风险的损害。螺旋模型将开发划分为制订计划，风险分析，实施工程，客户评估四类活动。沿着螺旋线每旋转一圈，表示开发出一个更完善的新的软件版本，如果开发风险过大，开发机构和客户无法接受，项目就有可能就此终止。多数情况下，会沿着螺旋线继续下去，自内向外逐步延伸，最终得到满意产品。螺旋模型开发的成败很大程度上依赖于风险评估的成败。
沿着螺旋线旋转，在笛卡尔坐标的四个象限上分别表达了四类活动：
制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。
风险分析：分析所选方案，考虑如何识别和消除风险。
实施工程：实施软件开发。
客户评估：评价软件功能和性能，提出修改建议。

图2.2螺旋模型[

]
螺旋模型的优点：
l 设计上的灵活性,可以在项目的各个阶段进行变更。 　　
l 以小的分段来构建大型系统,使成本计算变得简单容易。
l 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
l 随着项目推进,客户始终掌握项目的最新信，从而他或她能够和管理层有效地交互。
l 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
螺旋模型的缺点：
l 很难让用户确信这种演化方法的结果是可以控制的。
l 建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
2.1.3 面向对象的喷泉模型
在面向对象的方法中，提出了于瀑布模型相对应的喷泉模型，该模型的主要特点是认为软件生命周期的各个阶段是相互重叠和多次反复的，它是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。喷泉一词本身就体现了迭代和无间隙的特性。

图2.3喷泉模型[1]
喷泉模型的优点：软件项目开发效率高，节省开发时间，适应于面向对象的软件开发过程。喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。
喷泉模型的缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
形式化方法模型包含了一组活动，他们导致了计算机软件的数学规约。形式化方法使得软件工程师们能够通过应用一个严格的数学符号体系来规约、开发、和验证基于计算机的系统。在开发中使用形式化方法时，它们提供了一种机制，能够消除使用其它软件过程模型难以克服的很多问题。二义性、不完整性、不一致性能被更容易地发现和纠正，而不是通过专门的评审，是通过对应用的数学分析。 形式化方法提供了可以产生无缺陷软件的承诺。
2.2 UML建模技术
2.2.1 UML语言和要素
UML（Unified Modeling Language）统一建模语言,是用来对软件密集型系统进行可视化建模的一种通用语言。UML被广泛应用于数据建模，业务建模，对象建模，组件建模等。
UML与具体的程序设计语言无关，它只是一种建模语言而不是一种方法学，和其它的计算机语言一样，也是由基本词汇和语法两个部分构成。UML定义了一些建立模型、表达某种特定含义所需要的基本元素，这些元素称为元模型，相当于语言中的基本词汇，例如用例、类等。在此基础上，还定义了这些元模型互相之间关系的规则，以及如何用这些元素和规则绘制图形以建立模型来映射现实世界，这些规则和图形称为UML模型表示法或图示。
UML正处于不断演化和完善过程之中，最初的UML标准只是作为一种面向对象辅助的工具而设计的，即为软件的设计意图提供一种非形式化的捕获和表达手段和工具。因此，早期UML版本中存在着的一些因UML工具厂商不同而引入的分歧和模糊定义，正随着UML标准的演化而被逐步消除，让其向着成为一种形式化建模语言规范的方向不断演化。与此同时，UML也正在变得越来越庞大，但当我们只是运用UML来进行面向对象设计时，并不需要用到所有的UML内容，而是可以学习和使用UML那些最适合的部分。
2.2.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.3 数据库技术
2.3.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.3.2 数据建模
因为数据模型的内容是问题域和解域所共享的知识模型，所以可以用问题域的语言来描述它，也可以用解域的语言来描述它，还可以用介于二者之间的语言来描述，故产生了以下三种常用的数据模型：
1） 概念数据模型[2]。它反映了人们对现实世界的认知与理解，是从现实世界到人类大脑的映射。故它以问题域的语言解释数据模型，由一系列应用领域的概念组成。
2） 物理数据模型。它是以解域的语言解释数据模型，是面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有起对应的物理数据模型。
3） 逻辑数据模型。这是用户从数据库所看到的模型，是具体的DBMS所支持的数据模型，如网状数据模型(Network Data Model)、层次数据模型(Hierarchical Data Model)等等。此模型既要面向用户，又要面向系统，主要用于数据库管理系统（DBMS）的实现。
第三章 需求分析
软件需求过程是整个软件开发初始阶段，对软件的品质具有决定性的作用。软件需求工程研究如何理解和说明用户对所开发软件的要求和期望。
需求就是以一种清晰、简明、一致且无二义性的方式对一个待开发系统中的各个方面有意义的陈述的集合[4]。需求必须是完整的，足以使设计师和工程师来开发一个使客户满意的软件制品。
IEEE软件工程标准词汇表(1997年)中定义需求为[5]：
（1） 用户解决问题或达到目标所需的条件或能力(Capability)；
（2） 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力；
（3） 一种反映上面(l)或(2)所描述的条件或能力的文档说明。
软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）[6]。
3.1 业务需求
业务需求(business requirement)是客户对软件制品目标的高层次要求。
3.1.1. 业务描述
<描述系统当前的主要业务问题，进一步阐述通过计算机软件要达到哪些目标，解决哪些主要问题等。示例：>
（一） 能够实现商品展示、商品检索、商品选择、网上订货、网上支付和商品发货等功能，对网上购物的全过程进行管理
（二） 实现对网上购物过程中产生的所有业务数据的管理，如订货单、支付记录、发货信息的管理与维护
（三） 具有配套的系统后台管理维护功能，能够对商品信息、用户信息、系统日志等信息进行管理与维护，并能够进行对应的权限管理
（四） 响应速度合理，安全性较高
（五） 系统运行稳定，并且应易于维护
3.1.2. 主要业务流程
<使用UML的活动图描述系统的主要业务流程等。示例：>
（一）商品展示活动图

图3-1 商品展示活动图
（二）网上订货活动图

图3-2 网上订货活动图
（三）货款支付活动图

图3-3 货款支付活动图
（四）发货活动图

图3-4 商品发货活动图
（五）退货处理活动图

图3-5 退货处理活动图
3.2 功能需求
功能(function)是刻画系统行为、特别是系统与环境关系的重要概念。用户需求(User Requirement)描述了待开发的软件必须完成的任务。功能需求(Functional Requirement)定义了必须实现的软件功能，使得用户通过这些功能完成他们的任务，从而满足业务需要。
3.2.1 角色分析
<从系统的角度分析系统的参与者，并给出每一个参与者的描述。>
以下从网上购物系统的实际需求分析，系统涉及到以下角色：
角色
职责或功能
客户(买家)

卖家

系统管理员
管理和维护整个系统的用户组织结构，负责对用户、角色、用户级别的增、删、改、查等管理。

3.2.2 业务功能
<从系统的使用者的角度使用UML的用例图描述系统的用例，并给出每一个用例的用例描述。>
以下从业务角度出发，给出了系统的总体用例图，包含商品选购、网上订货、贷款支付、商品发货、退货管理、订单管理和发货信息等用例，如下图所示：

图3-6 系统总体用例图

3.2.2.1 商品选购

图3-7 商品选购用例图

表3-1商品选购用例描述
描述项
说明
用例名称
商品选购
标识符*
YL01
用例描述
描述了买家使用本系统销售管理子系统进行商品选购的整个过程
参与者表
客户（买家）
优先级
1
状态*
进行中
前置条件
用户已登录系统
后置条件
系统给出操作成功提示
基本操作流
1.用户在系统主页上选择商品分类，进入商品列表查看界面或在搜索框中要购买商品关键信息进行检索，提取符合条件的商品列表；
2.找到所需商品后点击“查看详细信息”按钮，进入商品详细信息查看页面；
3.确定购买后，设置购买数量，点击界面上的“放入购物车”按钮；
4.根据需要，点击“继续购物”按钮，返回主界面继续选购其他商品；
可选操作流
1．用户将选购商品放入购物车后，不继续选购其他商品，进入购物车中确认商品信息，确认无误后，点击结算按钮，进入支付界面。
2. 用户将选购商品放入购物车后，可以进入购物车删除已放入商品。
被泛化用例表
该用例的特化用例列表
被包含用例表
无
被扩展用例表
无
修改历史记录*
暂无
问题*
暂无
决策*
暂无
频率*
暂无

表3-2商品信息获取用例描述
描述项
说明
用例名称
商品信息获取
标识符*
YL02
用例描述
描述了买家使用本系统进行商品信息获取的过程
参与者表
客户（买家）
优先级
2
状态*
进行中
前置条件
用户已登录系统
后置条件
系统显示所获取商品信息
基本操作流
1.用户在系统主页上选择商品分类，进入商品列表查看界面。
2.输入关键字，进入关键字相关商品列表查看界面。
可选操作流
无
被泛化用例表
无
被包含用例表
商品选购
被扩展用例表
无
修改历史记录*
暂无
问题*
暂无
决策*
暂无
频率*
暂无
表3-3购物车管理用例描述
描述项
说明
用例名称
购物车管理
标识符*
YL03
用例描述
描述了买家使用本系统进行购物车管理的整个过程
参与者表
客户（买家）
优先级
2
状态*
进行中
前置条件
用户已登录系统
后置条件
系统给出操作成功提示
基本操作流
1.用户在系统商品列表页面选择某一商品
2.点击“加入购物车”按钮
3.将商品加入购物车
可选操作流
1．用户可同时选择多种商品再点击“加入购物车”按钮，同时加入多种商品
被泛化用例表
无
被包含用例表
商品选购
被扩展用例表
无
修改历史记录*
暂无
问题*
暂无
决策*
暂无
频率*
暂无

表3-4将商品放入购物车用例描述
描述项
说明
用例名称
将商品放入购物车
标识符*
YL04
用例描述
描述了买家使用本系统将商品放入购物车的整个过程
参与者表
客户（买家）
优先级
3
状态*
进行中
前置条件
用户已登录系统
后置条件
系统给出操作成功提示
基本操作流
1．选择商品
2．点击“加入购物车按钮”
可选操作流
1．用户可同时选择多种商品再点击“加入购物车”按钮，同时加入多种商品
被泛化用例表
无
被包含用例表
购物车管理
被扩展用例表
无
修改历史记录*
暂无
问题*
暂无
决策*
暂无
频率*
暂无

表3-5将商品从购物车移除用例描述
描述项
说明
用例名称
将商品从购物车移除
标识符*
YL05
用例描述
描述了买家使用本系统将商品移出购物车的整个过程
参与者表
客户（买家）
优先级
3
状态*
进行中
前置条件
用户已登录系统
后置条件
系统给出操作成功提示
基本操作流
1．点击“购物车”按钮进入购物车管理界面
2. 选择商品
3．点击“移出购物车按钮”
可选操作流
1．用户可同时选择多种商品再点击“移出购物车”按钮，同时移出多种商品
被泛化用例表
无
被包含用例表
购物车管理
被扩展用例表
无
修改历史记录*
暂无
问题*
暂无
决策*
暂无
频率*
暂无

表3-6设置购买数量用例描述
描述项
说明
用例名称
设置购买数量
标识符*
YL06
用例描述
描述了买家使用本系统进行商品选购的时设置购买数量整个过程
参与者表
客户（买家）
优先级
3
状态*
进行中
前置条件
用户已登录系统
后置条件
系统给出操作成功提示
基本操作流
1.用户点击“购买数量”后的加减箭头，或在文本框内输入购买数量
2.点击“确认”
可选操作流
无
被泛化用例表
无
被包含用例表
购物车管理
被扩展用例表
无
修改历史记录*
暂无
问题*
暂无
决策*
暂无
频率*
暂无

表3-7检索商品用例描述
描述项
说明
用例名称
检索商品
标识符*
YL07
用例描述
描述了买家使用本系统在商品选购时进行商品检索的整个过程
参与者表
客户（买家）
优先级
3
状态*
进行中
前置条件
用户已登录系统
后置条件
系统给出用户所搜索商品列表
基本操作流
1.用户点击在文本框中输入关键字
2.点击“搜索”按钮
可选操作流
无
被泛化用例表
无
被包含用例表
商品信息获取
被扩展用例表
手动浏览商品、使用关键字进行商品检索
修改历史记录*
暂无
问题*
暂无
决策*
暂无
频率*
暂无

表3-8查看商品详细信息用例描述
描述项
说