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

软件工程专业毕业论文指导规范软件工程结构化毕业设计指导书1 项目概述项目概述是在调研分析的基础上，对现系统的现状和用户要求。1.1 现系统的概述概述现系统在企业中的地位，作用及目标。下面以城市用水管理信息系统为例进行说明（供参考）：葫芦岛市市自来水公司始建于1974年，1980年正式向居民供水。目前，公司拥有水源地两座、净水厂4座，日净化能力为12万立米。公司拥有5个供水管理所、水表鉴定站1个，市区二次加压站25个。市区供水管长度246公里，主要担负市区近30万人口的居民生活用水、机关团体大生活用水和驻葫国营厂矿事业单位的部分生产用水。供水普及率98%。供水覆盖区域达3个区及市郊6个村屯。公司现有职工700余人。公司供水月份总户数达到5200余户，用水量约为54.28万吨，月份水费收缴金额约为138.56万元（人民币），月份排污金额19.55万元，合计收费金额约为158.11万元。整个公司水的产损率约为2.7%。1.2 组织机构及业务范围叙述系统中人员构成，画组织机构图。说明各机构的业务、范围、职能。下面以城市用水管理信息系统为例进行说明（供参考）：葫芦岛市自来水公司财务科人事科营业科办公室工会工程公司技术科渤海收费所连山收费所工业收费所新区收费所计算中心饮服收费所葫芦岛市自来水公司的组织机构如下：图1-1 葫芦岛市自来水公司的组织机构图Fig1-1 Huludao city running water companys organization structure公司的目标为“高质量供水,供品质量水,做好服务承诺,满足用户需要”,向用户提供优质服务,公司的主要业务如下 : （1）勘察设计对用水用户进行供水管路的勘察设计，严格按国家勘察、设计规范进行。（2）管道安装 对用水用户进行供水管路的安装调试，严格遵守国家工程施工规范进行施工。（3）管道维修定期巡检,保养和管理供水管道及附属设施,处理突发的水管道破损等事件，确保安全供水。（4）抄表收费抄表到位、准确、及时，按规定收费。（5）水质检测 按国家规定标准定期进行采样化验、分析,严格做好原水、出厂水和管网水的检测管理工作,严格按照国家水净化处理工艺,确保自来水的水质。（6）供水调度合理调度，确保城市供水干管末稍不低于0.16兆帕，供水压力合格率不低于国家规定的97%，因供水设施计划性维修而停水的,将及时预先发出停水通知。（7）水表计量 校核水表。鉴于葫芦岛市地下水、地表水等水源都极为紧张的实际情况，公司决定在全市居民实行定时供水，每天供水两次,同时，为鼓励居民、用水单位节约用水，经过省物价部门批准，实行水价高于全省平均水价的政策。全市执行如下水价：表1-1 葫芦岛市自来水公司水价表tab1-1 the water price of Huludao city running water company用水对象水费排污费合计居民计划2.040.462.5居民超额3.040.463.5工业、机关事业单位2.840.513.35经营服务业5.840.566.4特种行业0.640.6410.981.3 业务流程描述用业务流程图描述现系统各项业务处理过程，并结合业务流程图详细、准确地说明业务处理过程中数据的收集、输入、传递、存储、加工的方法、算法、输出的数量及形式等。业务流程图使用的符号数据处理月份片区居民水费收缴汇总图4.1 城市用水管理系统功能模块图1报表处理检索数据打印预览打印设置给定检索条件报表打印下一记录到尾记录到首记录插入记录系统管理员密码管理营业员密码维护片区代码维护表示处理表示帐册表示输入/输出的报表表示业务流向 说明：一个系统的业务流程图可以画一个图，也可按业务分别画。下面以城市用水管理信息系统和火电工程质量检验评定系统两个工程实例进行说明（供参考）：IIFig1-2 the city water management system industry flow chart水费排污费统计表水用户片区居民水费统计表片区单位水费汇总表收费员居民汇总表水费排污费统计表水费排污费统计表收费员单位水费汇总表收费员居民水费汇总表统计计算自来水公司营业科月份用户用水量表单图1-2城市用水管理系统业流程图抄表抄表员水费价格文件物价局收费所水费收费统计表月份用户水费表单水费发票收费员用户月份水费计算打印水费发票收费所图1-3 火电土建工程质量验评系统业务流程图验评人员分项工程质量验评表统计分部工程质量验评表统计员单位工程质量验评表质量检验评定建设单位负责人施工班组负责人 承建公司负责人工地施工负责人审核签名 建设单位档案室存档单位工程质量档案分部工程质量档案分项工程质量档案隐蔽工程质量档案Fig1-3 the flow chart of thermal power civil projects quality assessment system1.4 现系统存在的问题及薄弱环节分析可从组织机构、管理过程、方法、手段、数据流向、处理方法等方面发现问题。下面以城市用水管理信息系统为例进行说明（供参考）：通过系统调研，我们认为现行系统存在的问题及薄弱环节主要表现在下列几个方面：（1） 按照辽宁省物价局的最新规定和葫芦岛市环保局的文件要求，对每吨自来水加收0.2元的排污费。原系统由于设计缺陷，不能收此费用，而排污费月份可收取约为15.8万元（按照葫芦岛市2001年度用水量计算），年度可收取189.6万元。（2） 原系统的设计缺陷和安全漏洞导致的水费流失，存在着人情水、关系水的现象，导致较高的水损率。（3） 用水管理环节多，人员冗余。主要环节有抄表、收费、记账、审核、开具发票。在没有推广使用IC水表的情况下，本系统能够实现上述后四个步骤，在逐步推广IC水表后，上述的5环节本系统都可以实现。（4） 由于大量的重复性手工填（抄）写和人工统计计算，容易造成遗漏和统计数据错误。（5） 由于个人素质等方面的差异，容易出现记录字迹混淆、纸面脏乱、丢失数据等现象。（6） 耗费大量的人力、物力和财力。（7） 档案数量巨大，移交、存盘、查阅等非常不便。（8） 安全保密性不强。2 需求分析软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其它系统元素的接口细节，定义软件的其它有效性需求。需求分析阶段研究的对象是软件项目的用户要求。一方面，必须全面理解用户的各项要求，但又不能全盘接受所有的要求，另一方面，要准确地表达被接受的用户要求。只有经过确切描述的软件需求才能成为软件设计的基础。通常软件开发项目是要实现目标系统的物理模型。作为目标系统的参考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。其实现步骤如图2-1所示。图3-1 参考当前系统建立目标系统模型Fig2-1 Establishment goal system model refers to the current system综上，在设计中，应归纳出用户对新系统在功能和性能上的要求。2.1 总体目标总体需求目标是在企业需求分析、考察调研和工程基本原则大体确定后才能进行设计。在总体需求目标方面，以企业的基本需求和关键需求为重点。基本需求是企业正常的作业规范和业务流程的概念组合，关键需求是企业全部管理流程中重要环节和重要路线的概要抽取。如果没有基本需求就没有企业总体的经营作业管理，而没有关键需求也就没有了本企业的经营管理特色和个性。下面以葫芦岛自来水公司用水管理信息系统为例进行说明（供参考）：葫芦岛市自来水公司是辽西地级城市葫芦岛市的重要市政部门，是该市的城市供水的主要实施单位，实行企业式经营事业管理的管理方法。本系统的开发与实施，对实现城市用水管理的科学化和水费收缴的正规化，减少水的使用过程中的人情水、跑冒滴漏等，同时，鉴于葫芦岛市是一个严重的缺水城市，公司在政策许可的范围内在枯水期和丰水期灵活设定水价，可有效提高城市居民节约用水的意识，达到用市场手段和价格杠杆促进城市节约用水的目的。城市用水管理系统的最终目标是避免和克服人工管理的信息滞后，劳动量大，计算和统计的不准确等种种缺陷和弊端，使企业的管理规范化和自动化，从而为决策部门的生产管理决策，对抄表员、收费员、基层水管所的管理和监督提供更加科学,准确的依据。2.2 具体目标把总体需求目标按功能需求进行分解。目标中可以按管理方面、功能方面、效益方面、技术方面等进行分解。下面以葫芦岛自来水公司用水管理信息系统为例进行说明（供参考）：（1） 实现方便的严格的计划用水管理。可设定各收费所所管辖范围的所有用水单位、用水居民的月份用水量，作为收缴平价水费的重要依据。（2） 灵活设定水费价格。可根据各城市的水供应情况灵活设定水价，包括居民用水价格、工业用水价格、商饮用水价格、特殊行业（洗浴、桑拿）等行业用水价格。其中上述每项还包含了平价水和超额用水、超额外用水、排污水费四种价格。（3） 月份水费收缴。计划用水量享受平价水价格，超额部分按超额水费价格收缴。鉴于有单位用水和实现计划用水管理。可设定各收费所所管辖范围的所有用水单位、用水居民的月居民用水混收的情况（如葫芦岛锌厂），所以设计了工业平价水费、超额水费、超额外水费、商饮业平价水费、超额水费、超额外水费、居民平价水费、超额水费、超额外水费、排污水费等复杂情况的混合计算。（4） 水费发票打印。可实现水费发票的单张打印、片区连续打印。鉴于上述价格及收费情况，水费发票内容远比我市现用发票复杂，打印程序相对困难。（5）各种费用统计。可实现帐本统计、片区统计、收费所统计、收费员收费统计、自来水公司全部水费、排污费统计及按行业价格统计的水费等。（6）方便的查询、监督功能。采用万能查询方式，业务上收费员和抄表员分开登记数据进入系统，使管理者对应收水费和实收水费进行方便的比较，使监督更有效。（7） 严格的校核算法。原系统采用的人员配置方式为录入员和审核员，由于软件采用了较合理的校核方式，可为每个收费所节省两名审核人员。2.3 系统功能建模系统功能建模所采用的工具是数据流程图和数据字典，用于表达系统内部数据的运动以及对数据的描述和定义。2.3.1 系统数据流程图简称DFD，它用来描述目标系统的逻辑结构，它是由实体部分，处理部分，数据存储部分和数据流四部分组成，为了使数据流图所描述逻辑结构更加清晰，容易阅读，对数据流图作如下说明：表3-1 数据流图符号说明tab3-1 the sign explanation of data flow chart图形符号 名称 符号说明PMC DNSFM实体记述系统之外的数据提供或数据获得组织机构或个人，框内为实体名称。处理记述某种业务的手工或计算机处理，其中，PM区记述处理标号，C区记述处理名称。数据存储记述与处理有关的数据存储，DN区记述存储的标号，S区记述存储数据的名称。数据流记述数据流的流动方向，FM记述数据流的名称。（1） 每一细化过程的实体，处理，数据流都用汉字标识，并给出相应的标号。（2） 复杂系统的数据流图应分层表述。为了表达数据处理过程的数据加工情况，用一个数据流图是不够的。稍微复杂的实际问题，在数据流图上常常出现十几个甚至几十个加工。这样的数据流图看起来很不清楚。层次结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。图2-1给出分层数据流图的示例。数据处理S包括三个相对独立的功能1、2、3。顶层下面的第一层数据流图为DFDL1。第二层数据流图DFDL2.1、DFDL2.2及DFDL2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，我们称它的上层图为父图，在它下一层的图则称为子图。图2-1 分层数据流图示意图Fig2-1 Schematic drawing of level data flow chart（3） 画数据流图的基本步骤。概括地说，就是自外向内，自顶向下，逐层细化，完善求精。检查和修改的原则为： 数据流图上所有图形符号只限于前述四种基本图形元素。 顶层数据流图必须包括前述四种基本元素，缺一不可。 顶层数据流图上的数据流必须封闭在外部实体之间。 每个加工至少有一个输入数据流和一个输出数据流。 在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。 规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。 尽可能少的在数据流图中加入物质流。 图上每个元素都必须有名字。数据流和数据文件的名字应当是“名词”或“名词性短语”，表明流动的数据是什么。加工的名字应当是“名词宾语”，表明做什么事情。 数据流图中不可夹带控制流。 初画时可以忽略琐碎的细节，以集中精力于主要数据流。用户用户自然信息及用水信息发票P城市用水管理信息系统 用户统计信息收费员、收费所、公司下面以葫芦岛自来水公司用水管理信息系统为例进行说明（供参考）：图2-2 城市用水管理信息系统顶层数据流图Fig2-2 the top level data flow chart of city water smanagement information system用户 P1自然信息维护F1D1用户自然信息P2水费计算及发票打印收费员片区水费统计数据F3P4尾欠水费处理D4尾欠水费D2应收账款D3水价信息P3月份水价维护省建设厅及市建委F2用水表单F4欠费信息F5发票F6图2-3 城市用水管理信息系统一层数据流图Fig2-3 the first level data flow chart of city water smanagement information systemP2.1计算计划水量F1.1P2.2计算超额水量计划水量P2.3计算超额水费超额水量超额水费P2.4未超额水水费计算F6.1未超额水价P2.5用户月份水费计算未超额水水费F2.1本月表针F6.2超额水价F6.3排污费F3人口数量P2.6片区水费统计F1.2用户编码F5图2-4 城市用水管理信息系统二层发票计算及水费统计数据流图Fig2-4 the second level data flow chart of city water s management information system about receipt computation and water fee statistics2.3.2 数据字典数据字典是对数据流图的解释和说明，包含的内容如下： （1）数据元素。数据元素是不可再分的数据单位，一般而言，包括如下内容：数据项描述=数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系。其中，后两项定义了数据的完整性约束条件，用于数据校验。如果与数据库存储模式的数据字典一致，可注明“参考本设计的第X章第X节 表X的数据结构定义。名字：本月表针别名：描述：用户一个收费月份的表针指数数据类型：数值长度：8（2）数据存储。数据存储是数据结构停留或保存的地方。也是数据流的来源和去向之一。可以是手工文档或手工凭单，也可以是计算及文档。一般而言，应包括如下内容：数据存储名，说明，编号，输入的数据流，输出的数据流，组成（数据结构），数据量，存取频度，存取方式。名字：用户自然情况描述：一个用水户的家庭情况信息编号：D1组成：编码，户主姓名，家庭住址，人口，用水类别，表型编码，片区编码如果与数据库存储模式的数据字典一致，可注明“参考本设计的第X章第X节 表X的数据结构定义。（3）数据流。是数据结构在系统内传输的路径。对数据流的描述通常包括如下内容：数据流名，说明，编号，数据流来源，数据流去向，组成（数据结构）名字：发票描述：居民水费发票编号：F5组成：发票号，时间，姓名，人口，住址，月初表底指数，本月用水总量，月末表底指数，基本用水量，基本单价，基本金额，超额用水量，超额单价，超额用水金额，排污水量，排污单价，排污金额，金额合计（大写），金额合计（小写），收费员。（4）数据处理。处理过程的具体处理逻辑通常在详细设计过程中用判定表或判定树来描述。在数据字典中，只需描述处理过程的说明性信息，通常包括以下内容：处理过程名，说明，输入数据流，输出数据流，处理上述数据字典元素仅给出了写法，城市用水管理信息系统的全部数据字典限于篇名字：用户自然信息维护描述：一个用水户的家庭情况信息的登录，查询，输出等编号：P1输入/输出数据流：用户自然信息幅，并没有全部给出。同学们在自己设计的系统中，应该给出所涉及系统的全部数据字典。2.4 系统数据模型建立系统数据模型的主要工具是实体-关联图，即E-R图。如果系统是一个复杂的大型系统，可考虑按如下步骤实现：（1） 选择局部应用。在多层的数据流图中选择一个适当层次的数据流图，在该部分每一个部分对应一个局部应用，又有与共的数据流图只能反映系统的概貌，而中层的数据流图能较好的反映系统中局部应用的子系统组成，故通常选择中层数据流图作为设计分E-R图的依据。（2） 逐一设计分E-R图。根据上述所选择的局部应用逐一设计分E-R图，即局部E-R图。（3） 合并E-R图，生成初步E-R图。此时，可能存在分E-R图间的冲突，如属性冲突、命名冲突、结构冲突等现象，此时，应根据需求分析中的语义定义对实体联系的类型进行综合或调整。（4） 给出系统的综合E-R图。以上步骤可根据应用的具体情况进行适当取舍。为了进一步说明问题，系统的E-R图作如下规范：（1）E-R图的图形符号约定如下： 矩形。表示实体集。 椭圆。表示属性。 菱形。表示联系集。 线段。将属性连接到实体集或将实体集连接到联系集。 双椭圆。表示多值属性。 虚椭圆。表示派生属性。（2）标明映射的基数映射的基数即两个实体集之间联系的类型。在E-R图中除了上述的图形符号外，还应给出现实世界联系的类型，对于联系的类型，约束如下：图2-5 一对一或一对多映射的基数Fig2-5 A pair or pair of multi- mappings cardinal numbersa) 一对一 b)一对多对于实体集A和B之间的二元联系集R来说，映射的基数必然是以下情况之一：一对一。A中的一个实体至多同B中的一个实体相联系，B中的一个实体也至多同A中的一个实体相联系，如图5-5a所示。在E-R图，一端实体标注为1。一对多。A中的一个实体可以同B中的任意数目的实体相联系，而B中的一个实体至多同A中的一个实体相联系，如图3-6b所示。在E-R图，多端实体标注为M或N。多对一。A中的一个实体至多同B中的一个实体相联系，而B中的一个实体可以同A中任意数目的实体相联系，如图2-5a所示。图2-6 多对多映射的基数a) 多对一 b)多对多Fig 2-6 multi to multi-mappings cardinal numbers a)multi-one b)multi-multi多对多。A中的一个实体可以同B中任意数目的实体相联系，B中的一个实体也可以同A中任意数目的实体相联系，如图2-5b所示。（3）应注意弱实体集有些实体集的属性都不足以形成主码，这样的实体集称作弱实体集。与此相对，有主码的实体集称作强实体集。虽然弱实体集没有主码，仍需要用某种方法来区分该实体集中依赖于某个特定强实体的所有实体。弱实体集的分辫符是使得我们能进行这种区分的属性集合。弱实体集的主码由该弱实体集所存在依赖的强实体集的主码和该弱实体集的分辨符共同组成。弱实体集可以作为拥有者参与到与另一个弱实体集的标识性联系中。尽管一个弱实体集总是存在依赖于一个强实体集，但是一个存在依赖并不总会导致一个弱实体集从属实体集也可以有主码。在某些情况下，数据库设计者会选择用拥有者实体集的多值、复合属性来表示弱实体集。如果弱实体集只参与标识性联系，而且其属性不多，那么在建模时将其表述为一个属性更恰当。相反地，如果弱实体集参与到标识性联系以外的联系中，或者其属性较多，则建模时将其表述为弱实体集更恰当。下面以葫芦岛自来水公司用水管理信息系统为例进行说明（供参考）：由需求分析得到本系统的两个局部E-R图，在上述的数据流图中，考虑到居民用水的价格政策、管理方法、发票内容、计算手段的不同，故把“用户”实体一分为二，分别得到居民用户用水和单位用户用水两个局部E-R图。要正确确定关联关系。关系型数据库是通过表间某些列的逻辑关系决定两个实体间的关联关系的，正确确定关联关系和表的键至关重要。（1）居民用水管理系统局部E-R图 111城市自来水公司及其主管部门居民片区管理、分片 居住制定发布水价文件wenjian wenjian 管理、收、缴片区水费收费员收缴水费1n1mn11n 图2-4 居民用水管理局部E-R图 Fig2-4 Inhabitant water management partial E-R chart（2）单位用水局部E-R图如下：1n111城市自来水公司及其主管部门单位片区管理、分片制定发布水价文件wenjian wenjian 管理、收、缴片区水费收费员收缴水费1n1nn11n申请/配给月份用水计划 属于图2-5 单位用水管理局部E-R图Fig2-5 department water used management partial E-R chart1nn收缴水费1111城市自来水公司及其主管部门单位片区划分 属于制定发布水价文件wenjian wenjian 管理、收、缴片区水费收费员nn111n 居住居民收水费n1n1申请/配给月份用水计划图2-6 城市用水管理系统综合E-R图Fig2-6 city water management system synthesizes E-R chart限于篇幅，上述E-R图中的所有实体的属性都没有给出，主要给出集成过程，表2-4、表2-5以表格的形式给出各实体及其联系的属性。请注意联系的属性的确定过程，对于分析其他的系统会有所帮助。表2-4 实体及其属性表tab2-4 entity and property sheet实体名称属性居民用户编码，户主姓名，人口数，家庭住址片区片区编码，片区名称单位单位编码，单位名称，开户行，账号城市自来水公司公司代码，城市名称收费员收费员代码，收费员姓名水价收费月份，居民水价，工业水价，商饮水价，特种行业水价，排污水价表2-5 实体间联系及其属性表tab2-5 entity relation and property sheet联系名称属性居民-居住-片区单位-属于-片区收费员-收水费-居民收费月份，收费时间，月初表底指数，月末表底指数，基本用水量，基本单价，基本金额，超额用水量，超额单价，超额用水金额，排污水量，排污单价，排污金额，金额合计城市自来水公司及其主管部门-制定发布-水价文件无城市自来水公司及其主管部门-划分-片区无城市自来水公司及其主管部门-申请/配给月份计划-单位月份，工业计划水量，商饮计划水量，特种行业计划水量城市自来水公司及其主管部门-管理/收取片区水费-收费员户数，片区编码，总水量，水费金额，排污金额，总金额收费员-收水费-单位收费月份，商饮用水量，商饮用水金额，工业用水量，工业用水金额，特种行业用水量，特种行业用水金额，排污金额，总金额说明：（1） 上述表二中，消除冗余的工作留待关系模式设计时进行，包括冗余的数据和冗余的联系。冗余的数据是指可用基本表导出的数据，冗余的联系是只有其它联系导出的联系。（2）居民、片区等实体集因为没有表征自己的属性集，故为弱实体集，所以增加了居民编码、片区编码为其强制属性。3 概要设计需求分析阶段已经完全弄清楚了目标系统的各种需求，较好地解决了要让所开发的软件“做什么”的问题，并已在软件需求规格说明和数据要求规格说明中详尽和充分地阐明了这些需求。下一步就要着手实现软件的需求，即要着手解决“怎么做”的问题。分析模型中的每一个成份都提供了建立设计模型所需的信息。根据用数据、功能和行为模型表示的软件需求，采用某种设计方法进行数据设计、体系结构设计、接口设计和过程设计。数据设计将实体关系图中描述的对象和关系，以及数据词典中描述的详细数据内容转化为数据结构的定义。体系结构设计定义软件系统各主要成份之间的关系。接口设计根据数据流图定义软件内部各成份之间、软件与其它协同系统之间及软件与用户之间的交互机制。过程设计则是把结构成份转换成软件的过程性描述。在编码步骤，根据这种过程性描述，生成源程序代码，然后通过测试最终得到完整有效的软件。3.1 体系结构设计说明系统总体结构和模块外部设计。在体系结构中应注意如下几个问题：（1） 模块的分割要有一个合理的度。实际上，如果模块是相互独立的，当模块变得越小，每个模块花费的工作量越低；但当模块数增加时，模块间的联系也随之增加，把这些模块联接起来的工作量也随之增加。如图4-1所示。因此，存在一个模块个数M， 它使得总的开发成本达到最小。 图4-1 模块大小、模块数目与费用的关系Fig4-1 module size, module number and expense relations（2） 合理的控制层次控制层次也叫做程序结构，它表明了程序构件（模块）的组织情况。控制层次往往用程序的层次（树形或网状）结构来表示。如图4.4所示。位于最上层根部是顶层模块，它是程序的主模块。与其联系的有若干下属模块，各下属模块还可以进一步引出更下一层的下属模块。模块M是顶层模块，如果算做第0层，则其下属模块A、B和C为第1层，模块D、E、K、L和N是第2层，等等。图4-2 程序的层次结构图示例Fig4-2 Procedure level structure drawingA. 程序结构的深度：程序结构的层次数称为结构的深度。结构的深度在一定意义上反映了程序结构的规模和复杂程度。B. 程序结构的宽度：层次结构中同一层模块的最大模块个数称为结构的宽度。C. 模块的扇入和扇出：扇出表示一个模块直接调用（或控制）的其它模块数目。扇入则定义为调用（或控制）一个给定模块的模块个数。多扇出意味着需要控制和协调许多下属模块。而多扇入的模块通常是公用模块。D. 要注意的是，程序结构是软件的过程表示，但并未表明软件的某些过程性特征。比如，进程序列、事件决策的顺序或其它的软件动态特性。下面以城市用水管理信息系统为例，以功能树的形式给出体系结构设计的实例，仅供参考。根据对系统需求分析中的总体目标和具体目标部分的分析，得到系统的功能树如下：城市用水管理信息系统数据处理系统维护月份片区居民水费收缴汇总月份片区单位水费收缴汇总月份收费员居民水费收缴汇总表月份水费排污费汇总水管所收费户数报表居民水费收缴情况查询居民自然情况查询单位自然情况查询居民自然情况数据维护居民发票单张打印单位自然情况数据维护居民水费收缴数据维护单位水费收缴数据维护居民尾欠水费数据维护单位尾欠水费数据维护单位水费收缴情况查询单位发票单张打印单位发票片区打印居民发票片区打印月份收费所居民水费收缴汇总月份收费所单位水费收缴汇总月份收费员单位水费收缴汇总表水费价格维护收费所、营业员、收费员代码维护水用户自然信息维护图3-3 城市用水管理系统结构图Fig3-3 city water management system structure drawing3.2 接口设计3.2.1 外部接口 包括用户界面、软件接口与硬件接口。 3.2.2 内部接口 模块之间的接口。 示例（仅供参考）：3.2.1 外部接口3.2.1.1 用户界面在用户界面部分，根据需求分析的结果，用户需要一个用户友善界面。在界面设计上，应做到简单明了，易于操作，并且要注意到界面的布局，应突出的显示重要以及出错信息。外观上也要做到合理化，考虑到用户多对WINDOW 风格较熟悉，应尽量向这一方向靠拢。在设计语言上，已决定使用 SYBASE PowerBuilder 进行编程，在界面上可使用PowerBuilder 所提供的可视化控件，编写基于WINDOWS 风格的用户界面。总的来说，系统的用户界面应作到可靠性、简单性、易学习和使用3.2.1.2 软件接口服务器程序可使用PowerBuilder 提供的对 SQL SERVER 的接口，进行对数据库的所有访问。在网络软件接口方面，使用一种无差错的传输协议，采用滑动窗口方式对数据进行网络传输及接收。3.2.1.3 硬件接口在输入方面，对于键盘、鼠标的输入，对输入进行处理。在输出方面，打印机的连接及使用，也可用PowerBuilder的标准输入/输出对其进行处理。在网络传输部分，在网络硬件部分，为了实现高速传输，使用快速以太网。3.2 .2 内部接口内部接口方面，各模块之间采用函数调用、参数传递、返回值的方式进行信息传递。具体参数的结构将在下面数据结构设计的内容中说明。接口传递的信息将是以数据结构封装了的数据，以参数传递或返回值的形式在各模块间传输。3.3 代码设计3.3.1 代码设计的原则代码设计是处理对象的代号或表示符号，其主要目的是方便计算机排序、检索、查找等处理。代码设计的关键是方便用户，满足业务要求。1 要考虑的是编码的标准化，尽量按照有关的国际标准、国家标准、部门或行业的标准进行设计。2 要考虑容易修改，当某个代码在特点、条件或代表的实体关系改变时，容易进行变更。3 3. 要考虑结构简洁，代码的长度涉及到存储空间的占用和信息处理的速度。而且影响代码输入的出错率，所以，在满足当前需要和扩充性要求的前提下应尽量结构简单，长度要短4. 考虑代码值的唯一性5.4563.3.2 系统所需代码设计包括系统所需代码名称、作用、各位含义等，如代码内容较少，可直接列出，否则，可在附录列出。示例（仅供参考）：火电土建工程质量检验评定系统代码的设计是根据火电施工的特点，结合现场的工作经验，在争得用户认可的情况下设计出来的，所设计的代码结构如下：1 系统工程代码组成火电工程的系统工程共有九个，代码由一位数值组成，格式如下：系统工程编号X所代表的含义如下：表3-1 系统工程及其代码tab3-1 system project and code系统工程代码系统工程名称1热力系统2燃料供应系统3除灰系统4水处理系统5供水系统6电气系统7交通运输系统8附属生产工程9生活福利系统2 单位工程代码各系统工程下的单位工程数量不定，但其值在1-999之间，依据代码设计中的可扩充性的原则，单位工程代码由四字节成： 单位工程编号所属系统工程编号 X XXX各单位工程的代码及其所代表的单位工程名称详见附录一。3 分部工程代码 各单位工程下的分部工程数量不定，但其值在1-999之间，依据代码设计中的可扩充性的原则，分部工程代码由7字节成，格式如下： X XXX XXX所属单位工程编号分部工程编号所属系统工程编号各分部工程的代码及其所代表的单位工程名称详见附录一。4 分项工程代码 各分部工程下的分项工程数量不定，但其值应在1-999之间，依据代码设计中的可扩充性的原则，分项工程代码由10字节成，格式如下： X XXX XXX XXX 分项工程编号所属分部工程编号所属单位工程编号所属系统工程编号依据上述代码设计，火电土建工程所有工程项目实现代码化，方便系统进行数据提取、处理和查询。各工程的代码及其所代表的工程示意如下：表3-2 火电土建工程质量检验评定系统的部分工程及其代码tab3-2 the thermal power civil project quality evaluates systems partial project and code工程代码工程名称1000000000热力系统1001000000主厂房地下结构1001001000土（石）方工程1001003000汽机间基础1001003001外侧柱基础垫层1001003002外侧柱基础钢筋1001003003外侧柱基础模板1001003004外侧柱基础混凝土1001003005平台柱基础垫层1001003006平台柱基础钢筋1001003007平台柱基础模板1001003008平台柱基础混凝土1001003009固定端基础垫层1001003010固定端基础钢筋1001003011固定端基础模板1001003012固定端基础混凝土1001003013扩建端基础垫层1001003014扩建端基础钢筋1001003015扩建端基础模板1001003016扩建端基础混凝土也可以采用阿拉伯数字和字母混合编码的方式。为进一步说明代码设计方法，现再给出城市用水管理系统的代码设计过程，供参考：（1）收费所代码以各收费所的拼音简写为其代码，如连山收费所，其代码为LS。XX收费所代码所代表的含义如下：表3-3 收费所及其代码tab3-3 Charge department and its code收费所名称收费所代码连山收费所LS新区收费所XQ工业收费所GY渤海收费所BH(2)片区代码由五位字符组成。组成方式为前两位为所属收费所编号，后三位为片区编号。片区编号，为0-999的数字字符。所属收费所编号，参见收费所编码方式。XX XXX完整的片区编码表见城市用水管理系统设计报告的附录一葫芦岛市自来水公司片区编码表。(3)收费员代码由9位字符组成。组成方式如下：收费员编号，为0-99的数字字符。XX XX XXX XX片区编号，为0-999的数字字符。收费类型，其中，JM表示为居民收费类型，GY表示为工业收费类型。所属收费所编号，参见收费所编码方式。完整的收费员编码表见城市用水管理系统设计报告附录二葫芦岛市自来水公司收费员编码表。(4)收费用户代码由10位字符组成，组成方式如下：片区编号，为0-999的数字字符。所属收费所编号，参见收费所编码方式。片区内居民编号，为0-99999的数字字符。XX XXX XXXXX完整的收费用户编码表见城市用水管理系统设计报告附录三葫芦岛市自来水公司收费用户编码表。（5） 营业员代码由2位字符组成。组成方式如下：营业员编号，为0-99的数字字符。XX 完整的营业员编码表见城市用水管理系统设计报告附录四葫芦岛市自来水公司营业员编码表。3.4 数据库设计数据库设计是软件开发的灵魂和基础，是整个系统成功的关键所在，是开发高品质应用的前提，鉴于数据库设计的重要性，做如下约定：设计过程应按照概念模型设计-关系模型设计-物理数据库设计的步骤进行。3.4.1 关系模式设计由系统的概念模型导出关系模式（参见本书3.5 系统数据模型部分）。主要原则及实现方法如下：（1） 一个实体型转换为一个关系模式，实体的属性就是关系的属性，实体的键就是关系的键。（2） 个实体的联系转换为关系模式时，应首先确定该联系的类型，再确定相应的键：a) 若关系的类型为1：1，则每个实体的键均为该关系的侯选键，可二者择一为该联系的键。b) 若关系的类型为1：n，则应把一端实体的键移到n端，与n端实体的键共同组成该联系的键。c) 如果为弱实体集,可为其增加一个强制属性作为键。d) 若关系的类型为m：n，则该联系的键为两个实体的键的复合，即该关系的键一定为复合键。 3进行规范化处理，求出关系模式中的最小依赖集，并依据规范化理论，将关系模式规范到三范式。各范式的定义如下：范式是对关系的不同数据依赖程度 的要求。 通过模式分解将一个低级范式转换为若干个高级范式的过程称作规范化（概念的纯粹化）。 1NF： 关系中每一分量不可再分。即不能以集合、序列等作为属性值。 2NF：若R1NF， 且每个非主属性完全依赖于码，则称R2NF（消除非主属性对码的部分依赖 ）。 3NF：关系模式R中，若不存在这样的码X，属性组Y及非主属性Z(Z Y)，使得下式成立，XY , YZ , YX则称R3NF（消除非主属性对码的传递依赖）。下面以葫芦岛自来水公司用水管理信息系统为例进行说明（供参考）：3.4.2 关系模式设计依据上述原则，得出葫芦岛自来水公司用水管理信息系统的关系模式：（1） 城市自来水公司（公司代码，城市名称）（2） 收费员（收费员编码，收费员姓名）（3） 片区（片区编码，片区名称，收费员编码）（4） 居民（用户编码，户主姓名，人口数，家庭住址，所在片区编码）（5） 单位（单位编码，单位名称，单位地址，开户行，账号，所在片区编码）（6） 水价（收费月份，居民水价，工业水价，商饮水价，特种行业水价）（7） 居民水费收缴（用户编码，收费月份，收费时间，月初表底指数，月末表底指数，收费员编码）（8） 单位月份水费计划（单位编码，月份，工业计划水量，商饮计划水量，特种行业计划水量）（9） 单位月份水费收缴（单位编码，收费月份，商饮用水量，工业用水量，特种行业用水量）分析过程说明：1 严格而言，关系模式的内容应为：R(U,D,DOM,F)其中，R为关系名，U为组成该关系模式的属性名集合，D为属性组U中属性所来自的域，DOM为属性向域的映像集合，F为属性间数据的依赖关系集合。设计过程中仅要求给出前两项，即R,U，其它可作为中间优化过程的依据及结果的来源而省略。2 城市自来水公司，收费员，水价三个关系模式的属性集的确定来自E-R图中的同名实体，其关系模式上面已经列出，不再赘述。3 “片区”实体与“收费员”实体的联系类型为1：N的联系，所以应把一端实体（收费员）的键（收费员编码）加到N端实体（片区）的属性集中，并作该关系模式的外键。因此得到的关系模式为：片区（片区编码，片区名称，收费员编码）4 “居民”实体与“片区”实体的联系的类型为1：N的联系，所以该联系不产生第三关系模式，故应把一端实体（片区）的键（片区