数据库开发方法

1、.1第13章 数据库应用系统的开发方法结构化生命周期方法结构化生命周期方法快速原型方法快速原型方法面向对象设计方法面向对象设计方法!客户客户/服务器应用规划综述服务器应用规划综述.2结构化生命周期方法z确定系统需求；z系统开发；z系统安装配置；z系统运行；z系统切换。1.系统调查及可行性分析；2.系统分析（需求分析）；3.概要设计（总体设计）；4.详细设计（模块设计）；5.系统实现（编程）；6.系统调试与试运行（测试）；7.系统运行、评价与维护（运行）。.3系统调查和可行性分析z这一阶段的任务是初步了解信息系统用户的组织机构、业务范畴以及新系统的目标，并且做出可行性分析，包括经济可行性、技术可

2、行性和使用可行性。.4需求分析和信息采集z准确、全面地采集信息是数据库应用规划和设计的必不可少的重要组成部分，要想确保在数据库应用开发的各个阶段所做出的重要决定都是明智和正确的，那么做好这一步的工作就更加至关重要。.5总体设计z这一步的主要任务是把用户的信息要求统一到一个整体的逻辑结构或概念模式中，此结构能表达用户的要求，并且独立于任何硬件和数据库管理系统。这一步，从应用程序的角度来讲，要完成子系统的划分和功能模块的划分；从数据库的角度来讲要完成概念模型的设计。.6详细设计z这一步同样是包括数据库设计和应用程序设计两大部分。对数据库设计要根据具体的数据库管理系统设计数据库、设计关系、考虑数据的

3、完整性、考虑数据的安全和备份策略等。对应用程序设计要给出功能模块说明，考虑实施方法，设计存储过程等。.7编程z它根据上一步的设计结果进行具体实施，建立数据库并装入原始数据，建立存储过程，编写和调试应用程序代码等。.8调试与试运行z一般在编程阶段都做了局部测试，现在各个子系统、各个模块要进行联合调试和测试，并试运行。在试运行阶段要广泛听取用户的意见，并根据运行效果进行评估，修改系统的错误、改进系统的性能。.9交给用户使用z最后一步是将系统交给用户使用，在使用的过程中可能还会出现新的问题，甚至提出新的需求，所以还要不断对系统进行评价和维护。数据库系统的维护不是一朝一夕的事，只要数据库系统存在，就要

4、不断进行评价、调整、修改，直至数据库生命周期结束，或完全重新设计为止。.10快速原型方法z所谓“原型”可以看作是“企业作业原型”或“软件功能原型”，它基本反映了最终系统的基本功能和基本特征，依此可以快速开发一个可以演示的系统，用户可以在这个原型系统中得到启发，发现存在的问题，提出新的要求，并和开发人员一起修正和发展原型。如此反复进行，最后形成用户满意的系统。.11快速原型开发方法可以分为四个步骤：z系统基本需求的确定；z对原型的功能选择；z原型的构造与试用；z原型的修改和完善。.12面向对象方法z面向对象（Object Oriented）方法的思想源于面向对象程序设计。面向对象的分析方法是从现

5、实世界抽象出对象及发生在对象上的事件，从而建立起数据对象和处理操作之间的联系。而利用面向对象的开发工具去实现面向对象的模型是一件很自然的转换过程。.13面向对象的分析和设计方法z系统分析z系统设计z系统实施.14系统分析z和结构化生命周期法一样，在面向对象开发方法过程中需求分析阶段的主要任务也是确定用户的需求，面向对象的分析方法以现实世界的对象为基础，注重现实世界对象的数据特征和行为特征，虽然它在表述对象的数据需求和操作需求方面是很自然的，但却没有想象的那么简单，还是需要一定的经验，因为现实世界中的客观对象是五花八门的，所以有时利用面向对象方法进行抽象可能会有一定的困难。 .15系统分析z抽象

6、对象的过程可以由上向下，也可以由下向上。所谓由上向下，就是首先抽象出整个问题域中的所有对象，并以对象为基础分析对象的数据需求和操作需求，然后给出问题和解决问题过程的准确描述；而所谓由下向上则是首先描述各个问题和解决问题的过程，并从各个问题中抽象出对象，然后将同类对象进行合并。 .16系统分析z需求模型化是面向对象方法中最常用的方法之一，它通过对需要解决的实际问题建立业务模型来抽取对象、描述对象，从而将用户的需求准确地表达出来。一般包括对象模型、动态行为模型和用界面模型等。 .17对象模型z对象模型是整个面向对象方法的基础，它是整个系统的抽象，其中要描述用户需求中的各个对象，及其对象的属性、可能

7、处于的各种状态以及可能的继承、集合等，还要包括各个对象之间的相互关系等。 .18动态行为模型z动态行为模型主要用来描述系统的一些动态特征，如定义可能的系统事件和各实体对各种事件的响应等。 .19用界面模型z用户界面模型显然用来描述用户使用和操作应用系统的界面，包括界面的外观和各种具体的操作功能等，它可以使客户对未来的系统首先建立一个感官的认识。 .20系统设计z概要设计y概要设计也称作总体设计，所以这一阶段的任务是要将用户的需求统一到一个总体的逻辑结构和概念模式中，要描述出与对象模型对应的所有类，要描述类之间的相互关系和继承关系等；同时要将动态行为模型中的操作、事件和对事件的响应等体现在类中；

