软件工程结构化毕业设计指导书

1、软件工程结构化毕业设计指导书1项目概述项目概述是在调研分析的基础上，对现系统的现状和用户要求。1.1现系统的概述概述现系统在企业中的地位，作用及目标。下面以城市用水管理信息系统为例进 行说明（供参考）：葫芦岛市市自来水公司始建于1974年，1980年正式向居民供水。目前，公司拥有水源 地两座、净水厂4座，日净化能力为12万立米。公司拥有5个供水管理所、水表鉴定站1个, 市区二次加压站25个。市区供水管长度246公里，主要担负市区近30万人口的居民生活用 水、机关团体大生活用水和驻葫国营厂矿事业单位的部分生产用水。供水普及率98%供水覆盖区域达3个区及市郊6个村屯。公司现有职工700余人。公司供

2、水月份总户数达到5200余户，用水量约为54.28万吨，月份水费收缴金额约为 138.56万元（人民币），月份排污金额19.55万元，合计收费金额约为158.11万元。整个 公司水的产损率约为2.7%。1.2组织机构及业务范围叙述系统中人员构成，画组织机构图。说明各机构的业务、范围、职能。下面以城 市用水管理信息系统为例进行说明（供参考）：葫芦岛市自来水公司的组织机构如下:图1-1葫芦岛市自来水公司的组织机构图Fig1-1 Huludao city running water compa ny's orga ni zati on structure公司的目标为“高质量供水，供品质量水，

3、做好服务承诺，满足用户需要”，向用户提供优质服务,公司的主要业务如下（1）勘察设计对用水用户进行供水管路的勘察设计，严格按国家勘察、设计规范进行。（2）管道安装对用水用户进行供水管路的安装调试，严格遵守国家工程施工规范进行施工。（3）管道维修定期巡检,保养和管理供水管道及附属设施，处理突发的水管道破损等事件，确保安全供水(4) 抄表收费抄表到位、准确、及时，按规定收费。(5) 水质检测按国家规定标准定期进行采样化验、分析，严格做好原水、出厂水和管网水的检测管 理工作,严格按照国家水净化处理工艺，确保自来水的水质。(6) 供水调度合理调度，确保城市供水干管末稍不低于 0.16兆帕，供水压力合格率

4、不低于国家规定 的97%因供水设施计划性维修而停水的，将及时预先发出停水通知。(7) 水表计量校核水表。鉴于葫芦岛市地下水、地表水等水源都极为紧张的实际情况，公司决定在 全市居民实行定时供水，每天供水两次，同时，为鼓励居民、用水单位节约用水，经过省 物价部门批准，实行水价高于全省平均水价的政策。全市执行如下水价：表1-1葫芦岛市自来水公司水价表tab1-1 the water price of Huludao city running water compa ny用水对象水费排污费合计居民计划2.040.462.5居民超额3.040.463.5工业、机关事2.840.513.35业单位经营服务

5、业5.840.566.4特种行业0.640.6410.981.3业务流程描述用业务流程图描述现系统各项业务处理过程，并结合业务流程图详细、准确地说明业 务处理过程中数据的收集、输入、传递、存储、加工的方法、算法、输出的数量及形式等。说明：一个系统的业务流程图可以画一个图，也可按业务分别画。下面以城市用水 管理信息系统和火电工程质量检验评定系统两个工程实例进行说明（供参考）：quality assessme nt system1.4现系统存在的问题及薄弱环节分析可从组织机构、管理过程、方法、手段、数据流向、处理方法等方面发现问题。下面 以城市用水管理信息系统为例进行说明（供参考）：通过系统调研，

6、我们认为现行系统存在的问题及薄弱环节主要表现在下列几个方面：15.8IC（1）按照辽宁省物价局的最新规定和葫芦岛市环保局的文件要求，对每吨自来水加收 0.2元的排污费。原系统由于设计缺陷，不能收此费用，而排污费月份可收取约为 万元（按照葫芦岛市2001年度用水量计算），年度可收取189.6万元。（2）原系统的设计缺陷和安全漏洞导致的水费流失，存在着人情水、关系水的现象， 导致较高的水损率。（3）用水管理环节多，人员冗余。主要环节有抄表、收费、记账、审核、开具发票。 在没有推广使用IC水表的情况下，本系统能够实现上述后四个步骤，在逐步推广 水表后，上述的5环节本系统都可以实现。（4）由于大量的重

