软件工程结构化建模的方法和工具_软件工程概述(遥感院童鞋自取)

l 时序图:用来为系统各部分之间的交互建模,包括一些外部因素,表示在特定用例中的交互顺序

5.3 结构模型

l 表示系统的构成,表示为组件构成系统以及组件之间的关系

l 类图:表示系统中的类和这些类之间的关联

l 泛化:对类的所有成员给出一般性描述

l 聚合:显示对象类是如何由其他对象组合而成,类似于部分-整体关系

l 状态机模型是一种描述系统对内部或外部事件响应的行为模型

l 适合用来描述实时系统,因为这类系统多由外界环境刺激而驱动

l 状态机模型用节点表示系统状态,用节点之间的弧来表示事件

l 状态图:它允许将一个模型分解成多个子模型

l 为了描述系统内部或外部事件的发生/响应行为,需要使用状态机模型

1. 描述系统状态和事件

2. 描述事件引发的系统状态及状态间的转换

3. 但不描述系统中数据的流动

l 圆角矩形:代表系统状态;带标识箭头:表示状态转换;实心圆:状态始末

l 清晰结构的三个好处:1.信息持有者之间的沟通;2.系统分析;3.大规模复用

l 体系结构设计取决于开发系统的类型,但都有一些共同决策阶段

l 体系结构风格和结构依赖于非功能性系统需求:1.性能;2.信息安全性;3.安全性;4.可用性;5.可维护性

l 体系结构之间的冲突:

1. 使用大粒度组件虽然改进了系统的性能,但是降低了可维护性

2. 引入冗余性数据提高系统可用性,但使得系统信息安全性降低

3. 定位与安全相关的操作意味着增加了子系统之间的通信,但降低了系统性能

6.1 系统结构视图

l 概念视图:系统的高层抽象视图,给出系统本质内容

l 逻辑视图:显示系统中对象、对象类的抽象,通过该视图可将系统需求和实体关联

l 进程视图:显示系统运行时一组交互的进程,对于分析系统非功能特性很有效

l 开发视图:显示软件如何为了开发被分解,即将系统分解成组件

l 物理视图:即部署图,显示了系统硬件软件组件如何分布在处理器上

6.2 体系结构模式

l 体系结构风格是构造的一种模式,是描述某一特定应用域中系统组织方式的惯用模式,是对好的实践经验所做出的格式化抽象描述

l 体系结构模式就是模式思想:作为一种表示、共享和复用软件系统知识的方法

l MVC模式是构建基于web应用系统体系结构的基础。模型管理系统数据及其操作;视图管理显示数据;控制器管理用户交互

l 研究体系结构风格的意义:

1. 有利于发现不同系统在较高级别上的共同特性

2. 对体系结构的了解,使得在设计软件结构时选择合适的模式

3. 使用常用的、规范的模式来组织结构,使别的设计者易于理解,便于交流

4. 有利于较高级别上的软件复用

l 分层体系结构:用来把系统组织成一系列层次,支持增量式开发;当一层接口改变,只有毗邻层受到影响。该模式是实现分离性和独立性的另一个方式

4. 优点:1.支持基于抽象程度递增的系统设计;2.具有较好的可扩展性;3.支持软件复用

5. 缺点:并不是所有系统都会清晰分层,高层可能直接同底层交互,从而影响性能

l 容器体系结构:一个基于共享数据库的系统模型。是由一个子系统产生而由其他子系统使用的情形

6. 优点:1.是共享大量数据的一个高效方法;2.共享模型能通过容器模式看见;3.组件是独立的

7. 缺点:1.子系统一定要与容器数据模型一致;2.容器模型迫使所有子系统使用相同策略;3.很难将容器有效分配到多台机器上

l 客户机-服务器体系结构:是分布式系统运行时的组织,主要由服务器、客户机、 络构成

8. 优点:1.数据分布最直接;2.服务器可以分布到 络上;3.很容易就添加一台新服务器或更新现有服务器

9. 缺点:1.没有共享数据模型,数据交换效率无可预知;2.没有中央寄存器的名字和服务。很难找出哪个服务器和哪些服务可用;3.每个服务器上出现冗余数据管理

