软件工程【八】

六、面向对象方法学设计(续)


3、系统设计

面向对象方法学不断迭代更新,分析与设计也是互相作用,一定时刻明确它的特点。

(1)系统分解

面向对象设计模型:四部分组成。有些领域目标系统可只由3个或更少子系统组成。

问题域:直接负责实现客户需求子系统。

人机交互:实现用户界面子系统包括可复用的GUI子系统。

任务管理:确定各类任务,把任务分配给适当的硬件或软件去执行。

数据管理:负责对象的存储和检索的子系统。

(2)设计问题域子系统

是对分析阶段得到的结果在实现中的补充和迭代

  • 调整需求:如果用户需求或外部环境变化;分析模型不完整、准确。无论出现上述哪种情况,通常都只需简单地修改面向对象分析结果,然后再把这些修改反映到问题域子系统中。

  • 重用已有类:根据问题解决的需要,把从类库或其他来源得到既存类
    增加到问题解决方案中去。

  • 把问题域类组合在一起:设计时,从类库中引进一个根类,作为包容类,把所有与问题域有关的类关联到一起,建立类的层次。

  • 增加一般化类:某些特殊类要求一组类似的服务,应加入一般化的类,定义为所有特殊类共用的一组服务名,服务都是虚函数;在特殊类中定义其实现。

  • 调整继承关系:在OOA阶段建立的对象模型中可能包括多继承关系,但实现时使用程序设计语言可能只有单继承,需对分析结果修改。

(3)设计人机交互子系统

分析阶段:用户界面需求

设计阶段:确定人机交互细节,窗口报表形式,命令层次等。

三条黄金原则:

  • 置用户于控制之下:交互模式的定义不能强迫用户进入不必要的或不希望的动作的方式、允许用户交互可以被中断和撤销、当技能级别增长时可以使交互流水化并允许定制交互、使用户隔离内部技术细节
  • 减少用户的记忆负担:减少对短期记忆的要求、建立有意义的缺省、定义直觉性的捷径、界面的视觉布局应该基于真实世界的隐喻、以不断进展的方式揭示信息
  • 保持界面一致:所有可视信息的组织均按照贯穿所有屏幕显示所保持的设计标准、输入机制被约束到有限的集合,在整个应用中被一致地使用、从任务到任务的导航机制被一致地定义和实现

使用颜色的指导原则:避免使用太多的颜色(通常一个窗口内不要多于三种颜色)、使用颜色的变化显示系统状态的变化、注意颜色的搭配

(4)设计任务管理子系统

在实际系统中,许多对象之间往往存在相互依赖关系。设计工作的一项重要内容就是,确定哪些是必须同时动作的对象,哪些是相互排斥的对象。进一步设计任务管理子系统。

系统总有许多并发行为,需按照各自行为的协调和通信关系,划分各种任务(进程),简化并发行为的设计和编码。

确定各类任务,把任务分配给适当的硬件和软件去执行。

动态模型就是这种设计的基础。

一、分析并发性

并发对象:1.无交互行为的对象2.同时接受事件的对象

检查各个对象的状态图,找没并发对象的路径(任何时候路径中只有单个对象是活跃的),称控制线。
通过分离出控制线设计任务。

并发任务的分配方案:1.每个任务分配到独立的处理器2.分配到相同处理器,通过操作系统提供并发支持

二、设计任务子系统

1、事件驱动型:指睡眠任务(不占用cpu),某个事件发生,任务被触发,醒来做

2、时钟驱动型任务:按特定时间间隔去触发任务进行处理。如某些设备需要周期性的采集数据。

3、确定优先任务:高优先级,分离成独立任务,保证时间约束。

4、确定关键任务:严格可靠性,分离考虑,精心设计和编码,严格测试。

5、确定协调任务:三个以上任务,引入协调任务,控制封装任务间协调。

6、尽量减少任务数:任务多,设计复杂、不易理解、难维护

7、确定资源需求:计算系统载荷,每秒处理业务数,处理一个业务花费时间,估算所需cpu(或其他固件)处理能力。

综合考虑,确定哪些任务硬件实现,哪些任务软件实现。

(5)设计数据管理子系统

即设计合理数据库

七、面向对象方法学实现


1、程序设计语言

所有语言都可完成面向对象实现,但效果不同。使用非面向对象语言编写面向对象程序,则必须由程序员自己把面向对象概念映射到目标程序中。

选用面向对象语言有很多优点。

2、程序设计风格

