文章目录
- 六、软件设计
-
- 1、目标
- 2、软件设计过程
-
- 概要设计
-
- 动态结构设计
- 静态结构设计
- 详细设计
- 3、软件设计模型
- 4、模块内聚性
- 5、模块耦合性
- 6、面向对象的设计原则
-
- 单一职责(Single Responsibility)
- 开闭原则(Open Closed)
- 里氏替换原则(Liskov Substitution)
- 依赖倒置原则(Dependency Inversion)
- 接口隔离原则(Interface Segregation)
- 组合/聚合复用(Composite/Aggregation Reuse)
- 迪米特法则(Law of Demeter)
- 7、软件设计基础
- 七、面向对象设计
-
- 1、综述
- 2、软件的层次化结构
- 3、类职责分配(Grasp)模式
-
- 控制器(Controller)模式
-
- 指导原则
- 创建者(Creator)模式
- 信息专家(Information Expert)模式
- 八、结构化软件设计
-
- 1、系统功能结构图
-
- 基本结构
- 变换型结构
- 事务型结构
- 变换-事务混合型结构
- 确定系统边界
- 2、变换映射
- 3、事务映射
- 4、详细设计
-
- 程序流程图
- N-S图
- PAD图
- 判定表
- 九、软件测试
-
- 1、软件测试的目的和原则
-
- 目的
- 原则
- 软件测试对象
- 流程
- 软件测试与各阶段关系
- 2、测试方法
-
- 白盒测试
-
- 逻辑覆盖
- 程序控制流图
-
- 举例
- 黑盒测试
-
- 等价类划分
-
- 举例
- 边界值分析
- 因果图
-
- 举例
- 3、软件测试基本类型
- 十、剩余章节
-
- 1、软件维护
-
- 定义
- 分类
- 软件维护的活动
- 2、软件项目管理
-
- 定义
- 项目管理过程
六、软件设计
1、目标
- 根据软件需求分析的结果,设想并设计软件,即根据“目标系统”的逻辑模型确定“目标系统”的物理模型,概括地描述系统如何实现用户所提出来的功能和性能等方面的需求。
- 软件设计是软件开发的基础和依据,是软件工程过程中的技术核心。
- 软件设计的最终目标是要取得最佳方案(Best Solution,主观)。
- “最佳”是指在所有候选方案中,就节省开发费用,降低资源消耗,缩短开发时间的条件,选择具有较高的生产率、较高的可靠性和可维护性的方案。
2、软件设计过程
软件设计是一个把软件需求变换成包含软件功能模型、数据模型以及行为模型的过程,分为概要设计和详细设计。
- 系统结构设计:定义了软件系统各主要元素(主要指功能模块)之间的关系,其中包括软件的模块接口设计;
- 数据设计:将软件各模块所需要处理的数据以及系统需要长久保存的数据进行数据结构和数据存储的设计;
- 过程设计:主要是确定各功能模块内部结构的详细定义,包括模块主要算法逻辑和局部数据结构的定义。
概要设计
概要设计:只需描绘出可直接反映功能、数据、行为需求的软件总体框架。
动态结构设计
- 用例实现过程设计,针对用例对应的 SSD 中的每个系统事件,运用 UML 的顺序图 / 协作图给出符合该系统事件定义的操作契约的内容;
- 如果软件对象具有多种不同的职责(主要考虑对应于不同的用例)的情况下,需要运用状态图对该软件对象进行状态迁移的设计。
静态结构设计
- 对所有用例或者子系统级别的用例的交互图进行归纳,运用 UML 的类图给出系统的静态结构。
详细设计
详细设计:即过程设计,通过对软件结构进行细化,得到各功能模块的详细数据结构和算法,使得功能模块在细节上非常接近于源程序的软件设计模型。
3、软件设计模型
由两个部分构成:
-
动态结构设计:以某种方式表示功能响应客户请求时处理数据的过程或条件,用于进一步解释软件结构中各功能之间是如何协调工作的机制。
-
静态结构设计:由软件的功能结构和数据结构组成,展示软件系统能够满足所有需求的框架结构。
4、模块内聚性
信息隐藏:每个模块的实现细节对于其他模块来说是隐藏的。就是说,模块中所包含的信息(包括数据和过程)不允许其他不需要这些信息的模块使用。
内聚是模块功能强度的度量,一个模块内部各元素之间的联系越紧密,则它的内聚性就越高,相对地,它与其他模块之间的耦合性就会减低,而模块独立性就越强。
- 巧合内聚
- 逻辑内聚
- 时间内聚(经典内聚)
- 过程内聚
- 通信内聚
- 信息内聚
- 功能内聚
降低耦合性的方法:
- 模块间多传递数据信息,尽量减少和避免传送控制信息。
- 降低模块接口的复杂性。
- 减少接口信息传送数量。
- 以系统调用方式(或 call 方式)代替直接引用。
- 传送信息的结构尽量简单(或以数据耦合代替标记耦合)。
- 把模块的通信信息放在缓冲区中。
6、面向对象的设计原则
单一职责(Single Responsibility)
定义:针对类,应该只有一个引起它变化的原因,“职责”定义为变化的原因
- 如果有其他原因去改变一个类,那么这个类就具有其他的职责。类具有多个职责,等于这些职责具有耦合关系。
- 为了提高类的内聚度,应将对象的不同职责分离至两个或多个类中,确保引起该类变化的原因只有一个。
开闭原则(Open Closed)
软件实体(类、模块、函数)可以扩展,但不能修改。
- 对于扩展是开放的(Open 4 extension),需求改变时,对实体进行扩展。
- 对于更改是封闭的(Closed 4 modification),需求改变时,禁止对原来的代码进行修改。
- 实现 OCP 的关键是使用抽象,识别不同类之间的共性和变化点,利用封装对变化点进行处理
里氏替换原则(Liskov Substitution)
子类应当可以替换父类并出现在父类能够出现的任何地方
组合/聚合复用(Composite/Aggregation Reuse)
在一个新对象里面使用一些已有对象,使之成为新对象的一部分;新对象通过向已有对象委托(delegate)一部分责任而达到复用已有对象的目的。
迪米特法则(Law of Demeter)
- 最少知识原则:一个对象应当可能少的了解其它对象。
- 只与你直接的朋友们通信,不要跟“陌生人”说话。
- 符合以下特征的属于朋友:
- 当前对象本身(this);
- 以参量形式传入到当前对象方法中的对象;
- 当前对象的实例变量直接引用的对象;
- 当前对象的实例变量如果是一个聚集,那么聚集中的元素也都是朋友;
- 当前对象所创建的对象。
7、软件设计基础
- 自顶向下,逐步细化
- 系统控制结构
- 结构划分和结构图
- 数据结构
- 软件过程
七、面向对象设计
1、综述
模块层次化好处:增加软件的健壮性,易于扩展和维护;增加软件的可移植性。
3、类职责分配(Grasp)模式
-
核心逻辑由领域模型中的概念类转换而来
-
另一部分则是为实现而新增的一些类,如负责对象持久化的类、负责通信的类。
核心思想:每一个设计类都有明确的职责
- 自己干自己的事:
- 对象要了解自己私有的封装数据;
- 了解相关联的对象;
- 了解能够派生或者计算的事物。
- 自己干自己能干的事:
- 对象自身要能执行一些行为,如创建一个对象或者进行计算;
- 对象要能启动其他对象中的动作;
- 对象要能控制或协调其他对象中的活动。
- 自己只干自己的事(职责的内聚)
面向对象的设计模式
- 对象的职责通过调用对象的方法来实现。将职责分配给一个对象还是多个对象,是分配给一个方法还是多个方法要受到职责粒度的影响。
- 面向对象设计最关键的活动是正确地给对象分配职责。
- 模式是面向对象软件的设计经验,是可重用的设计思想,它描述了在特定环境中反复出现的一类设计问题,并提供经过实践检验的解决这类问题的通用模式。
- 模式定义了一组相互协作的类,包括类的职责和类之间的交互方式。
控制器(Controller)模式
解决方案:把接收和处理系统事件的职责分配给位于控制器层的对象
-
它代表整个系统(系统简单且不复杂),称为外观(facade)控制器;
-
它代表一个发生系统事件的用例场景,这个类通常命名为 “控制器”,称为用例控制器或者会话控制器。
-
在相同的用例场景中使用同一个控制器类处理所有的系统事件;
-
一次会话是与一个参与者进行交谈的一个实例。
指导原则
- 当一个系统不具有“太多”的系统事件,或者用户接口不可能将事件消息重定向到其他控制器时,选择外观控制器是合适的。这时,外观控制器相当于一个应用的封面,隔离了用户接口和应用逻辑。
- 如果外观控制器由于职责过多而变得“臃肿”的时候,应该选择用例控制器。
- 如果选择了用例控制器,那么每一个用例都有一个不同的控制类,而且只有一个,以便维护用例的状态。用例控制器可以实现有一定执行顺序的系统操作。
- 不论是外观控制器还是用例控制器,它们只是接收系统事件消息,并没有实现系统操作的职责,系统操作应该委托给领域对象处理。
创建者(Creator)模式
如果符合下面的一个或者多个条件,则可将创建类A实例的职责分配给类B(B创建A)。
-
B聚合(aggregate)或包含(contain)对象A;
-
B记录(record)对象A;
-
B密切使用对象A;
-
B拥有创建对象A所需要的初始化数据(B是创建对象A的信息专家)。
创建者模式体现了低耦合的设计思想,是对迪米特法则的具体运用。
信息专家(Information Expert)模式
给对象分配职责的通用原则:将职责分配给拥有履行职责所必需信息的类,即信息专家。换言之,对象具有处理自己拥有信息的职责或能力。
根据信息专家模式,应该找到拥有履行职责所必须的信息的类,选取类的方法:
-
如果在设计模型中存在相关的类,先到设计模型中查看;
-
如果在设计模型中不存在相关的类,则到领域模型中查看,试着应用或扩展领域模型,得出相应的设计类。
职责的实现(即功能)需要信息,而信息往往分布在不同的对象中,一个任务可能需要多个对象(信息专家)协作来完成。
八、结构化软件设计
1、系统功能结构图
基本结构
四种模块
-
传入模块 :从下属模块取得数据,经过某些处理,再将其传送给上级模块。
-
传出模块 :从上级模块获得数据,进行某些处理,再将其传送给下属模块。
-
变换模块 :即加工模块。它从上级模块取得数据,进行处理,转换成其它形式,再传送回上级模块。
-
协调模块 :对所有下属模块进行协调和管理的模块。
事务是最小的工作单元,不论成功与否都作为一个整体进行工作。
3、事务映射
对于下图,以 I 为中心或以 O 为中心,都是事务型结构。
4、详细设计
从软件开发的工程化观点来看,在编制程序以前,需要对所采用算法的逻辑关系进行分析,设计出全部必要的过程细节,并给予清晰的表达,使之成为编码的依据,这就是详细设计的任务。
程序流程图
为使用流程图描述结构化程序,必须限制流程图只能使用下面给出的五种基本控制结构:
PAD图
- Problem Analysis Diagram
- 设置了五种基本控制结构的图式,并允许递归使用。
软件配置:软件需求规格说明、软件设计规格说明、源代码等;
测试配置:测试计划、测试用例、测试程序等;
测试工具:测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等;
测试结果分析:比较实测结果与预期结果,评价错误是否发生以及错误的级别和严重性。
排错(调试):对已经发现的错误进行错误定位和确定出错性质,并改正错误,同时修改相关的文档。
修正后的文档再测试:直到通过测试为止;
利用可靠性分析,评价软件质量:
-
软件的质量和可靠性达到可接受的程度
-
是否所做的测试不足以发现严重的错误
如果测试发现不了错误,只能说明测试配置考虑得不够细致充分,错误仍然潜伏在软件中。
软件测试与各阶段关系
2、测试方法
白盒测试
将测试对象看做一个透明的盒子,允许利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致,又称为结构测试或逻辑驱动测试。
白盒测试主要应用于单元测试,是检查程序逻辑错误的主要方法。
逻辑覆盖
-
语句覆盖:使得每一个可执行语句至少执行一次。
-
判定覆盖:使得程序中每个判断的取真分支和取假分支至少经历一次,又称为分支覆盖。
-
条件覆盖:使得程序中每个判断的每个条件的可能取值至少执行一次。
-
判定-条件覆盖:使得判断中每个条件的所有可能取值至少执行一次,同时每个判断的所有可能判断结果取值至少执行一次。
-
条件组合覆盖:使得每个判断的所有可能的条件取值组合至少执行一次。
-
路径覆盖:设计足够的测试用例,覆盖程序中所有可能的路径。
程序控制流图
控制流图是对程序流程图进行简化后得到的一种图示方式,可以更加突出地表示程序控制流的结构。一个典型的控制流图结构如下图:
使用基本路径测试方法设计测试用例的步骤如下:
- 根据程序代码或程序流程图导出程序的控制流图。
黑盒测试
这种方法完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书和概要设计说明,检查程序的功能是否符合它的功能说明,又称为功能测试或数据驱动测试。
有以下三种常用方法:
等价类划分
黑盒测试方法不能选用穷举方式,为此通过寻找具有代表意义的数据进行替代其它同类型的数据,称为等价类。
并合理地假定:测试某等价类的代表值就等价于对这一类其它值的测试。
-
划分等价类
- 有效等价类:是指对于程序的规格说明来说,是合理的,有意义的输入数据构成的集合。
- 无效等价类:是指对于程序的规格说明来说,是不合理的,无意义的输入数据构成的集合。
-
选取测试用例
- 为每一个等价类规定一个唯一编 ;
- 设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;
- 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。
划分方式
- 按区间划分 [x, y]
- 数值集合
- 布尔值
- 数值划分
- 限制条件 / 规则
- 确定测试用例,每个唯一编
举例
转换判定表:
2、软件项目管理
定义
项目:是一项为了创造某一唯一的产品或服务的时限性工作。具有以下特征:
- 需要由人来完成;
- 受到有限资源的限制;
- 需要计划、执行和控制。
软件项目:是一种成果体现为软件产品的项目。其特有的特征表现为:
- 软件产品是无形的;
- 软件产品没有标准的软件过程 ;
- 大型软件项目开发常常是 “一次性的”。
项目管理过程
项目管理就是为了满足甚至超越项目干系人员对项目的需求和期望的一些活动,并将理论知识、技能、工具和技巧应用到项目的活动中。
包含以下九个知识领域:
-
综合管理:将项目管理各种必要要素综合为整体的过程和活动,并在项目管理过程组范围内识别、定义、组合、统一并协调。
-
范围管理:界定为了确保成功地完成项目所需要做的工作,也是仅仅被要求做的工作。
-
时间管理:阐述确保项目按时完成所需的各项过程。
-
成本管理:阐述了确保项目按照规定预算完成需要进行的费用规划、估算、预算的各项过程。
-
质量管理:阐述了确保项目达到其既定质量要求所需实施的各项过程。
-
人力资源管理:阐述了组织和管理项目团队的各个过程。
-
沟通管理:阐述了为确保项目信息及时而恰当地提取、收集、传输、存储和最终处置而需要实施的一系列过程。
-
风险管理:阐述了与项目风险管理有关的过程。
-
采购管理:阐述了采购或取得产品、服务或成果,以及合同管理所需的各过程。
软件项目管理过程如下:
上半部分传送门:
https://blog.csdn.net/qq_43791817/article/details/116189749
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!