基于敏捷開發(fā)增量UML模型的研究

惠子青，劉曉燕，朱匯龍

（昆明理工大學(xué) 信息工程與自動化學(xué)院，云南 昆明 650500）

0 引言

敏捷開發(fā)方法是目前非常流行也是非常成功的開發(fā)方式[1]。敏捷開發(fā)方法要求“在全面的文檔中使用文件”.綜合的uml圖認(rèn)為代碼是次要的，uml的維護(hù)成本似乎也說明了代碼是次要的。uml圖與代碼是分開的它只能在文檔中體現(xiàn)，當(dāng)uml圖用于增量模型設(shè)計時它與源代碼之間的協(xié)調(diào)是非常困難的，增量模型因此也變得非常的復(fù)雜，由于uml的類模型很少允許遞歸，因此幾乎沒有伸縮性（相反，數(shù)據(jù)流圖允許遞歸，因為流程就是一個數(shù)據(jù)流圖）.另一方面，uml提供了很好的可視化效果，它的好處我們不應(yīng)該丟棄[6]。一般來說，uml除了成本因素，是非常有利于開發(fā)的。

本文描述了一種在代碼注釋中逐步嵌入圖形化UML類模型的嚴(yán)格方法。它是和快速開發(fā)的代碼一起進(jìn)行的，最后的結(jié)果由簡單易懂的類模塊組成。該方法從確定我們所需調(diào)用的函數(shù)開始，每個函數(shù)對應(yīng)一個需求。例如：如果用戶需要訪問一個購物網(wǎng)站所需的函數(shù)可能包括display_product_image()、verify_password()和process_payment()，當(dāng)一個函數(shù)被識別并且驅(qū)動非平凡的main()，我們可以稱它為-跟設(shè)計函數(shù)。跟設(shè)計函數(shù)存在的前提條件是所需要的功能函數(shù)存在，而它的后置條件是將跟設(shè)計函數(shù)需放在開發(fā)人員所創(chuàng)建的類中，（后置條件也有可能包括設(shè)計約束）。跟設(shè)計函數(shù)的高階規(guī)范是這篇文章主要討論的問題。

1 敏捷UML建模研究現(xiàn)狀

一般來說，除了成本之外，UML已經(jīng)被發(fā)現(xiàn)對軟件開發(fā)有利。例如，Vargas發(fā)現(xiàn)[3]，“在系統(tǒng)層面上，使用類圖建模的代碼的變化傾向性低于根本沒有建模的代碼的變化傾向性”

UML在敏捷開發(fā)中的應(yīng)用已經(jīng)讓研究人員關(guān)注了一段時間（例如Wei等人[2]），但是還沒有出現(xiàn)廣泛使用的方法。模型驅(qū)動分析指定了用 XML描述 UML模型和元模型的廣泛方法，但是這些對于僅僅處理代碼的開發(fā)者來說并不是立即可見的。Pitk?nen和Selonen[10]對增量建模的研究就是一個例子。Marovac在[1]中也將 UML表示為“被標(biāo)記的句子”而不是數(shù)字。Ambler[7]在敏捷建模方面做了非常有用的工作，但是他并沒有像在這里展示的那樣討論嵌入UML。他在[8]中指出：“在AM（敏捷建模）的范圍內(nèi)，它（源代碼）不會被認(rèn)為是一個模型，因為我想?yún)^(qū)分這兩個概念?！币恍┟艚萁９ぷ鞯男问剑ɡ鏡umpe[5]）。一個具體的例子是Karagiannis[4]，它描述了敏捷建模方法工程（AMME）。

Weiser顯示，開發(fā)人員在調(diào)試相關(guān)的代碼片段時使用片段，而這些片段不一定是連續(xù)的。在不同的上下文中，本文描述的技術(shù)使用切片[11]。

2 方法

2.1 分析在uml中嵌入類的前提