l 管道和过滤器体系结构:一个系统运行时组织的模型,函数转换处理输入并产生输出,数据从一个处理单元流到另一个,每经过一个单元做一次变换。转换可以串行也可以并行。系统运行时组织的模型,可以看作是对相继输入数据的一系列变换。组件称为过滤器,数据流通路称为管道

10. 优点:1.没有复杂的组件交互;2.支持软件复用;3.易于维护;4.支持并行

11. 缺点:适用批处理方式

6.3 应用体系结构

l 应用体系结构通用模型(封装了该类系统的基本特征),能帮助我们较好地进行应用系统设计,通过比较相同类型的应用,达到模型或大粒度组件的复用,并能验证应用系统设计的有效性

l 分类:

12. 1.事务处理应用(事务是为了达到某个目标的相关操作序列,事务处理系统用来处理用户对数据库的查询或请求,并更新数据库):以数据库为中心;【1.表示层:Web服务器负责对所有用户通信;2.应用逻辑层:应用服务器负责实现与应用有关的逻辑;3.数据层:数据库服务器负责管理数据的存入和检出】

13. 2.语言处理系统:用形式化语言来表达

第七章 设计与实现

l 一个系统中,对象是实体,表示真实世界中的实例,对象类是对象的模板,可以创建对象,对象类可以继承其他对象类的属性和服务

l 面向对象的分析:功能模型;面向对象的设计:解决方案;面向对象的程序设计:软件设计

l 对象是现实世界或者系统实体的抽象;对象是独立的;系统的功能表达为对象服务;对象通过信息传递进行通信;对象可能是分布式的

l 优点:易维护、易复用、易拓展

7.1 使用UML的面向对象设计

l UML是面向对象建模的一个标准

l 由概念设计转变为详细设计,需要完成以下几点:

1. 了解并定义上下文和系统的外部交互(系统上下文模型;系统时序模型)(用例模型代表与系统的每个交互)

2. 设计系统体系结构

3. 识别出系统中的主要对象(最难部分;迭代的过程)(对自然语言描述做文法分析、使用领域中的真实实体等、使用基于脚本的分析、使用行为方法)

4. 开发设计模型 (对系统中包含的对象或对象类以及它们之间的不同类型关系描述)(子系统模型、序列模型、状态机模型、其他模型)

5. 定义对象接口(将具体的接口实现方法隐藏起来)

7.2 设计模式

l 模式:对问题和解决方案基本内容的描述(名字、问题域的描述、对部分设计的解决方案描述、结果陈述)

7.3 实现问题

l 复用:抽象层(运用软件设计中的成功抽象)、对象层(直接复用库中对象)、组件层(增加自己的代码对组件进行调整和扩展)、系统层(复用整个应用系统)

l 配置管理:版本管理(对组件不同版本追踪提供支持)、系统集成(提供支持帮助开发人员定义在创建每个系统版本时所用的组件版本)、问题追踪(允许客户 告缺陷)

l 宿主机-目标机开发:软件在一台计算机开发,在另一台计算机中运行

7.4 开源开发

第八章 软件测试

l 有效性测试、缺陷测试(只能证明存在错误,不能证明不存在)

l 检验和有效性测试的区别:前者是一般过程,确保满足用户期望;后者是审查软件满足它所规定的功能和非功能性需求

l 软件审查:审查系统需求、设计模型、程序源代码,是静态过程;软件测试:动态过程

l 软件审查的优势:可以发现系统的多个错误,也可以考虑程序的质量属性,审查不完整版本不需要额外代价,比测试更有效地发现缺陷

l 软件审查的不足:难以发现1.由于程序间未预料到的交互造成的 2.时序问题产生的 3.系统性能问题造成的 问题

l 程序测试:可以揭示错误的地方;通过执行软件来观察其行为;应与静态检验联合

l 调试:错误出现的地方和如何改正错误

l 定义了在选择系统测试中使用的方法:

1. 所有的能从菜单中得到的系统功能都应该被测试到

2. 可以从同一菜单中访问的组合功能需要被测试

3. 提供用户输入的地方,所有功能都必须用正确和不正确的输入进行测试

l 三个阶段:开发测试、发布测试、用户测试

8.1 开发测试

l A.单元测试:1.测试与对象相关的所有操作;2.设置和检查与对象相关的属性;3.让对象处于所有可能的状态下

