当前位置:   article > 正文

二 需求工程和设计模式_组装外桥享适代

组装外桥享适代

目录

一、需求工程

1、需求开发

1.1需求获取

1.2需求分析

1.2.1 SA 结构式需求分析

1.2.2 面向对象OOA分析、UML

1.3需求定义

1.4需求验证

2、需求管理

二、系统设计

2.1 界面设计 两星⭐⭐

2.2 结构化设计 两星⭐⭐

2.3面向对象设计 五星⭐⭐⭐⭐⭐

2.4 对象设计模式的分类

2.4.1 创建型模式(工抽构单原)

2.4.2 结构型模式(适桥组装外享代)

2.4.3 行为型模式(责观命策状,解迭中访备)

三、软件测试

四、软件调试

五、系统运行和维护

六、拓展知识


一、需求工程

需求工程分为需求开发和需求管理

需求开发:需求获取,需求分析,需求定义、需求验证。

需求管理:变更控制、版本控制、需求跟踪,需求状态跟踪。

1、需求开发

需求开发:需求获取,需求分析(重点),需求定义、需求验证。 

1.1需求获取

分类:从技术分类为业务需求(高层次需求),用户需求,系统需求(功能需求,性能需求,设计约束)。

从项目管理分为基本需求,期望需求(隐含的,最可能出争论),兴奋需求(镀金)。

获取:收集资料,讨论会,用户访谈,观摩,抽样调查等。

1.2需求分析

1.2.1 SA 结构式需求分析

功能模型DFD数据量,加工,数据存储,外部实体。分层的功能模块)。应用架构建模中要绘制的第一个物理数据流图(PDFD)是网络架构DFD,它们不显示单位时间的数据流量,需要显示的信息包括服务器及其物理位置;客户端及其物理位置;处理器说明;传输协议。

E-R图实体和实体之间的联系,数据模型)。

状态转换图STD(状态事件联系,行为模型)

数据字典

1.2.2 面向对象OOA分析、UML

基本概念:类分为实体类,控制类(动词名称类,衔接其他类进行用例类控制),边界类(接口,流动的类)。

UML-统一建模语言组成:

  • 构造块。分为事物(结构事物-静态部分,行为事物-动作,分组事物,注释事物)、关系、图。
  • 规则。
  • 公共机制。

UML需求建立模型:用例模型和分析模型。

  • 用例模型。对应用例图。
  • 分析模型。对应类图。

UML分类:

  • 静态图(结构图)
  1. 类图。
  2. 对象图。
  3. 部署图。软硬件直接映射,部署后的图。
  4. 制品图.
  5. 包图。软件体系结构图
  6. 组合结构图。
  • 动态图(行为图)
  1. 用例图。系统和外部参与者的交互,强调需求。
  2. 顺序图。强调按时间顺序。
  3. 通信图(协作图)
  4. 状态图。状态转换变迁。
  5. 活动图。类似程序流程图,并行行为
  6. 定时图。强调时实际时间。
  7. 交互概念图。

顺序图强调的是对象交互的时间次序。通信图强调的是对象之间的组织结构。

顺序图(序列图)。一种交互图,强调对象之间消息的发送顺序,同时显示对象之间的交互。有时间线。

活动图。活动之间的进程交互,可表现并发,强调对象间的控制流程。有比较科学的表达形式:泳道式活动图。

状态图。状态的变迁,强调事件导致的对象行为。

通信图。有序号例如1.1,1.1.1对象关系。

基于UML的需求分析过程大致可分为以下步骤:

利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景;对场景进行汇总、分类、抽象,形成用例;确定执行者与用例、用例与用例图之间的关系,生成用例图。

利用包图和类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构;从业务需求描述中提取“关键概念”,形成领域概念模型;从概念模型和用例出发,研究系统中主要的类之间的关系,生成类图。

面向对象设计的基本任务,把面向对象分析模型转换为面向对象设计模型。面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成。设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和描述流程化处理过程的活动图等。

用例图

  • 包含。公共部分。include
  • 扩展关系。基本用例,扩展用例,扩展出的功能,不是每次都做。例如取款,打印凭条。 extend
  • 泛化关系。有父子关系。

类图和对象图

  • 依赖关系: 一个事物变化影响另外一个依赖某个方法。
  • 泛化关系: 特殊/一般关系。父子关系。
  • 关联关系: 描述一组链,链是对象之间的连接。
  • 聚合关系:整体与部分生命周期不同。例如汽车和轮子。
  • 组合关系:整体与部分生命周期相同。比如公司倒闭和部门。
  • 实现关系:接口与类之间的关系。

UML 4+1视图