7、复性手工填（抄）写和人工统计计算，容易造成遗漏和统计数据错 误。（5）由于个人素质等方面的差异，容易出现记录字迹混淆、纸面脏乱、丢失数据等现 象。（6）耗费大量的人力、物力和财力。（7）档案数量巨大，移交、存盘、查阅等非常不便。（8）安全保密性不强。2需求分析软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其 它系统元素的接口细节，定义软件的其它有效性需求。需求分析阶段研究的对象是软件项目的用户要求。一方面，必须全面理解用户的各项 要求，但又不能全盘接受所有的要求，另一方面，要准确地表达被接受的用户要求。只有 经过确切描述的软件需求才能成为软件设计的基础。通常软件开发项

8、目是要实现目标系统的物理模型。作为目标系统的参考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。其实现步骤如图2-1所示。一、 艮体化实例化,.适标系包”（物理模型）（逻樹橫空）图3-1 参考当前系统建立目标系统模型Fig2-1 Establishme nt goal system model refers to the curre nt system综上，在设计中，应归纳出用户对新系统在功能和性能上的要求。2.1总体目标总体需求目标是在企业需求分析、考察调研和工程基本原则大体确定后才能进行设 计。在总体需求目标方面，以企业的基本需求和关键需

9、求为重点。基本需求是企业正常的 作业规范和业务流程的概念组合，关键需求是企业全部管理流程中重要环节和重要路线的 概要抽取。如果没有基本需求就没有企业总体的经营作业管理，而没有关键需求也就没有 了本企业的经营管理特色和个性。下面以葫芦岛自来水公司用水管理信息系统为例进行说明（供参考）：葫芦岛市自来水公司是辽西地级城市葫芦岛市的重要市政部门，是该市的城市供水的主要实施单位，实行企业式经营事业管理的管理方法。本系统的开发与实施，对实现城市 用水管理的科学化和水费收缴的正规化，减少水的使用过程中的人情水、跑冒滴漏等，同 时，鉴于葫芦岛市是一个严重的缺水城市，公司在政策许可的范围内在枯水期和丰水期灵 活

10、设定水价，可有效提高城市居民节约用水的意识，达到用市场手段和价格杠杆促进城市 节约用水的目的。城市用水管理系统的最终目标是避免和克服人工管理的信息滞后，劳动量大，计算和 统计的不准确等种种缺陷和弊端，使企业的管理规范化和自动化，从而为决策部门的生产 管理决策，对抄表员、收费员、基层水管所的管理和监督提供更加科学 ，准确的依据。2.2具体目标把总体需求目标按功能需求进行分解。 目标中可以按管理方面、功能方面、效益方面、 技术方面等进行分解。下面以葫芦岛自来水公司用水管理信息系统为例进行说明（供介廿 参考）：（1）实现方便的严格的计划用水管理。可设定各收费所所管辖范围的所有用水单位、用水居民的月份

11、用水量，作为收缴平价 水费的重要依据。（2）灵活设定水费价格。可根据各城市的水供应情况灵活设定水价，包括居民用水价格、工业用水价格、商饮 用水价格、特殊行业（洗浴、桑拿）等行业用水价格。其中上述每项还包含了平价水和超 额用水、超额外用水、排污水费四种价格。（3）月份水费收缴。计划用水量享受平价水价格，超额部分按超额水费价格收缴。鉴于有单位用水和实现 计划用水管理。可设定各收费所所管辖范围的所有用水单位、用水居民的月居民用水混收 的情况（如葫芦岛锌厂），所以设计了工业平价水费、超额水费、超额外水费、商饮业平 价水费、超额水费、超额外水费、居民平价水费、超额水费、超额外水费、排污水费等复 杂情况的

12、混合计算。（4）水费发票打印。可实现水费发票的单张打印、片区连续打印。鉴于上述价格及收费情况，水费发票内 容远比我市现用发票复杂，打印程序相对困难。（5）各种费用统计。可实现帐本统计、片区统计、收费所统计、收费员收费统计、自来水公司全部水费、 排污费统计及按行业价格统计的水费等。（6）方便的查询、监督功能。采用万能查询方式，业务上收费员和抄表员分开登记数据进入系统，使管理者对应收 水费和实收水费进行方便的比较，使监督更有效。（7）严格的校核算法。原系统采用的人员配置方式为录入员和审核员，由于软件采用了较合理的校核方式， 可为每个收费所节省两名审核人员。2.3系统功能建模系统功能建模所采用的工具

13、是数据流程图和数据字典，用于表达系统内部数据的运动 以及对数据的描述和定义。231系统数据流程图简称DFD它用来描述目标系统的逻辑结构，它是由实体部分，处理部分，数据存储 部分和数据流四部分组成，为了使数据流图所描述逻辑结构更加清晰，容易阅读，对数据 流图作如下说明：表3-1数据流图符号说明tab3-1 the sign explanation of data flow chart图形符号名称符号说明实体记述系统之外的数据提供或数据 获得组织机构或个人，框内为实体名 称。!处理记述某种业务的手工或计算机处 理，其中，PM区记述处理标号，C区记 述处理名称。DNS数据存储记述与处理有关的数据存储