8、在这个阶段还要确定整个应用系统的结构框架和输入输出接口等。 .21系统设计z详细设计y确定系统的具体实施方法。要对每个类进行细化、分析、验证，要确定每个类的属性，要确定每个对象可能出现的各种状态，要确定每个类将要支持的方法，要确定每个方法的功能、参数和返回值等。 y在设计类时要充分考虑类的封装性、继承性和多态性。要明确规定类和类内成员的访问权限；要充分分析类之间的关系，特别是继承关系，使软件可重用性得到充分体现；要仔细、严格设计和验证各种方法和函数，保证系统描述的一致性。 .22系统实施 z通过选择一种合适的面向对象的开发工具（如PowerBuilder）具体开发和实现经过仔细设计的应用系统。

9、在编程实现工作过程中，肯定会发现在分析和设计阶段隐藏的问题，这时则要及时地返回相关步骤进行调整。 .23可能会失败！ .24认识问题 有些系统集成公司在项目的网络、硬件、系统软件等方面都很有经验，也很成功，但当他们为用户开发软件时，往往开始也踌躇满志，在经过一段时间后就显得力不从心了，结果搞的焦头烂额。其原因是这些系统集成公司多是一些硬件商或软件商的代理，对产品很了解，但是他们缺少系统分析人员，对数据库项目的开发认识不足、了解甚少，并且普遍轻视系统分析和系统设计工作，结果很难收场，最后以失败告终。.25方法问题 国内各种教科书对结构化生命周期方法介绍较多，这种方法比较规范，国外成功的例子也很多

10、。这种方法对需求分析的结果要求很高，按规定需求分析所产生的系统说明书将作为系统开发的技术合同，以后的工作按部就班地进行就可以了。 如果照搬结构化生命周期方法开发国内的数据库项目，多数情况下都不现实，往往按照技术合同开发的系统并不是用户所需要的系统，其原因我们已经在前文中说明了。结果是用户对开发的系统不认可、不验收；开发方以技术合同为证指责用户。如果双方都不让步，则只能以失败告终。.26工具问题 有一些开发单位或开发人员，对数据库项目开发了解甚少，经常称自己采用的是“快速原形方法”，但结果却不快。程序是一条条编出来的，开发人员需要经常修改程序和数据库结构，甚至推倒重来。这里面，一方面是忽视了前期

11、的分析和设计工作，没有构造出准确的原型；另一方面是没有掌握快速的开发工具，靠手工完成大部分程序。 由于缺少对开发数据库项目的整体认识，盲目采用所谓快速原型方法，结果反而不快，搞的自己狼狈不堪。.27管理问题 有些单位对开发一些简单的系统还可以胜任，在开发大系统时，各独立的子系统也分别能正确运行。但是，这些子系统却不能协同工作，数据共享差。另外，各子系统的界面风格可能也相差甚远。之所以会这样，主要是项目负责人或开发单位缺乏对整个项目的有效管理，开发人员之间也缺乏有效的沟通和交流.28客户/服务器应用规划综述 可以量化的需求分析 性能需求 并发需求 数据分布需求 恢复需求 安全问题 系统需求.29

12、可以量化的需求分析（1）站点的数量：1.整个应用系统是否需要有一个中心服务器？2.是否需要多台服务器？若是，是按部门划分还是按地理区域划分？3.下一级服务器是否需要向上一级服务器传送汇总数据？4.各站点间的需求是否会不一致？事务的数量：1.应用系统的事务有哪些？2.每一个事务的复杂程度如何？3.每一个事务的执行频率如何？4.事务的峰值会在每天的固定时间出现吗？5.比较大且复杂的事务可以分解为数个小而简单的事务吗？.30可以量化的需求分析（2）数据特征：动态与静态数据数据的增长历史数据用户的数量：1.一共有多少用户？2.在同一时刻最多会有多少用户连接到服务器？3.这些用户执行事务的分布情况如何？

13、会很集中吗？4.用户是按照地理因素或部门因素平均分布的吗？.31性能需求事务的速度：1.更新数据库的哪些事务是最复杂的？2.复杂的事务可以分解为数个较简单的事务吗？3.从业务规则来看，哪些事务是最重要的？4.哪些事务必须有最快的响应时间？5.每类事务的时间峰值会发生在什么时间？6.每类事务的数据量峰值是多少？7.复杂的事务可以在非峰值时间段中运行吗？查询速度：1.哪些重要的查询需要有最快的响应时间？2.是否可能让一些查询定时运行，特别是在非高峰的时间段内？3.是否允许一些汇总数据以冗余方式保留在数据库中？4.允许即席查询吗？5.可否通过灵活的参数来建立结构化查询以便处理更多的查询？6.可以将即

14、席查询限制在预定义的视图上吗？7.哪些查询需要保证读一致性？.32并发需求1.某一应用程序的运行只发生在一天之中的某些时刻吗？2.某一应用程序会在不同的站点同时运行吗？3.会有一些应用程序出现“热点”或“瓶颈”现象吗？.33数据分布需求数据如何分布？如何利用复制功能完成数据分布管理？.34恢复需求1.在一次故障事件中，某个应用服务器可以承受多少数据损失？2.某个服务器可以为恢复数据而停止多长时间？3.备份是自动控制还是由人工控制？4.对服务器设备是否有物理的存取限制？5.如何考虑备份的代价？.35安全问题 建立正确的安全性级别和方案，是保证整个SQL Server应用成功的一个保障。太低的保密级别会使一些未经授权的操作者看到敏感的数据；太严格的保密级别又会限制操作者完成正常的工作，并可能会导致用户对应用程序、甚至对整个系统的不满意。.36系