SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 4807|回复: 1

[推荐] 利用以代码为中心的开发和建模实现成功的代码重用

[复制链接]
发表于 2012-5-15 11:29:02 | 显示全部楼层 |阅读模式
本帖最后由 技术狂人 于 2012-5-15 11:32 编辑 ; `( n6 W7 R: J: D6 F
( C3 b/ t) `1 u# f' N7 y
新的开发项目往往从现有的源代码开始。了解代码对于重用是必不可少的,重用并不像看起来那么简单。例如,也许原来的开发人员已经离职或退休。代码可能一直由多个开发人员编写,或来自多个来源。代码的存在形式可能是您的公司所拥有的代码、外部代码(例如,开源或现成的代码)或库。它很可能在多年后已经有所改变和发展。无论代码的历史如何,您需要知道源代码如何进行交互,以及它包含哪些内容。您需要了解如何将代码结合在一起,将来如何最好地利用它,以及您可能想修改哪些部分。- N2 ^/ n6 {! w$ o6 ^" y% K

* p: j& N+ S. M) Z8 `6 [& k代码分析的原因* Z. P2 x$ c, }9 t5 M$ l4 l  _$ z
' q. Q2 z0 L& [  g3 J1 Q9 @* [: [
分析代码的主要原因可以概括为:文档、重用、修改或维护。根据具体的情况,其动机包括:
& b: V# T" p4 l0 Y& f- e+ \
  • 记录您的代码,以便您更好地理解它,并为下一次开发人员退休或离职做好准备(“记录” 意味着有用于解释代码的图表)
  • 建立产品线,其功能都在一个产品中,而在另一个产品线中,您可能不需要该产品
  • 将应用程序修改或更新为一个新版本
  • 维护现有代码1 e6 C/ I! \2 r6 y; c2 Q
所有这些原因对于更好地理解代码都是合理的。本文着重于重用原因和实现重用所必须的代码分析。
4 K) Z. W/ ]( e: K! p1 z

8 o& e8 i  z/ M" ?: x$ J: v- F( r8 G. e6 a2 y5 v; m+ G
重用的风险
1 A9 r6 [' G* G) E; m( k. Z4 R0 j3 {5 i' I1 o
重用有潜在的风险,某些具体的原因可能导致重用失败。证明投资的挑战之一,是某些管理人员不允许团队花时间了解旧代码。失败的另一个潜在风险是缺乏对代码的域和组件的了解。分析瘫痪又是另一个潜在的风险。
# G4 `$ m% V' {1 f5 q努力了解所有的代码可能是一项艰巨的任务,分拆现有代码并确定要重用的关键代码非常重要。前期应该多花一些时间来评估应该重用哪些代码组件。在某些情况下,可能有必要记录在您的代码中所做的一切(如监管的原因),但是,试图重用并记录所有代码的效率通常并不高。在大多数情况下,我们的目标是智能地确定要记录哪些代码块,以及要重用哪些代码块。
7 V* P# |0 V$ I- m/ x/ G* Y

  Q- R" @+ G8 U, a) Y成功的四个关键要素" t0 S; c# H/ Z2 v) K8 _  [