首先，我們現(xiàn)在假設(shè)需求是給定的，沒有執(zhí)行已經(jīng)設(shè)計的uml可視化，并且注釋源代碼是我們唯一了解軟件結(jié)構(gòu)的途徑。其次，假設(shè)代碼設(shè)計的功能是可用的。在這里我們不假設(shè)uml必須以完整的形式顯示，如：顯示所有類或全部類關(guān)系或類的所有方法。

2.2 uml嵌入類所需要的功能

快速開發(fā)規(guī)范從需求開始當(dāng)前的輸出。在示例中，“用戶”可以指定廚房的裝修風(fēng)格，以及收到相應(yīng)的反饋。例如，這就要求存在一個將櫥柜置于某個位置的功能，如place_s_wall cabinet（a_position）。這種功能的識別取決于開發(fā)者，在這種情況下，我們將把它們稱為“需求”。

2.3 設(shè)計功能

根設(shè)計功能是執(zhí)行滿足當(dāng)前所有要求（即通過授權(quán)）的功能。所需功能的存在是明確的前置條件。根設(shè)計功能依靠這些功能來完成其后置條件，其中包括明確的創(chuàng)建適用于所需功能的類，并將這些類關(guān)聯(lián)起來。這是 UML可視化變得有用的地方。對于快速開發(fā)來說，我們所描述的技術(shù)就是創(chuàng)建這些UML片段-不需要放置所需的功能。由于這些片段通常只有 1-4個類的組合，所以它們及其相互關(guān)系可以作為簡單的ASCII數(shù)字在評論內(nèi)提供。 就像每個代碼塊依賴于前面的代碼一樣，每個新的 UML片段都應(yīng)該和已經(jīng)給出的代碼相關(guān)聯(lián)。換句話說，一個連接類可以使模型變得簡單。在本質(zhì)上，根設(shè)計函數(shù)所要求的功能可以是設(shè)計功能遞歸地重復(fù)本文描述的過程。

2.4 規(guī)則與符號

在本文中，每個函數(shù)被分解組織成一個有序的積累的子目標(biāo)。它們的連接必須滿足所有的后置條件。在最簡單的情況下，一個子目標(biāo)可能與后置條件相同?！胺e累”屬性意味著一旦子目標(biāo)被實現(xiàn)，就通過功能代碼的其余部分來維護(hù)。這種漸進(jìn)方式與快速開發(fā)是一致的。子目標(biāo)在代碼中用“-”表示。為了方便起見，對于不是必需子目標(biāo)的邏輯充分性的推理用方括號表示。

2.5 開發(fā)人員的角色

開發(fā)人員需要確定滿足后置條件的子目標(biāo)，并且選擇執(zhí)行子目標(biāo)的順序。另一個是將所需的功能放在合適的位置。

3 實例研究

我們選擇本文的例子的目標(biāo)是：它們應(yīng)該足夠小，足以被充分描述和實施，足夠復(fù)雜以說明技術(shù)，并且足夠熟悉，以便讀者可以將結(jié)果與傳統(tǒng)起草的UML文檔進(jìn)行比較。因此，我們選擇了設(shè)計模式的應(yīng)用程序：抽象工廠和調(diào)解器，一般在Gamma等[9]中描述。

例1：廚房的可視化

第一個例子取自[6]，使得用戶能夠以“古董”或“現(xiàn)代”等各種風(fēng)格可視化給定的廚房布局（在下面的代碼中基本上是櫥柜布局）。布局由5乘以 5格的櫥柜（“f”）和墻柜（“w”），如下例所示：

arrange_kitchen_with（“ANTIQUE”）的執(zhí)行

產(chǎn)生以下內(nèi)容：

執(zhí)行 arrange_kitchen_wit（“MODERN”）

相同的布局產(chǎn)生以下內(nèi)容：

設(shè)計和實施必須很容易適應(yīng)新的櫥柜和新的風(fēng)格。

（1）選擇根設(shè)計功能

這個過程是由根設(shè)計功能驅(qū)動的，執(zhí)行產(chǎn)生所需的應(yīng)用程序，并依賴于它在附屬（“必需”）功能。根設(shè)計函數(shù)的如下。