4+1模型视图即:逻辑视图、开发视图、物理视图(部署视图)、进程视图、场景。

  • 逻辑视图类和对象,表现系统的功能。面向用户。
  • 实现视图(开发视图)。面向程序员,物理代码和模块组件。
  • 进程视图。线程,进程,性能。系统集成人员。
  • 部署视图。软件到硬件的映射。系统工程师。
  • 用例视图需求分析模型。测试和分析人员。

1.3需求定义

严格定义法和原型法。

1.4需求验证

需求评审和需求测试。

2、需求管理

 需求管理:变更控制、版本控制、需求跟踪,需求状态跟踪。

  • 变更控制。申请,评估,决策,实施,验证,沟通存档。流程:提出问题,问题分析和变更描述,变更分析和成本计算,变更实现。
  • 版本控制。
  • 需求跟踪。需求进行跟踪,跟进。正向跟踪和反向跟踪。用户原始需求到软件需求到下游工作产品。
  • 需求状态跟踪

系统建模:结构化建模方法、信息化工程建模方法(数据库建模方法)、面向对象建模方法

二、系统设计

2.1 界面设计 两星⭐⭐

人机界面设计:置于用户控制之下,减少用户的记忆负担,保持界面的一致性。

2.2 结构化设计 两星⭐⭐

概要设计(模块的划分和模块接口的设计)和详细设计(模块内)。

基本思想: 抽象化,自顶而下,逐步求精,信息隐蔽,模块独立(高内聚,低耦合)。

设计准则: 保持模块的大小适中。尽可能减少调用的深度。多扇入,少扇出。单入口,单出口。模块的作用域应该在模块之内。功能应该可预测。

