草稿.docx
- 文档编号:29745497
- 上传时间:2023-07-26
- 格式:DOCX
- 页数:14
- 大小:51.33KB
草稿.docx
《草稿.docx》由会员分享,可在线阅读,更多相关《草稿.docx(14页珍藏版)》请在冰豆网上搜索。
草稿
实训:
用面向对象的方法开发数据库中的基本表
在应用系统的开发中,系统的架构主要由数据库的设计决定。
如果把软件开发比喻成建造一栋大楼,那么数据库就是这栋大楼的框架,数据库的设计决定着系统开发、系统性能以及日后系统维护与升级的难易度,是系统成败的关键。
由此可见数据库的重要性。
而在三层架构的开发模式(接口层、逻辑层、数据库层)中,数据库层的开发以基本数据表(简称基本表)为主。
数据库开发之后的系统开发中,开发者根据应用逻辑层(代码层)的需要会对数据库作进一步的设计,但基本表一般已确定不变。
本章讨论“智能停车场管理系统”的核心子系统——“停车收费”中,“进场计费”用例的基本表的设计。
为了简化问题,这个系统是专门为小区设计的,假设长类只能停小汽车车,而且无论小汽车的款式、档次如何,收费标准都一样。
1.1概述
对于大型复杂的应用系统来说,其“核心需求”大约只占整个系统的10%~15%左右,而且“核心中的核心”所占的比例更少。
以“智能停车场管理”系统为例,客户作为停车场的场主,最关心的是:
在汽车进场停车后能实现收费盈利的目的,即实现以下两个功能:
1.为客户提供停车场地。
2.收取停车费用。
所以智能停车场管理系统中的核心需求为“停车收费”子系统。
面向对象软件开发方法进行数据库开发的步骤是:
1.对将要开发的应用系统进行需求分析与建模。
2.建立待开发的系统概念模型、域模型。
3.进行数据库分析与设计。
第1步和第2步是应用面向对象方法开发数据库设计的关键。
1.2建模工具的选用
数据库开发涉及到需求分析与建模、概念模型、域模型与数据库设计,需要使用UML建模工具和数据库建模工具。
现在市面上流行的工具比较多。
这里推荐Sybase公司的PowerDesigner(简称PD,本章使用第11版)。
PD是目前最优秀的数据库开发工具之一,有许多优点,这里给出部分特点如下:
1.建模速度快,可视化程度高。
一些软件(如.Net、SqlServer等)也实现部分可视化设计的功能,但效果远远不如PD。
2.提供“一站式”服务,贯穿于整个软件开发的各个阶段。
特别是在数据库分析、建模与实现中享有盛誉,这是许多其他工具(如Visio,NationalRose等)无法做到的。
3.提供许多将模型自动转化为系统设计的功能。
如概念数据模型自动转化为物理数据模型,物理数据模型自动转化为数据库,自动生成开发文档等等。
PD的这些优点被许多软件所模仿。
如VisualStudio、SqlServer的早期版本缺乏可视化模型,新版本的模型带有类似PD的部分功能,但远远不如PD好用。
不过PD也有其缺点,本人认为其主要的缺点有:
图形元素简单朴素,自动化排版的效果比较差。
这一点PD有点吃亏,因为华丽的广告往往能让质量稍微差的产品大受欢迎。
一般来说,客户不太关心系统开发所用的核心技术,只看重系统能实现的功能。
就算系统的模型中出现严重的逻辑错误,使得系统不可能实现,但客户往往也不太在意或难以觉察。
显然图形元素丰富华丽,加上系统推广员洞察客户心理,会很好地掩饰上述的逻辑错误,深深地打动客户的心。
不过后续开发人员可能要消耗大量精力和金钱来解决问题,使得开发成本激增。
本人认为,作为软件开发者,只关心核心技术,追求的是简单易用、快速开发,这点是PD的优势,故PD可以说主要是面向软件开发者的。
1.3系统结构
在大型服装企业中,把生产服装的过程分为做领子、缝纽扣、缝口袋、锁边等十几道工序,按流水线模式让每位员工做一道工序,从而降低员工技术要求,大大提高产品的质量,同时实现“一分钟生产一件衣服”的极高效率。
类似地,对于大型复杂的应用系统,应用面向对象的方法,通过系统的需求分析,将系统分成若干个相对独立的子系统,如果子系统还是很复杂,可以将其逐步细分为一级子系统、二级子系统……最后还可以分成模块、子模块。
各子系统或模块由不同的开发人员负责。
应用此方法,理论上应能将系统进行“无限细分”。
对于智能停车场管理系统,可分为如图1-1所示的各个子系统,:
图1-1智能停车场管理系统的子系统划分
现围绕其中的核心需求——“停车收费”子系统,并对其作进一步的细分,阐述使用面向对象进行数据库开发的方法。
1.4用例模型
从使用计算机系统实现业务流程的角度考虑整个“停车收费”业务的工作流程,此即用例模型。
描述业务流程可以遵循“晴天叙述”模式,即以最理想的状况完成业务,不会出现任何意外或差错。
这样能使开发的难度大为降低。
整个停车收费的过程描述如下:
1.购买IC卡。
2.汽车进场,同时收费系统启动计费。
3.导航系统将汽车导航至停车位。
4.汽车出场,同时收费系统结束计费并结账。
5.对上述业务进行监控,更新业务记录。
1.4.1基本用例
上述的事件用来设计基本用例。
整个业务完成的过程中有可能出现“晴天叙述”没有涉及的情况,如万一出现“IC卡余额不足”、“汽车超过保管期”等,留作下一步设计(称为扩展用例)解决。
扩展用例的设计方法与基本用例一样,这里不再叙述。
根据上述分析,得出“停车收费”子系统的用例图如下:
图1-2停车收费用例图
1.4.2用例详述
观察用例图,能明确系统有哪些业务,涉及哪些参与者。
但是业务流程具体是怎么完成的,各步骤的细节如何,用例图并没有明确。
这个任务由用例详述完成。
用例详述是从系统操作的角度描述完成整个业务流程的过程。
现以“进场计费”为例,给出其详述:
日期:
2005-07-06
版本号:
1.0
用例名称:
进场计费
前置条件:
汽车已有IC卡
用例详述:
1.汽车开始驶近停车场入口。
2.汽车离入口20~30米处,遥感IC卡读卡器自动获取卡的序列号,并发送给控制中心。
3.控制中心查询数据库,获取IC卡的种类(年票卡、月票卡、临时卡)、余额信息。
4.控制中心根据IC卡信息确认汽车可以进场,向入口栏杆发出开闸命令。
5.栏杆打开。
6.汽车进场。
7.入场感应器测出汽车已进场,向入场栏杆发出闭闸命令。
8.入场栏杆合上。
9.控制中心对该车启动计费系统。
10.控制中心通知车位管理中心更新车位信息。
11.业务中心记录业务。
后置条件:
汽车已进场。
注:
用例详述应描述为操作流(从通过系统操作完成业务的角度)。
不要描述为业务流(不使用系统时完成业务的流程)。
“停车收费”中的其它设计用例留作练习,由读者自行完成。
1.4.3活动图
用例详述以文字的方式进行详述,虽然条理清晰、逻辑性强,但文字描述并不是可视化的,给人的感觉不是十分满意。
为了进一步理解用例详述,使用另一个重要的可视化模型——活动图。
用例“进场计费”的活动图如图1-3所示。
图1-3进场计费活动图
注:
有些较大的软件公司在开发项目时,用非常大的打印纸打印上述模型,并贴在开发现场的墙壁上,让客户深深地感受公司的技术氛围,同时让开发团队各成员对自己的位置和任务都很清楚,开发者对整个系统也能一目了然。
1.5顺序图
接下来要明确用例中的事件流发生的顺序。
在现实中,有些事件的顺序性不强,甚至有并发事件。
但计算机的速度快,能按顺序执行事件而人类缺觉察不到。
在设计顺序图中,可以的话,把并发事件也设计成具有一定顺序的事件,这有利于系统的实现。
“进场计费”用例所对应的顺序图如图1-4所示。
图1-4进场计费顺序图
1.6建立概念模型
利用上面的模型进行概念模型的设计。
概念模型实际上就是面向对象中的分析类,只不过前者是从业务领域的角度,而后者是从设计系统的角度。
注:
1.分析类不是后续代码开发中的设计类,但前者是后者的基础。
2.作为程序员,已经懂得概念与类的关系,有些公司为了省事,直接设计类,跳过概念模型这一步,这也是一种方法。
本章暂时不用此法,待大家熟悉之后可以自行选择方法。
以“进场计费”为例,根据上述模型可以得到一些词汇:
车主、汽车、IC卡(序列号、类型余额)、IC卡读卡器、栏杆、控制中心、汽车进场感应器、车位、管理中心、业务中心(记录业务)
接下来对这些词汇进行详细的分析。
这些词汇中有些进过整合,可以作为系统的概念,有些与系统无关,就去掉。
这里举一个例子:
车主驾驶汽车进场停车引发了“进场计费”业务,是否在“进场计费”系统的概念模型中包含这两个概念:
车主、汽车?
站在客户(停车场场主)的角度来说,只要汽车进场就可以收取费用,客户“认车不认人”,况且有些车主也不远留下个人信息。
所以系统只需要“汽车”这个概念,而把“车主”这个概念去掉。
(当然,其他地方可能需要车主信息。
但现在是设计“进场计费”,应撇开其他任何情况,集中精力只考虑这一问题。
)
再进一步讨论:
停车场实行“一车一卡”,以IC卡作为汽车的身份标志,故去掉词汇“汽车”。
又如,栏杆和读卡器是硬件设备,生产厂家已经设计好了,可直接使用,不作为软件系统设计中的一个概念。
注:
上述建模过程中,把与系统相关的概念进行整合,而把与系统关系不大的概念去掉,这就是面向对象中的一个非常重要的方法——抽象。
其余的问题按照类似的方法处理,最后得出概念模型,如图1-5所示。
图1-5进场计费概念模型
每一个概念都具有一些属性。
设计概念属性的过程中也运用面向对象中的“抽象”方法:
与系统相关的属性要保留,而把与系统无关的属性去掉。
各个概念的属性设计如图1-5所示。
图1-6概念的属性设计
注:
这里只研究用例“进场计费”所涉及的概念,如果把整个子系统考虑进去,所需的概念,以及每个概念具有的属性会更多。
这一步留给读者自己完成。
1.7域模型
概念与概念之间存在一定的关系,通过它们之间的协作完成整个业务流程,域模型就是描述概念与概念之间的关系的。
以图1-6为例,汽车进场时通过IC卡触发控制中心对汽车进场事务进行处理,控制中心通知业务中心启动业务记录,三者的合作完成了“进场计费”业务,如图1-7所示。
图1-7进场计费域模型
注:
本章域模型中所涉及的概念与概念之间的关系均为简单关联。
读者如果想进一步研究,可参考UML方面的书籍。
注:
上述各步骤后,要经过反复修改,并与开发团队中的其他成员相互交流(软件工程中称为“头脑风暴”法)。
1.5数据库基本表建模与设计
根据域模型中的概念与属性,可以设计出数据库模型。
使用PD可以设计概念数据模型和物理数据模型。
按理应先设计概念数据模型,再设计物理数据模型。
但软件公司为了加快开发进度,往往直接设计物理数据模型。
如果所开发的项目还不知道将要用什么数据库,只能先设计概念数据模型,不过这种情况很少见,一般来说,项目在启动之前就决定使用什么技术,包括将使用哪种数据库,故作者认为直接开发物理数据模型也是一种好方法。
PD提供将概念数据模型自动转化为物理数据模型和将物理数据模型自动转化为实际数据库的功能,非常方便。
感兴趣的读者以参考相关文档。
1.5.1设计基本表
根据上述的模型,可以建立数据库基本表的模型。
在基本表中,先不考虑个字段的类型,如图1-8所示。
图1-8进场计费数据表模型
注:
实际设计中的表名和字段名不出现中文。
这里只是为了使读者不产生误解。
数据表的作用是记录企业信息,并根据需要,向客户呈现信息。
如果能以最科学的方式记录信息和呈现信息,同时又是最简单合理的,这种设计就是最好的。
为了做到这一点,虽然采用三层模式,各层的开发相对独立,但在数据库开发中稍微考虑数据层与表示层、数据层与逻辑层之间的关系,会对本层的设计有所帮助。
现分别对上述基本表进行完善与整合。
1.IC卡表
先看IC卡表中主要字段的含义:
卡ID:
汽车的惟一标识,可设为主键。
卡类型:
分为包年、包月、按日收费、按小时收费4类,分别其称为金卡、银卡、铜卡、临时卡。
从中发现,IC卡表中只制定了卡种类,至于停车该收多少钱,还没有设计呢。
价格应由停车场拥有者自己制定。
如图1-9所示。
图1-9收费标准数据表模型
2.车位信息表
给出两种种设计思路:
设计1:
记录空闲车位总数,搜索定位空车位,若有车辆进场,引导其进入此车位,空闲车位总数减1,若车位未满,重新搜索定位空车位。
为此,要添加场地信息表,如图1-10所示。
图1-10场地信息数据表模型
设计2:
制定停车规则,记录最后进场的汽车车位号。
根据是否有空闲车位的信息,按车位号顺序搜索其下一个空闲车位;如果已到最后一个车位,从第1个车位开始搜索。
因此,设计场地信息表如图1-11所示。
图1-11新场地信息数据表模型
3.业务记录表
系统的业务不仅仅是“进场计费”,此表要在设计完智能停车场管理系统的其他部分后才进行整合。
现讨论其与车位信息表的不同之处:
车位信息为动态表。
随着汽车的进场出场,表中的记录可以即时更新。
而业务记录表是静态表,只能添加记录,不能删除或修改记录。
业务记录表的这一点很重要:
由于实行“一卡一车”,卡就代表了车。
但是可能会出现这种情形:
卡与车对不上号,有可能是客户的车被盗或卡被盗。
为了向客户提供更好的服务,停车场方可以提供业务记录给客户或警方,业务记录中的任何信息都不能被删除或更改。
这一点与银行储蓄业务的“数据保险箱”相类似。
注:
在实际开发中,有些数据库(如SQLServer)为实现业务记录表的“数据保险箱”功能,能自动成“全球惟一主键”(模仿网卡的“全球惟一MAC地址”的说法)。
1.5.2表之间的关联
1.6小结
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 草稿