def arrange_kitchen_with(a_style):

前置條件明確地引用了所需的功能——實際繪制或放置各種櫥柜的方法風(fēng)格各異，如下：

Preconditions

1. a_style = 'MODERN' or 'ANTIQUE'

2. place_y_x_cabinet(a_position) are defined,each placing an x cabinet in style y at a_position on the console, where x = floor or wall and y = modern or antique

3. arrange_kitchen() is defined, using place_x_cabinet() with x = floor or wall, to produce a picture of a kitchen on the console.

4. cabinet_arrangement specifies where the flooror wall cabinets should be located on a two-dimensional grid

Postconditions

1.arrange_kitchen()and place_x_cabinet() are allocated

2. place_y_x_cabinet() are allocated for x =floor/wall and y = modern/antique

3. (place_x_cabinet() delegates):

Kitchen.place_x_cabinet() delegates to

place_y_x_cabinet()where y corresponds to a_style

4. A kitchen is displayed on the console as per

cabinet_arrangement and a_style

這些規(guī)范依賴于 place_y_x_cabinet（）等詳細(xì)規(guī)范的存在。

（2）分解

根設(shè)計函數(shù)被分解成一系列代碼塊，每個代碼塊實現(xiàn)一個子目標(biāo)（在代碼中用“ - ”表示）。 總體來說，子目標(biāo)聲明暗示了整個設(shè)計功能的后置條件。當(dāng)一個子目標(biāo)標(biāo)簽是有用的，它顯示在括號內(nèi)。

第一個子目標(biāo)放置函數(shù) arrange_kitchen（），place_floor_cabinet（）和 place_wall_cabinet（）。 這個子目標(biāo)的實現(xiàn)由這里描述的UML和Kitchen的代碼組成（通常在一個單獨的文件中）。

--(Postcondition 1): arrange_kitchen() and

place_x_cabinet()with x = floor or wall are allocated AND

the_kitchen is Kitchen instance with cabinet_arrangement

|_______Kitchen_______|

| arrange_kitchen() |

|place_floor_cabinet()|

| place_wall_cabinet()|

from … import Kitchen

the_kitchen = Kitchen()

the_kitchen.set_arrangement(cabinet_arrangement)

我們接下來找到place_y_x_cabinet（），注意將新的UML片段連接到已經(jīng)引入的UML。

--(Postcondition 2): place_y_x_cabinet() allocated with x

= floor or wall and y = antique or modern

Kitchen<>---->|_XCabinet_|

_________________________ ^

|____AntiqueXCabinet______|

|____ModernXCabinet______|

|place_antique_x_cabinet()|

|place_modern_x_cabinet()|

現(xiàn)在可以使用place_x_cabinet（）函數(shù)實施

--(Postcondition 3): place_x_cabinet() delegates

Kitchen<>-x_cabinet---> XCabinet|place()_|

Kitchen.place_x_cabinet() delegates to x_cabinet.place(),

and YXCabinet.place() delegates to place_y_x_cabinet()

where x = floor or wall and y = antique or modern

接下來，開發(fā)者可以將Style引入為對象。 方括號表示一個子目標(biāo)，雖然需要執(zhí)行，但是在檢查子目標(biāo)的意味著聯(lián)合后置條件時是不需要的。

--[Style]: the_kitchen.the_style is a Style instance

corresponding to a_style

Kitchen<>-the_style--->|_Style_|

_____________________ ^

|_AntiqueKitchenStyle_||_ModernKitchenStyle_|

’’’

from … import AntiqueKitchenStyle, ModernKitchenStyle

if a_style == "ANTIQUE":

the_style = AntiqueKitchenStyle()

else:

the_style = ModernKitchenStyle()

the_kitchen.set_kitchen_style(the_style)

下一個子目標(biāo)確保the_kitchen.x_cabinet是設(shè)置為適當(dāng)樣式的對象。

--[x_cabinet set]: the_kitchen.x_cabinet is an YXCabinet,