软件设计包括体系结构设计、接口设计、数据设计和过程设计。

  • 结构设计:定义软件系统各主要部件之间的关系
  • 数据设计:将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分,降低过程复杂性。
  • 接口设计(人机界面设计软件内部,软件和操作系统间以及软件和人之间如何通信
  • 过程设计:系统结构部件转换成软件的过程描述。

2.3面向对象设计 五星⭐⭐⭐⭐⭐

设计原则

  • 单一职责原则。设计目的单一的类。
  • 开放-封闭原则。对扩展开放,对封闭修改。
  • 里氏替换原则。子类可以替换父类。
  • 依赖倒置原则。要依赖于抽象,而不是具体实现。针对接口变成,不要针对实现编程。
  • 接口隔离原则。使用多个专门的接口比单一的总接口好。
  • 组合重用原则。尽量使用组合,而不是继承达到重用目的。
  • 迪米特原则(最少知识法则)。一个对象应当对其他对象有尽少可能的了解。

设计模式概念

  • 架构模式。高层决策,反映最基本设计决策
  • 设计模式。关注系统设计,与实现语言无关。
  • 惯用法。最低层模式,某种语音都有自己特定的模式,叫语言的惯用法,例如引用-计数就是c++中的一种惯用法。

2.4 对象设计模式的分类

设计模型分为三大类创建型、结构型、行为型。

2.4.1 创建型模式(工抽构单原)

口诀:工抽构单原。

理解:提供灵活创建对象的方法。(创建对象)

  • 工厂方法模型(factory method。定义一个对象接口,但是由子类决定实例化哪个类,子类实例化动态生产对象
  • 抽象工厂模型 (abstract factory。提供一个接口,创建一系列或相关依赖的对象,无需指定具体类。生产成系列对象(其实是抽象工厂,需先指定工厂)。
  • 原型模型(prototype。原型实例创建对象。克隆对象
  • 单例模型(singleton。保证一个类只有一个实例。单实例
  • 构建器模型(builder。复杂类的表示和构造分离,使用相同的构建能够得到不同的表示。复杂对象构造。

2.4.2 结构型模式(适桥组装外享代

口诀:适桥组装外享代

理解:主要解决如何组织类和对象,以获得更大的结构。

  • 适配器模型(adaptor)。将一个类的接口转换成用户希望的另一个接口,使得不相容的接口可以协作工作转换接口,其实就是中转。例如充电器。解决原有接口不匹配的问题
  • 桥接模型(bridge)。将类的抽象部分和实现部分分离使得他们可以独立变化。继承树拆分。解决两个独立变化。
  • 组合模型(composite。整体和部分的层次结构,总分分,树形目录结构,组织结构
  • 装饰模型(decorator。给一个对象添加一些额外的职责。动态附加职责
  • 外观模型(facade。定义高层接口。对外统一接口
  • 享元模型(flyweight。提供大量细粒度对象共享的有效方法。汉字编码
  • 代理模型(proxy。为其他对象提供一种代理以控制这个对象的访问。快捷方式,解决烦杂的处理流程,由代理去处理。而行为型的中介模式,是解决信息之间的不对称,由一个中介去处理。

2.4.3 行为型模式(责观命策状,解迭中访备

口诀:责观命策状,解迭中访备。

理解:主要解决对象直接如何交互和职责分配。

  • 责任链链模式(chain of responsibility)。 传递职责,将接收对象链接起来,在链中传递请求,直到有一个对象处理这个请求。例如审批流程
  • 命令模式(command)。将一个请求封装成一个对象日志记录和可撤销。每个操作可以撤销,ctrl+z
  • 备忘录模式(memento。在不破坏封装性的前提下,保存这个状态,从而可以讲对象恢复原先保存的状态。游戏存档,总成果保存存档,快照功能
  • 解释器模型(interpreter。自定义语法和规则进行解释,灵活度高。虚拟机机制,工作流规则引擎
  • 迭代器模式(iterator。提供一种方法来顺序访问一个聚合对象中的各个元素,无需暴露内部对象。数据集。
  • 中介者模式(mediator不直接引用,不需要显示调用,松散解耦,可以独立改变之间的交互。
  • 观察者模式(observer。一种一对多的依赖关系,当一个对象状态发生改变,所有依赖的都得到通知并自动更新。联动,订阅,通知
  • 状态模式(state。一个对象在其内部状态改变时改变它的行为。状态变成类
  • 策略模式(strategy。定义一系列算法,可以互相替换,让算法可以独立于使用它的用户而变化。算法和多方案切换。
  • 模板方法模式(template method。固化一部分,另外一部分变化。框架
  • 访问者模式(visitor数据和操作分离

三、软件测试

动态测试。黑盒白盒灰盒测试。

  • 黑盒测试。里面的东西不知道,测试功能

等价类划分(不同的类型进行划分),边界值分析(边界值±1,4个值测试),错误推测,因果图。

  • 白盒测试。根据内部功能测试
  1. 基本路径测试
  2. 循环覆盖测试
  3. 逻辑覆盖测试(语句覆盖最弱,路径覆盖最强)

静态测试。包括桌前检查,代码审定,代码走查。

单元测试:测试模块的功能、性能、接口等。

集成测试:模块间的接口概要设计阶段

确认测试:软件和需求的一致性。内部确认测试,alpha测试(开发环境测试),beta测试(发一个版本到公测),验收测试

系统测试:真实环境下,软硬件联调验证软件配置项。功能性,性能性测试,强度测试,容量测试(并发)。全面度最高。

回归测试:软件变更后,变更部分的正确性和符合性。

面向对象的测试:算法层(单元测试),类层(模块测试),模块层/类树层(集成测试),系统层(系统测试)。

四、软件调试

调试方法

  • 蛮力法。通过计算机找错,低效耗时
  • 回溯法。正向。
  • 原因排除法。正向。

软件测试与测试的区别

  • 测试的目的找出存在的错误。调试的目的定位错误进行修改,bebug
  • 调试是在测试之后,测试和调试在目标、方法、思路上不同。
  • 测试从一个已知条件开始,有预知结果。调试从未知的条件开始,结束过程不可预计。
  • 测试过程可以事先设计,进度可以事先确定,调试不能描述过程或持续时间

五、系统运行和维护

系统转换计划

  • 遗留系统演化策略
  1. 低水平低价值 :淘汰
  2. 高水平低价值: 集成。高技术,不划算重写,集成打通。
  3. 高水平高价值:改造。调整改造。
  4. 低水平高价值: 继承。根据业务流程继承功能模型和数据模型。

第一到第四象限:改造、集成、淘汰、继承。

图片借鉴:

f423be08e80f42028792cd130c99d3d5.jpeg

  • 新旧系统转换策略
  1. 现有系统直接转换策略:风险高
  2. 并行:时间和成本高。
  3. 分段转换(折中): 风险低和成本适合调节。

数据迁移与转换:旧数据库抽取,转换,新数据库装载

运行维护(最耗时的周期)

  • 正确性维护:改正正在系统开发阶段已发送而测试阶段未发生的错误
  • 适应性维护: 信息技术变化和管理需求变化而进行的修改。操作系统变化,软件运行变化,数据库变化,导致系统不能正常运行。
  • 完善性维护:扩充功能和改善性能
  • 预防性维护:改进软件未来可靠性和可维护性。

六、拓展知识

软件系统文档分为用户文档和系统文档。

用户文档:功能描述,安装文档,使用手册,参考手册,操作员指南

系统文档:系统设计,实现和测试方面的文档。

系统测试是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起,进行信息系统的各种组装测试和确认测试,其目的是通过与系统的需求相比较,发现所开发的系统与用户需求不符或矛盾的地方。系统测试是根据系统方案说明书来设计测试例子的,常见的系统测试主要有以下内容:

1. 恢复测试恢复测试监测系统的容错能力。

检测方法是采用各种方法让系统出现故障,检验系统是否按照要求能从故障中恢复过来,并在约定的时间内开始事务处理,而且不对系统造成任何伤害。如果系统的恢复是自动的(由系统自动完成),需要验证重新初始化、检查点、数据恢复等是否正确。如果恢复需要人工干预,就要对恢复的平均时间进行评估并判断它是否在允许的范围内。

2. 安全性测试:系统的安全性测试是检测系统的安全机制、保密措施是否完善,主要是为了检验系统的防范能力。测试的方法是测试人员模拟非法入侵者,采用各种方法冲破防线。

系统安全性设计准则是使非法入侵者所花费的代价比进入系统后所得到的好处要大,此时非法入侵已无利可图。

3. 强度测试:是对系统在异常情况下的承受能力的测试,是检查系统在极限状态下运行时,性能下降的幅度是否在允许的范围内。

因此,强度测试要求系统在非正常数量、频率或容量的情况下运行。强度测试主要是为了发现在有效的输入数据中可能引起不稳定或不正确的数据组合。例如,运行使系统处理超过设计能力的最大允许值的测试例子;使系统传输超过设计最大能力的数据,包括内存的写入和读出等。

4.性能测试:检査系统是否满足系统设计方案说明书对性能的要求。性能测试覆盖了软件测试的各阶段,而不是等到系统的各部分都组装之后,才确定系统的真正性能。

通常与强度测试结合起来进行,并同时对软件、硬件进行测试。软件方面主要从响应时间、处理速度、吞吐量、处理精度等方面来检测。

5. 可靠性测试:通常使用以下两个指标来衡量系统的可靠性:平均失效间隔时间MTBF (mean time between failures)是否超过了规定的时限,因故障而停机时间MTTR (mean time to repairs)在一年中不应超过多少时间。

6. 安装测试:在安装软件系统时,会有多种选择。安装测试就是为了检测在安装过程中是否有误、是否容易操作等。主要监测系统的每一个部分是否齐全,硬件的配置是否合理,安装中需要产生的文件和数据库是否已产生,其内容是否正确等。

在处理流程设计过程中,为了更清晰地表达过程规则说明,陆续出现了一些用于表示处理流程的工具,这些工具包括三类:图形工具、表格工具和语言工具。其中常见的图形工具包括程序流程图、IPO图、盒图、问题分析图、判定树,表格工具包括判定表,语言工具包括过程设计语言等。

程序流程图(Program FLow Diagram,PFD)用一些图框表示各种操作,它独立于任何一种程序设计语言,比较直观、清晰,易于学习掌握。流程图中只能包括5种基本控制结构:顺序型、选择型、WHILE循环型(当型循环)、UNTIL循环型(直到型循环)和多分支选择型。

IPO图是由IBM公司发起并逐步完善的一种流程描述工具,其主体是处理过程说明,可以采用流程图、判定树、判定表、盒图、问题分析图或过程设计语言来进行描述。IPO图中的输入、输出与功能模块、文件及系统外部项都需要通过数据字典来描述,同时需要为其中的某些元素添加注释

N-S图与PFD类似,也包括5种控制结构,分别是顺序型、选择型、WHILE循环型(当型循环)、UNTIL循环型(直到型循环)和多分支选择型,任何一个N-S图都是这5种基本控制结构相互组合与嵌套的结果。在N-S图中,过程的作用域明确;它没有箭头,不能随意转移控制;而且容易表示嵌套关系和层次关系;并具有强烈的结构化特征。但是当问题很复杂时,N-S图可能很大。

问题分析图(Problem Analysis Diagram,PAD)是继PFD和N-S图之后,又一种描述详细设计的工具。PAD也包含5种基本控制结构,并允许递归使用。

过程设计语言(Process Design Language,PDL)也称为结构化语言或伪代码(pseudocode),它是一种混合语言,采用自然语言的词汇和结构化程序设计语言的语法,用于描述处理过程怎么做,类似于编程语言。过程设计语言用于描述模块中算法和加工逻辑的具体细节,以便在开发人员之间比较精确地进行交流。

对于具有多个互相联系的条件和可能产生多种结果的问题,用结构化语言描述则显得不够直观和紧凑,这时可以用以清楚、简明为特征的判定表(Decision Table)来描述。判定表采用表格形式来表达逻辑判断问题,表格分成4个部分,左上部分为条件说明,左下部分为行动说明,右上部分为各种条件的组合说明,右下部分为各条件组合下相应的行动。

判定树(Decision Tree)也是用来表示逻辑判断问题的一种常用的图形工具,它用树来表达不同条件下的不同处理流程,比语言、表格的方式更为直观。判定树的左侧(称为树根)为加工名,中间是各种条件,所有的行动都列于最右侧。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小惠珠哦/article/detail/924495
推荐阅读
相关标签
  

闽ICP备14008679号