n 泛化或继承让对象类测试更困难原因是要测试的数据没有被定位

n 自动化测试的三部分:准备部分、调用部分、断言部分

n 单元测试案例的有效性

? 划分测试:识别具有共同特性和以相同方法处理的一组数据

14. ? 程序的输入数据和输出结果总是落在几个不同类中,这些类中的数据有公共特征

15. ? 由于类中成员的这些等价行为,这些类通常叫做等价划分或者域

16. ? 测试用例应从每个划分中选择

? 基于准则测试:使用测试准则来选择测试案例。当测试带有序列、数组或是链表的程序时,有多个准则可以揭露缺陷

1. 选择能够迫使系统产生所有错误信息的输入

2. 设计能够使系统的输入缓冲溢出的输入

17. 3. 重复相同的输入或一系列输入很多次

18. 4. 迫使产生无效的输出

19. 5. 迫使输出结果太大或太小

l B.组件测试:通常有许多彼此交互的对象组合的符合组件,首先关心的是组件接口行为是否符合描述

n 接口测试:目标是为了检测由于接口的错误或无效的接口假设所造成的故障

n 接口类型:1.参数接口、共享内存接口、程序接口、消息传递接口

n 接口错误:接口误用、接口误解、时序错误

n 接口测试准则:

1. 检查要测试的代码并明确列出对外部组件的每个调用

2. 当有指针从接口传递时,总用空指针参数来测试接口

3. 当通过程序接口调用组件时,设计一些容易引起组件失败的测试

4. 在消息传递系统中进行强度测试

5. 当组件间通过共享内存交互时,可以设计一种测试,使其对激活组件的次序有所改变

6. 审查和复查有时比发现接口错误的测试更有效

l C.系统测试:包括组件继承后的系统或子系统,两个阶段:集成测试、发布测试,注重交互

n 集成测试:从组件建立系统和对合成的系统进行测试,发现组件交互引起的问题

n 系统测试策略:

1. 所有的能从菜单中得到的系统功能都应该被测试到

2. 可以从同一菜单中访问的组合功能需要被测试

3. 提供用户输入的地方,所有功能都必须用正确和不正确的输入进行测试

c2700ab4-3d13-eb11-8da9-e4434bdf6706.png

n 黑盒测试:把测试对象看作一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明

n 白盒测试:此方法把测试对象看作一个透明的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试

8.2 测试驱动开发

l 是一种程序开发方法,交错地进行测试和代码开发

l 步骤:

1. 从识别所需要的功能增量开始

2. 针对此功能编写一个测试并实现为一个自动测试

3. 运行此测试,以及所有已实现的其他测试

4. 实现这个功能,并重新运行这个测试

5. 一旦所有的测试成功,转去实现下一个功能模块

l 优势:便于理解、代码覆盖、回归测试、简化调试、系统文档

8.3 发布测试

l 发布测试:是对将要分发给用户的系统版本的测试过程

l 一般使黑盒测试或者是功能测试

l 基于需求的测试:有效性验证测试而非缺陷测试

l 情景测试:也叫脚本测试、场景测试,将用户和工作联系起来

l 性能测试:释放测试的部分可能涉及测试系统的重要属性,保证系统可以处理预期负荷

8.4 用户测试

l α测试:软件的用户和开发小组一起在开发者的地点测试软件

l β测试:该软件的版本提供给用户让他们进行试验,并向开发者提出所发现的问题

l 接收测试:客户测试系统,以决定他们是否愿意从系统开发者那里接收系统

第九章 软件进化

l 软件的开发不会因为系统的交付而停止,它贯穿于系统的整个生命周期

9.1 进化过程

l 软件变更是不可避免的(用户需求改变,运行环境变化,软件错误 告,硬件变更,性能提升)

l 软件移交之后的变更过程被称为软件维护

l 软件工程是一个贯穿于系统生命周期的由需求、设计、实现、测试、运行组成的螺旋过程

l 进化:涉及软件体系结构和功能性重大改变的阶段;服务:对软件做一些小的和必不可少的改变;淘汰:软件仍在使用但不会有进一步改动

l 变更建议驱动系统进化

l 迭代开发过程中完成对系统涉及的修改、实现、测试