14、，DN 区记述存储的标号，S区记述存储数据 的名称。FM -数据流记述数据流的流动方向，FM己述 数据流的名称。（1）每一细化过程的实体，处理，数据流都用汉字标识，并给出相应的标号(2) 复杂系统的数据流图应分层表述。为了表达数据处理过程的数据加工情况，用一个 数据流图是不够的。稍微复杂的实际问题，在数据流图上常常出现十几个甚至几十个加 工。这样的数据流图看起来很不清楚。层次结构的数据流图能很好地解决这一问题。按 照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表 达和容易理解整个系统。图2-1给出分层数据流图的示例。数据处理 S包括三个相对独立的功能1、2、3。顶

15、层下面的第一层数据流图为 DFAL1。第二层数据流图DFAL2.1、DFyL2.2及DFAL2.3 分别是子系统1、2和3的细化。对任何一层数据流图来说，我们称它的上层图为父图， 在它下一层的图则称为子图。Fig2-1 Schematic draw ing of level data flow chart(3) 画数据流图的基本步骤。概括地说，就是自外向内，自顶向下，逐层细化，完善求 精。检查和修改的原则为： 数据流图上所有图形符号只限于前述四种基本图形元素。 顶层数据流图必须包括前述四种基本元素，缺一不可。 顶层数据流图上的数据流必须封闭在外部实体之间。 每个加工至少有一个输入数据流和一个输

16、出数据流。 在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上 下层的父图与子图的对应关系。 规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据 流和输出数据流必须一致。此即父图与子图的平衡。 尽可能少的在数据流图中加入物质流。 图上每个元素都必须有名字。数据流和数据文件的名字应当是“名词”或“名 词性短语”，表明流动的数据是什么。加工的名字应当是“名词+宾语”，表明做什么事情。 数据流图中不可夹带控制流。 初画时可以忽略琐碎的细节，以集中精力于主要数据流。F面以葫芦岛自来水公司用水管理信息系统为例进行说明（供参考）：Fig2-2 the top level d

17、ata flow chart of city waterman ageme nt in formatio n systemsF1F2用 水 表 单D2用户F5发票应收账款P1自然信息维护rD1用户自然信息:P4 I尾欠水费it处理1FL尾欠水费D4欠费信息F4F3厂 P2 '水费计算 及发票打印*J丿片区水费 统计数据收费员D3水价信息*P3月份水价维护k)F6省建 设厅 及市 建委图2-3城市用水管理信息系统一层数据流图Fig2-3 the first level data flow chart of city waterman ageme nt in formatio n syst