, h3 u: t( G4 k, x要获得成功,关键要素是:- \- \; U1 G- _0 @- m+ j& y
  • 了解原始代码的架构,从而识别组件、边界和接口
  • 确定潜在可重用的代码
  • 估计重用与重构组件的时间比较
  • 基于每个组件确定重用哪些内容以及重用的方式:不需要更改、小的更新和主要更新
    8 a5 i. F: J" F. l6 }


$ d- L4 q5 j( f# J使用统一建模语言澄清软件代码
( @+ P" E, b/ ]无论您什么时候想获得对代码的明确了解,统一建模语言 (UML) 都是一个很好的方法。UML 是一个用于表示代码的标准图形化语言。它使您可以说明代码实际上在做什么,而这反过来又可以使您看到组件设计的全局。UML 使您能够理解原始代码的架构,从而识别组件、边界和接口。UML 澄清了代码是如何结合在一起的。您可以使用 UML 来分析你的代码。分析是记录代码之前的第一步。
' k$ t. ~% j3 N9 @
- j7 B2 X# u+ x' ]6 W; o利用 UML 建模组合以代码为中心的开发1 J1 p% `8 D; ]; D
1 Q4 B0 V# e  g! Y6 b
本文前面说明了成功的四个关键要素,其中一个要素是基于每个组件确定重用哪些内容和重用的方式。如果您想保持现有的代码并记录它,那么您可以继续采用以代码为中心的开发方式,但要将它与建模相结合。您可能不需要在模型中生成代码,但您肯定想更好地沟通和了解现有的代码如何组合在一起。通过将以代码为中心的开发与建模相结合,可以做到这一点。
7 L7 X9 B2 k9 |如果您想了解现有的软件代码,以便能够重用它来创建新的产品或维护多个现有产品,那么模型驱动的开发可能是最佳解决方案。通过采用以代码为中心的开发,并结合模型驱动的开发,您可以确定自己要维护和重用代码的哪一部分。
8 u3 j- T+ M& g: ^术语的定义/ H1 x  E7 O! q* a6 {
2 T2 \  b8 F8 s$ S; d8 M
以模型为中心模型不仅驱动架构,还驱动最终的应用程序代码。
) E; }8 F% @$ {  ]9 R6 D8 d( C 以代码为中心将代码作为一个可视化的参考导入模型。这意味着将使用模型来帮助显示架构,但永远不会改变代码。为了更新设计,您需要更新代码,然后将它再次导入模型。
! e) m4 _, W5 \0 c8 v+ y. ?9 t 动态模型代码关联 (Dynamic Model Code Associativity, DMCA)在 IBM® Rational® Rhapsody® 建模软件中,这表示更新的方向。您可以从模型到代码进行更新,或者从代码到模型进行更新,抑或可以指定双向自动更新。往返 是将代码更新带进模型的过程。' t& o. a% e& @9 m5 o; Q1 U, X
! d3 O0 P1 p4 g+ f' K2 ]9 H! |
不同类型的用户喜欢的开发场景是不同的。喜欢在模型中工作的用户被称为 “以模型为中心的用户”,而以代码为中心的用户喜欢在代码中完成所有工作。还有一些人处于两者之间。您可以使用您选择的代码重用和建模类型来适应不同类型的用户。不同类型的用户可以利用传统编码和以模型驱动的开发相结合来进行协作、共同努力。
; o9 |( I2 u) @技术定义可以映射到下一节中所描述的三种不同场景。1 ]* z  Z6 o' P0 |9 i

9 m; J( r8 [. G$ G( r# I7 s# X: H注意:+ L* t5 |$ q- H7 Y, ^" F$ h
这些定义可以在组件的基础上使用,也就是说,应用程序中有一个组件以模型为中心,而另一个组件可能以代码为中心。& h# _( i: P: I$ X. `% S1 x
以代码为中心和以模型驱动的开发相结合的场景# M! C" z8 S8 {
您可以使用几种方法来组合传统的代码重用与建模。选择范围可以在较高的层面上描述为以下四种场景:
: a4 G8 ?8 J) X# b
  • 可视化外部代码(仅可视化)是一个以代码为中心的流程。外部代码对于可视化建模工具而言仍然是外部的。您可以在建模工具中引用外部代码来使用和测试它。
  • 利用更新的文档持续编码 是一个以代码为中心的流程,支持将更新发送给模型。您可以在一个模型中可视化代码,但永远不能改变模型。
  • 以代码为中心的开发,在模型中进行的修改被生成代码。此开发是以代码为主。
  • 使用模型驱动的开发实现代码现代化,该开发以模型为主。确定要重用外部代码的一部分,并将它们直接带入模型。) R* K  `+ c: K
可视化外部代码
( |# f8 T6 W% l
/ ?( k4 K8 f. b6 ^7 ^可视化意味着您将使用图表帮助您了解代码的设计、结构和对象(比如类和文件)之间的关系。作为一个用户,您还能够根据模型元素创建新图,在图中添加注释,并将模型元素与需求相联系。来自代码的元素描述被保存在模型中,并可以通过在模型上制作报告,然后将该描述生成一份报告。在模型中还可以更轻松地完成变更,比如添加可以在图上绘制的元素,在图上复制元素,继承元素等等。
( B. ^1 W+ q2 Y" e! Z( o" a) Y3 u( U4 k/ l7 w3 H. d* n4 u
利用代码可视化,代码的更新可以在建模工具外部的代码中完成。执行外部代码的可视化,向模型展示代码中的关系。例如,您可能希望引用外部 C 库,并在图中显示该引用。可以采用这种方式可视化和记录库与模型其他部分的关系。可以在模型内部完成库的以模型驱动的测试。利用模型驱动的开发,您不仅可视化自己的代码,还可以执行您的模型,从而验证和测试该模型。
! Z( U& A4 ~) F- j3 A+ q  k# ]9 T4 m! T8 M0 `+ E# `
利用更新的文档持续编码
' p" R: M: P( @3 X$ v  ^% u4 Q0 C6 |0 M; w% ^7 l8 s2 \
在第二个场景中,由于对外部代码进行了更改,所以可以执行往返操作,将代码变更发送到模型中。该操作将从外部代码带入修改后的代码来更新文档。如果您选择可视化和更新代码的选项,那么您可以继续在模型或在外部代码中开发代码,并保持两者同步。8 u% l; \0 l- s3 `' w
8 ?7 k9 x8 m: l) o- d# w8 ]0 T; S
以代码为中心的开发 * W( L6 \1 o! |7 r' Q' G2 H$ F2 W7 r
. @  U- P: r: _! q
如之前在场景 3 中所述,您可以通过在 Rational Rhapsody 中生成代码并用变更来更新外部代码,从而利用模型驱动的开发来现代化代码。代码生成可以在建模工具中完成,同时在原始源文件中保留现有代码的指引。在模型中运行代码生成的选项,有助于将变更从模型带回代码中。可以使用模型动画来显示代码的行为。在这种场景中,开发是以代码为主的。
' \( R& E) K7 G3 k/ p
  i0 X+ J1 h9 k. X+ \' M- L使用模型驱动的开发实现代码的现代化 " y4 k* k8 {" v, H

0 R9 M6 e+ Y' Y+ {( F您可以选择在模型中维护代码。这是场景 4 的基础。您希望如场景 1-3 中那样完成可视化代码,还是直接在模型中维护它以执行模型驱动的开发,决定这个选择的关键条件是,您是否希望在模型中严格地生成代码。如果您在模型中维护代码,则可以更高效地执行更多设计变更和增强。此开发是以模型为主的。3 L0 M/ _, R  f! p
Rational Rhapsody 现在显示了一个简单的示例,展示了 UML 如何实现现有代码的重用。该示例讲述的是一个用户如何基于现有的硬件建立一个新的收银机。第一个图被称为 Package 图。它提供了一个系统包的高层次视图。这些包是 CashRegister、Hardware 包,以及通过 Interfaces 包实现的两者之间的链接。Interfaces 包使得 Hardware 易于重用,并且支持按需要将现有硬件交换为新硬件。
7 D8 j4 _+ I* j9 v9 y. M4 L& ~7 A3 m; N3 S
图 1. 包图
1 z+ ^) |* u+ H: Z! p- z 6 ~6 I$ I8 w6 C& R1 C8 `
下面的类图显示继承自接口 IBarcodeReader 的 Cash Register。这使 CashRegister 类可以实现接口,并从 BarcodeReader 类接收通信,那么 BarcodeReader 类需要来自外部硬件包。BarcodeReader 不需要在图中显示,尽管图中显示了 Barcode Reader 接口(图 2),因为 CashRegister 只需实现可以获得所需行为的接口即可。
7 `0 z# L1 ~4 B! ]4 ~5 V
+ e) g, p4 b( q6 v图 2. 类图
9 [; t  X$ e4 C, [9 Z" j4 j, d , R% a4 {+ B! [" y# {; n+ d
图 3 中的类图显示的 Tester 类执行包括 来自外部源的 C 源文件。外部源被可视化,以显示来自 point_of_sale 文件的操作和变量,所以 Tester 类可以决定自己能够调用什么。! y$ k# w' }' v2 Q, @1 D3 J

2 O7 A, Y% _5 F图 3. Tester 类包括一个来自外部源的 C 源文件# \; P9 c$ m5 x9 y! a

) \( U7 }: m  w# r! \, @7 g# [在图 4 中,动画序列图显示的 CashRegister 类,扫描产品上的条形码,并将产品添加到顾客的账单中。
) s: B% m4 [& O, B( g6 Q! {5 `; Z! ?7 q
图 4. 动画序列图7 m( T  `0 {+ i* L, C, y

* X8 z5 R3 E; k动画可使您能够在主机或目标上执行应用程序,然后使用 Rational Rhapsody 在设计中查看结果。这是一个重要的工具,可以查看代码的行为并调试代码,当您在重用代码时,这些工作非常重要。查看静态代码只会向您显示通过它的潜在路径。图 4 中所示的序列图显示了当应用程序真正响应外部刺激时通过它的路径。因此,您会看到在应用程序的真正生命周期中执行了哪些路径。因此,动画模型是一种测试和验证您的可重用代码行为的方法。
- h. Z5 {. R' E. `9 w

' Z4 j" p9 r0 c- \) e重用和产品线工程 (PLE)" w8 G- L, ]1 R1 U: I  A& S4 \
  v2 P6 c& Q/ C. }
重用的制胜法宝是所谓的产品线工程 (PLE)。PLE 是一种实践,可以识别应用程序中因产品而异的特性,并将这些特性映射到每个产品的特定变体,那么,在最后,您会有一组支持多种产品的代码。因为重用的主要目标是在未来的产品中实现重用,所以这是一个制胜法宝,也是 PLE 的目标。# ]  j2 U% q/ p- E
构建多个产品中的其他选项是克隆并拥有 产品,或者使用 ifdefs
- D# F+ U+ q. _" q8 A. B
  • 克隆并拥有产品带来了一堆问题,例如,当您在一个产品中发现一个 bug 时,该 bug 是否也存在于其他产品中?当您想将某个特性传播到所有产品时,会发生什么呢?寻找克隆中的变更会是一个噩梦。
  • Ifdefs 使代码变得不可读,并且当尝试在某个特定产品上工作时,代码会变得非常难以导航。- C) ]- o" y# J& D% a
建模通过在代码上添加一个抽象层次,这有助于解决此难题。您可以在映射到特性时识别特定的模型元素(类、函数或其他任何元素),然后为产品特定的差异添加标签。因为它是图形,所以标签可以是链接,您可以根据需要调查这些链接。此外,当您从模型生成代码时,它只使用产品特定的标签,让您可以获得每个产品的定制代码。然后在模型中进行相应修改,拥有该特性的每个产品都会获得这些变更。不需要从产品到产品地传播变更。( e9 N% M/ A& v3 g, p! _7 ^: Z


) z, x: f; m, Y结束语
9 i0 J9 B2 v/ z; G" e总之,因为时间线很短,所以重用对于满足最后期限非常重要。关键是如何在您的操作中构建有效的重用。首先,请确保您了解自己的架构,然后深入了解要重用的组件。建模在这个过程中非常有用,因为它可以帮助您对代码进行分析,并决定重用哪些内容。当您了解整体架构之后,将您的产品构建到一个完整的 PLE 工作流中就会变得更易于完成和维护。, w! g4 P) ~5 H$ v) z! k: ]
' I# R% W- R+ d* j) E$ ^6 n

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
 楼主| 发表于 2012-5-15 11:31:35 | 显示全部楼层
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2018-6-22 11:44 , Processed in 0.077607 second(s), 9 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表