当前位置：首页 > news >正文

网站开发文档源码wordpress悬浮工具

news 2025/12/1 15:40:48

网站开发文档源码,wordpress悬浮工具,网址建设,郑州不孕不育#x1f4d6; 前言#xff1a;随着软件产业的发展#xff0c;计算机应用逐步渗透到社会生活的各个角落#xff0c;使各行各业都发生了很大的变化。这同时也促使人们对软件的品种、数量、功能和质量等提出了越来越高的要求。然而#xff0c;软件的规模越大、越复杂#xf… 前言随着软件产业的发展计算机应用逐步渗透到社会生活的各个角落使各行各业都发生了很大的变化。这同时也促使人们对软件的品种、数量、功能和质量等提出了越来越高的要求。然而软件的规模越大、越复杂软件开发越显得力不从心。于是业界开始重视软件开发过程、方法、工具和环境的研究软件工程应运而生。目录 1. 软件工程学概述 1.1 软件和软件危机 1.2 软件工程学的研究范畴 1.3 软件工程的发展 2. 软件生存周期与软件过程 2.1 软件生存周期 2.2 传统的软件过程 2.2.1 瀑布模型Waterfall Model 2.2.2 快速原型模型Rapid Prototype Model 2.3 软件演化模型 2.3.1 增量模型Incremental Model 2.3.2 螺旋模型Spiral Model 2.3.2 构件集成模型Component Integration Model 2.4 形式化方法模型 2.4.1 转换模型Transformational Model 2.4.2 净室模型Cleanroom Model 2.5 统一过程和敏捷过程 2.5.1 统一过程Rational Unified ProcessRUP 2.5.2 敏捷过程Agile Process 2.5.3 极限编程extreme programmingXP 2.6 软件可行性研究Feasibility Study 3. 结构化分析Structured AnalysisSA与设计SD 3.1 概述 3.1.1 SA模型的组成与描述 3.1.2 SD模型的组成与描述 3.2 结构化系统分析 3.3 结构化系统设计 3.3.1 变换映射 3.3.2 事务映射 3.3.3 优化结构设计的指导规则 3.4 模块化设计 1. 软件工程学概述软件程序包含数据文档程序是为了解决某个特定问题而用程序设计语言描述的适合计算机处理的语句序列数据是使程序能正常操纵信息的数据结构文档是与程序开发维护和使用有关的图文材料 1.1 软件和软件危机软件与硬件的不同软件开发不同于硬件设计软件生产与硬件制造不同软件维护不同于硬件维修软件是逻辑的而不是物理的软件开发与人关系密切软件开发成本大软件生产是简单的拷贝软件不会磨损和老化软件受环境影响大软件维护易产生新的问题软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求从而导致软件开发与维护过程中出现一系列严重问题的现象。软件危机的表现对软件开发成本和进度的估算很不准确用户很不满意质量很不可靠没有适当的文档软件成本比重上升供不应求软件开发生产率跟不上计算机应用迅速深入的趋势软件危机的原因客观软件本身特点逻辑部件规模庞大、复杂度高主观不正确的开发方法忽视需求分析个人化方式软件开发程序编写轻视软件维护解决途径组织管理工程项目管理方法技术措施软件开发技术与方法、软件工具促使了软件工程的诞生按工程化的原理和方法组织软件开发是软件开发中的问题一个主要出路 1.2 软件工程学的研究范畴软件开发方法为软件开发提供了 “如何做” 的技术个性化方法 → 结构化方法 → 面向对象方法 → 软件复用软件工具为软件开发提供了自动的或半自动的软件支撑环境单个工具 → 工具箱、集成工具 → 环境软件工程管理目的为了按进度及预算完成软件计划内容成本估算、进度安排、人员组织、质量保证等 1.3 软件工程的发展三种编程范型过程式编程范型程序由一组被动数据和一组能动过程组成程序数据结构算法着眼于程序的过程和基本控制结构粒度最小面向对象编程范型数据及其操作被封装在对象中程序对象消息着眼于程序中的对象粒度比较大基于构件技术的编程范型构件是通用的、可复用的标准化对象类程序构件架构着眼于适合整个领域的类对象粒度更大三代软件工程传统软件工程结构化分析 →结构化设计 → 面向过程的编码 → 软件测试面向对象软件工程面向对象基本概念对象类继承消息通信OO分析与对象抽取 → 对象详细设计 → 面向对象的编码和测试基于构件的软件工程领域分析和测试计划定制 → 领域设计 → 建立可复用构件库 → 查找并集成构件 2. 软件生存周期与软件过程 2.1 软件生存周期需求分析 → 软件分析 → 软件设计 → 编码测试 → 交付测试 → 使用维护需求分析明确需要解决的问题从用户的视角建立需求模型功能、性能、约束、接口等软件分析从开发人员的视角对软件进行分析建立分析模型软件的逻辑模型软件设计确定软件的总体结构和各部件的数据结构和操作建立软件设计模型考虑实现技术和平台编码用程序设计语言将设计文档翻译成源程序建立软件实现模型包含现有软件构件包软件测试发现程序中的错误、提高软件质量单元测试、集成测试、确认测试、系统测试运行维护软件过程围绕软件开发所进行的一系列活动软件过程模型把软件生存周期中软件开发活动的有序流程用一个合理的框架来规范描述。软件过程模型是一种软件过程的抽象表示法它从一个特定的角度表现一个开发过程。软件生存周期中的阶段和软件过程中的活动是基本一致的。 2.2 传统的软件过程 2.2.1 瀑布模型Waterfall Model 瀑布开发模型是一种基于软件生存周期的线性开发模型它与软件生存周期的特点是一致的强调软件文档每一个阶段必须完成规定的文档每一个阶段都要复审完成的文档。特点阶段的顺序性和依赖性推迟实现的观点质量保证的观点存在问题不适合需求模糊的系统开发初始阶段很难彻底弄清软件需求 2.2.2 快速原型模型Rapid Prototype Model 快速原型模型是一种基于原型的迭代化开发模型。中心思想是先建立一个能够反映用户主要需求的原型Demo让用户实际看一下未来系统的概貌以便判断哪些功能是符合需要的哪些方面还需要改进。然后将原型反复改进直至建立完全符合用户要求的新系统。特点 “逼真”的原型可以使用户迅速作出反馈循环回溯和迭代非线性模型使用快速开发工具种类渐进型对原型补充和修改获得最终系统抛弃型原型废弃不用应防止的偏向舍不得抛弃从而影响软件质量小结瀑布模型是纸上谈兵快速原型模型是真枪实干。 2.3 软件演化模型演化开发模型使所开发的软件在迭代中逐步完善。 2.3.1 增量模型Incremental Model 定义把软件看作一系列相互联系的增量每次迭代完成一个增量。增量小而可用的软件第一个增量通常是软件的核心特点在前面增量的基础上开发后面的增量每个增量的开发可用瀑布或快速原型模型每个增量开发的顺序性和总体的迭代性相结合 2.3.2 螺旋模型Spiral Model 特点瀑布模型顺序性、边开发边复审快速原型迭代性风险分析 → 发现、控制风险一个螺旋式周期计划确定目标选择方案选定完成目标的策略风险分析从风险角度分析该策略开发启动一个开发活动评审评价前一步的结果计划下一轮的工作 2.3.2 构件集成模型Component Integration Model 构件在某个领域内具有通用性可以复用的软件部件将可以复用的构件存储起来形成构件库特点面向对象基于构件库融合螺旋模型特征支持软件开发的迭代方法软件复用 2.4 形式化方法模型形式化方法模型基于程序变换和验证技术的软件开发 2.4.1 转换模型Transformational Model 开发过程确定形式化需求规格说明书进行自动的程序变换针对形式化开发记录进行测试特点形式化软件开发方法形式化需求规格说明变换技术程序自动生成技术确保正确 2.4.2 净室模型Cleanroom Model 净室思想在分析和设计阶段消除错误在“洁净”状态下实现软件制作形式化盒结构表示分析和设计正确性验证增量模型把软件看成一系列的增量软件过程模型的特点汇总开发模型特点适用场合瀑布模型线性模型每一阶段必须完成规定的文档需求明确的中、小型软件开发快速原型模型用户介入早通过迭代完善用户需求原型废弃不用需求模糊的小型软件开发增量模型每次迭代完成一个增量可用于OO开发容易分块的大型软件开发螺旋模型典型迭代模型重视风险分析可用于OO开发具有不确定性大型软件开发构件集成模型软件开发与构件开发平行进行领域工程、行业的中型软件开发转换模型形式化的规格说明自动的程序变换系统理想化模型尚无成熟工具支持净室模型形式化的增量开发模型在洁净状态下实现软件制作开发团队熟悉形式化方法中小型软件开发 2.5 统一过程和敏捷过程 2.5.1 统一过程Rational Unified ProcessRUP 统一过程描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做描述了一组以某种顺序完成的活动。统一过程将软件开发分为四个阶段先启定义整个项目的范围精化制定项目计划、描述功能、建立体系架构框架构建构造软件产品迁移将软件产品移交到最终用户手中 2.5.2 敏捷过程Agile Process 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法其软件开发过程称为“敏捷过程” 2.5.3 极限编程extreme programmingXP 极限编程是敏捷过程中的一种是轻量级的、敏捷的软件开发方法。 2.6 软件可行性研究Feasibility Study 目的研究项目是否可能实现和值得进行回答 Why to do? 研究的内容经济可行性、技术可行性、运行可行性、法律可行性可行性研究的步骤对当前系统进行调查和研究弄清当前系统导出新系统逻辑模型导出新系统的解决方案设计不同的解决方案提出推荐的方案本项目的开发价值推荐这个方案的理由编写可行性认证报告系统概述可行性分析结论意见软件风险分析风险识别项目风险、技术风险、商业风险风险预测风险发生的可能性风险发生后的后果风险的驾驭和监控 3. 结构化分析Structured AnalysisSA与设计SD 3.1 概述结构化分析与设计最初系由结构化程序设计扩展而来是瀑布模型的首次实践SA与SD的流程结构化分析工具DFD、PSPEC → 分析模型分层DFD图 SRS结构化设计工具SC图 → 映射 \stackrel{映射}{\rightarrow} →映射初始设计模型初始SC图初始设计模型初始SC图 → 优化 \stackrel{优化}{\rightarrow} →优化最终设计模型最终SC图基本任务与指导思想结构化分析建立分析模型Analysis Model编写需求说明Software Requirements SpecificationSRS 结构化设计软件设计总体设计详细设计SC图须分两步完成初始SC图、最终SC图细化与分解逐步细化细化的本质就是分解 3.1.1 SA模型的组成与描述 SA模型的描述工具 DFD、DD和PSPEC这是早期SA模型的基本组成部分CFDControl Flow Diagram控制流图、CSPECControl Specification控制规格说明和STDStatus Transform Diagram状态转换图是早期SA模型的扩展成分适应实时软件的建模需要E-R图Entity-Relation Diagram适用于描述具有复杂数据结构的软件数据模型数据流图Data Flow DiagramDFD 指明数据在系统中移动时如何被变换描述对数据流进行变换的功能和子功能。组成符号圆框代表加工箭头代表数据的流向数据名称总是标在箭头的边上方框表示数据的源点和终点双杠或单杠表示数据文件或数据库文件与加工之间用带箭头的直线连接单向表示只读或只写双向表示又读又写数据字典Data DictionaryDD 对软件中的每个数据规定一个定义条目。①数据流、②数据文件、③数据项数据流图与数据字典共同构成系统的逻辑模型加工说明Process SpecificationPSPEC 对数据流图中出现的每个加工/处理的功能描述主要工具结构化语言判定树或判定表例题某公司为推销人员制订了奖励办法把奖金与推销金额及预收货款的数额挂钩。凡每周推销金额不超过10000元按预收货款是否超过50分别奖励推销额的6或4。反之若推销金额超过10000元则按预收货款是否超过50分别奖励推销额的8或5。对于月薪低于1000元的推销员分别另发鼓励奖300、200和500、300元。试分别采用判定表和判定树为DFD图中用来“计算奖金”的加工写出加工说明即PSPEC。 3.1.2 SD模型的组成与描述包含数据设计、体系结构设计、接口设计与过程设计。体系结构设计是用来确定软件结构的其描述工具为结构图简称SC图。过程设计主要指模块内部的详细设计 SC图的组成符号矩形框来表示模块带箭头的连线表示模块间的调用并在调用线的两旁标出传入和传出模块的数据流 SC图的模块调用为了画面简洁在下图中调用线的两旁均未标出数据流。在实际的 SC 图中不允许这种省略。 3.2 结构化系统分析定义结构化分析就是使用DFD、DD、结构化英语、判定表和判定树等工具来建立一种新的、称为结构化说明书的目标文档。结构化分析的基本步骤由顶向下对系统进行功能分解画出分层DFD图由后向前定义系统的数据和加工编制DD和PSPEC最终写出SRS 画分层数据流图自顶向下逐步细化好处便于实现便于使用顶层DFD通常把整个系统当作一个大的加工标明系统的输入与输出以及数据的源点与终点统称为“外部项” 第二层DFD 第三层DFD——销售子系统第三层DFD——采购子系统确定数据定义与加工策略从数据的终点开始定义数据和加工数据定义—DD 例如发票发票学号姓名书号单价数量总价书费合计加工策略—PSPEC 数据定义DD加工策略PSPEC需求规格说明书SRS 需求分析的复审 3.3 结构化系统设计 SD概述面向数据流设计和面向数据设计面向数据流数据流是考虑一切问题的出发点面向数据以数据结构作为分析与设计的基础从分析模型导出设计模型结构化设计的描述工具SC图从分析模型导出设计模型数据流图DFD的类型变换transform型结构传入路径变换中心传出路径事务transaction型结构一条接受路径一个事务中心若干条动作路径同时存在两类结构 SD方法的步骤复审DFD图必要时可再次进行修改或细化鉴别DFD图所表示的软件系统的结构特征确定它所代表的软件结构是属于变换型还是事务型按照SD方法规定的一组规则把DFD图为初始的SC图变换型DFD图 → 变换映射 \stackrel{变换映射}{\rightarrow} →变换映射初始SC图事务型DFD图 → 事务映射 \stackrel{事务映射}{\rightarrow} →事务映射初始SC图按照优化设计的指导原则改进初始的SC图获得最终SC图 3.3.1 变换映射划分DFD图的边界建立初始SC图的框架顶层都只含一个用于控制的主模块第一层包括传入、传出和中心变换三个模块分解SC图的各个分支分解实质上是“映射” 例题用变换映射规则从下图导出初始 SC图划定边界左边是输入流、中间是变换中心、右边是输出流一级分解 MC控制模块可以将整个系统的名称作为控制模块MA传入模块输入流整体作为传入模块MT变换模块变换中心作为变换模块ME传出模块输出流整体作为传出模块二级分解对传入、传出和变换模块的分解从变换分析导出的初始 SC 图深度5层宽度广度7层注意必须对一个模块的全部直接下属模块都设计完成之后才能转向另一个模块的下层模块的设计在设计下层模块时应考虑模块的耦合和内聚问题使用“黑箱”技术先把这个模块的所有下层模块定义成“黑箱”不考虑其内部结构和实现一个模块的直接下属模块一般在五个左右如果直接下属模块超过10个可设立中间层次。 3.3.2 事务映射在DFD图上确定边界事务中心接受部分包括接受路径发送部分包括全部动作路径画出SC图框架 DFD图的三个部分分别映射为事务控制模块接受模块和动作发送模块分解和细化接受分支和发送分支一个事务型数据流图事务中心是 I 从事务分析导出的两种初始 SC 图通常一个大型的软件系统是变换型结构和事务型结构的混合结构。 3.3.3 优化结构设计的指导规则对模块划分的指导规则提高内聚降低耦合后简化模块接口少用全局性数据和控制型信息保持高扇入/低扇出的原则扇入高则上级模块多能够增加模块的利用率扇出低则表示下级模块少可以减少模块调用和控制的复杂度煎饼型不可取应增加中间层减少扇出实现塔型结构。设计良好的软件通常具有瓮型结构两头小中间大在低层模块使用了较多高扇入的共享模块。 3.4 模块化设计模块设计是传统软件工程的重要组成部分其性质属于详细设计。目的为SC图中的每个模块确定算法和数据结构用选定的表达工具给出清晰的描述主要任务编写软件的“模块设计说明书” 原则与方法清晰第一的设计风格结构化的控制结构仅用这三种控制结构顺序、选择、循环来构成程序每个控制结构只应有一个入口和一个出口逐步细化的实现方法详细设计中常用的表达工具流程图、N-S图、伪代码、PDL语言 N-S图 OK以上就是本期知识点“软工学绪论及传统软件工程”的知识啦~~ 感谢友友们的阅读。后续还会继续更新欢迎持续关注哟~ 如果有错误❌欢迎批评指正呀~让我们一起相互进步如果觉得收获满满可以点点赞支持一下哟~ ❗ 转载请注明出处作者HinsCoder 博客链接作者博客主页

查看全文

http://www.dnsts.com.cn/news/153150.html