18、emF1.1*人口数量厂 P2.1、计算计划水量P2.2:超额水量P2.31计算超额水量丿计算超额水费< 丿计划水量F2.1F6.2本月超额表针水价超额水费F3F6.1未超额水价(P2.4未超额P2.5未超额水水水费用户月份水费计算水费计算1 丿L丿F5厂 P2.6'-片区水费统计<)F6.3排污费F1.2用户编码图2-4城市用水管理信息系统二层发票计算及水费统计数据流图Fig2-4 the sec ond level data flow chart of city water s man ageme nt in formati onsystem about receipt

19、 computati on and water fee statistics数据字典数据字典是对数据流图的解释和说明，包含的内容如下：(1) 数据元素。数据元素是不可再分的数据单位，一般而言，包括如下内容：数据项描述=数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值 含义，与其他数据项的逻辑关系，数据项之间的联系。其中，后两项定义了数据的完整性约束条件，用于数据校验。如果与数据库存储模式的数据字典一致，可注明“参考本设计的第X章第X节表X的数据结构定义名字：本月表针别名：描述：用户一个收费月份的表针指数数据类型：数值长度：8（2）数据存储。数据存储是数据结构停留或保存的地方。也是

20、数据流的来源和去向之一。可以是手工文档或手工凭单，也可以是计算及文档。一般而言，应包括如下内容：数据存储名，说明，编号，输入的数据流，输出的数据流，组成（数据结构），数据量，存取频度，存取方式。如果与数据库存储模式的数据字典一致，可注明“参考本设计的第X章第X节 表X的数据结构定义。名字：用户自然情况描述：一个用水户的家庭情况信息编号：D1组成：编码，户主姓名，家庭住址，人口，用水类别，表型编码，片区编码（3）数据流。是数据结构在系统内传输的路径。对数据流的描述通常包括如下内容：数据流名，说明，编号，数据流来源，数据流去向，组成（数据结构）名字：发票描述：居民水费发票编号：F5组成：发票号，时

21、间，姓名，人口，住址，月初表底指数，本月用水总 量，月末表底指数，基本用水量，基本单价，基本金额，超额用水量，超额 单价，超额用水金额，排污水量，排污单价，排污金额，金额合计（大写），金额合计（小写），收费员。（4）数据处理。处理过程的具体处理逻辑通常在详细设计过程中用判定表或判定树来 描述。在数据字典中，只需描述处理过程的说明性信息，通常包括以下内容：处理过程名，说明，输入数据流，输出数据流，处理上述数据字典元素仅给出了写法，城市用水管理信息系统的全部数据字典限于篇名字：用户自然信息维护描述：一个用水户的家庭情况信息的登录，查询，输出等编号：P1输入/输出数据流：用户自然信息幅，并没有全部给

22、出。同学们在自己设计的系统中，应该给出所涉及系统的全部数据字典2.4系统数据模型建立系统数据模型的主要工具是实体-关联图，即E-R图。如果系统是一个复杂的大型 系统，可考虑按如下步骤实现：（1）选择局部应用。在多层的数据流图中选择一个适当层次的数据流图，在该部分每一个部分对应一个局部应用，又有与共的数据流图只能反映系统的概貌，而中层的数据流图能较好的反映系统中局部应用的子系统组成，故通常选择中层数据流图作为设计分E-R图的依据。（2）逐一设计分E-R图。根据上述所选择的局部应用逐一设计分 E-R图，即局部E-R图。（3）合并E-R图，生成初步E-R图。此时，可能存在分E-R图间的冲突，如属性冲

23、突、命 名冲突、结构冲突等现象，此时，应根据需求分析中的语义定义对实体联系的类型进行综 合或调整。（4）给出系统的综合E-R图。以上步骤可根据应用的具体情况进行适当取舍。为了进一步说明问题，系统的E-R图作如下规范：（1）E-R图的图形符号约定如下：矩形。表示实体集。椭圆。表示属性。菱形。表示联系集。线段。将属性连接到实体集或将实体集连接到联系集。双椭圆。表示多值属性。虚椭圆。表示派生属性。（2）标明映射的基数映射的基数即两个实体集之间联系的类型。在E-R图中除了上述的图形符号外，还应给出 现实世界联系的类型，对于联系的类型，约束如下：对于实体集A和B之间的二元联系集F来说，映射的基数必然是以

24、下情况之一:一对一。A中的一个实体至多同B中的 一个实体相联系，B中的一个实体也至多 同A中的一个实体相联系，如图5-5a所示一对多。A中的一个实体可以同B中的 任意数目的实体相联系，而B中的一个实 体至多同A中的一个实体相联系， 如图3-6b所示。在E-R图，多端实体标注 为 M或 No多对一。A中的一个实体至多同B中的一图2-5 一对一或一对多映射的基数Fig2-5 A pair or pair of multi- mappings cardi nal nu mbersal凹一也50*1bj分辫符是使得我们能进行这种区分的属性集合。弱实体集的主码由该弱实体集所存在图2-6多对多映射的基数a

25、)多对一 b)多对多Fig 2-6 multi to multi-mapp ings card inal nu mbersa) multi-one b)multi-multi个实体相联系，而B中的一个实体可以同A中任意数目的实体相联系，如图2-5a所示多对多。A中的一个实体可以同B中任意数目的实体相联系，B中的一个实体也可以同A 中任意数目的实体相联系，如图2-5b所示。彳円Ag(3) 应注意弱实体集有些实体集的属性都不足以形成主码, 这样的实体集称作弱实体集。与此相对， 有主码的实体集称作强实体集。虽然弱实体集没有主码，仍需要用某 种方法来区分该实体集中依赖于某个 特定强实体的所有实体。弱实

26、体集的依赖的强实体集的主码和该弱实体集的分辨符共同组成弱实体集可以作为拥有者参与到与另一个弱实体集的标识性联系中。尽管一个弱实体 集总是存在依赖于一个强实体集，但是一个存在依赖并不总会导致一个弱实体集一从属实 体集也可以有主码。在某些情况下，数据库设计者会选择用拥有者实体集的多值、复合属性来表示弱实体 集。如果弱实体集只参与标识性联系，而且其属性不多，那么在建模时将其表述为一个属 性更恰当。相反地，如果弱实体集参与到标识性联系以外的联系中，或者其属性较多，贝U 建模时将其表述为弱实体集更恰当。下面以葫芦岛自来水公司用水管理信息系统为例进行说明(供参考)： 由需求分析得到本系统的两个局部E-R图