where x/X = wall or floor, and Y corresponds to a_style

Style ---->XCabinet

|get_cabinets()|

YKitchenStyle.get_cabinet() sets the_kitchen.x_cabinet

to a YXCabinet instance

現(xiàn)在的設(shè)計足以實現(xiàn)后置條件4，如下所示：

# --(Postcondition 4): A kitchen is displayed

# on the console as per a_style and arrange_kitchen()

the_kitchen.arrange_kitchen()

例2：對接模擬

第二個例子模擬了一艘船的對接，并附有一艘拖船。一個簡單的5×5網(wǎng)格就足以證明該方法。我們將指定船舶傾向于1空間的對角線運動，拖船最多可以移動2個空間，但只能垂直和水平移動。例如，下面顯示了初始條件，其中d是船的目的地，“0”和s分別表示拖船和船的初始位置。

輸出顯示如下，每當(dāng)有重疊時，拖輪位置（數(shù)字）占主導(dǎo)地位：

讀者將認(rèn)識到中介設(shè)計模式的出現(xiàn)。

（1）選擇根設(shè)計功能

由于對接是主要的用戶故事，因此以下是一個合適的根設(shè)計功能：

def dock(a_ship_position, a_tugboat_position,

a_dock_position):

dock（）的規(guī)范主要涉及所需函數(shù)的位置，但是它們也包含一個設(shè)計約束（后置條件1）。

Intent: Simulate docking of a ship with tugboat support

Preconditions

1: The parameters are instances of Position

2: a_ship_position is the ship's initial position

3: a_tugboat_position is the tugboat's initial position

4: a_dock_position is the ship's destination

5: move_ship() is defined--the effects of a single move

with specified constraints

6: move_tugboat() is defined–the effects single move with

specified constraints

Postconditions

1. (Independence): The code defining ship and tugboat is

independent of each other

2. move_ship() is allocated

3. move_tugboat() is allocated

4. (Trajectories shown): The ship and tugboat's

trajectories are on the console for the ship traveling in

a minimal path from a_ship_position to a_dock_position

and the tugboat staying as close as possible but out of

the way.

（2）分解

前兩個子目標(biāo)與前兩個后置條件相同，并且以避免獨立所禁止的相互引用的方式分配所需函數(shù)move_ship（）和 move_tugboat（）。這意味著船舶和拖船之間不應(yīng)存在隨后的依賴關(guān)系。

# --(Postconditions 1 & 2): "Independence" observed

# AND move_ship() is allocated

# _________ ___________

# |_Docking_|<>-ship--->|___Ship____|

# |move_ship()|

# --(Postcondition 3): move_tugboat() allocated

# ______________

# Docking<>-tugboat--->|____Tugboat___|

# |move_tugboat()|

下一個子目標(biāo)履行滿足超過相應(yīng)的后置條件。

# --[Vessel instances have position and heading]

# ________

# |_Vessel_|

# |position|

# |_heading|

# ^

# Ship Tugboat

下一個子目標(biāo)可以協(xié)調(diào)。

# --[Each Vessel is aware of its peer]

# ____________________

#

|_VesselCoordination_|<---coordination-<>Vessel

# |_____get_peer()_____|

# ^

# Docking

一旦滿足其主要需求，根設(shè)計函數(shù)通常會通過控制來構(gòu)建應(yīng)用程序的設(shè)計。

# --(Postcondition 4): Trajectories shown

#

# This is executed by Docking.execute()

from mediator.docking_class import Docking

Docking().execute(a_ship_position,a_tugboat_position,

a_dock_position)

4 結(jié)論

UML的可視化屬性可以在敏捷項目中通過建立放置所需函數(shù)的設(shè)計函數(shù)以及將 UML嵌入到有意義的片段中來利用。這不僅僅是一個權(quán)宜之計：它減輕了復(fù)雜和龐大的UML類模型的不可讀性。

