SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 5099|回复: 1

[推荐] 利用RSA定义应用程序架构,第 2 部分: 迭代优化架构

[复制链接]
发表于 2012-4-23 13:29:38 | 显示全部楼层 |阅读模式
本帖最后由 技术狂人 于 2012-4-23 13:37 编辑
' v9 @) I- S* D4 ^% I$ V
8 R& U$ i7 x5 \( S0 h简介" x, F8 b  ]/ ]8 |

: e1 D6 ^) I# d; C" m$ z! `架构构想是一个灵活的最佳实践,可以概述用于指导软件密集型系统的开发和测试的技术决策。软件架构师通常使用以下步骤来勾勒软件密集型系统的目标架构(请访问本系列第 1 部分,参阅 参考资料 部分):
* b5 w1 Q# ]% z8 h' L
  • 确定重要的需求
  • 确定候选架构
  • 定义初始部署模型
  • 定义域模型; s5 p) X4 e5 y! S; S
) o: A5 l; P/ U  J
但架构思考并不是一次性的活动。它是经验丰富的敏捷团队融入其开发工作的一项持续性工作。在您的团队逐步构建系统的过程中,您会发现新的技术挑战,并制定出新的架构决策。! X4 Y, x. Y1 Z: ~
以下架构活动通常在开发迭代过程中执行:
+ H1 g+ a1 y) r' ~, j
% g) A7 B% ~  _5 F) a- K0 j3 x
  • 优化架构机制:可以满足在第一步中确定的架构性重要需求的技术概念。
  • 优化设计元素:架构性重要设计元素
  • 优化部署架构:部署单元和拓扑
    6 Z8 r0 U6 v0 ^% c5 Q

% T! l' j4 \4 u& ~0 Q$ {
( g& u0 W. V( _6 l- j
以迭代的方式优化架构7 q5 z) M. x  w! U/ z; h
像我们了解的那样,通常您并不需要为系统的所有部分指定设计。就像项目中的其他部分一样,只有某项工作会为您带来价值时,您才会执行它。但软件密集型系统的某些部分必须比其他部分指定得更详细。这可能是因为某些组件非常难以理解和实现,或者因为它们影响了其他子系统的关键元素。有些组织需要制定更详细的规定,然后才能将开发转交给业务合作伙伴或地理分布的开发团队。有些团队必须更仔细地指定并记录他们的架构,以满足合规要求。+ }" F9 f4 a% w% s: ^  G. Y& x
优化架构机制
  W2 A1 i1 `2 w6 m1 L可用的电子书从作者的博客文章下载电子书 "Evolutionary architecture with Rational Software Architect v8"。 # K5 y! k; U" N4 e1 K) `9 n: O% H  t
