《软件工程》学习笔记五
软件工程学习笔记

软件工程学习笔记一、引言软件工程是指通过系统化、规范化和数量化的方法来开发、运行和维护软件的一门学科。
在当今日益发展的科技领域中,软件工程无疑扮演着至关重要的角色。
本文将从软件工程的基本概念、原理和方法入手,对软件工程学习进行详尽的笔记整理。
二、软件工程的基本概念软件工程的基本概念包括软件、软件生命周期和软件过程。
1.软件:软件是指对计算机指令和数据的组织,以及在计算机上执行这些指令的所有程序和数据的总称。
它是计算机系统中不可见的部分,以代码形式存在。
2.软件生命周期:软件生命周期是指软件从诞生到退役的整个过程,包括需求分析、设计、编码、测试、发布和维护等阶段。
3.软件过程:软件过程是指完成软件开发的一系列活动和任务的集合。
常见的软件过程模型包括瀑布模型、迭代模型和敏捷模型等。
三、软件工程的原理软件工程的原理是软件工程学科中的基本理论和法则,包括模块化原理、结构化原理和信息隐藏原理等。
1.模块化原理:将一个大型复杂的系统划分成若干个相对独立且易于管理的模块,以降低开发的复杂度。
2.结构化原理:通过模块化、顺序、选择和重复四种控制结构来组织和设计程序,以提高代码的可读性和可维护性。
3.信息隐藏原理:将系统中的细节和模块之间的关系隐藏起来,只对外提供简洁的接口,以便于模块的替换和重用。
四、软件工程的方法软件工程的方法主要包括软件需求分析、软件设计、软件测试和软件维护等。
下面对每个方法进行简要介绍。
1.软件需求分析:通过与用户的沟通和交流,收集并分析用户的需求,明确软件系统的功能和性能要求。
2.软件设计:在软件需求分析的基础上,进行软件结构、算法和数据结构的设计,确保软件系统具备可靠性和可扩展性。
3.软件测试:通过测试用例和测试技术,验证软件系统的正确性、健壮性和可靠性。
4.软件维护:及时修复软件中的缺陷和问题,更新和改进软件功能,以满足用户的需求。
五、软件工程的工具软件工程的工具是指用于支持软件开发过程的各种工具和技术,包括集成开发环境(IDE)、版本控制系统、测试工具和项目管理工具等。
软件工程笔记(完整版)

第一章第二章第三章第四章软件工程概述1.软件危机(software crisis):是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
即“两低一高”问题:质量低、效率低、成本高。
软件危机也成为“软件萧条(depression)”或“软件困扰(afflication)”2.软件危机主要表现1)开发成本和进度估计不准2)用户对“已完成的”软件系统不满意3)软件质量往往靠不住4)软件常常是不可维护的5)软件通常没有适当的文档资料6)软件成本逐年上升7)软件开发生产率滞后于硬件和计算机应用普及的趋势3.产生软件危机的原因1)与软件本身的特点有关a. 软件不同于硬件,是逻辑部件而不是物理部件缺乏可见性难于测试管理和控制开发过程困难不会因使用时间过长而被“用坏”难以维护b.软件不同于一般程序,规模庞大,而且程序复杂性随着程序规模的增加而呈指数上升2)和软件开发与维护的方法不正确有关a.对软件开发和维护有关的错误认识和作法忽视软件需求分析的重要性认为软件开发就是写程序轻视软件维护b. 对软件开发过程与方法的认识与应用软件开发要经历一个漫长的时期(编程占10-20%)程序仅是完成软件配置的一个组成部分软件开发方法要有利于软件维护4.软件的特点(1)软件是无形的(intangible)(2)软件副本的大批量生产轻而易举(3)软件业是劳动密集型的(4)一个没有经过充分训练的软件开发人员很容易编写出难以理解和修改的软件(5)软件本身很容易修改。
但由于它的复杂性,又很难正确地修改。
(6)软件不像其他的工业产品那样会因使用而磨损,随着反复修改,它的设计会逐渐退化5.消除软件危机的途径1)对计算机软件的正确认识2)认识到软件开发不是个体劳动的神秘技巧,而是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目3)推广使用成功的软件开发技术和方法4)开发和使用更好的软件开发工具总之, 为了消除软件危机,既要有技术措施(方法和工具),又要有必要的组织管理措施。
软件工程笔记

