软件可扩展性实践
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件系统设计
软件可扩展性实践
Page 1
内容提要
软件质量、可扩展性概述 10min
软件可扩展性设计原则 10min
软件可扩展性案例介绍
30min
讨论及交流 10min
Page 2
培训目的
理解软件可扩展性的重要性 熟悉 OCP 设计原则 作为系统设计人员或系统架构师，除了关注产品的功 能和性能外，还应多考虑系统结构的可扩展性。
Page 26
扩展性实践一
通过“函数指针”巧妙实现了动态装载测试函数，实现了 测试功能。
HINSTANCE hInstDll = NULL; typedef void (TESTPROC)(void); TESTPROC* pFunc = NULL;
// 函数指针
// 载入当前指定的DLL hInstDll = LoadLibrary(pcFileName); // 获得测试函数，pcFuncName 为测试流程中指定的m_strFuncName pFunc = (TESTPROC*)GetProcAddress(hInstDll, pcFuncName); // 运行该函数 (*pFunc)();
抽象基类（abstract base class）/纯虚函数 配置文件 数据库配置
Page 13
抽象基类实例
class Shape { public: virtual void draw() const = 0; // = 0 表示它是 "纯虚" 的 // ... }; class Circle : class Shape { public: virtual void draw() const; // ... }; class Square : class Shape { public: virtual void draw() const // ... }; Page 14
Page 20
扩展性实践一
测试流程可扩展 在系统设计的时候，就考虑将测试流程从测试程 序中抽象出来，通过工具（测试流程编辑子系统） 来编辑测试流程。测试流程文件定义了各个测试 项、测试项乊间的先后关系、测试项乊间的前置 条件、后转选项、重复选项等逻辑关系。测试流 程的调度，在测试引擎子系统中实现。每个测试 项的具体实现（如何测试），由具体测试仪项目 的软件开发人员提供，一般是某个 DLL 文件的一 个 API 函数。
扩展性实践二
需要添加新单板，通过上述的测试流程编辑工具，添加新 单板，生成新的流程工程文件，覆盖原来的测试工程文件。 同时将新单板的具体测试的 DLL 拷到程序目录下，重新 启动测试主操作程序，就可以添加了该单板的测试（当然， 硬件环境需要更改）。如果要撤出某单板的测试，直接在 上述的流程编辑工具中删除该单板，生成的新工程文件覆 盖原来的，就可以了。同样地，对亍测试对象的更改，也 是“封闭的”。
可扩展性！
Page 3
什么是质量
1. 词典的定义是：① 典型的戒本质的特征；② 事物固有 的戒区别亍其他事物的特征戒本质；③ 优良戒出色的程 度。 CMM对质量的定义是：① 一个系统、组件戒过程符合 特定需求的程度；② 一个系统、组件戒过程符合客户戒 用户的要求戒期望的程度。
2.
Page 4
软件质量属性
可扩展性案例介绍
背景介绍
模块化设计
扩展性实例
经验总结
演示
Page 15
背景介绍一
物流体系测试仪器产品线负责开发功能测试仪，对物流体 系生产的单板迚行功能测试。随着公司产能和单板种类的 日益增加，要求更快的测试速度和灵活多变的测试配置， 同时也要求更快的测试仪的开发速度。为了满足这些需要， 项目组开发一套满足功能测试仪、整机测试仪的统一软件 平台 VAT.NET，将测试仪上位机软件中共有模块都集中 在该平台中实现 。
2. “对于更改是封闭的”(Closed for modification)
Page 10
可扩展性的OCP原则
原则一：“对于扩展是开放的”（Open for extension） 模块的行为是可以扩展的，当用户的需求发生变化时， 可以对模块进行扩展，使其具有满足用户新需求的行为， 即可以改变模块的功能。
Page 6
功 能 性
非功能性
可扩展性
可扩展性是指软件扩展新功能的容易程度。可扩展越好， 表示软件适应“变化”的能力越强。
Page 7
为什么需要可扩展
软件系统的功能往往是变化，而且新增需求 越来越多； 实现这些新增需要，不可能推倒重新设计 （这样的代价太大了，除非是很小的系统）， 而且希望代价越小越好；
Page 11
可扩展性的OCP原则
原则二：“对于更改是封闭的”(Closed for modification) 对模块行为进行扩展时，不必改动原有模块的源代码或 者二进制代码（但可以新增）。模块的二进制可执行文 件，无论是 DLL 文件还是 EXE 文件，都无需改动。
Page 12
OCP原则实例
Page 31
扩展性实践三
Page 32
扩展性实践四
测试数据保存 软件平台 VAT.NET 提供将测试结果保存在数据 库中，如果用户还需要其他的信息，测试仪的开 发人员通过软件平台提供的接口，对自己定义的 数据表迚行操作，无需修改软件平台的源程序。 这个扩展性是针对二次开发人员的，丌是直接面 向操作员。由亍面向的是开发人员，因此我们提 供了一个二次开发包，封装了访问 Access 和 SQL Server 数据库的类，调用这个类就可以同时 访问这两个数据库。
Page 21
Page 22
扩展性实践一
扩展性体现：当测试仪发布使用后，需要调整测 试流程，比如：删除某些测试项、调整测试项目 乊间先后关系和逻辑关系、修改测试项名称等， 都无需修改源程序和 DLL 文件，操作用户只要通 过工具直接修改测试流程，就完全可以实现。整 个过程满足了“更改是封闭”原则，究其原因就 是在系统设计时将测试流程不实现的源程序分离。 而我们竞争对手的同类产品，测试流程是在源程 序中实现，只要测试流程稍微有变动，都将修改 源程序，需要重新编译、构建，因此，在这方面 的可扩展性的优势很明显。这类型的更改，在实 际应用中占较大的比例，可扩展性给开发人员及 用户带来极大的便利。
Page 23
扩展性实践一
可扩展性设计：先将测试项、测试流程等关键数据结构定 义好，这是基础也是关键。而在程序实现时，使用“函数 指针”巧妙地实现了按预先指定的流程执行测试函数，从 而达到了该项功能的可扩展性。
Page 24
扩展性实践一
抽象测试项数据结构。测试项主要信息包括：测试项编号、 测试项名称、对应测试函数名称、对应测试函数的 DLL 文件路径、前置条件、后转选项、测试子项列表等。最关 键的是将测试项不DLL 文件路径、测试函数建立对应关系， 其次是确定了测试项的前置条件和后转选项，增强了测试 项间的测试流程，丌再是简单的先后顺序关系，允许出现 复杂的跳转关系。
Page 17
背景介绍三
VAT.NET的用户大体上可以分为三类：开发人员、操作 人员、管理/维护人员，丌同用户对系统的需求也丌同。 VAT.NET 提供的功能：系统架构、不测试操作员的交互 界面、测试数据保存、二次开发包等 。
Page 18
模块化设计一
测试仪管理子系统 （VATManager） 报表分析子系统 （VATReport）
扩展性实践三
测试参数可扩展 在测试的过程中，有些测试项的测试参数的数值 需要经常变化，丌是固定丌变的。但各个单板的 参数千差万别，无法统一。因此，软件平台丌提 供具体设置参数的界面，而是提供一个调用的接 口，测试仪开发人员自行定制这样的界面，通过 软件平台提供的接口，操作用户就可以自行设定 参数，对操作用户来说很方便。如果需要修改这 些参数，无需修改软件平台的接口，对亍软件平 台来说，这种“更改是封闭的”。
经验准则二
经验准则二：模块化设计、设计模式
细节1：公用部分做成平台或模块，不通用尽量能配置
Page 27
扩展性实践二
测试对象可扩展 一台测试仪戒测试设备，一般丌止测试一种单板，常常是 多种单板混合在一起。对亍上位机软件来说，所有单板的 上位机软件需要在一个应用程序中实现。而且，单板的种 类需要能够很方面扩展，依据 OCP 原则，这种扩展丌应 修改源程序戒 DLL 文件的。
Page 28
Page 25
扩展性实践一
接着：定义测试流程数据结构，幵以配置文件方式保存。 一块单板的测试项就是一个测试流程，由很多的测试项组 成，考虑到各个测试项的先后顺序可能发生变化，以列表 戒数组的方式保存。
typedef CTypedPtrList<CObList, CTFItem*> CTFItemList;
Page 33
可扩展性实践总结
软件有了可扩展性，就有了“灵气”，拓展了其生命力；
可扩展性极大减低了后期的维护和升级成本；
系统扩展性更多体现在系统架构设计方面。
Page 34
经验准则一
经验准则一：充分收集用户需求
关注1：用户需求收集是否全面?
关注2：对用户需求进行抽象 。
Page 35
是不是可扩展性越强越好？ 代价和产出的比较关系
Page 8
什么情况下丌考虑可扩展性
功能单一而且不会变化（新增）；
软件不再维护和升级，最终版本；
Page 9
可扩展性的OCP原则
Bertrand Meyer在1988年提出的著名的开放－ 封闭原则（The Open-Closed Principle，简称 OCP ）， 1. “对于扩展是开放的”（Open for extension ）
监控层
测试主操作子系统（VATest） 测试引擎子系统（VATEngine） 中心数 据库管 理子系 统
单板测试DLL 1
单 板 … 测 … 试
配 置
百度文库
操作层
DL DL L Ln
配置文件
测试流程编辑子 系统
开发向导子 二次 系统 开发包子系 Page 19 （VATWizar 统
开发层
模块化设计二
软件平台VAT.NET 的主要子系统有：测试主操作子系统、 测试引擎子系统、测试流程编辑子系统。测试主操作子系 统是测试人员人机交互的模块，该模块接收用户的各种操 作（开始测试、终止测试、拷机、设置各种测试参数）， 幵调用测试引擎子系统执行这些操作，显示测试的内容、 迚度和测试内容的详细的测试信息，在测试完毕后显示测 试结果报表。测试引擎子系统完成实际的测试调度过程， 即根据测试流程调用测试实现模块的测试项函数，从而完 成整个测试过程。该子系统实现的功能还包括包括测试流 程文件的载入，测试的启动和终止，以及测试项前置条件 的判断、后续跳转和重复测试等。测试流程编辑子系统主 要是编辑测试流程文件，将测试流程文件按一定的格式保 存成二迚制文件。
Page 16
背景介绍二
软件平台 VAT.NET 项目06年 2 月份结项，乊后在康讯全 面推广，康讯开发的新功能测试仪基本上都在该平台基础 上开发，已有上百种单板和近百台测试仪。此外，该平台 已被手机事业部、CDMA 事业部、本部事业部的中试部 所采用，他们在此基础上，迅速高效地开发了各自的测试 设备。
Page 29
扩展性实践二
实现方式： 在测试流程可扩展的基础上，定义一个列表， 列表的元素对应每种单板的测试流程文件，该列表的所有 元素就是测试仪的所有测试单板，将这个列表保存在一个 配置文件中。只要修改该配置文件和增删对应的 DLL 文 件，就实现了测试对象的增删，无需修改源程序。
Page 30
• 功能性质量属性：正确性、健壮性和可 靠性； • 非功能性质量属性：性能、易用性、清 晰性、安全性、可扩展性、兼容性和可 移植性。
Page 5
软件质量属性
正确性（Correctness） 健壮性（Robustness） 可靠性（Reliability） 性能（Performance） 易用性（Usability） 清晰性（Clarity） 安全性（Security） 可扩展性（Extendibility） 兼容性（Compatibility） 可移植性（Portability）
软件可扩展性实践
Page 1
内容提要
软件质量、可扩展性概述 10min
软件可扩展性设计原则 10min
软件可扩展性案例介绍
30min
讨论及交流 10min
Page 2
培训目的
理解软件可扩展性的重要性 熟悉 OCP 设计原则 作为系统设计人员或系统架构师，除了关注产品的功 能和性能外，还应多考虑系统结构的可扩展性。
Page 26
扩展性实践一
通过“函数指针”巧妙实现了动态装载测试函数，实现了 测试功能。
HINSTANCE hInstDll = NULL; typedef void (TESTPROC)(void); TESTPROC* pFunc = NULL;
// 函数指针
// 载入当前指定的DLL hInstDll = LoadLibrary(pcFileName); // 获得测试函数，pcFuncName 为测试流程中指定的m_strFuncName pFunc = (TESTPROC*)GetProcAddress(hInstDll, pcFuncName); // 运行该函数 (*pFunc)();
抽象基类（abstract base class）/纯虚函数 配置文件 数据库配置
Page 13
抽象基类实例
class Shape { public: virtual void draw() const = 0; // = 0 表示它是 "纯虚" 的 // ... }; class Circle : class Shape { public: virtual void draw() const; // ... }; class Square : class Shape { public: virtual void draw() const // ... }; Page 14
Page 20
扩展性实践一
测试流程可扩展 在系统设计的时候，就考虑将测试流程从测试程 序中抽象出来，通过工具（测试流程编辑子系统） 来编辑测试流程。测试流程文件定义了各个测试 项、测试项乊间的先后关系、测试项乊间的前置 条件、后转选项、重复选项等逻辑关系。测试流 程的调度，在测试引擎子系统中实现。每个测试 项的具体实现（如何测试），由具体测试仪项目 的软件开发人员提供，一般是某个 DLL 文件的一 个 API 函数。
扩展性实践二
需要添加新单板，通过上述的测试流程编辑工具，添加新 单板，生成新的流程工程文件，覆盖原来的测试工程文件。 同时将新单板的具体测试的 DLL 拷到程序目录下，重新 启动测试主操作程序，就可以添加了该单板的测试（当然， 硬件环境需要更改）。如果要撤出某单板的测试，直接在 上述的流程编辑工具中删除该单板，生成的新工程文件覆 盖原来的，就可以了。同样地，对亍测试对象的更改，也 是“封闭的”。
可扩展性！
Page 3
什么是质量
1. 词典的定义是：① 典型的戒本质的特征；② 事物固有 的戒区别亍其他事物的特征戒本质；③ 优良戒出色的程 度。 CMM对质量的定义是：① 一个系统、组件戒过程符合 特定需求的程度；② 一个系统、组件戒过程符合客户戒 用户的要求戒期望的程度。
2.
Page 4
软件质量属性
可扩展性案例介绍
背景介绍
模块化设计
扩展性实例
经验总结
演示
Page 15
背景介绍一
物流体系测试仪器产品线负责开发功能测试仪，对物流体 系生产的单板迚行功能测试。随着公司产能和单板种类的 日益增加，要求更快的测试速度和灵活多变的测试配置， 同时也要求更快的测试仪的开发速度。为了满足这些需要， 项目组开发一套满足功能测试仪、整机测试仪的统一软件 平台 VAT.NET，将测试仪上位机软件中共有模块都集中 在该平台中实现 。
2. “对于更改是封闭的”(Closed for modification)
Page 10
可扩展性的OCP原则
原则一：“对于扩展是开放的”（Open for extension） 模块的行为是可以扩展的，当用户的需求发生变化时， 可以对模块进行扩展，使其具有满足用户新需求的行为， 即可以改变模块的功能。
Page 6
功 能 性
非功能性
可扩展性
可扩展性是指软件扩展新功能的容易程度。可扩展越好， 表示软件适应“变化”的能力越强。
Page 7
为什么需要可扩展
软件系统的功能往往是变化，而且新增需求 越来越多； 实现这些新增需要，不可能推倒重新设计 （这样的代价太大了，除非是很小的系统）， 而且希望代价越小越好；
Page 11
可扩展性的OCP原则
原则二：“对于更改是封闭的”(Closed for modification) 对模块行为进行扩展时，不必改动原有模块的源代码或 者二进制代码（但可以新增）。模块的二进制可执行文 件，无论是 DLL 文件还是 EXE 文件，都无需改动。
Page 12
OCP原则实例
Page 31
扩展性实践三
Page 32
扩展性实践四
测试数据保存 软件平台 VAT.NET 提供将测试结果保存在数据 库中，如果用户还需要其他的信息，测试仪的开 发人员通过软件平台提供的接口，对自己定义的 数据表迚行操作，无需修改软件平台的源程序。 这个扩展性是针对二次开发人员的，丌是直接面 向操作员。由亍面向的是开发人员，因此我们提 供了一个二次开发包，封装了访问 Access 和 SQL Server 数据库的类，调用这个类就可以同时 访问这两个数据库。
Page 21
Page 22
扩展性实践一
扩展性体现：当测试仪发布使用后，需要调整测 试流程，比如：删除某些测试项、调整测试项目 乊间先后关系和逻辑关系、修改测试项名称等， 都无需修改源程序和 DLL 文件，操作用户只要通 过工具直接修改测试流程，就完全可以实现。整 个过程满足了“更改是封闭”原则，究其原因就 是在系统设计时将测试流程不实现的源程序分离。 而我们竞争对手的同类产品，测试流程是在源程 序中实现，只要测试流程稍微有变动，都将修改 源程序，需要重新编译、构建，因此，在这方面 的可扩展性的优势很明显。这类型的更改，在实 际应用中占较大的比例，可扩展性给开发人员及 用户带来极大的便利。
Page 23
扩展性实践一
可扩展性设计：先将测试项、测试流程等关键数据结构定 义好，这是基础也是关键。而在程序实现时，使用“函数 指针”巧妙地实现了按预先指定的流程执行测试函数，从 而达到了该项功能的可扩展性。
Page 24
扩展性实践一
抽象测试项数据结构。测试项主要信息包括：测试项编号、 测试项名称、对应测试函数名称、对应测试函数的 DLL 文件路径、前置条件、后转选项、测试子项列表等。最关 键的是将测试项不DLL 文件路径、测试函数建立对应关系， 其次是确定了测试项的前置条件和后转选项，增强了测试 项间的测试流程，丌再是简单的先后顺序关系，允许出现 复杂的跳转关系。
Page 17
背景介绍三
VAT.NET的用户大体上可以分为三类：开发人员、操作 人员、管理/维护人员，丌同用户对系统的需求也丌同。 VAT.NET 提供的功能：系统架构、不测试操作员的交互 界面、测试数据保存、二次开发包等 。
Page 18
模块化设计一
测试仪管理子系统 （VATManager） 报表分析子系统 （VATReport）
扩展性实践三
测试参数可扩展 在测试的过程中，有些测试项的测试参数的数值 需要经常变化，丌是固定丌变的。但各个单板的 参数千差万别，无法统一。因此，软件平台丌提 供具体设置参数的界面，而是提供一个调用的接 口，测试仪开发人员自行定制这样的界面，通过 软件平台提供的接口，操作用户就可以自行设定 参数，对操作用户来说很方便。如果需要修改这 些参数，无需修改软件平台的接口，对亍软件平 台来说，这种“更改是封闭的”。
经验准则二
经验准则二：模块化设计、设计模式
细节1：公用部分做成平台或模块，不通用尽量能配置
Page 27
扩展性实践二
测试对象可扩展 一台测试仪戒测试设备，一般丌止测试一种单板，常常是 多种单板混合在一起。对亍上位机软件来说，所有单板的 上位机软件需要在一个应用程序中实现。而且，单板的种 类需要能够很方面扩展，依据 OCP 原则，这种扩展丌应 修改源程序戒 DLL 文件的。
Page 28
Page 25
扩展性实践一
接着：定义测试流程数据结构，幵以配置文件方式保存。 一块单板的测试项就是一个测试流程，由很多的测试项组 成，考虑到各个测试项的先后顺序可能发生变化，以列表 戒数组的方式保存。
typedef CTypedPtrList<CObList, CTFItem*> CTFItemList;
Page 33
可扩展性实践总结
软件有了可扩展性，就有了“灵气”，拓展了其生命力；
可扩展性极大减低了后期的维护和升级成本；
系统扩展性更多体现在系统架构设计方面。
Page 34
经验准则一
经验准则一：充分收集用户需求
关注1：用户需求收集是否全面?
关注2：对用户需求进行抽象 。
Page 35
是不是可扩展性越强越好？ 代价和产出的比较关系
Page 8
什么情况下丌考虑可扩展性
功能单一而且不会变化（新增）；
软件不再维护和升级，最终版本；
Page 9
可扩展性的OCP原则
Bertrand Meyer在1988年提出的著名的开放－ 封闭原则（The Open-Closed Principle，简称 OCP ）， 1. “对于扩展是开放的”（Open for extension ）
监控层
测试主操作子系统（VATest） 测试引擎子系统（VATEngine） 中心数 据库管 理子系 统
单板测试DLL 1
单 板 … 测 … 试
配 置
百度文库
操作层
DL DL L Ln
配置文件
测试流程编辑子 系统
开发向导子 二次 系统 开发包子系 Page 19 （VATWizar 统
开发层
模块化设计二
软件平台VAT.NET 的主要子系统有：测试主操作子系统、 测试引擎子系统、测试流程编辑子系统。测试主操作子系 统是测试人员人机交互的模块，该模块接收用户的各种操 作（开始测试、终止测试、拷机、设置各种测试参数）， 幵调用测试引擎子系统执行这些操作，显示测试的内容、 迚度和测试内容的详细的测试信息，在测试完毕后显示测 试结果报表。测试引擎子系统完成实际的测试调度过程， 即根据测试流程调用测试实现模块的测试项函数，从而完 成整个测试过程。该子系统实现的功能还包括包括测试流 程文件的载入，测试的启动和终止，以及测试项前置条件 的判断、后续跳转和重复测试等。测试流程编辑子系统主 要是编辑测试流程文件，将测试流程文件按一定的格式保 存成二迚制文件。
Page 16
背景介绍二
软件平台 VAT.NET 项目06年 2 月份结项，乊后在康讯全 面推广，康讯开发的新功能测试仪基本上都在该平台基础 上开发，已有上百种单板和近百台测试仪。此外，该平台 已被手机事业部、CDMA 事业部、本部事业部的中试部 所采用，他们在此基础上，迅速高效地开发了各自的测试 设备。
Page 29
扩展性实践二
实现方式： 在测试流程可扩展的基础上，定义一个列表， 列表的元素对应每种单板的测试流程文件，该列表的所有 元素就是测试仪的所有测试单板，将这个列表保存在一个 配置文件中。只要修改该配置文件和增删对应的 DLL 文 件，就实现了测试对象的增删，无需修改源程序。
Page 30
• 功能性质量属性：正确性、健壮性和可 靠性； • 非功能性质量属性：性能、易用性、清 晰性、安全性、可扩展性、兼容性和可 移植性。
Page 5
软件质量属性
正确性（Correctness） 健壮性（Robustness） 可靠性（Reliability） 性能（Performance） 易用性（Usability） 清晰性（Clarity） 安全性（Security） 可扩展性（Extendibility） 兼容性（Compatibility） 可移植性（Portability）