27、，在上述的数据流图中，考虑到居民用水的 价格政策、管理方法、发票内容、计算手段的不同，故把“用户”实体一分为二，分别得 到居民用户用水和单位用户用水两个局部 E-R图。要正确确定关联关系。关系型数据库是通过表间某些列的逻辑关系决定两个实体间的 关联关系的，正确确定关联关系和表的键至关重要。(1)居民用水管理系统局部E-R图(2)单位用水局部E-R图如下:图2-5 单位用水管理局部E-R图Fig2-5 departme nt water used man ageme nt partial E-R chart图2-6 城市用水管理系统综合 E-R图Fig2-6 city water man age

28、me nt system syn thesizes E-R chart2-4、限于篇幅，上述E-R图中的所有实体的属性都没有给出，主要给出集成过程，表 表2-5以表格的形式给出各实体及其联系的属性。请注意联系的属性的确定过程，对于分 析其他的系统会有所帮助。表2-4实体及其属性表tab2-4 en tity and property sheet实体名称属性居民用户编码，户主姓名，人口数，家庭住址片区片区编码，片区名称单位单位编码，单位名称，开户行，账号城市自来水公司公司代码，城市名称收费员收费员代码，收费员姓名水价收费月份，居民水价，工业水价，商饮水价，特种 行业水价，排污水价表2-5实体间联

29、系及其属性表tab2-5en tity relatio n and property sheet联系名称属性居民-居住-片区单位-属于-片区收费月份，收费时间，月初表底指数，月末表底指数，收费员-收水费-居民基本用水量，基本单价，基本金额，超额用水量，超 额单价，超额用水金额，排污水量，排污单价，排污 金额，金额合计城市自来水公司及其主管部 门-制定发布-水价文件无城市自来水公司及其主管部门-划分-片区无城市自来水公司及其主管部月份，工业计划水量，商饮计划水量，特种行业计划门-申请/配给月份计划-单位水量城市自来水公司及其主管部门-管理/收取片区水费-收费 员户数，片区编码，总水量，水费金额，

30、排污金额，总金额收费月份，商饮用水量，商饮用水金额，工业用水量，收费员-收水费-单位工业用水金额，特种行业用水量，特种行业用水金额， 排污金额，总金额说明：(1) 上述表二中，消除冗余的工作留待关系模式设计时进行，包括冗余的数据和 冗余的联系。冗余的数据是指可用基本表导出的数据，冗余的联系是只有其它联系 导出的联系。(2) 居民、片区等实体集因为没有表征自己的属性集，故为弱实体集，所以增加了居民编码、片区编码为其强制属性。3概要设计需求分析阶段已经完全弄清楚了目标系统的各种需求，较好地解决了要让所开发的软 件“做什么”的问题，并已在软件需求规格说明和数据要求规格说明中详尽和充分地阐明 了这些需

31、求。下一步就要着手实现软件的需求，即要着手解决“怎么做”的问题。分析模型中的每一个成份都提供了建立设计模型所需的信息。根据用数据、功能和行 为模型表示的软件需求，采用某种设计方法进行数据设计、体系结构设计、接口设计和过 程设计。数据设计将实体一关系图中描述的对象和关系，以及数据词典中描述的详细数据内容 转化为数据结构的定义。体系结构设计定义软件系统各主要成份之间的关系。接口设计根 据数据流图定义软件内部各成份之间、软件与其它协同系统之间及软件与用户之间的交互 机制。过程设计则是把结构成份转换成软件的过程性描述。在编码步骤，根据这种过程性 描述，生成源程序代码，然后通过测试最终得到完整有效的软件

32、。3.1体系结构设计说明系统总体结构和模块外部设计。在体系结构中应注意如下几个问题：（1）模块的分割要有一个合理的度。实际上，如果模块是相互独立的，当模块变得 越小，每个模块花费的工作量越低；但当模块数增加时，模块间的联系也随之增加，把这 些模块联接起来的工作量也随之增加。如图 4-1所示。因此，存在一个模块个数 M 它使 得总的开发成本达到最小。图4-1模块大小、模块数目与费用的关系Fig4-1 module size, module nu mber and expe nse relati ons（2）合理的控制层次控制层次也叫做程序结构，它表明了程序构件（模块）的组织情况。控制层次往往用程

33、序的层次（树形或网状）结构来表示。如图 4.4所示。位于最上层根部是顶层模块，它是程序的主模块。与其联系的有若干下属模块，各下属模块还可以进一步引出更下一层的下属模块。模块M是顶层模块，如果算做第0层，则其下属模块A B和C为第1层，模块D E、图4-2程序的层次结构图示例Fig4-2 Procedure level structure draw ingA. 程序结构的深度：程序结构的层次数称为结构的深度。结构的深度在一定意义上 反映了程序结构的规模和复杂程度。B. 程序结构的宽度：层次结构中同一层模块的最大模块个数称为结构的宽度。C. 模块的扇入和扇出：扇出表示一个模块直接调用（或控制）的其

