英语原文共 5 页，剩余内容已隐藏，支付完成后下载完整资料
2009年第16届逆向工程技术会议
设计模式和变化趋势：使用专有C#软件的复制
M. Gatrell, S. Counsell and T. Hall
计算机与信息系统系
布鲁内尔大学，阿克斯布里奇，密德萨斯，英国。
Email：mattgatrell@googlemail.com, steve.counsell@brunel.ac.uk,
摘要. 这篇论文记录了一个关于商业上的改变，专有的软件和用来确定是否一个类的改变倾向与它的设计背景之间有一个联系的尝试；更加明确地是：一个类是否是设计模式的参与者。我们确定具体的设计模式及其倾向的变化。设计模式的参与者被发现与没有参与设计模式的类相比，设计模式的参与者拥有更高的改变倾向，上述支持了Biemanetal. 早期的一个研究；一些设计模式，如适配器模式，工厂模式和单例模式被发现比其他者拥有一个更高的改变倾向。
关键词. 模式，C#，改变
1. 引言
确定一个系统的变化趋势可以突出问题领域，从而可以通知开展补救行动。它也可以帮助开发人员或项目经理预测未来变化以及资源配置。以前经验研究软件的复制可以帮助建立一个机构的知识以支持或反驳假设的集合[2,12]。在有争议或反直觉结果的研究中发现，探索这种主张的优点是具有相当大的价值。早先Biemanetal.的研究表明以模式为基础的类被认为是比不参与设计的类更容易改变的类。在本文中，我们分析了一个类在设计背景下的变化。在复制biemanetal的研究中，我们研究了商业C #系统，是由266K行代码，7439个类和79964种方法组成。该系统在一个超过两年期间经历了19054个变化，这些变化是由于增强和故障修复。有针对性的手动检测是用来确定一个类是否是一个设计模式的参与者。模式参与的特点被用来与决定任何关系的类的变化历史进行比较。包括那些gammaetal描述的许多设计模式通过支持专业化修改来提高适应性。使用模式的系统可以通过创建新的具体类功能被修改，而不是通过直接修改现有类。因此，我们可能会期待设计模式的“参与者”类相对于其他类有相对较低的变化倾向。那些结果被发现支持早期研究；参与设计模式的类被发现比其他类改变地更频繁。
2. 动机
这项研究的动机源于几个来源。首先，据我们所知，先前Biemanetal的工作自发布以来没有复制过，但它代表了一个有争议并且有趣的研究。其次，模式是常用的开源软件和专有软件。对于开发商和渠道预知未来的维护活动和资源优先级，知识的变化趋势是有价值的信息。最后，分析标志着一系列研究的开始，相对于其他类作者打算向承担模式使用包括诱导模式故障分析类。Gammaetal记录了23种设计模式，根据文献，这些都被其他人添加到和修改该研究提出的Biemanetal剩余的模式，选定了13种这些设计模式看是否达到他们的预期效果，特别是，其相对稳定性是否跟其他类相比能够被经验实现在同一项研究中，它被显示出了伴随五种商业开源系统设计环境例如尺寸等和遗传具有什么样的影响Biemanetal研究本身是一个复制的早期的研究，被一些相同的作者在39版C 系统使用。早期的开创性研究的结果是，大的类被发现是最容易发生变化的，基于模式的类更容易改变
最后，一些工作已经进行了自动提取的模式，使用的指标和其他工具
3. 前言
这个软件作为证实研究的基础是来自于一个专门从事交易内容处理软件的大型国际软件公司，其中一位作者是该公司的一位建筑师，因此有机会进入到版本控制系统，并对系统的所有修改都有接触。每一个变更的文件和登记的需要是一个硬性规定的公司。代码本身与一个拥有8-10个成员的开发人员团队用C#编写的核心技术产品相关，此核心技术产品已运行约4年。我们分析的这一时期是基于代表最近两年的发展。该系统包括服务器IDE组件，Web应用程序和多个客户端组件和工具因此，我们将软件系统称作大约包含超过7439个类的“WebCSC”其拥有266K行代码。
3.1假设
一个单一的假设被探讨，作为我们的研究的一部分。
假设的组成与Biemanetal揭示的是一样的
假设1：模式的基础类比其他类的变化可能性小？
模式的设计，使变化是通过子类或通过添加新的参与者类（而不是修改现有的类）。
模式促进变化的易化，因此，参与模式的类应该需要更少的变化。
3.2 识别设计模式
同bieman的最初的研究中，我们重点对刻意设计模式研究。
手动方法用于识别包括了我们的步骤的设计模式（与bieman的研究保持一致）：
1、在文档中搜索设计模式名称。
2、确定类的环境的第一步就是分析对象模型
一旦这些类其文档指定一个类的模式/角色被发现，我们检查这些的对象模型的目的是用来确定构成该模式的类。
然后，我们寻找实施这种模式的类之间的联系。
3、验证候选模式是一个模式实例，我们研究了模式实现寻找低层细节，例如，所需的委托构造。
4、验证模式的目的。我们检查了每一组代表一个模式候选的类，以确定这些类和关系有一个权威模式引用所描述的相同的目的。
这些同样的设计模式像那些在Biemanetal所研究的那样作为此研究的一部分：
- 适配器模式：将一个接口转换为一个类的接口，允许通常由于不兼容的接口的类工作在一起，
2、 构建模式：将对象的结构和表示分离，通过抽象的建筑步骤。可以提供不同的实现方法，从而产生不同的对象表示。
3、 命令模式：命令请求封装为一个对象，记录所有需要在稍后的时间调用一个方法的信息，如方法的名称，该对象拥有方法和任何参数值。
4、 创建器模式：定义创建其他类的新实例的责任的类，根据是否原创类包含集合或包含类的初始化信息。
5、 工厂模式：创建几个派生类的一个实例，通过定义创建可由子类重写指定的派生类型对象的方法。
6、方法模式：允许子类来实现可以通过重写方法改变的行为。
7、过滤器模式：允许插入式过滤器拦截传入或传出消息，过滤器可以无声无息地添加或删除，无需修改现有代码。
8、迭代器模式：不暴露底层表示的顺序访问集合的元素
9、 代理服务器：一个对象表示另一个对象，允许一个类作为一个接口，以一个不同的对象。
10、单例模式：一类只有一个实例可以通过限制实例化一个对象的存在的。
11、状态模式：允许对象在状态变化时的行为的改变。
12、策略模式：封装在一个允许算法被动态交换的类中。
13、访客模式：通过将该算法与操作的对象结构分离，定义一种新的操作。
3.3确定变化
在版本控制系统中的每一个修改，无论是故障修复，增强（或其他）构成了一个新版本的类还是每个版本被算作一个单一的变化。为了本研究的目的和调整biemanetal的研究。，我们假设每个变化相当，即没有考虑代码行受变更影响的相对大小的变化。
4.数据分析
两年期间，共有19054个改变了的7439类的系统.其中4434个类他们都在同一时期没有变化。大量的类有2到30个之间的变化，只有29个类有30个或更多的变化。最经常改变的类有145个变化发生，第二多的类有75个变化，最多的几乎是变化第二多的类的两倍。
表1显示了每个类的变化的频率。29个类有超过30个的变化，56个类有20到29个之间的变化，以及280个类有10和19个之间的变化。
表1.改变数量/类
|
0个变化 |
1-9 |
10-19 |
20-29 |
gt;=30 |
|
4434 |
2687 |
280 |
56 |
29 |
对具有小于10的变化可以从表1可见类总高偏差，4434个类并无变化，有2687个类有1和9个之间变化，在系统中每类变化平均数（包括模式基础类）是2.55。
4.1模式类和变化
我们探索的假设是，是否基于模式的类比其他类的变化少。总的，在7439个类外有658个其他类被发现参与设计模式。类相关的单例模式和策略模式被认为是最流行的（分别具有168和101个类，）；而创建器和方法模式为基础类分别相对于只有5和8个参与者类是不常见的。没有找到一个基于迭代器的类，但在系统中只有一个代理被识别。但是，显著的统计结果是，没有参与故意设计模式的类的平均变化是2.51个，与类变化的平均数量相比，参加故意设计模式的是6.34个。五种模式，即适配器，方法，代理，单例和状态模式与整个系统相比被发现有一个非常高的变化率。战略和访问者模式也被发现有一个相对更高的变化倾向。工厂和过滤器模式被发现有一个接近正常的倾向变化（当与系统平均数相比），而命令和创建者模式实际上比整个系统的平均有一个较低的倾向。表2显示了13种模式中的每一种模式的变化数据。当手动检查的模式类，有超过正常的变化率，我们注意到，许多这些类包含执行代码，这不应该是模式类的责任去提供。我们怀疑，因为对这些模式类的强烈熟悉，系统开发人员很自然地选择了这些模式类作为产生变化的焦点，而不是贴近周围的类（这将是一个更合理的行动过程）。这是特别为最高变化的模式案例：适配器，方法，代理，单例和状态模式。换句话说，我们的研究揭示了为什么模式为基础的类可能会更容易改变-这是因为熟悉这些类的开发，使他们很容易适应和变化。
表2.模式类的改变
|
模式 |
类 |
改变 |
平均数 |
|
适配器 |
74 |
466 |
6.38 |
|
构建 |
64 |
176 |
<strong 剩余内容已隐藏，支付完成后下载完整资料</strong 资料编号：[153476]，资料为PDF文档或Word文档，PDF文档可免费转换为Word |
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