软件工程笔记软件工程是一门关于构建和维护软件系统的学科。
在这门学科中,我们需要掌握一系列的原理和方法,以确保软件的质量和可靠性。
本文将对软件工程的基本概念和常用工具进行笔记总结,帮助读者更好地理解并应用软件工程的知识。
一、软件生命周期软件开发的过程可以被看作是一个生命周期,其中包含了多个阶段。
常见的软件生命周期模型有瀑布模型、迭代模型和敏捷模型等。
1. 瀑布模型瀑布模型是最经典的软件开发模型之一,它将软件开发过程划分为需求分析、设计、编码、测试和维护五个阶段。
开发团队需逐个完成这些阶段,且每个阶段的结果是固定的,即前一阶段的输出作为后一阶段的输入。
2. 迭代模型迭代模型是在瀑布模型基础上发展而来的一种软件开发模型。
该模型将整个开发过程划分为多个迭代周期,每个迭代都包含需求分析、设计、编码、测试和维护等阶段。
每个迭代的输出可作为下一次迭代的输入,以此循环进行。
3. 敏捷模型敏捷模型强调快速迭代和反馈,鼓励团队协作和灵活性。
开发团队通过短周期的迭代,不断交付可用的软件版本,并根据用户反馈进行调整和改进。
敏捷开发方法有Scrum、XP等。
二、需求工程需求工程是软件工程的重要环节,它包括需求获取、需求分析、需求规格和需求验证等过程。
1. 需求获取需求获取是指通过各种技术手段和方法,从用户、领域专家和相关文档中获取软件系统的需求信息。
常用的需求获取技术包括访谈、问卷调查、原型设计和场景分析等。
2. 需求分析需求分析是对获取的需求进行理解和分类的过程。
分析人员需要识别出用户的需求,确定需求的优先级和约束条件,并将其转化为可操作的规格说明。
3. 需求规格需求规格是将需求写入规范文档的过程。
通常采用的规格化方法有自然语言、用例和面向对象建模等。
4. 需求验证需求验证是确保规格所描述的需求能够满足用户期望的过程。
常用的验证方法包括检查列表、原型演示和用户评审等。
三、软件设计软件设计是将需求转化为软件结构和组件的过程。
软件工程读书笔记

软件工程读书笔记【篇一:软件工程读书笔记】1.软件危机在计算机软件的开发和维护过程中所遇到的一系列严重问题。
2.软件危机的表现–软件成本日益增长–开发进度难以控制–软件质量差–软件维护困难–软件开发速度跟不上计算机发展速度3.软件危机的原因–技术原因? 软件规模越来越大? 软件复杂度越来越高–管理原因? 软件开发缺乏正确的理论指导,过分依靠个人技巧和创造性? 对用户需求没有完整准确的认识,就匆忙着手编写程序4.软件工程1) 将系统化、规范化、可量化的工程原则和方法,应用于软件的开发、运行和维护。
2) 对1)中方法的理论研究。
5.生命周期软件生命周期由软件定义、软件开发和运行维护三个时期组成,每个时期又可进一步划分成若干个阶段,每个阶段有各自的任务。
?????? 问题定义可行性分析需求分析概要设计详细设计编码和单元测试? 综合测试? 维护6.软件过程生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序,因此,也称为过程模型。
7.瀑布模型:? 阶段间具有顺序性和依赖性?? 推迟实现的观点质量保证的观点,文档驱动优点:文档驱动的规范坏,每个阶段的仔细验证。
缺点:通过文档与客户沟通,最终产品可能不能真正满足客户需求。
8.快速原型模型:? 快速建立起可以运行的程序,其功能往往是最终产品功能的子集。
特点:通过原型系统获取客户要求,一旦需求确定,原型将被抛弃。
9.增量模型:? 把软件产品作为一系列增量构件来设计、编码、集成和测试。
优点:能在最早的时间把最新的功能提交给客户;减少客户对全新软件的冲击。
缺点:开发困难,设计阶段必需有一个好的体系结构10.螺旋模型:? 在每个阶段之前都增加了风险分析过程的快速原型模型。
优点:对可选方案和约束条件的强调有利于已有软件的重用;减少了过多测试或测试不足带来的风险;维护只是一个周期;风险驱动。
11.瀑布模型:面向对象迭代无缝可行性分析1. 可行性分析任务? 技术可行性? 经济可行性? 操作可行性? 法律可行性2. 可行性分析过程???????3.复查系统规模和目标研究目前正在使用的系统导出新系统的高层逻辑模型进一步定义问题导出和评价供选择的解法推荐行动方针草拟开发计划 ? 书写文档提交审查系统流程图–概括描绘物理系统的传统工具–用图形符号,以黑盒子形式描述组成系统的每个部件–程序、文档、数据库、人工过程3. 数据流图(dfd)描绘信息流和数据从输入移动到输出的过程中所经受的变换。
软件工程笔记分享