34、它模块数目。扇 入则定义为调用（或控制）一个给定模块的模块个数。多扇出意味着需要控制和 协调许多下属模块。而多扇入的模块通常是公用模块。D. 要注意的是，程序结构是软件的过程表示，但并未表明软件的某些过程性特征。比如，进程序列、事件/决策的顺序或其它的软件动态特性。下面以城市用水管理信息系统为例，以功能树的形式给出体系结构设计的实例, 仅供参考。根据对系统需求分析中的总体目标和具体目标部分的分析，得到系统的功能树如下：图3-3 城市用水管理系统结构图Fig3-3 city water management system structuredrawing3.2接口设计321外部接口包括用户界面、

35、软件接口与硬件接口。322内部接口模块之间的接口。示例（仅供参考）：3.2.1外部接口3.2.1.1 用户界面在用户界面部分，根据需求分析的结果，用户需要一个用户友善界面。在界面设 计上，应做到简单明了，易于操作，并且要注意到界面的布局，应突出的显示重要以 及出错信息。外观上也要做到合理化，考虑到用户多对 WINDOW格较熟悉，应尽量 向这一方向靠拢。在设计语言上，已决定使用SYBASE PowerBuilder进行编程，在界面上可使用PowerBuilder所提供的可视化控件，编写基于WINDOW风格的用户界 面。总的来说，系统的用户界面应作到可靠性、简单性、易学习和使用3.2.1.2 软件

36、接口服务器程序可使用PowerBuilder提供的对SQL SERVER勺接口，进行对数据库 的所有访问。在网络软件接口方面，使用一种无差错的传输协议，采用滑动窗口方式对数据进 行网络传输及接收。3.2.1.3 硬件接口在输入方面，对于键盘、鼠标的输入，对输入进行处理。在输出方面，打印机的连接及使用，也可用 PowerBuilder的标准输入/输出对其 进行处理。在网络传输部分，在网络硬件部分，为了实现高速传输，使用快速以太网。 3.2 .2 内部接口内部接口方面，各模块之间采用函数调用、参数传递、返回值的方式进行信息传 递。具体参数的结构将在下面数据结构设计的内容中说明。接口传递的信息将是以

37、数据结构封装了的数据，以参数传递或返回值的形式在各模块间传输。3.3代码设计331代码设计的原则代码设计是处理对象的代号或表示符号，其主要目的是方便计算机排序、检索、查找 等处理。代码设计的关键是方便用户，满足业务要求。1. 要考虑的是编码的标准化，尽量按照有关的国际标准、国家标准、部门或行 业的标准进行设计。2. 要考虑容易修改，当某个代码在特点、条件或代表的实体关系改变时，容易 进行变更。3. 要考虑结构简洁，代码的长度涉及到存储空间的占用和信息处理的速度。而 且影响代码输入的出错率，所以，在满足当前需要和扩充性要求的前提下应尽量结 构简单，长度要短4. 考虑代码值的唯一性系统所需代码设计

38、包括系统所需代码名称、作用、各位含义等，如代码内容较少，可直接列出，否则， 可在附录列出。示例（仅供参考）：火电土建工程质量检验评定系统代码的设计是根据火电施工的特点，结合现场的 工作经验，在争得用户认可的情况下设计出来的，所设计的代码结构如下：1系统工程代码组成火电工程的系统工程共有九个，代码由一位数值组成，格式如下：X系统工程编号所代表的含义如下:表3-1系统工程及其代码tab3-1 system project and code系统工程代码系统工程名称1热力系统2燃料供应系统3除灰系统4水处理系统5供水系统6电气系统7交通运输系统8附属生产工程9生活福利系统2单位工程代码各系统工程下的单

39、位工程数量不定，但其值在 1-999之间，依据代码设计中的可扩充 性的原则，单位工程代码由四字节成：X XXX单位工程编号所属系统工程编号各单位工程的代码及其所代表的单位工程名称详见附录3分部工程代码各单位工程下的分部工程数量不定， 但其值在1-999之间，依据代码设计中的可扩充性 的原则，分部工程代码由7字节成，格式如下：X XXX XXX分部工程编号所属单位工程编号所属系统工程编号各分部工程的代码及其所代表的单位工程名称详见附录4分项工程代码各分部工程下的分项工程数量不定，但其值应在1-999之间，依据代码设计中的可扩充性的原则，分项工程代码由10字节成，格式如下：X XXX XXX XX

40、X分项工程编号所属分部工程编号所属单位工程编号j 所属系统工程编号依据上述代码设计，火电土建工程所有工程项目实现代码化， 方便系统进行数据提取、 处理和查询。各工程的代码及其所代表的工程示意如下：表3-2火电土建工程质量检验评定系统的部分工程及其代码tab3-2 the thermal power civil project quality evaluates system' s partial project andcode工程代码工程名称1000000000热力系统1001000000主厂房地下结构1001001000土（石）方工程1001003000汽机间基础1001003001