5 T- @' e' B5 P9 x! y- G
如果您的团队需要指定一个组件的设计,那么您可以从定义架构机制开始实现该目的。
1 x% u: c# ?. j: H' [& y5 |; y( ~这一阶段的目标是,对实现系统的重要需求所需的分析类进行定义。换句话说,您要确定满足特定业务需求所需的所有元素。
: z( Z8 f; p. T为了获得更好的可视化表示,可以选择将这些类与一个分析构造原型 (stereotype) 相关联。使用 Boundary 构造原型来代表一个类,作为系统的接口。使用 Control 类描述一个组件,执行对其他类的控制。使用 Entity 构造原型指定承载数据的类。3 ~* u- B, F: C, U
这些分析构造原型的图形表示如图 1 所示。
" \3 ^' Y* u/ C: b4 Z1 [
9 L; E, ~7 F' w4 f' o* l图 1. 分析构造原型6 v, C7 |! ^8 Q5 V
0 x. E' n" \+ J% u
图 2 显示的分析构造原型适用于系统的一个重要需求。在 Yummy Inc. 的示例中,订单业务涉及一些元素(分析类),如顾客、菜单和支付处理。, T" r8 X. ^; K, Y
( b$ v6 A1 o2 C7 Z( q4 N' l" |' \
3 f1 f2 Q9 N; U4 L0 I
图 2. 订单包的分析元素7 m$ S0 L' x4 v1 ^
- D, ^. X# y+ A* ^5 k' E/ Y
在确定分析类(参见图 2)之后,您可能还需要定义某些重要需求的静态和动态方面。: K+ @; K  a) G# S. T
这一步的目的是,为每个重要场景定义其静态和动态两个方面。Rational Software Architect 通过提供一个用例实现模板来帮助架构师完成这项任务。; G3 F9 {4 d+ P: M2 J5 S" r# @
默认自带的模板(图 3)有一个记录静态方面 (Participants) 的类图,以及记录动态行为的一组序列图(Basic Flow、Alternative Flow 等等)。
/ J8 s9 h" K$ [2 X  {6 l
  R3 J) W. _7 [3 o8 e图 3. Order Menus 功能的用例实现模板9 ^' E& h4 X" ~
! h6 J: Y" r4 |8 V3 |0 C8 Z
每个图分别解决组件的一个不同方面。类图(图 4)描述在用例实现(动态)中所涉及的所有类,而序列图(图 5)则说明它们之间的交互(动态)。* M7 i3 q9 y8 V  v
& v6 J/ |' ]  P0 a- S2 B
图 4. Order Menus 功能的类图2 W, Q6 e0 F% H' a# w

& r! @6 |1 A) O8 {9 c9 K& q
: B* ?" A4 o& n; C图 5. Order Menus 功能的序列图
! S. N# C0 _! L6 s8 L$ a/ d7 ~
+ k, N. C7 V6 y( Q; ^9 C0 L! u在结束此步骤时,您已利用 UML 模型开发了系统的一些重要需求实现。当您需要描述软件密集型系统的静态结构和某些组件的行为时,这是架构中的一个重要组成部分。
+ {: u5 `1 u0 R4 X- X9 @# l' I# x
由于 Design Model 仍然是与技术无关的,所以您可以将它重用为多种实现的起点。
5 x' q8 s4 }$ f/ A- F: K& a优化 Design Model
8 I7 e; ^; g: a& n2 `当您定义好您想如何在分析模型中实现重要需求之后,就可以深入研究组件的具体设计了。5 k  d: O' M- d( S1 G9 Z1 ?
虽然 Design Model 是抽象的,但 Design Model 必须更接近于实际实现。软件架构师通常需要确定与实现解决方案所用的技术相关的一套目标和约束。Design Model 通常不是从头开始开发的,而是从您已经定义的分析模型演变而来(参见图 2 和图 3)。
% l/ a: @' R4 ^9 h在我们的示例中,Yummy Inc. Online Catering 是使用 Java EE 平台开发的。数据持久性利用了 Java Persistence API(参见 参考资料),应用程序逻辑通过 Session Beans 实现,而交付服务的访问则通过 Web 服务实现。7 U5 q: m- J8 V# `& a+ U
在架构和设计中,广泛采用的最佳实践是:定义解决方案的不同层次,以及它们如何相互关联。Java EE 的 n 层架构在各层次之间促进了关注点的分离。! c. \7 |1 M% _  [7 s
在 Rational Software Architect 的 Architectural Layers 透视图中,设计模板提供了一个视图,供您定义层与层之间的依赖关系(图 6)。
% Y3 s- w: B- d* X5 B; Y$ F
4 S3 E2 ?; t. W图 6. Online Catering 系统的 Architectural Layer Dependencies 视图) o/ y/ u5 b9 E& _1 Z

# X+ j1 Z5 f0 K  t2 G( F& i利用已定义的架构层次,软件架构师可以生成设计的第一次迭代。Rational Software Architect 设计模板为该活动提供了一个预定义的结构。组件规范通常包含用来与组件进行交互的接口和数据(图 7)。它通常是软件架构师需要定义的第一个方面的内容。对于每个组件而言,需要指定它操纵的数据和接口(包括可用的操作),这是很重要的。
4 c( C" u( ^! F+ a8 }, s1 R, F& r7 M" D7 }9 U

' @; j8 d* P4 _; `" w0 U4 B图 7. Online Catering 系统的设计包( Q# S4 S; K' y# \0 m6 s
- g9 X# \" l+ y  U5 e6 W+ a( J- l) t
请注意,因为在这个阶段已选定实现平台,所以我们可通过特定技术信息来丰富设计模型。在我们的示例中,持久性对象都标有一个JPA 构造原型,用于确定如何将对象模型映射到数据库。
) r/ j. M4 X5 S. m0 n对于软件密集型系统的某些组件,您可能会更详细地指定设计。请记住,只有在可以帮助您的团队实现和交付应用程序的情况下,才可以在设计中添加细节。在图 8 中,已针对特定目标创建了详细的类图。团队希望使用由 Rational Software Architect 提供的一些转换,根据设计模型生成 Java 代码(有关转换的更多信息,请参阅 参考资料 )。
# j. \, d2 z) C' T: B" x/ Y
8 A+ J9 `6 R, W$ @3 L2 C图 8. 用于代码生成的一些详细的类图2 [# O! S7 G9 W0 _0 j2 c, H

) n  m& S9 E7 L4 R5 w! y' Q为某些组件创建具体设计并不总是软件架构师的责任。根据项目团队的规模和技能,可以相应地将软件设计师承担的任务分配给一个或多个不同的人,如高级开发人员(架构、设计和开发之间的界限有时并不那么清晰)。* \& r; w0 T4 W- s0 e$ x$ d) [
优化部署架构) B  h6 Q  E0 V5 \, q$ S
架构师负责建立满足业务需求的系统。软件密集型系统的重要方面之一是,如何在物理架构上部署它们。初始部署模型通常是在构想架构时定义的(请参阅 参考资料 部分,访问本系列第 1 部分)。随着项目的进展,架构师会优化部署架构,以整合与生产环境相关的非功能性需求和约束。
/ A/ ?9 T4 T) a2 W/ F& u) q利用 Rational Software Architect 的部署规划工具,您可以创建拓扑来显示信息技术资源之间的关系。您还可以规划和验证部署场景(有关利用 Rational Software Architect 实现部署规划和自动化的更多信息,请参阅 参考资料 部分)。% L/ @) Z! C% d+ |) I" }2 d
Rational Software Architect 有助于在抽象的不同层次实现部署分析。您可以创建逻辑拓扑,从而捕获与软件密集型系统的运作架构有关的决策(图 9)。在逻辑拓扑中,您可以高度抽象地描述某个系统。您可以指定如何组织和连接应用程序的组件,将它们放置和托管在哪个地方。请注意,代表解决方案的单元并不总是从头开始创建的,而是从 UML 元素派生的,以便可以实现更好的可追溯性。0 i, r0 Y& T1 @8 \0 `9 j& I6 E$ P5 E+ a

- r. }: R# I2 V+ n' p0 B5 O% |图 9. Online Catering 系统的逻辑拓朴示例
$ `7 j$ R, M1 } ' ^, m( `' B: O. D4 v

$ o) S0 [. r% i. i0 n4 f' D架构师也可以定义一个拓扑来描述如何部署应用程序。这种类型的模型描述了应用程序的具体、完整的部署实例,以及部署应用程序的相应具体基础架构(图 10)。
5 l$ H! m& w. l1 O7 L0 g/ \# ^( }4 N/ U; i7 a8 k1 \
图 10. Online Catering 系统的详细部署模型示例
) ^( ]6 M- l) @( U- [" M
$ R$ j; Q/ x2 n7 G* P
1 N6 V$ J- b; O
2 @" C0 ~! F, Y
以递增的方式构建系统
( c% o8 x$ b# y! {" K: W5 _) m致力于交付软件密集型系统的团队必须始终牢记,可用的软件是进度的首要衡量标准。开发应用程序所需的活动已经超出了本文的范围,但您需要重点记住的是,成功的团队都将架构和设计融入了其开发工作中。+ `4 t4 }8 `0 x! \
持续的架构思考是开发工作的一部分,如果没有考虑到变更对整个应用程序所产生的影响,那么团队不应该编写新的代码,亦不应该修改现有的代码。修改现有代码的一项流行技术称为重构(有关重构的更多信息,请参阅 参考资料)。Rational Software Architect 中提供了大量的工具集,有助于代码的开发和重构。您可以使用重构协助,改变代码的结构(图 11)。您还可以使用架构发现功能来确定应用程序代码中的模式和反模式(图 12)。这两种特性都可以帮助您编写更好的代码,并在软件开发的早期阶段发现问题。5 |. W0 C4 ~; W$ ]

3 a" g3 ?3 r! l; N2 H1 w6 U# m( p图 11. Rational Software Architect 中的重构协助
- F" r$ k8 V3 _2 x% K
. ~4 F& Z! x& [' @) F/ J" p/ G
6 H6 `7 K' c, l/ k图 12. 确定模式
- N' l6 w0 Q- v) E% l8 E8 Y
+ a  H8 f0 L1 B; i" I# v如果您已经在架构思考活动中创建了一些模型,那么您也可以决定是否将它们转换成代码。Rational Software Architect 自带了一组转换,可使用它们生成 Java 代码、Java EE 元素或 SOA 构件(参见图 13)。您还可以从现有的源代码中生成模型。7 c8 J2 e: B4 W3 L
. c% R" `4 b9 N( T
图 13. Rational Software Architect 中的转换  I. k- ?$ I8 ?( K) T7 u- M
9 t9 o, h" T7 x
在您以递增方式构建系统的过程中,您将创建一些可用的软件,这些软件应符合在架构思考活动期间制定的设计决策。0 H5 ~/ b. s* H( Y; e

3 `6 P$ I, a( q& o5 W0 b1 @' j

( K# K% |9 _5 s" b/ n/ H1 e; H结束语2 L2 l9 J# F3 c+ v
敏捷方法促进了用来逐步构建系统的短迭代的采用。虽然主要在瀑布模型中采用的 Big Design Up Front(请参见 参考资源 了解有关 BDUF 的信息)已被证明是一个低效的方法,但这并不意味着必须在敏捷项目中禁止架构和设计活动。设计必须是有意识的和紧急的。说设计是有意识的,是因为在项目开始时,需要根据产品库预测一些技术需求(架构构想)。而说设计是紧急的,则是因为在开发迭代过程中,您会根据团队发现的新技术挑战来调整和丰富设计。* N: q" D* Y# d9 H6 k, s( L
在本系列的 利用 Rational Software Architect 定义应用程序架构,第 1 部分:构想架构 中,我们将重点放在概括架构以及根据开发需求调整技术愿景的典型任务上。在第 2 部分,我们介绍了在开发迭代中如何优化架构。Rational Software Architect 为整个项目生命周期提供了模型模板,从不同的视角指定软件密集型系统的架构(图 14)
7 [+ n# l( }8 f5 W2 Z( i5 x/ n5 S# |* a0 Q  a4 L' H1 D

, D6 V- P: f0 E# K  j图 14. 适用于各种架构视图的模型
* J# k( {5 `2 m3 X! |  ?% Y * G" ^9 ]+ H$ r2 J& _0 @
架构思考是经验丰富的敏捷团队在其开发工作中进行的一项持续性工作。它并不总是产生正式的图表。请记住,在您的环境中,如果 UML 不是正确的方法,那么没有什么能够阻止您改用 Rational Software Architect 草图,就像您在白板上进行操作一样。与 UML 图相比,Rational Software Architect 草图没那么正式,但对于特定项目,它们可能是一个不错的选择。6 _9 `8 l% n# U! V0 c$ X1 _
: T1 z# |9 d+ B

& Q. Q2 k$ b# E; l
5 ^0 f- @# E0 G4 k

; `* _4 y6 J/ @' s; j( I# `8 t# W

本帖子中包含更多资源

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

x
 楼主| 发表于 2012-4-23 13:32:30 | 显示全部楼层
回复 支持 反对

使用道具 举报

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

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

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

GMT+8, 2018-7-19 17:37 , Processed in 0.071548 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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