搜索
三大块内容：软件危机与软件工程传统软件开发方法面向对象方法一、软件危机与软件工程：软件、软件危机、软件生存期、软件开发模型、软件管理1、软件：软件是能够完成预定功能和性能的可执行的计算机程序+使程序正常运行所需要的数据+描述软件开发过程及其管理、程序的操作和使用的有关文档。文档：分开发、管理、用户、维护文档，作用是记录及解决不可视性、通信与交流、管理与维护、用户服务2、软件危机a)表现：软件成本高、难于控制开发进度、软件工作量估计困难、软件质量低、软件修改维护困难b)原因：需求问题(描述不精确、理解不一致)、管理问题、方法和工具问题、软件本身的特点3、软件生存期：a)三个时期：定义时期(软件计划、需求分析)—开发时期(软件设计、编码实现、测试)—使用和维护时期(维护)b)六个阶段：软件计划需求分析设计编码测试使用与维护c)生命周期方法特点：顺序性、依赖性，推迟程序的物理实现、质量保证的观点(利于尽早发现错误，如阶段文档、评审)4、软件开发模型a)瀑布模型：文档驱动i.阶段划分、分而治之、控制开发过程的复杂性ii.自顶向下、由抽象到具体，顺序进行优点：规范管理开发过程、文档驱动缺点：初期系统的需求难以完全确定、文档驱动、周期长b)原型模型：i.针对：软件开发初期需求难以确定ii.基本思想：快速建立原型，完善用户需求iii.优点：用户参与、快速iv.缺点：快速弱功能、对开发环境要求高c)螺旋模型(风险驱动)d)增量模型(模块、功能驱动)e)迭代模型f)喷泉模型5、软件管理a)区别于其他工业产品生产管理的特点b)主要内容：开发计划与进度管理、文档管理、人员组织管理、成本管理、质量管理二、传统软件工程方法：a)软件计划i.问题定义ii.可行性研究1.经济可行性2.技术可行性3.法律可行性b)需求分析i.结构化分析SAii.面向数据流的分析方法1.DFD四个组成部分(表示方法、命名)2.DFD作图：需求描述DFD3.层次分解法(保持父图和其子图的平衡)4.数据字典(符号)c)软件设计i.总体设计1.模块独立性：高内聚2.作用域是控制域的子集3.单入单出4.规模、深度、宽度、扇入、扇出适当ii.传统设计方法1.面向数据流的设计方法(数据流图)a)结构化设计SD-对应有SD结构化需求分析、SP结构化实现b)DFD软件结构(层次图)i.变换设计ii.事务设计c)优缺点2.面向数据结构的设计方法a)Jackson方法b)Jackson图i.三种元素间的逻辑关系：顺序、选择、重复ii.可描述两种数据结构:数据结构、程序结构c)思想：数据结构与程序处理过程相互转换d)步骤：I/ODS对应关系ProgramStructure细化求精e)优缺点：i.数据入手ii.简化数据处理程序的设计iii.模块与独立性原则没有给予应有的重视iv.求提供对复杂系统设计过程的支持3.Parnas方法iii.详细设计1.结构化程序设计SPa)高效率---良结构b)三种基本控制结构、单入单出2.过程设计的工具d)实现/编码i.语言1.功能等价2.描述问题方便性有差异a)例如：OOPL---非OOPLii.程序设计风格e)软件测试i.目标ii.方法1.正确性证明2.静态测试3.动态测试a)黑盒(功能)测试i.等价类划分ii.边界值分析iii.错误推测b)白盒(结构)测试i.语句覆盖ii.判定覆盖iii.条件覆盖iv.判定—条件覆盖v.条件组合覆盖iii.步骤f)软件维护i.四种类型1.校正性2.适应性3.完善性4.预防性ii.提高可维护性的措施三、面向对象方法(Object-orientedMethod)a)OOM与CM对比：区别—优点i.思维方式iv.稳定性ii.可重用性v.可维护性iii.大型软件b)OOSE方法i.三个阶段、五个模型、ii.USECASE第二章．传统软件工程方法：软件计划具体任务：项目定义、可行性分析、软件计划其中：可行性分析：1、可行性研究实质：可行性研究试一次大大压缩和简化了的系统分析和设计过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计过程。2、主要内容：a)经济可行性:资金有无落实、成本—效益分析b)技术可行性:开发的风险、资源的有效性、技术方案c)操作可行性:用户组织内的管理制度、人员素质、操作方式等是否可行。d)法律及社会可行性e)开发方案的选择:折衷手段权衡。3、可行性研究的主要步骤：a)复查系统规模b)研究正在使用的旧系统c)导出高层逻辑模型d)重新定义问题e)导出多种解法f)推荐行动方针g)草拟开发计划h)书写文档并提交审查系统流程图(物理建模工具)：会读、读懂。数据流图：概述描绘系统的逻辑模型的工具DFD:DataFlowDiagram描绘信息流和数据从输入移动到输出的过程中所经受的变换数据从哪里来，到哪里去，经过怎样的处理，保存在哪里没有任何具体的物理部件，只是描绘数据在软件中流动和被处理的逻辑过程。是系统逻辑功能的图形表示。是分析员和用户沟通的工具是后期设计的出发点DFD的绘制一般采用自顶向下、逐步细化的方法，主要步骤如下：·明确系统界面。识别出那些不受系统控制但又影响系统运行的外部环境。·绘制基本系统模型。基本系统模型由若干源点、终点和一个基本处理组成，表明系统对数据加工变换的基本功能。·逐层细化基本系统模型得到功能级DFD和详细DFD。下面即分层数据流图。假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据；零件编号零件名称、定货数量、目前价格、主要供应者和次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。从问题描述中提取数据流图的四种成分。首先考虑数据的源点和终点：“采购部每天需要一张定货报表”“通过放在仓库中的CRT终端把事务报告给定货系统”可知：采购员是终点仓库管理员是源点接下来考虑处理：“采购部每天需要一张定货报表”--采购部需要报表“零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。”--事务的后果是改变库存量可知：产生报表是一个处理处理事务是另一个处理最后考虑数据流和数据存储：系统把定货报表送给采购部----定货报表事务需要从仓库送到系统中----事务----需把事务数据存储起来产生报表和处理事务在时间上不匹配,当某种零件的库存数量少于库存量临界值时就应该再次定货，而每天打印一次定货报表-----需把定货信息存储起来可知：定货报表、事务是数据流(数据流如报表包含零件编号零件名称、定货数量、目前价格、主要供应者和次要供应者等信息。事务包含零件编号、事务类型、数量等。)库存清单、定货信息是数据存储基本系统模型：功能数据流图：注意符号进一步分解处理事务：命名1）为数据流(或数据存储)命名名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的2）为处理命名通常先为数据流命名，然后再为与之相关联的处理命名，体现了人类习惯的“由表及里”的思考过程名字应该反映整个处理的功能名字最好由一个具体的及物动词，加上一个具体的宾语组成。通常名字中仅包括一个动词如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解应注意的问题1）是数据流不是控制流画数据流不是控制流；数据流图反映系统“做什么”，不反映“如何做”，因此箭头上的数据流名称只能是名词或名词短语，整个图中不反映加工的执行顺序。2）一般不画物质流数据流反映的是能用计算机处理的数据，并不是实物，因此系统的数据流图上一般不要画物质流。3）加工的画法每个加工至少有一个输入数据数据流图的用途：1）建立新系统逻辑模型的工具2）作为与用户和开发人员交流信息的工具3）作为分析、设计乃至维护的依据数据字典：概念数据字典是关于数据的信息的集合DD:DataDictionary是对DFD中包含的所有元素的定义的集合在分析、设计和维护过程中供查阅用内容1）数据流2）数据流分量（即数据元素）3）数据存储4）处理（IPO图或PDL更加方便）——是对上述四类元素的定义具体信息名字——数据、控制项、数据存储或外部实体的主要名称别名——该元素等价的其他名字，尽量减少使用地点与方式——使用数据或控制项的处理的列表，以及使用这些对象的方式(例如作为处理的输入，从处理输出，作为数据存储，作为外部实体)内容描述——描述数据或控制项内容的符号补充信息——关于数据类型、预置值、限制等的其他信息软件项目的量化估算成本估算&工作量估算工程进度安排行成本估算阶段成本估算甘特图：历史悠久、应用广泛的进度计划工具进度安排的任务网络图优点：简单，能动态地反映开发进展缺点：难以反映多个任务间的逻辑关系第三章．传统软件工程方法：需求分析需求分析1目标和任务2需求获取技术3需求内容4需求建模方法需求分析任务问题分析需求描述需求评审需求建模方法1.面向数据流的分析方法2.面向对象的分析方法3.面向数据结构的分析方法需求工程的任务需求开发包含四个过程：需求获取、需求整理与分析、需求定义、需求验证。需求分析的具体任务：需求获取、确定和分析需求、开发原型系统、编写SRS、需求验证、变更管理、修正计划软件需求及需求的分类软件需求：以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。（表达做什么而不描述如何做。）RequirementistheBasicsofQuality，软件需求的作用：①分理解现实中的业务问题，并作为软件设计的基础；②为软件项目的成本、时间、风险估计提供准确的依据；③少开发工作量，避免将时间与资源浪费在设计与实现错误的需求上；④通提供需求文档和需求基线，来有效的管理系统演化与变更；⑤为顾客与开发团队之间正式合同的一部分；⑥最终的验收测试提供标准和依据需求的分类：业务需求业务需求指导需求获取用户需求转化用户需求为系统需求系统需求前四个为原始问题空间、后面系统需求为解决方案空间。业务需求(BusinessRequirements)：客户对于系统的高层次目标要求(highlevelobjectives)，定义了项目的远景和范畴(visionandscope)1、业务：属于哪类业务范畴？应完成什么功能？为何目的？2、客户：软件为谁服务？目标客户是谁？3、特性：区别于其他竞争产品的特性是什么？4、价值：价值体现在那些方面？5、优先级：功能特性的优先级次序是什么？用户需求(UserRequirements)：从用户角度描述的系统功能需求与非功能需求，通常只涉及系统的外部行为而不涉及内部特性。系统需求(SystemRequirements,SR)：系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节系统需求的类型分：功能性需求：描述了系统与其实现环境之间的交互。环境包括用户和任何其他与该系统进行交互的外部系统。功能需求可以以不同的详细程度反复编写和细化功能需求描述应该完整而且一致和准确完整性意味着用户所需的所有的服务应该全部给出描述一致性意味着需求描述不能前后矛盾准确性是指需求不能出现模糊和二义性的地方非功能性需求：描述了不直接关联到系统功能行为的系统的方方面面。从各个角度对系统的约束和限制，反映了客户对软件系统质量和性能的额外要求，如响应时间、数据精度、可靠性等。可用性(Usability):是一种用户可以学会的操作、输入准备、解释一个系统或者构件输出的状况。可靠性(Reliability):是系统或构件在给定时间内、指定条件下，完成其要求功能的能力。性能(Performance):需求要考虑系统的定量属性，比如响应时间，吞吐量、有效性和准确性。可支持性(Supportability):需求