41、外侧柱基础垫层1001003002外侧柱基础钢筋1001003003外侧柱基础模板1001003004外侧柱基础混凝土1001003005平台柱基础垫层1001003006平台柱基础钢筋1001003007平台柱基础模板1001003008平台柱基础混凝土1001003009固疋端基础垫层1001003010固疋端基础钢筋1001003011固疋端基础模板1001003012固疋端基础混凝土1001003013扩建端基础垫层1001003014扩建端基础钢肋1001003015扩建端基础模板也可以采用阿拉伯数字和字母混合编码的方式。为进一步说明代码设计方法，现再给 出城市用水管理系统的代码设计

42、过程，供参考：(1) 收费所代码以各收费所的拼音简写为其代码，如连山收费所，其代码为 LSXX收费所代码所代表的含义如下：表3-3收费所及其代码tab3-3 Charge departme nt and its code收费所名称收费所代码连山收费所LS新区收费所XQ工业收费所GY渤海收费所BH(2)片区代码由五位字符组成。组成方式为前两位为所属收费所编号，后三位为片区编号XX XXX片区编号，为0-999的数字字符。所属收费所编号，参见收费所编码方式完整的片区编码表见城市用水管理系统设计报告的附录一葫芦岛市自来水公司 片区编码表。(3)收费员代码由9位字符组成。组成方式如下:XX XX XX

43、X XX收费员编号，为0-99的数字字符片区编号，为0-999的数字字符收费类型，其中，JM表示为居民收费类型, GY表示为工业收费类型。所属收费所编号，参见收费所编码方式完整的收费员编码表见城市用水管理系统设计报告附录二葫芦岛市自来水公司 收费员编码表。（4）收费用户代码由10位字符组成，组成方式如下:XX XXX XXXXX片区内居民编号，为0-99999的数字字片区编号，为0-999的数字字符。所属收费所编号，参见收费所编码方式。完整的收费用户编码表见城市用水管理系统设计报告附录三葫芦岛市自来水公 司收费用户编码表。（5）营业员代码由2位字符组成。组成方式如下：XX营业员编号，为0-99

44、的数字字符。完整的营业员编码表见城市用水管理系统设计报告附录四葫芦岛市自来水公司 营业员编码表。3.4数据库设计数据库设计是软件开发的灵魂和基础，是整个系统成功的关键所在，是开发高品质应 用的前提，鉴于数据库设计的重要性，做如下约定：设计过程应按照概念模型设计-关系模型设计-物理数据库设计的步骤进行。关系模式设计由系统的概念模型导出关系模式（参见本书 3.5系统数据模型部分）。主要原则及实 现方法如下：（1）一个实体型转换为一个关系模式，实体的属性就是关系的属性，实体的键就是关系 的键。（2）个实体的联系转换为关系模式时，应首先确定该联系的类型，再确定相应的键：a）若关系的类型为1:1,则每个

45、实体的键均为该关系的侯选键，可二者择一为 该联系的键。b）若关系的类型为1： n,则应把一端实体的键移到n端，与n端实体的键共同组 成该联系的键。c）如果为弱实体集，可为其增加一个强制属性作为键。d）若关系的类型为m n,则该联系的键为两个实体的键的复合，即该关系的键 一定为复合键。3 进行规范化处理，求出关系模式中的最小依赖集，并依据规范化理论，将关系模 式规范到三范式。各范式的定义如下：范式是对关系的不同数据依赖程度的要求。通过模式分解将一个低级范式转换为若干个高级范式的过程称作规范化（概念的纯粹化）。1NF:关系中每一分量不可再分。即不能以集合、序列等作为属性值。2NF:若R 1NF,且

46、每个非主属性完全依赖于码，则称 R 2NF （消除非主属性对码的 部分依赖）。3NF:关系模式R< U , F >中，若不存在这样的码X,属性组丫及非主属性Z（Z Y）， 使得下式成立，X Y，丫 Z,Y X则称R 3NF （消除非主属性对码的传递依赖）。下面以葫芦岛自来水公司用水管理信息系统为例进行说明（供参考）：关系模式设计依据上述原则，得出葫芦岛自来水公司用水管理信息系统的关系模式：（1）城市自来水公司（公司代码，城市名称）（2）收费员（收费员编码，收费员姓名）（3）片区（片区编码，片区名称，收费员编码）（4）居民（用户编码，户主姓名，人口数，家庭住址，所在片区编码）（5）单