l 紧急修补:紧急变更的实现不需要经历软件工程的所有阶段

  1. 如果有严重的系统缺陷发生,那么必须修补
  2. 如果系统操作环境的变更中有不期望的情况发生
  3. 如果系统上运行的业务有未预料的改变发生

9.2 程序进化动态特性

l Lehman定律的内容

1. ? 第1条:系统维护是一个不可避免的过程

2. ? 第2条:随着系统的改变,其结构在退化

3. ? 第3条:大型系统自身的动态特性是在开发过程的早期阶段建立的

4. ? 第4条:绝大多数大型程序设计项目是在一种称之为“饱和”状态下运作的

5. ? 第5条:关于在每个系统版本中的变更增量

6. ? 第6条、第7条:软件用户将变得愈加的不满意,除非软件得到维护并且有新功能加入进来

7. ? 第8条:反馈过程

l Lehman定律适用于大型组织开发大型、定制软件

9.3 软件维护

l 软件交付后变更软件的过程称为软件维护

1. 纠正性维护:修补软件缺陷

2. 适应性维护:使软件适应不同操作环境

3. 完善性维护:增加或修改系统功能

l 对于业务应用系统,维护成本和系统开发成本大体相等。对于嵌入式实时系统,维护费用是开发成本的四倍以上

l 变更预测:预测变更请求的数目需要了解系统和外部环境之间的关系。影响这个关系的因素有:

1. 系统接口的数目和复杂性

2. 固有的易变性系统需求数目

3. 系统所处的业务过程

l 可维护性度量:

1. 请求纠正性维护的数目

2. 作用分析所需的平均时间:反映受变更请求影响的程序组件数目

3. 实现一个变更请求的平均时间:取决于程序设计的难易程度

4. 突出的变更请求的数目

l 软件再工程:

? 重组,或重写一部分或全部的遗留系统而不变更其功能

? 适用于大型系统中需要频繁维护的子系统

? 系统再工程使得系统更易于维护

? 优势:较小的风险和成本

  1. 源代码转换:使用工具将语言转换成相同语言新版本或另一种语言
  2. 逆向工程:从源代码中抽取系统的说明和设计信息,把这种信息求精与简化以备用
  3. 程序结构改善:对控制结构进行分析和修改,提高可读性
  4. 程序模块化:可能涉及到体系结构的重构
  5. 数据再工程:对数据及其结构进行分析重组

l 再工程和重构的区别:再工程发生在系统已经维护了一段时间并且维护费用不断上升的情况下;重构是一个连续不断的改进过程

l 可通过重构被改进的情况:1.冗余代码;2.长方法;3.选择语句;4.数据聚集;5.假设的一般性

9.4 遗留系统管理

l 对遗留系统的四种基本选择:1.彻底抛弃这个系统;2.继续维护这个系统;3.对系统再工程以改善这个系统;4.以一个新的系统代替整个或部分系统

l 系统业务价值评估要考虑:1.系统的使用;2.支持的业务流程;3.系统可靠性;4.系统的输出

l 评估应用系统技术质量:1.请求系统变更的数目;2.用户界面数目;3.系统使用的数据量

其他内容

1.项目管理

l 目标:按时交付、成本控制、满足用户要求、好的团队

l 软件工程与其他工程的不同 1. 软件产品是无形的2. 大型软件常常是一次性的项目 3. 软件开发过程是可变的和机构特定的

l 风险管理:种类:项目风险、产品风险、业务风险;过程:风险识别、分析、规划、监控(最重要)

l 人员管理:一致性、尊重、包容、诚实

l 要点:?

n 软件项目管理是必要的 ?

n 软件项目管理与其他工程管理的区别 ?

n 风险管理是项目管理最重要的任务之一 ?

n 开发小组不宜太大而且要有凝聚力 ?

n 小组内部沟通受到多种因素影响

2.项目规划

l 软件成本组成部分:1.硬件软件费用2.差旅费和培训费3.工作成本4.管理费用

l 计划驱动开发:基于计划的开发,给开发过程制定详细计划(项目计划和项目规划)

l 进度安排:决定如何组织项目工作,将其分为单独任务,并何时何方式完成项目的过程

l 要点