這項研究已經(jīng)預(yù)見到了實驗和規(guī)模的使用，在不斷的發(fā)展。實際上，大小適中的應(yīng)用程序需要封裝，同樣的設(shè)計功能驅(qū)動的過程應(yīng)該能夠驅(qū)動創(chuàng)建包及其使用關(guān)系，就像驅(qū)動創(chuàng)建類及其關(guān)系一樣。

不斷發(fā)展的應(yīng)用程序開發(fā)的主要障礙是可能存在不一致，效率低下以及難以看清整體。本文描述的所需 UML片段允許驗證已建立的系統(tǒng)符合嵌入式 UML規(guī)范。工具支持是必需的。一個工具將檢查一個程序的 UML片段的一致性，并產(chǎn)生一個XML UML描述（以及圖）。至少有兩種一致性要檢查。第一個驗證片段集內(nèi)的自我一致性（例如，使得類A未被顯示為從B繼承，反之亦然）。第二個檢查代碼是與 UML片段一致（例如，使得承諾的類A實際上被構(gòu)造）。

檢查一個已建立的系統(tǒng)是否符合其公布的UML的能力并不是特定于本文描述的零碎方法；然而，在持續(xù)進(jìn)化的背景下，開發(fā)人員實際上更容易表達(dá)“這里是我需要實現(xiàn)當(dāng)前沖刺的額外的UML”，而不是通過一個大的 UML類模型尋找合適的地方來編輯。

未來的工作將涉及規(guī)模項目的設(shè)計功能樹和碎片化UML的影響。根設(shè)計函數(shù)假定存在一組函數(shù)，其中一些函數(shù)本身就是設(shè)計函數(shù)等等。由此產(chǎn)生的設(shè)計函數(shù)層次結(jié)構(gòu)可以改善在簡介中提到的 UML類模型中遞歸“伸縮”的缺乏。

[1] N. Marovac. “UML based embedded documentation for semiautomatic software development,” SIGSOFT Softw. Eng.Notes 32.5 (2007), pages 1–3, doi: 10.1145/1290993.1290997.

[2] Q. Wei, G. Danwei, X. Yaohong, F. Jingtao, H. Cheng, and J.Zhengang. “Research on software development process conjunction of scrum and UML modeling,” Proceedings - 2014 4th International Conference on Instrumentation and Measurement, Computer, Communication and Control (IMCCC 2014), 2014, pages 978–982, doi: 10.1109/IMCCC. 2014.206.

[3] R. Vargas, A. Nugroho, M. Chaudron, and J. Visser. “The use of UML class diagrams and its effect on code changeproneness,” Proceedings of the Second Edition of the International Workshop on Experiences and Empirical Studies in Software Modelling (EESSMod '12), Article No. 2, 2012, doi:10.1145/2424563.2424566.

[4] D. Karagiannis. Agile modeling method engineering. 2015,doi: 10.1145/ 2801948.2802040.

[5] B. Rumpe. “Agile Modeling with the UML,” Rissef (2002),pages 297– 309, doi: 10.1007/978-3-540-24626-8_21.

[6] E. Braude. Software design: from programming to architecture.Hoboken, NJ: J. Wiley, 2003, pp133-135.

[7] S. Ambler. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. 2002, page 400, doi:10.1017/CBO9780511817533.018.

[8] S. Ambler. Agile/Lean Documentation: Strategies for Agile Software Development. url: http://agilemodeling.com/essays/agileDocumentation.htm# ModelsDocumentsSourceCode.

[9] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: elements of reusable object-oriented software. Reading,Mass.: Addison-Wesley, 1995.

[10] R. Pitk?nen and P. Selonen “A UML Profile for Executable and Incremental Specification-Level Modeling,” ?UML?2004 — The Unified Modeling Language. Modeling Languages and Applications Vol 3273, Lecture Notes in Computer Science, pages 158-172, doi 10.1007/978-3-540-30187-5_12.

[11] M. Weiser, "Programmers use slices when debugging,"Communications of the ACM (1982), pages 446-452, doi 10.1145/358557.358577.