软件工程笔记分享
- 软件工程的定义:软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
- 软件工程的目标:在给定成本、进度的前提下,开发出具有可修改性、有效性、可靠性、可维护性、可复用性、可适应性、可移植性、可追踪性和可互操作性并满足用户需求的软件产品。
- 软件生命周期:软件生命周期是指从软件定义、开发、使用、维护到退役的整个过程。
- 软件开发过程模型:瀑布模型、迭代模型、敏捷开发模型等。
- 软件需求分析:确定软件系统需要完成的功能和性能要求。
- 软件设计:设计软件系统的架构、模块、接口和数据结构。
- 软件编码:编写代码实现软件系统的功能。
- 软件测试:验证软件系统是否满足需求和设计要求。
- 软件维护:对软件系统进行修改、完善和升级。
软件工程是一门涉及多个学科领域的交叉学科,需要掌握计算机科学、数学、工程学等方面的知识。
在软件开发过程中,需要遵循软件工程的原则和方法,以确保软件系统的质量和可靠性。
软件工程 第五章(总结和课后习题)

出:分析类[完成];4、对包进行分析: 输入:系统体系结构描述[分析]、分析 包[概述]输出:分析类[完成]。 � (18)创建系统的分析模型,一般应进 行体系结构分析、用况分析、类的分析 以及包的分析 4 项活动。 � (19)用况分析[分析]的目标:1、标识 那些在用况事件流执行中所需要的分析 类和对象;2、将用况的行为,分布到参 与交互的各个分析对象;3、捕获用况细 化上的特定需求。 � (20)用况分析[分析]开展的活动包括: 1、标识分析类,标识在细化一个用况中 所需要的实体类、控制类和边界类,给 出它们的名字、责任、属性和关系;2、 描述分析(类)对象之间的交互,通常 使用交互图来描述。 � (21)类的分析[分析]的目标:1、标识 并维护分析类的责任;2、基于它们在用 况细化中的角色,标识并维护分析类的 属性和关系;3、捕获分析类细化中的特 定需求。 � (22)类的分析[分析] 开展的活动包 括:1、标识责任;2、标识属性;3 标识 关联与聚合; � (23)需求分析模型对以后开发工作的 影响?1、对设计中子系统的影响。分析 包一般将影响设计子系统的结构;2、对 设计类的影响。分析包可以作为类设计 时的规格说明;3、对用况细化[设计]的 影响。用况细分[分析]对用况细化[设计] 有两方面影响,一个是它们有乃至于为 用况创建更精确的规格说明,另一个是 当对用况进行设计时,用况细化[分析] 可作为其输入。 (24)需求获取模型与需求分析模型之
第五章 RUP
[概述];输出:子系统[完成]、接口[完 成]。 � (29)用况的设计包括以下任务:1、标 识参与用况细化的设计类;2、标识参与 用况细化的子系统的接口。 � (30)类的设计包括以下任务:1、概括 描述设计类;2、标识操作;3、标识属 性;4、标识关联、聚合;5、标识泛化; 6、描述方法; � � � (31)RUP 设计的突出优点:P165 页 (32)RUP 的设计系统生成构件;对构件进行测试,进行 集成测试和连接;把可执行的构件映射 到部署模型。 � (34)RUP 实现包括以下活动:1、实现 模型;2、实现子系统;3、实现模型视 角下的体系结构描述;4、实现类; � � (35)RUP 测试包括内部测试、中间测试 和最终测试。 (36)RUP 测试的主要活动:1、计划测 试;2、设计测试;3、实现测试;4、执 行集成测试;5、执行系统测试;6、评 价测试。
软件工程笔记整理
软件工程笔记整理一、软件工程的定义与发展历程软件工程是一门应用计算机科学原理和方法,以科学的方式开发和维护软件的学科。
软件工程的发展可以追溯到上世纪50年代,经历了演进、发展、成熟等不同阶段。
二、软件工程的基本原则1. 分析和定义需求:软件开发的第一步是分析客户需求并明确定义,确保软件开发符合客户预期。
2. 设计和构建:在明确需求后,进行软件架构和设计,确保软件的可扩展性、可维护性和可重用性。
3. 测试和验证:针对软件开发的每个阶段进行测试和验证,确保软件的质量和可靠性。
4. 配置和管理:对软件进行版本控制、配置管理和项目管理,确保软件开发过程的可控性和可管理性。
5. 文档和交流:编写详细的文档和开展有效的沟通,确保团队成员之间的交流和合作。
三、软件开发生命周期1. 需求分析:确定和规划软件开发的需求和目标,包括需求收集、需求分析和需求验证等。
2. 设计阶段:根据需求分析的结果进行软件架构和系统设计,确定软件的结构和组件。
3. 编码和测试:开发人员根据设计文档进行编码,并进行单元测试、集成测试和系统测试。
4. 部署和维护:将开发完成的软件部署到实际环境中,并进行维护、更新和修复Bug等工作。
5. 软件版本管理:对软件进行版本控制和配置管理,确保软件开发过程的可追溯性和可控性。
四、常见的软件开发方法和模型1. 瀑布模型:按照严格线性顺序进行软件开发的经典模型,适用于需求稳定的项目。
2. 敏捷开发:以迭代、循序渐进的方式进行软件开发,强调团队合作和客户交互。
3. 原型模型:通过多次迭代构建原型来满足用户需求,适用于需求变动较大的项目。
4. 增量模型:将软件开发划分为多个阶段,每个阶段增量添加功能,适用于大型项目。
5. 螺旋模型:将风险管理和迭代开发相结合,适用于高风险项目或创新性项目。
五、软件质量保证1. 静态质量保证:通过静态分析、代码审查等手段,提前发现和修复潜在的质量问题。
2. 动态质量保证:通过自动化测试和手动测试等手段,确保软件在运行时的质量和性能。
软件工程学习笔记
第1章软件工程基本观念1.1 软件工程的目标与常用模型1.2 软件开发的基本策略1.2.1 复用软件复用可以表述为:构造新的软件系统可以不必每次从零开始,直接使用已有(稳定)的软构件,即可组装(或合理修改)成新的系统。
1.2.2 分而治之分而治之是指把一个复杂的问题分解成若干个简单的子问题,然后逐个解决。
诸如软件的体系结构设计,模块化设计等都是分而治之的表象。
1.2.3 优化-折衷软件的优化是指优化软件的各个质量因素,比如提高软件运行速度,提高对内存资源的利用率,改善用户界面效果,使三维图形的真实感更强等等。
但是软件优化比较复杂,当所有因素不能都得到优化的时候,就需要“折衷”策略。
软件中的“折衷”策略是指通过协调各个质量因素,实现整体质量的最优。
在保证其他质量因素不变差的前提下,使某些质量因素变得更好。
第2章程序员与程序经理2.1 了解程序员2.2了解程序经理好的程序经理应具备以下品质:1)技术水平是程序员当中的最高级别2)能做最多且最难的工作3)有人格魅力程序员升为经理后一定要保持编程的习惯。
2.4 软件团队建设技术级别和管理级别都划分为四个等级:第3章项目计划与质量管理在可行性分析之后,项目计划与质量管理将贯穿需求分析,系统设计,程序设计,测试,维护等软件工程环节。
软件的高质量是“设计”出来的,不是“管”出来的。
3.1 项目计划只有知己知彼才能做出合理的项目计划。
“知己”是指了解有多少可用资源,包括:人;可复用的软构件;软硬件环境。
“知彼”是指了解项目的规模,难度与时间限制。
3.2 零缺陷质量管理的理念“零缺陷”质量管理有两个核心内容:高目标;可执行的规范。
3.3 软件的质量因素3.4 质量检查质量检查应该在每个实践环节(里程碑)都执行。
检查工作要预防被检查者弄虚作假。
检查工作要有科学的评审方式。
第4章可行性分析与需求分析可行性分析是要决定“做还是不做”。
需求分析是要决定“做什么,不做什么”。
第五章 软件工程总结
用某种程序语言为每个模块编写程序
高级程序员、程序员
程序清单
软件测试
发现软件中的错误,并加以纠正
高级程序员或系统分析员(另一部门或单位)
软件测试计划、软件测试用例说明,软件测试报告
测试步骤
测试方法
测试用例
软件维护阶段—开发后交付使用的软件的维护
软件维护
使软件适应外界环境的变化、实现功能的扩充和质量的改善而修改软件
3、内聚度
4、其他模块设计
功能分解模块设计策略
1、变换型软件结构
2、事务型软件结构
详细设计
设计每个模块的实现细系统设计
确定实现系统的策略和目标系统的高层结构,构造设计模型
高级程序员、程序员
主体部件设计
用户界面设计
任务管理部件设计
数据管理部件设计
对象设计
包括对类及其关联接口形式和实现算法
确定属性
定义操作
分析对象所属类及类间关系(继承关系、部分-整体关系)
软件开发阶段——待开发软件“怎么做”
软件设计
结构化设计(SD)
概要设计
模块分解,确定软件的结构,模块的功能和模块间的接口,以及全局数据结构的设计
系统分析员、高级程序员
系统设计说明书(结构图和模块说明)
模块设计原则
1、模块独立性
2、耦合度
软件工程知识点总结
阶段
任务
参与人员
产生文档
掌握内容
软件定义阶段——待开发软件要“做什么”
需求分析阶段
系统分析
确定待开发软件的总体要求和适用范围,以及与之有关的硬件、支撑软件的要求
用户、项目负责人、系统分析员
可合并项目计划书中
软件项目计划
软件工程笔记
软件工程笔记软件工程,作为一门致力于开发高质量软件的学科,涵盖了从需求分析到软件维护的整个生命周期。
它不仅需要掌握各种技术和工具,还需要具备良好的团队协作和项目管理能力。
接下来,就让我详细地聊聊软件工程的各个方面。
首先,需求分析是软件工程的第一步,也是最为关键的一步。
在这个阶段,我们需要与客户或者用户进行深入的沟通,了解他们的需求和期望。
这可不是一件简单的事情,因为用户往往并不能清晰地表达自己的需求,或者他们的需求可能会随着时间的推移而发生变化。
所以,我们需要通过各种方法,比如问卷调查、用户访谈、现场观察等,来挖掘出真正的需求。
而且,在需求分析的过程中,我们还要对需求进行优先级排序,区分出哪些是核心需求,哪些是次要需求,以便在后续的开发过程中合理分配资源。
有了明确的需求之后,就进入了软件设计阶段。
这个阶段就像是给软件搭建一个框架,决定了软件的整体结构和模块划分。
良好的软件设计应该具有高内聚、低耦合的特点,也就是说,每个模块内部的功能应该紧密相关,而模块之间的联系应该尽量简单。
这样可以提高软件的可维护性和可扩展性。
在设计阶段,我们还需要考虑软件的架构,比如是选择分层架构、微服务架构还是其他的架构模式。
同时,还要设计数据库结构、接口规范等。
接下来就是编码实现阶段了。
在这个阶段,开发人员根据设计文档,使用选定的编程语言和开发工具,将软件的功能逐步实现。
编码的过程中,要遵循良好的编程规范,保证代码的可读性、可维护性和可测试性。
而且,要注意代码的效率和安全性,避免出现常见的编程错误,比如内存泄漏、缓冲区溢出等。
软件测试是确保软件质量的重要环节。
测试可以分为单元测试、集成测试、系统测试和验收测试等不同的类型。
单元测试是对软件中的最小单元——函数或者模块进行测试,确保它们的功能正确。
集成测试则是测试各个模块之间的接口是否正常。
系统测试是在整个系统的层面上进行测试,验证软件是否满足需求规格说明书中的要求。
验收测试则是由用户或者客户来进行,确认软件是否符合他们的期望。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
高内聚和低耦合的要求。模块作用范围是否在其控制范围之内 l 风险:确认该设计在现有技术条件下和预算范围内是否能按时实现 l 实用性:确认该设计对于需求的解决方案是否实用 l 技术清晰度:确认该设计是否以一种易于翻译成代码的形式表达 l 可维护性:确认该设计是否考虑了方便未来的维护 l 质量:确认该设计是否表现出良好的质量特征 l 各种选择方案:看是否考虑过其它方案,比较各种选择方案的标准是什么 l 限制:评估对该软件的限制是否现实,是否与需求一致 l 其它具体问题:对于文档、可测试性、设计过程..等进行评估
模块的调用关系和接口:模块之间用单向箭头联结,箭头从调用模块指向被调用模 块,表示调用模块调用了被调用模块。
模块化原理 模块间的信息传递:当一个模块调用另一个模块时,调用模块把数据或控制信息传 送给被调用模块,以使被调用模块能够运行。而被调用模块在执行过程中又把它产生的 数据或控制信息回送给调用模块 抽象 概念:人们在实践中认识到,在现实世界中一定事物、状态或过程之间总存在着某 些相似的方面(共性)。把这些相似的地方集中和概括起来,暂时忽略它们之间的差异, 这就是抽象 抽象要求人们将注意力集中在某一层次上考虑问题,而忽略那些低层次的细节。使 用抽象技术便于人们用“问题域”本来的概念和术语描述问题,而无须过早地转换为那 些不熟悉的结构。软件设计过程应当是在不同抽象级别上考虑和处理问题的过程。 逐步求精 “逐步求精”是与“抽象”密切相关的一个概念,它由 N.Wirth提出,可视为一种 早期的自顶向下设计策略,其主要思想是:针对某个功能的宏观描述,用逐步求精的方 法不断地分解,逐步确立过程细节,直至该功能用程序语言描述的算法实现为止。 因为求精的每一步都是用更为详细的描述替代上一层次的抽象描述,所以在整个设 计过程中产生的、具有不同详细程度的各种描述,组成了系统的层次结构。层次结构的 上一层是下一层的抽象,下一层是上一层的求精。 信息隐藏 信息隐藏原理告诉我们,模块应该设计得使其所含信息> C(P2)
(a)
则
E(P1)>E(P2)
(b)
因为解决一个复杂问题总比解决一个简单问题耗时多。
同时,人类求解问题的实践同时揭示了另一个有趣的性质:
C(P1+P2)>C(P1)+C(P2)
(a)
即,由 P1、P2组合而成的问题的复杂性往往比考虑单个问题复杂性的和更大。由前
面两式可得
E(P1+P2)>E(P1)+E(P2)
n 周转时间 n 响应时间 n 吞吐量 n 精度 l 确定外部信号的接收发送形式 4) 数据结构设计 l 确定软件涉及的文件系统的结构以及数据库的模式、子模式,进行数据完整 性和安全性的设计 l 确定输入,输出文件的详细的数据结构 l 结合算法设计,确定算法所必需的逻辑数据结构及其操作 l 确定对逻辑数据结构所必需的那些操作的程序模块(软件包) l 限制和确定各个数据设计决策的影响范围 l 若需要与操作系统或调度程序接口所必须的控制表等数据时,确定其详细的 数据结构和使用规则 l 数据的保护性设计 防卫性设计:在软件设计中就插入自动检错,报错和纠错的功能 l 一致性设计:
模块之间耦合性越强,功能独立性越差,这样形成的模块结构界面不好。 非直接耦合(NondirectCoupling) 两个模块之间没有直接关系,它们之间的联系完全是通过主模块的控制和调用来实 现的。 非直接耦合的模块独立性最强。
软件工程—学习笔记五
数据耦合 (DataCoupling) 一个模块访问另一个模块时,彼此之间是通过简单数据参数 (不是控制参数、公共 数据结构或外部变量) 来交换输入、输出信息的。
(b)
即一个复杂问题分割成若干个容易解决、容易管理的小问题后更易于求解,模块化
正是以此为依据。但这是否就意味着我们可以把软件无限制地细分下去,从而使所需工
作量越来越少呢?如果无限地分割软件,最后为了开发软件所需要的工作量也就小得可
以忽略了。但事实上,当分割过度后其它因素将开始发挥作用
软件工程—学习笔记五
软件工程—学习笔记五
正。在软件开发的一开始就要确定软件可靠性和其它质量指标,考虑相应措施,以使得 软件易于修改和易于维护
6) 编写概要设计阶段的文档 概要设计阶段完成时应编写以下文档:
l 概要设计说明书 l 数据库设计说明书 l 用户手册 l 制定初步的测试计划 7) 概要设计评审 l 可追溯性:确认该设计是否复盖了所有已确定的软件需求,软件每一成份是
配备下列 4份资料:
l 系统流程图
l 组成系统的物理元素清单
l 成本/效益分析
l 进度计划
选择最佳方案并制定详细的实现计划
2)结构设计 —— 模块化思想:
将 DFD细化,至每个子功能都明白易懂;每个模块完成一个子功能;每层模块合成
一个高一级的功能。
主要工具有 SystemDesignHierarchy及 HIPO图等。
软件工程—学习笔记五
保证软件运行过程中所使用的数据的类型和取值范围不变 在并发处理过程中使用封锁和解除封锁机制保持数据不被破坏 l 冗余性设计:针对同一问题,由两个开发者采用不同的程序设计风格不同的 算法设计软件,当两者运行结果之差不在允许范围内时,利用检错系统予以 纠正,或使用表决技术决定一个正确结果。
2.总体设计的概念和原理 2.1总体设计 从回答“做什么”到回答“怎样做” 划分出组成系统的物理元素——程序、文件、数据库、过程和文档等等 每个元素还是黑盒子 ---“全局高度,抽象层次” 2.2软件结构和过程 结构 l 树状结构 l 网状结构 程序结构 程序结构表明了程序各个部件(模块)的组织情况,是软件的过程表示。
3)数据库设计
4)测试计划
5)文档、审查
2.3模块化
模块(Module)
“模块”,又称“组件”。它一般具有如下三个基本属性:
功能:描述该模块实现什么功能
逻辑:描述模块内部怎么做
状态:该模块使用时的环境和条件
假设函数 C(X)定义了问题 X已被觉察到的复杂性,函数 E(X)定义了求解问题 X所要
求的工作量(按时间计),对于问题 P1和 P2,如果
软件工程—学习笔记五
主 题: 《软件工程》学习笔记 内 容:
《软件工程》学习笔记五
——总体设计
从工程管理的角度看,软件设计可分为概要(preliminary)设计/总体设计和详细 (detail)设计两大步骤。概要设计是根据需求确定软件和数据的总体框架,详细设计 是将其进一步精化成软件的算法表示和数据结构。
从技术角度来看,软件设计可分为数据设计、系统结构设计和过程设计。现在越来 越多地把界面设计也单独取出来作为一个方面。数据设计把分析阶段建立的信息描述转 换为实现软件所要求的数据结构,侧重于数据结构的定义;系统结构设计定义软件系统 各主要部件、成分之间的关系,过程设计则是把结构成分转换成软件的过程性描述即完 成每一部件的过程化描述。在编码步骤,根据这种过程性描述,生成源程序代码,然后 通过测试最终得到完整有效的软件。在设计阶段所做的种种决策直接影响软件的质量, 没有好的设计,就没有稳定的系统,也不会有易维护的软件。
局部化 所谓局部化是指把一些关系密切的软件元素物理地放得彼此靠近。在模块中使用局 部数据元素就是局部化的一个例子。显然,局部化有助于实现信息隐藏。 模块独立 如果说,一个模块在不需要另一个模块的情况下,能够完整地执行其功能,我们就 称这两个模块是完全独立的。模块独立性的概念是模块化、抽象和信息隐藏概念的直接 产物,模块独立性是通过开发具有单一功能和与其他模块没有过多交互作用的模块来达 到的。完全独立的模块是无所谓构成系统的。 模块独立性可用两个定量准则来度量:耦合(coupling)和内聚(cohesion)。耦合 是模块之间相对独立性的量度,而内聚则是模块功能相对强度的量度。 模块化--功能独立性(模块独立) 功能独立性是抽象、模块化和信息隐蔽的直接产物。如果一个模块能够独立于其他 模块被编程、测试和修改,则该模块具有功能独立性。 1978年 Myers提出用两个准则来度量功能独立性,即模块间的耦合和模块的内聚。 内聚性:内聚是一个模块内部各个元素彼此结合的紧密程度的度量。 耦合性: 耦合是模块间互相连接的紧密程度的度量,它取决于各个模块之间接口 的复杂度、调用方式以及哪些信息通过接口。 模块化--耦合
软件工程—学习笔记五
软件设计过程 1) 制定规范 在进入软件开发阶段之初,首先应为软件开发组制定在设计时应该共同遵守的标准, 以便协调组内各成员的工作。包括:
l 阅读和理解软件需求说明书,确认用户要求能否实现,明确实现的条件,从 而确定设计的目标,以及它们的优先顺序
l 根据目标确定最合适的设计方法 l 规定设计文档的编制标准 l 规定编码的信息形式,与硬件,操作系统的接口规约,命名规则 2) 软件系统结构的总体设计 基于功能层次结构建立系统。 l 采用某种设计方法,将系统按功能划分成模块的层次结构 l 确定每个模块的功能 l 建立与已确定的软件需求的对应关系 l 确定模块间的调用关系 l 确定模块间的接口 l 评估模块划分的质量 3) 处理方式设计 l 确定为实现系统的功能需求所必需的算法,评估算法的性能 l 确定为满足系统的性能需求所必需的算法和模块间的控制方式
开发阶段的信息流 软件设计的意义 软件设计是后续开发步骤及软件维护工作的基础。如果没有设计,只能建立一个不 稳定的系统结构 从工程管理的角度来看,软件设计分两步完成。 l 概要设计,将软件需求转化为数据结构和软件的系统结构。 l 详细设计,即过程设计。通过对结构表示进行细化,得到软件的详细的数据结
构和算法。
标记耦合 (StampCoupling) 一组模块通过参数表传递记录信息,就是标记耦合。这个记录是某一数据结构的子 结构,而不是简单变量。
控制耦合 (ControlCoupling) 如果一个模块通过传送开关、标志、名字等控制参数,明显地控制选择另一模块的 功能,就是控制耦合。