n 系统 价并不仅仅取决于它的估计开发成本和开发公司要求的利润。机构因素可能提高售价以补偿升高的风险,或者降低售价以获得竞争的优势

n 软件通常是先有定价以得到合同,然后再据此调整相应的功能 ?

n 计划驱动开发是围绕一个详细定义的项目计划进行组织的 ?

n 项目进度安排需要创建有关项目计划的各种图形化表示

3.质量管理

l 质量:产品必须符合其描述

l 软件质量管理:关心一个软件产品是否达到需要的质量水平(确定适当的质量标准和程序)

l 质量管理范围:质量文档和质量文化

l 质量管理活动:1.质量保证2.质量规划3.质量控制(质量管理和项目管理应该分开)

l 过程和产品质量:开发过程的质量直接影响了交付产品的质量;因某些质量属性难以评估,所以这十分重要;过程质量和产品质量的关系十分复杂和难以理解

l 质量规划:列出了所需的产品品质以及如何达到这些品质要求,同时确定最重要的质量属性(质量规划应定义质量评估过程)

l 质量规划结构:1. 产品介绍 2. 产品计划 3. 过程描述 4. 质量目标 5. 风险和风险管理

l 质量控制:包括监督检查整个软件开发过程(质量评审、自动化的软件评估)

l 质量评审:是验证一个过程或产品指令最广泛的方法(设计或程序检查 (产品) 过程审查 (产品和过程) 质量审查 (产品和标准))

l 质量审查:目标是发现系统中错误和不一致的地方,所有文档都有被审查到

l 审查结果:审查过程中的所有意见都应分类(1. 不采取行动2. 参照修理3. 重新考虑整体设计)

l 标准是有效地进行质量管理的关键

n 产品标准:用于待开发的所有组件,如文档标准等

n 过程标准:定义了软件开发必须遵循的过程

l 标准的重要性:

1. 软件标准封装了最成功至少是最恰当的软件开发经验

2. 软件标准提供了一个框架,围绕这个框架才能实现质量保证过程

3. 软件标准还有助于工作的连贯性,由一个人着手进行的工作,别人可以接着做

l 存在的问题:

1. 在软件工程师看来,它们可能是不相关或不是最新的

2. 它们往往涉及太多的形式化内容

3. 如果软件工具不支持这些标准,那么为了能使文档和标准联系起来,则需要繁琐的手工劳动

l 标准开发:1.软件工程人员参与产品标准的选择 2.定期评审和修改标准,以反映技术的变化 3.尽可能提供支持软件标准的软件工具

l 文档化标准:1. 文档过程标准2. 文档标准3. 文档转换标准

l 文档标准:1. 文档标识标准2. 文档结构标准3. 文档书写标准4. 文档更新标准

l 文档转化标准:交换标准允许电子文件间的转换和邮发等

l 复查和审查:复查与审查是检查项目可交付文档质量的互动

l 软件度量:量是对软件产品或过程的某种属性进行量化

l 软件量度是能够被客观度量的软件系统、系统文档或开发过程有关的特性,包括控制量度(支持过程管理)和预言者量度(帮助预测软件特性)

4.配置管理

l 配置管理关注的是管理不断变化的软件系统,配置管理有时候被看做是软件质量管理过程的一部分

1. 变更管理 ? 包括跟踪来自客户和开发者的软件变更请求,计算做出这些变更的花费并估计其影响,决定是否变更、何时完成变更

2. 版本管理 ? 包括跟踪系统组件的多个版本,确保由不同开发者对组件做出的变更不会彼此干涉

3. 系统构建 ? 是一个组装程序组件、数据和库的过程,然后把这些组件编译链接成一个可执行系统

4. 发布管理 ? 包括准备对外发布的软件,持续跟踪已经发布以供客户使用的系统版本

l 配置管理(CM)应始终基于组织内部应用标准,标准应基于外部配置管理标准

l 配置项识别:大型项目中可能包含数以千计的文档,它们的配置中一定要唯一标识(分层命名规则)

配置数据库:所有的CM信息都要存储CM数据库中,配置数据库必须能够对各种系统配置查询做出应

相关资源:优优-群化软件5.6.rar-互联 文档类资源-CSDN文库

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2020年9月19日
下一篇 2020年9月19日

相关推荐