(1)提高可重用性

  • 提高方法的内聚:方法只完成单个功能。涉及多个不相关功能,分解。
  • 减小方法的规模: 方法规模过大,分解。
  • 保持方法的一致性:功能相似方法有一致名字、参数特征(包括参数个数、类型和次序)、返回值类型、使用条件及出错条件等。
  • 把策略与实现分开负责做出决策,提供变元,管理全局资源,称策略方法。负责完成具体操作,称实现方法。实现方法相对独立,可在其它系统中重用,将二者分开。
  • 尽量不用全局信息:降低方法与外界耦合程度。
  • 利用继承机制:实现共享和提高重用程度的主要途径。
    • ①调用子过程,把公共代码分离出来,构成一个公用方法。
    • ②分解因子,从不同类相似方法分解出不同的代码,余下作为公用方法中公共代码。把分解出的
      因子作为名字相同算法不同的方法,在不同类中定义。

(2)提高可扩充性

  • 封装实现策略: 应把类的实现策略(包括数据结构、算法等)封装起来,对外提供公有接口。
  • 不要用一个方法遍历多条关联链:一个方法应只包含对象模型中有限内容。否则导致方法过分复杂,不易理解和修改扩充。
  • 避免使用多分支语句:增添新类时会修改原有的代码。合理利用多态性机制。
  • 精心确定公有方法:公有方法是向公众公布的接口。

(3)提高健壮性

  • 预防用户操作错误:任何输入(错误),给出提示信息,再次接收用户输入。

  • 检查参数合法性

  • 不预先确定限制条件:使用动态内存分配机制,创建未预先设定限制条件数据结构。

  • 先测试后优化

3、面向对象程序测试

(1)测试策略

单元测试—>集成测试—>确认测试

  • 单元测试
    • 单元:封装的类和对象
    • 对程序内部具体单一功能模块测试,如程序用C++实现,主要对类成员函数测试。
    • 传统的测试方法都可使用,等价类划分、边值分析、逻辑覆盖法、基本路径法。
  • 集成测试
    • 在面向对象的软件中不存在层次的控 制结构,传统的自顶向下或自底向上的集成策略就没有意义了。 此外,由于构成类的各个成分彼此间存在直接或间接的交互,一次集成一个操作到类中(传统的渐增式集成方法)通常是不现实的。 面向对象软件的集成测试主要有下述两种不同的策略。
    • 基于线程的集成测试:把响应系统的一个输入或一个事件所需类集成起来。
    • 基于使用的集成测试:先测独立类,测完后测独立类下一层类(依赖类),到测完。
  • 确认测试
    • 测用户可见动作,可识别系统输出。 根据动态模型和描述系统行为的脚本设计确认测试用例。黑盒法

(2)测试用例设计

1、单元测试方法用例
  • ①随机测试:在类的多个操作排列中,随机选择。但是要注意有些方法有前置条件,据此我们需要找到一条最小操作排列。然后从奇遇操作随机选择测试。

  • ②划分测试:随机测试过于盲目,且不好分析。引出划分测试

    • 根据改变类状态能力划分设计测试用例:改变类状态;不改变类状态。
    • 基于类操作属性的划分: 使用该属性;修改属性;不操作该属性。
    • 根据类操作完成功能:初始化操作、计算、查询、终止
  • ③基于故障测试:错误推测法,如边界或输入输出为零等。

2、集成测试方法用例

https://blog.csdn.net/winterwinner/article/details/6283597

3、确认测试

和传统确认测试方法一样,OO软件的确认关注用户可见的动作和用户可识别的系统输出。

为辅助确认测试的导出,应充分分析模型中的用例图的场景来提高交互需求中发现错误的可能性。

八、软件项目管理


1、软件规模度量

(1)代码行技术

估计每个功能需要源代码(参考类似项目的历史数据);累计;估计整个软件源程序行数。

当程序较小时常用的单位是代码行数(LOC[line of code]),当程序较大时常用的单位是千行代码数(KLOC)。

具体方法:

  • 1.多名(n)有经验软件工程师估计
    • a:程序最小规模
    • b:程序最大规模
    • m:程序最可能规模
  • 2.求三种规模的平均值
  • 3.求程序规模

优点:代码是所有软件开发项目都有的“产品”,而且很容易计算代码行数。

缺点:源程序不等于软件,实现语言不同代码行数不同,不适用非过程语言

(2)功能点技术

依据软件信息域特性和软件复杂性评估结果估算软件规模。

  • 1、估算未调整功能点UFP
  • 2、计算技术复杂性因子DI
    • 以及计算TCF=0.65+0.01×DI
  • 3、计算功能点数FP=UFP×TCF