47、位（单位编码，单位名称，单位地址，开户行，账号，所在片区编码）（6）水价（收费月份，居民水价，工业水价，商饮水价，特种行业水价）（7）居民水费收缴（用户编码，收费月份，收费时间，月初表底指数，月末表底指 数，收费员编码）（8）单位月份水费计划（单位编码，月份，工业计划水量，商饮计划水量，特种行 业计划水量）（9）单位月份水费收缴（单位编码，收费月份，商饮用水量，工业用水量，特种行 业用水量）分析过程说明：1 严格而言，关系模式的内容应为:R（U,D,DOM,F）其中，R为关系名，U为组成该关系模式的属性名集合，D为属性组U中属性所来自的域， DO为属性向域的映像集合，F为属性间数据的依赖关系集

48、合。设计过程中仅要求给出 前两项，即R,U，其它可作为中间优化过程的依据及结果的来源而省略。2城市自来水公司，收费员，水价三个关系模式的属性集的确定来自E-R图中的同名实体，其关系模式上面已经列出，不再赘述。3“片区”实体与“收费员”实体的联系类型为1: N的联系，所以应把一端实体（收 费员）的键（收费员编码）加到N端实体（片区）的属性集中，并作该关系模式的 外键。因此得到的关系模式为：片区（片区编码，片区名称，收费员编码）4“居民”实体与“片区”实体的联系的类型为1: N的联系，所以该联系不产生第三关系模式，故应把一端实体（片区）的键（片区编码）加到N端实体（居民）的属性集中，并作“居民”关

49、系模式的外键。因此得到的“居民”关系模式为：居民（用户编码，户主姓名，人口数，家庭住址，所在片区编码）5“单位”实体与“片区”实体的联系的类型为1: N的联系，所以应把一端实体（片 区）的键（片区编码）加到N端实体（单位）的属性集中，并作“单位”关系模式 的外键。因此得到的“单位”关系模式为：单位（单位编码，单位名称，单位地址，开户行，账号，所在片区编码）6. （1）“居民月份水费收缴”关系模式的键的确定“居民”实体与“收费员”实体的联系的类型为 1： N的联系，但该联系存在其内在的 属性（收费月份，收费时间，月初表底指数，月末表底指数，基本用水量，基本单价， 基本金额，超额用水量，超额单价，

50、超额用水金额，排污水量，排污单价，排污金额， 金额合计），所以，应把该联系作为一个关系模式，并把两侧实体的键（居民编码， 收费员编码）复合起来，又根据语义定义，每月对居民的收费仅一次，故该关系模式 的键为（居民编码，收费月份，收费员编码），又根据该关系模式内部的函数依赖关 系及最小函数依赖集的定义，得到该关系模式的键为（居民编码，收费月份）。（2）关系模式“居民月份水费收缴”的三范式的确定联系的属性“收费月份”，“收费时间”，“月初表底指数”，“月末表底指数”，“基本用水量”，“基本单价”，“基本金额”，“超额用水量”，“超额单价”，“超额用水金额”，“排污水量”，“排污单价”，“排污金额”，

51、“金额合计” 存在如下的传递函数依赖：（居民编码，收费月份）一基本用水量*基本金额（居民编码，收费月份）一-超额用水量一 超额用水金额（居民编码，收费月份）一-排污量排污金额所以，去除基本金额，超额用水金额，排污金额。同理，去除金额合计“基本单价”，“超额单价”，“排污单价”在单价关系模式中已经存在，故为冗 余属性，应去除。最终得到居民水费收缴关系模式的属性集为居民水费收缴(居民编码，收费月份，收费时间，月初表底指数，月末表底指数， 收费员编码)7 同理可得，“单位月份水费计划”，“单位月份水费收缴”两个关系模式。单位月份水费计划(单位编码，月份，工业计划水量，商饮计划水量，特种行业 计划水量

52、，收费员编码)单位月份水费收缴(单位编码，收费月份，商饮用水量，工业用水量，特种行业用水量)342数据字典数据字典是物理数据库的具体体现， 主要规定各关系的名称、各列的数据类型、长度、 小数位、完整性约束等。1、 各属性的属性名、类型、长度、小数位、是否空值、缺省值等，其中，不同的DBMS 的数据类型不完全一致，请参考所用 DBM的用户手册。2、完整性约束。完整性是指数据的正确性和相容性。它包括实体完整性和关联完整性和用户定义的完 整性。(1) 实体完整性约束有如下几种：1) 主属性非空。如果主属性为空值，或是主码值在表中不唯一，则系统拒绝操 作，该完整性由SQL SERVER统提供。以下几种情况由表的 OWN定义。2) 列值非空。3) 列值唯一4) 检查列值是否满足一个布尔表达式5) 检查各列之间是否满足一个布尔表达式。(2) 关联完整性约束有如下几种：6) 外码是否可以接受