| 查看: 244 | 回复: 3 | |||
| 当前主题已经存档。 | |||
| 当前只显示满足指定条件的回帖，点击这里查看本话题的所有回帖 | |||
p1801321金虫 (著名写手)
|
[交流]
[重金求助]以下两大段的翻译
|
||
|
谢绝软件翻译，不给金币，分隔线上下各15币 By and large, the approach worked well on the case study. Although we have not yet been able to assess the efficacy of design rules in ongoing development, we found the tool very helpful in extracting the architecture, identifying problems and checking the results of refactoring. Our experience confirmed the value of the two key features of DSM's: the hierarchical structure, and the partitioning algorithm. Without these features, we would not have been able to handle a code base even of this size; a boxand- line diagram extracted directly from the code is unintelligible. We had two kinds of problems. First, matrices, such as the DSM, while inherently more scalable a representation of relations than graphs, are not always easy to read. In particular, finding the cell that corresponds to a relationship between two elements has a greater cognitive overhead, and following the edges of a relation transitively requires going back and forth between row and column indices rather than simply following arrows along a path. With time, however, our proficiency at reading DSM's increased. Second, there were limitations of the underlying dependency model. Haystack's design involves two orthogonal classifications; while we could have constructed two separate DSM's, we would have liked to have been able to use the tool to understand the interplay of dependencies between the two views. Also, we occasionally wanted a more refined notion of dependency, which maps a client class to the class it uses at runtime rather than to the class it declares as a use in its code. There seems to be no fundamental reason why a richer dependency model (such as [6]) could not be incorporated into the tool. ------------------------------------------------------------------------- The importance of understanding dependencies between modules has also been understood and emphasized by other researchers. Our work is perhaps most similar to the work on the Reflexion Model Tool (RMT)[3]. Our design rules combine the reflexion map and the idealized model. When there are multiple, orthogonal views of the architecture this will make our design rules less succinct than the idealized model of RMT; on the other hand, when a single hierarchy is dominant, our design rules are likely to be simpler to express than the model and map of RMT together. We believe that our hierarchical matrix representation scales better than the graphical representation of RMT. The use of DSM algorithms for architectural discovery is a major benefit of our approach; it would be interesting to see how it might be incorporated into RMT. Hierarchical representations are, of course, not new. Tran et al. [4] examines systems in terms of their hierarchical decomposition, using Harel’s higraphs. Heuristic algorithms for organizing a system into layers have been investigated in the context of the reverse engineering tool Rigi [16]. Rigi seems to be less flexible than LDM in allowing a mixture of manual and automatic organization, and in terms of its ability to scale. We have not been able to evaluate the effectiveness of Rigi’s algorithms in comparison to the DSM algorithms, but such a study would be worthwhile. A number of tools are available for extracting dependencies from code, such as sa4j from IBM, OptimalJ from Compuware and JDepend from Clarkware Consulting. These do much the same as the frontend of LDM. Jackson [6] has proposed a more elaborate notion of dependence, in which interfaces are not treated as modules in their own right, but rather mediate dependencies. We plan to explore whether this notion might be useful in our context. A dependence-based view of software is, of course, only one of several useful views. In Kruchten’s “4+1” model of software architecture [8], our representation of the system corresponds roughly to the ‘development view’. |
回复此楼» 猜你喜欢
假如你的研究生提出不合理要求
已经有8人回复
-
萌生出自己或许不适合搞科研的想法，现在跑or等等看？
已经有4人回复
-
Materials Today Chemistry审稿周期
已经有4人回复
-
参与限项
已经有3人回复
-
实验室接单子
已经有4人回复
-
全日制（定向）博士
已经有4人回复
-
对氯苯硼酸纯化
已经有3人回复
-
求助:我三月中下旬出站，青基依托单位怎么办？
已经有12人回复
-
所感
已经有4人回复
-
要不要辞职读博？
已经有7人回复
syh9288
捐助贵宾 (著名写手)
海军上将
- 翻译EPI: 6
- 应助: 2 (幼儿园)
- 金币: 1598.6
- 散金: 543
- 红花: 1
- 帖子: 1046
- 在线: 475.4小时
- 虫号: 735351
- 注册: 2009-03-30
- 性别: GG
- 专业: 应用高分子化学与物理
★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★
p1801321(金币+15,VIP+0):谢谢兄弟！ 12-9 14:16
p1801321(金币+15,VIP+0):谢谢兄弟！ 12-9 14:16
|
总的来说,这个方法在研究这种情况上有着很好的作用。虽然我们还不能去评估在今后的发展中这种设计规则的有效性,我们发现：这个工具有助于简化结构、识别问题和检查重构的结果。我们的经验确定了DSM两个关键特征的重要性是:层次结构矩阵以及划分算法。如果没有这些特点,我们将不能掌握甚至是这个尺寸的代码基；直接从代码中得到box-and-line图是不明智的选择。 我们现在碰到了两种类型的问题。首先,矩阵,如DSM，比曲线还能扩展伸缩的一种内在的联系表示形式总是很让人费解。在特定的情况下，与两个元素之间关系相呼应的一个小的缓存区有着更大的认知超越能力。关系链的传递不是在行与列的字符串之间前后移动而是简单沿着一个路径按照箭头的方向传递下去。然而,随着时间的推移,我们阅读DSM的效率会提高。 第二,对于这种潜在的链接模型有诸多限制。 Haystack的设计包括两个正交分类。 如果我们能构建两个独立的DSM，我们将极有可能通过利用这种工具来理解这两种视图之间的链接的相互影响。我们有时也想给链接一个更加精炼的概念，这样就可以为那些在时间运行层面上而不是需要在代码中使用的一类链接提供匹配的客户端。 似乎没有理由来解释为什么一种具有更多链接的模型(如[6])不能被纳入到这种工具中。 |
3楼2009-12-09 11:25:12
2楼2009-12-09 04:43:12
syh9288
捐助贵宾 (著名写手)
海军上将
- 翻译EPI: 6
- 应助: 2 (幼儿园)
- 金币: 1598.6
- 散金: 543
- 红花: 1
- 帖子: 1046
- 在线: 475.4小时
- 虫号: 735351
- 注册: 2009-03-30
- 性别: GG
- 专业: 应用高分子化学与物理
★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★
p1801321(金币+12,VIP+0):谢谢兄弟！ 12-9 14:17
p1801321(金币+12,VIP+0):谢谢兄弟！ 12-9 14:17
|
理解模块之间链接关系的重要性也被其他研究者认识和强调。我们的工作或许与开发Reflexion Model Tool(RMT)[3]的工作有很大的相似性。我们的设计准则结合了反射图和理想化模型。当架构视图是多样的和正交的，这将使我们的设计规则比RMT的理想模型更加复杂;另一方面,当一个层次占优势的时候,相比RTM的模式和映射，我们的设计规则可能要更简单些。我们认为我们的分层矩阵表示尺度比RMT的曲线表示法要好。 对于发现架构的DSM算法式的使用是我们方法的一个很主要的优点;去检查它是怎么样被纳入进RTM是一件有趣的事情。当然，目前多层次表示形式是很新的。根据他们的层次结构分解，Tran等[4]利用Harel的Higraph语言检查系统的层次分解。在逆向工程工具Rigi[16]的背景下，用于将系统层状化的启发式算法也被研究,。在容许手工和自动组织方面，根据他们的缩放能力，Rigi似乎没有LDM那么灵活。与DSM算法式相比较，我们没能评估Rigi算法式的有效性。但这样的研究是很有价值的。 大量的被应用于从代码中提取到链接的工具能被得到,如IBM公司的sa4j和Compuware的OptimalJ以及从Clarkware Consulting的JDepen。这些工具有着与LDM一样的前端。 杰克逊[6]提出了一种更精细的链接,在这里界面不被视为自主模块，而是起调节作用的链接。我们计划去探索这种观点是否能应用于我们的研究之中。 当然一个以连接为基础的软件视图仅仅是多种有用软件的视图之一。在Kruchten“4 + 1”软件架构模式中[8],我们系统的表示法大致与开发视图相适应 |
4楼2009-12-09 12:52:12