2、工作量估算

工作量是软件规模函数,单位为人月(pm)。支持大多数估算模型的经验数据,都是从有限个项目的样本
集中总结出来的,因此,没有一个估算模型可以适用于所有类型的软件和开发环境。

(1)静态单变量模型

E=A+B*(ev)C
A、B、C为经验常数,ev是估算变量(LOC或FP)。

  • 面向LOC估算模型

  • 面向FP估算模型

(2)动态多变量模型

工作量是软件规模和开发时间两个变量的函数。是根据从4000多个当代软件项目中收集的生产率数据推导出来的。

(3)基于过程的估算

将任务分解为相对较小任务集合。估算完成每个任务需要的工作量。累计.

3、进度计划

管理复杂工程项目,最好办法是把工程项目分解成许多逻辑步骤(作业),安排作业顺序,确定每项作业需要用时间,及作业开始和终止时间。

把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期,从而将估算出的项目工作量分布于计划好的项目持续期内。

Gantt图

例如:矩形木板房需重新油漆。三步:刮旧漆,刷新漆,清除溅在窗上油漆。15名工人,5把刮旧漆刮板,5把刷漆刷子,5把清除溅在窗上油漆小刮刀。

在甘特图上加上菱形标记代表里程碑。

4、软件开发组织形式

(1)民主制小组(Democratic Team)

组内成员之间可以平等交换意见。组内成员之间可以平等交换意见。

优点:发挥每个成员积极性。

缺点:削弱个人责任心和必要权威作用。且人员多了交流会影响效率

适用领域:适合于研制时间长、开发难度大项目。

(2)主程序员制小组

专业化:每名成员完成受过专业训练的工作

层次化:主程序员有绝对权威

(3)现代程序员组

主程序员由两人担任:技术负责人;行政负责人。分工明确。明确划分技术负责人和行政负责人权限.

软件项目规模较大,程序员组分成若干个小组

将民主式程序员组与主程序员组的优点结合进来,形成包含分散决策组织形式。

5、控制—风险管理

使软件项目按预定计划和预期目标进行.

(1)风险的类别

项目风险:可能对项目的预算、进度、人力、资源、顾客和需求等方面产生不良影响的的潜在问题

技术风险:潜在的设计、实现、接口、验证和维护等方面的问题,此外,规约的二义性、技术的不确定性、陈旧或不成熟的“领先的”技术都可能是技术风险

商业风险:威胁要开发的软件的生存能力

  • 开发了一个无人真正需要的产品(市场风险)
  • 开发的产品不符合公司的整体商业策略(策略风险)
  • 建造了一个销售部门不知如何销售的产品(销售风险)
  • 由于重点转移失去了高级管理层支持(管理风险)
  • 没有得到充分预算或人力资源保证(预算风险)

(2)风险识别

采用系统化方法,识别特定项目已知和可预测的风险。

例如风险检查表。

(3)风险分析

对已识别风险进行估计和评价,确定风险发生的概率与后果。定性分析。

评估已识别项目风险影响和可能性,按可能产生影响排序。定量分析。

(4)风险驾驭

制定具体风险应对策略。

-风险规避是设法降低风险出现的可能性;

-风险缓解是设法减少风险产生的影响;

-风险转移是将风险转移给第三方;

-风险接受是采取应急方案应对风险的发生。

6、控制—质量控制

对于非物理实体,而是逻辑实体的软件怎么衡量?

软件质量定义(ANSI/IEEE):与软件产品满足规定的和隐含的需求能力有关的特征或特性全体。

  • (1) 软件需求是度量软件质量的基础。
  • (2) 按规范化标准定义开发准则,不遵守软件质量不能保证。
  • (3) 不能忽略隐含需求。

影响软件质量因素:用软件质量模型描述,较著名模型为McCall等人1979年提
出,这些因素是从管理角度对软件质量的度量。不在赘述。

软件质量保证措施:

  • 基于非执行的测试:复审或评审
  • 基于执行的测试:软件测试
  • 程序正确性证明

技术复审的必要性(走查、审查):

  • 走查:是开发者的一次友好的会议,需要仔细规划,有明确的目的、日程、持续时间和参与人员,许多小组以星期为单位走查。
  • 审查:最系统化严密的评审技术。审查范围比走查广泛、步骤较多。不再赘述

7、控制—配置管理

-----------------------本文结束 感谢阅读-----------------------
坚持原创技术分享,您的支持将鼓励我继续创作!恰饭^.^~