引用
Kim Mens and Angela Lozano. Source Code-Based Recommendation Systems. Recommendation Systems in Software Engineering, 2014, 93-130.
摘要
儘管今天的軟件系統由各種各樣的軟件工件組成，但是源代碼可以說仍然是最早更新的軟件工件，因此也是最可靠的數據源。它提供了豐富而結構化的信息源，推薦系統可以依靠該信息源向軟件開發者提供有用的推薦。基於源代碼的推薦系統可以為諸如如何使用給定的 API 或框架這樣的任務提供支持，提供代碼中缺少內容的提示，建議如何重用或糾正現有代碼，幫助新手學習新項目、編程範式、語言或風格等。本文重點介紹在開發基於源代碼的推薦系統時涉及的相關決策。對我們所開發的特定系統的深入介紹可以具體說明構建此類系統時可能遇到的一些問題以及需要做出的開發選擇。
1. 介紹
通常，推薦系統可幫助人們在執行任務時查找相關信息來做出正確的決定。軟件工程推薦系統（RSSE）可以幫助開發者進行一系列活動，從重用代碼到編寫有效的錯誤報告等。本文的重點是基於源碼的推薦系統（SCoReS），即通過分析軟件系統的源代碼來產生其推薦。
當前許多 SCoReS 旨在支持正確使用 API、庫或框架。它們通常依賴於已有的 API 使用示例語料庫，這些示例通過分析一些特定的應用程序獲得的。這類推薦工具通常包括嵌入在 IDE 中的前端和存儲語料庫的後端。前端負責顯示結果並從 IDE 或開發上下文中獲取正確的信息，以便制定合適的查詢。後端負責產生與這些查詢匹配的結果並更新語料庫。當開發者編輯程序時，推薦系統可以根據 API 的已有用法，推薦如何使用 API。此類推薦系統可以視為“智能”代碼補全工具。匹配過程使用的信息與代碼補全工具類似，例如目標對象的類型（預期的返回類型）以及開發者期望功能所需的對象類型。
除了此類 SCoReS 之外，還可以區分許多其他類型的 SCoReS，不僅取決於它們從源碼中提取推薦的種類或使用的技術，而且取決於建立這些系統時所採用的設計。儘管存在各種各樣的源代碼分析技術，並且即使已經確定了開發者在編寫代碼時的信息需求，但將特定技術運用到成功的推薦工具中並不容易。
本文的目的是向基於源碼的推薦系統領域的新手提供一些現有方法的概述，以使他們瞭解構建此類系統的問題和困難，並提出更系統的過程來開發 SCoReS。這個過程是從對現有方法的非詳盡比較和分類以及我們在構建工具支持各種軟件開發和維護任務的經驗中提煉出來的。
2. 一系列基於源碼的推薦系統
在提出 SCoReS 的設計過程之前，我們簡要介紹五個推薦系統，這些系統將幫助我們說明某些設計決策的重要性。它們分別為 Rascal，FrUiT，Strathcona，Hipikat 和 CodeBroker。 選擇這些系統是因為它們在設計方法方面是互補的。
2.1 Rascal
Rascal 是一種推薦系統，通過分析與當前正在編寫的類相似的類來預測開發者可以使用的下一種方法。Rascal 依賴於協同過濾的傳統推薦技術。協同過濾基於這樣一種假設，即用戶會聚集在偏好相同條目的用戶組中。Rascal 的“用戶”就是類，推薦的條目是要調用的方法。當前類和其他類之間的相似性正是基於它們所調用的方法。
Rascal 分為四個部分，負責推薦過程的不同階段。首先，活動用戶標識當前正在開發的類。其次，使用歷史記錄收集器，它自動為一組 API 中的所有類挖掘類方法使用矩陣和類方法順序列表（圖 1.1）。矩陣中的每個單元代表一個類調用特定方法的次數。第三，構造代碼存儲庫，用於存儲歷史記錄收集器挖掘的數據。第四，推薦程序代理器，它為用戶推薦下一個方法，以供用戶在光標當前所在的方法和類的實現中調用。推薦代理器從查找與當前所選類相似的類開始。兩個類之間的相似性是通過比較它們調用的方法來計算的。考慮使用同一種方法的頻率來識別明顯的相似性。比較兩個類時，像 toString()這樣的常用方法比其他方法具有較低的權重。為了對推薦的方法進行排序，RASCAL 從最相似的類中選擇那些包含當前類中使用的最後一個方法調用的類，然後按照優先級來推薦該方法調用之後的方法調用，以使它們出現在該方法調用之後（圖 1.2）。
2.2 FrUiT
FrUiT 是一個 Eclipse 插件，用於支持框架的使用。FrUiT 顯示了框架的源代碼關係，該關係顯露在開發者當前正在編輯的文件的上下文中。圖 1.3 展示了 FrUiT 的屏幕截圖。源碼編輯器 (1) 確定開發者的上下文，在本例中為 Demo.java 文件。在 IDE 的外圍視圖中展示了該文件的 FrUiT 提示 (2)，並且還顯示了每個實現提示的原理（例如“實例化 Wizard”） (3)。對於每種實現的提示，開發者還可以閱讀所推薦的類或方法的 Javadoc (4)。
FrUiT 的推薦分三個階段進行計算。首先，FrUiT 使用給定的框架或 API 從一組應用程序中提取結構關係。這些結構關係包括繼承（類 A 繼承類 B），實現（類 A 實現接口 B），覆蓋（類 A 覆蓋繼承的方法 m），調用（類 A 的任何方法調用方法 m）以及實例化（從類 A 的實現中調用類 B 的構造函數）。其次，FrUiT 使用關聯規則挖掘來識別每當使用框架或 API 時常見的結構關係。關聯規則為
，可以將其解釋為“ if-then”規則。例如，規則
意味著使用框架的應用程序每次調用方法 m 時，它也傾向於（在 80％的情況下）調用類 B 的構造函數。請注意，FrUiT 還顯示了每種情況下關聯規則是否成立（參見圖 1.3 中 IDE 的右下角）。鑑於關聯規則挖掘往往會產生結果的組合爆炸，因此有必要對結果進行過濾以確保該工具僅產生相關信息。 最後，對於 Eclipse 編輯器當前關注的文件，FrUiT 推薦在該文件之前或之後提及的所有規則。
2.3 Strathcona
Strathcona 也是一個 Eclipse 插件，推薦使用第三方庫方法的示例（請參見圖 1.4（d））。用戶高亮源代碼片段,以向 Strathcona 請求第三方庫方法使用方式的示例（請參見圖 1.4（a））。這些示例取自使用相同第三方庫的其他應用程序。
Strathcona 通過提取源碼的結構上下文來工作。這種結構上下文包括方法的簽名、聲明的類型和父類型、調用的方法、訪問的字段的名稱以及每種方法引用的類型。提取的結構上下文可以通過兩種方式使用。首先，作為自動查詢，描述開發者請求支持的源代碼片段。其次，使用該工具支持的庫來構建一個包含類的結構上下文的數據庫。通過在 Strathcona 數據庫中識別具有與所分析片段之一相似的結構上下文的實體，可以找到相關示例（請參見圖 1.4（b）和（c））。
2.4 Hipikat
Hipikat 幫助軟件項目新人找到有關維護任務的相關信息。Hipikat 的想法是根據其源代碼、電子郵件討論、錯誤報告、更改歷史記錄和文檔來收集檢索項目歷史記錄的相關部分。圖 1.5 展示了 Hipikat 的屏幕截圖。IDE 的主窗口顯示了開發者要修復的錯誤報告（參見圖 1.5（a））。開發者從上下文菜單中選擇“查詢 Hipikat”後，該工具將返回相關工件的列表。與 bug 相關的工件在單獨的視圖中顯示（圖 1.5（b））。對於找到的每個工件，Hipikat 會顯示其名稱、類型（網頁，新聞文章，CVS 修訂版或 Bugzilla 項），推薦它的理由以及它與查詢工件的相關性。可以在 IDE 的主窗口中打開工件，以繼續查詢 Hipikat。
2.5 CodeBroker
CodeBroker 根據開發者光標當前所在的方法的註釋和簽名，推薦要調用的方法。該系統的目標是通過找到已經（部分）實現了目標功能的方法來支持新方法的開發。
CodeBroker 的前端監視光標，使用當前上下文中的相關信息查詢後端，並顯示結果。後端分為兩部分。首先，一種論述模型可以存儲和更新一組庫、API 和框架中方法的註釋和簽名，以供重用。其次，一種用戶模型，用於從推薦列表中刪除方法、類或包，圖 1.6（c）說明了右鍵單擊推薦來將其從推薦列表中刪除。
CodeBroker 是與源代碼編輯器（emacs）集成的推薦工具。一旦開發者編寫代碼，該工具就會通過監視方法聲明及其描述來主動識別推薦的需求。這意味著每次遊標更改位置時，它都會自動查詢後端存儲庫。該查詢旨在查找具有與正在開發的方法相似註釋和簽名的方法。然後根據焦點方法中使用的類型和匹配類型之間的相似性來過濾文本搜索結果。一旦查詢響應，就會在源碼編輯器的外圍視圖中顯示按相關性排序的匹配方法（請參見圖 1.6（a））。最後，圖 1.6（d）展示了 CodeBroker 如何允許開發者引導後端找到相關建議，通過將方法、類或包的名稱添加到“過濾的組件”中使它們從結果中被排除，或添加到感興趣的組件以便搜索被限制在這些實體範圍內。
3. 建立 SCoReS 時的開發決策
在基於源代碼的推薦系統的整個開發過程中，需要做出許多重要的決定。這些決策可以沿兩個維度進行分類。 第一個維度是開發週期階段：是與系統需求、設計、實現還是最終驗證相關的決策？另一個維度是系統如何與用戶交互的。表 1.1 對主要決策類別進行了說明。
3.1 過程
假設我們遵循從需求開始的傳統開發週期，表 1.1 中的數字表明瞭如何以及何時做出這些決策的過程：
- 首先考慮系統的意圖，這些意圖均與推薦方法的目的有關。
- 然後確定人機交互，即終端用戶（通常是開發者）如何與 SCoReS 交互。
- 一旦確定了功能和用戶交互要求，請選擇系統將用來提供建議的數據源。
- 接下來，根據一般投入產出決策來完善先前採取的人機交互決策。
- 現在確定推薦方法的細節，即與如何實施推薦過程有關的所有細節。
- 由於上一步的決定可能會更詳細地說明“輸入輸出”，因此接下來，我們可以決定該方法需要什麼樣的精確信息作為輸入，以及它是什麼以及如何產生其輸出。
- 實施系統後，我們需要選擇如何驗證它。主要問題是系統要為其提供推薦的任務提供支持的能力。
- 最後關於驗證需要做出一些決策，以決定如何評估不同用戶與 SCoReS 的交互。
3.2 意圖
3.2.1 目標用戶
目標用戶，即首先應確定系統預期用戶的角色。儘管大多數 SCoReS（都是針對開發者的，但其他角色類型也需要考慮，例如維護人員，逆向工程師，重構者，經理，測試人員，文檔編寫員或研究人員。第二個決策因素與目標用戶的體驗水平有關。儘管某些推薦系統不去假設用戶的經驗水平，但部分推薦系統專門針對新手或專家。例如，Hipikat 可以幫助新人加入某個項目，而 CodeBroker 可以根據其用戶的經驗水平進行個性化設置。
3.2.2 任務支持
如前所述，許多 SCoReS 旨在支持正確使用 API，庫或框架。一些支持 API 演化或語言遷移的映射。還有一些則推薦代碼更正、重用代碼（方法重用，如 CodeBroker）、代碼更改或代碼提示。另外一些 SCoReS（例如 Hipikat）可以支持新手學習新項目。或者提供相關信息來幫助開發者瞭解如何實現某些問題或解決某些錯誤。
3.2.3 認知支持
據 German 等人的研究，另一個重要的決策是推薦系統如何支持用戶認知來完成某些任務。換句話說，系統可以幫助您回答有關任務的哪些問題，可以區分為五類問題：who，why，when，what 以及 how。
系統的推薦解釋信息往往取決於其應用環境。提供 API 支持並與 IDE 集成的代碼補全工具通常不提供詳細信息來幫助用戶評估推薦的合適性。另一方面，未嵌入為代碼補全工具的 API 支持工具往往會提供多重視圖，以解釋每個推薦的理由。但是，提供信息的詳細程度不僅僅取決於系統與 IDE 的集成方式。
由 SCoReS 提供的另一種流行的認知支持（如 FrUiT 和 Strathcona）為開發者提供瞭如何完成其任務的信息。提供的詳細程度取決於系統提供的支持類型。具有特定目標的系統（例如，如何替換不推薦使用的方法或如何從另一個類型的實例中獲取目標類型的實例）比涉及廣泛目標的系統（例如，如何補全方法）需要的背景知識更少，目標廣泛的系統可能需要用戶輸入或者指明方法如何使用。
只有很少的系統回答有關特定實現選擇背後的原因(why)；最接近的是那些尋找與工件相關的實體，但是這些實體之間的關係仍然必須由開發者發現。同樣，回答時間問題（when）的系統也很少，這可能是由於它們通常不依賴於變更信息。但是，此類時間信息可能會有助於回答基本原理問題，因為它可以揭示更改背後的痕跡。最後，SCoReS 很少回答作者（who）的問題，這是因為源代碼很少包含作者的信息，除非有其他來源對此進行補充。
3.2.4 推薦信息
一些推薦系統不僅推薦做什麼，而且還推薦如何做。對於大多數直接推薦做法的系統，用戶要做的事情就是選擇他們認為適合當前上下文或任務的更改，然後系統將自動執行更改（例如，在最後一條語句後插入代碼）。
像 FrUiT，Rascal 和 CodeBroker 一樣，另一種常見的輸出類型是源代碼實體，即更改或使用的內容，而不是更改方式。根據當前的任務和推薦系統的類型，可能需要對推薦的結果做進一步的解釋。例如，推薦系統可能會推薦以非常特定的方式修改源代碼實體，但是系統與 IDE 的集成不夠全面無法自動執行操作，因此需要用戶手動執行。
示例可以幫助用戶理解在類似情況下如何解決類似問題。用戶的工作是確定示例內容的哪個部分與當前任務相關，以及如何將示例應用到當前情況。
最後，SCoReS 可以推薦相關的軟件工件（即非源代碼實體的軟件開發過程的任何副產品），以幫助開發者更好地理解手頭任務的含義。這些推薦的有用性和有效性取決於信息的相關性以及開發者可以從系統提供的信息中抽象出來的聯結。
3.3 人機交互
在系統意圖相關的決策之後，我們現在將注意力轉向人機交互。這些決策使我們能夠建立用戶與 SCoReS 之間的預期交互。包括系統類型，系統推薦類型以及用戶的預期輸入。
3.3.1 系統類型
推薦系統可以是 IDE 插件，獨立應用程序或其他類型，例如命令行工具或系統用戶要使用的內部或外部 DSL。鑑於我們分析的大多數 SCoReS 都是針對開發者的，因此它們往往與開發環境集成在一起。這可以更輕鬆地檢測用戶上下文或活動，有時還可以更輕鬆地訪問該上下文中使用的句法實體和關係。推薦系統的另一種選擇是獨立的應用程序，例如 Rascal。為降低侵入性，編程式 SCoReS 一般較少作為實現。
3.3.2 推薦類型
諸如 Hipikat 和 Strathcona 之類的推薦系統是專用的搜索引擎，可以為手頭上的特定任務找到相關信息。Strathcona 查找給定 API 的使用示例，而 Hipikat 查找與源代碼工件相關的信息。其他系統如 FrUiT，Rascal 和 CodeBroker，則側重於向用戶推薦某些行動方案。例如，Rascal 建議需要添加哪些方法調用。許多其他系統更多地關注驗證源碼的某些屬性，例如遵守某些約定或設計規則。
3.3.3 用戶參與
一個重要決策是 SCoReS 需要什麼樣的用戶參與。例如，它需要手動輸入還是需要用戶過濾輸出？通常，可以從編程上下文中自動提取 SCoReS 所需的輸入。例如正在編寫的方法、已調用的方法、已使用的類型、調用方法的順序，最後創建的語句或標識符等。假定大多數 SCoReS 僅依賴於正在編輯的源碼，無需手動輸入。然而，如果 SCoReS 需要無法從編程上下文中提取數據，則必須確定用戶將以哪種方式提供所需信息。
另一個重要決策是用戶是否可以過濾推薦。可以像在 FrUiT 或 CodeBroker 中那樣反覆進行此過濾，也可以諸如 Strathcona，Rascal 和 CodeBroker 從最終結果組中進行迭代。有趣的是，結果過濾也可以用來排除。例如，CodeBroker 通過查看他們的本地歷史記錄來消除用戶已知的結果。另一個值得考慮的方法是允許按用戶會話或模塊過濾結果
3.4 語料庫
決定 SCoReS 的主體就等於決定系統需要依賴哪些數據源來提供推薦。SCoReS 使用的主要信息來源是程序代碼，但有時也會使用其他信息來源，例如變更管理、缺陷跟蹤存儲庫、非正式通信、本地歷史記錄等。當合並多個數據來源時，明確決定如何關聯這些來源。
3.4.1 程序代碼
關於語料庫，要做的第一個重要決策是系統根據開發者正在開發的應用程序還是基於他們正在使用的應用程序來計算其推薦。前者從單個應用程序（正在構建的應用程序）的代碼構建主體，而後者從多個應用程序（正在被使用的應用程序）中構建主體。這種選擇會對可用於計算推薦的技術、方法、存儲需求及其實用性產生影響。基於多個應用程序語料庫的 SCoReS 可以使用通用數據分析技術，但需存儲先前收集的數據，且它們的推薦通常限於特定庫或框架的分析。因此，其有用性取決於 SCoReS 用戶使用的 API 與服務器上可用 API 之間的匹配。相反，分析單個應用程序的 SCoReS 不需要單獨的存儲也不需要預取數據，但通常需要基於啟發式的數據分析技術，這些 SCoReS 適合封閉源應用程序。
3.4.2 補充信息
除源代碼或源代碼存儲庫之外，推薦系統還可以從程序執行跟蹤、軟件配置管理系統、問題管理系統、開發者之間的非正式交流記錄（電子郵件討論，即時消息，論壇等）、用戶的導航和編輯行為及用戶歷史記錄中提取的有用信息。
3.4.3 相關信息
所有非源碼數據的 SCoReS 都需要將其與源代碼相關聯。如果系統不能將多個數據源組合成超出獨立事實的數據便沒有價值。因此，需做出的一個相關決策是如何將程序代碼的信息與互補資源中提取的信息進行混合。例如可以將 CVS 信息庫中文件的作者信息和時間戳與這些文件中包含的源代碼相關聯，以推斷出哪些源代碼實體可能一起更改的。
3.5 通用輸入/輸出
3.5.1 輸入機制
無論何時觸發推薦，第一個決策都是考慮 SCoReS 是否從當前活動的源碼實體或工件推斷出其輸入。該決策取決於是否需要從源代碼上下文中獲得的信息來計算推薦信息。儘管大多數 SCoReS 會從用戶的當前上下文或活動中隱式推斷出他們的輸入（例如 FrUiT，Strathcona 和 Rasca），但也有一些系統部分或完全依賴於用戶的輸入來請求的任務或實體的推薦，如 CodeBroker 和 Hipikat。
3.5.2 輸入的性質
輸入的性質直接影響用戶對使用該系統易用性的看法。大多數 SCoReS 都要求輸入（片段）源代碼以提供有關該源代碼的具體推薦，例如 FrUiT 或 Rascal。其他系統隱式或顯式地考慮了用戶的上下文和活動，例如 Strathcona 和 CodeBroker。編程上下文通常限於關注的焦點或正在使用的源代碼實體。另外，某些系統以自然語言查詢或其他非代碼工件的形式接收輸入。
3.5.3 響應觸發器
構建 SCoReS 時還需要確定何時觸發系統以計算推薦。可以根據用戶的明確請求來計算推薦，也可以在發生某些上下文時主動計算。但是，即使是在開發環境中隱式發現輸入的 SCoReS，除了少數如 CodeBroker 之類的系統會不斷更新其結果，計算推薦的請求仍然是顯式的。該決策被認為與侵入性有關，大多數 SCoReS 僅在開發者明確請求後才觸發響應，並在外圍視圖而不是在主編程視圖中提出推薦及其理由，從而避免形成干擾。
3.5.4 輸出的性質
輸出的性質也會影響 SCoReS 的可用性。例如，對於作為輸入的源代碼片段，Strathcona 向開發者提供了類似的源代碼示例。由三部分組成：類似於 UML 的圖形化概述說明示例與查詢片段的結構相似性，推薦原因的文字說明，以及突出顯示與查詢的源代碼片段。
SCoReS 沒有典型的輸出類型。儘管其中一些限制發送某些原始文本描述中要求的信息，但其他一些旨在將推薦集成到 IDE 中，以便無縫地使用它。包括導航和瀏覽輔助工具。儘管現有的 SCoReS 往往多使用 UML 圖，但目前為止，SCoReS 的中間數據表示（例如，圖形，樹，矢量）確實已被忽略，無法作為提供推薦的方式。我們認為，在某些情況下，以這種風格呈現推薦而不是僅呈現列表，可能為終端用戶提供了一種更直觀的方式來理解結果。
3.5.5 輸出類型
SCoReS 的有用性還取決於為支持任務而產生的輸出的適當性。這些輸出的示例包括現有軟件工件或與用戶當前任務相關的源代碼實體、缺少源代碼實體或片段、或映射實體的推薦（如語句或方法）。相關實體指作為輸入的源代碼實體通常使用或更改的其他實體。例如，重用的方法、更改的方法、下一個要調用的方法或要調用的一組方法。映射指示一個實體的組件如何使用或被替換為另一實體的組件。實現關係顯示出可能被遺忘的句法或結構關係（例如，實現接口，調用方法，使用類型等）。
3.6 方法
3.6.1 數據選擇
SCoReS 的開發者還必須決定數據收集的詳細程度，這意味著 SCoReS 可以做哪些分析以及用戶可以使用哪些信息。還需預先描述數據收集的原理，尤其是如何使用它來提供有用的推薦，以便選擇適當的粒度級別。在分析面向對象的源代碼時，大多數 SCoReS 的首選是方法和方法之間的關係（例如調用語句、覆蓋信息、繼承，實現）。但是，類型信息（例如方法的返回類型或其參數的類型）對於連接不同的源代碼實體也非常有用。源代碼實體名稱中的令牌是另一重要信息，可以進行詞彙分析。使用的其他源代碼信息包括註釋、文件、類型、字段、文字、簽名、包含/實例化語句、訪問信息、語句、和代碼的變更信息等。
3.6.2 分析類型
最簡單的分析方法是直接對源代碼進行文本分析。像 Hipikat 和 CodeBroker 一樣，詞彙方法或基於令牌的技術使用詞彙分析將代碼轉換為一系列詞彙令牌。語法方法將源代碼轉換為解析樹或抽象語法樹，並在這些樹的基礎上執行其後續分析，就像 FrUiT，Strathcona，Rascal 和 CodeBroker 一樣。語義感知方法通過依賴動態程序分析技術在語義層次上執行其分析。
3.6.3 數據要求
此決策說明了數據的特定限制，以使系統能夠正常工作，例如系統所針對的編程範例（面向對象還是過程）或特定編程語言（Java，Smalltalk，C 等）。做出此決定通常是出於務實的原因，例如能夠將 SCoReS 的結果與另一個結果進行比較，這需要能夠分析相同的源代碼，或者使用某些輔助工具進行數據提取和處理。
最常見範例是面向對象的，因為它在當前的工業實踐中更為普遍，儘管其中有一些限於程序範例。但是，對面向對象代碼所做的許多假設可以轉換為過程，反之亦然。Java 似乎是 SCoReS 最普遍支持的語言之一。其他語言包括 C 和 SmallTalk。儘管實現語言的選擇似乎微不足道，但是像 Smalltalk 這樣的動態類型語言可能使原型化工具更加容易，但是另一方面，動態類型語言不能確保像 Java 這樣的靜態類型語言所做的所有假設。例如，方法簽名可以唯一地鏈接到類型，方法可以返回特定類型的變量，或者其參數為特定類型。類似地，儘管方法名稱可以用 Java 之類的語言表示類似的問題，但對於 Smalltalk 之類的語言（方法的名稱和簽名之間沒有區別），這種指示更難於驗證。
除了語言之外，對系統所需的數據可能還有其他特殊要求，例如應有足夠的使用特定 API 的示例代碼，例如 Strathcona。
3.6.4 中間數據表示
該決策涉及將原始數據處理成合適的格式以進一步處理的情況。關於這種中間格式，SCoReS 的設計人員可以通過程序依賴或調用關係使用基於圖的方法；也可以通過轉換抽象語法樹或其他樹結構採取基於樹的方法；Rascal 和 CodeBroker 使用矢量和矩陣作為中間表示，FrUiT，Hipikat 及 Strathcona 等基於事實來組織邏輯或事實集的數據。其他方法可能會使用度量標準或文本數據來做推論。Hybrid 體現了多種方法的結合使用。
以圖和事實為基礎似乎是最受歡迎的表示形式之一，可能是因為它們提供了靈活且眾所周知的機制來查找內在關係，而這些關係可以用來解釋推薦背後的原理。向量或矩陣表示可提供高性能的運算，同時也能準確說明相關事實。文本和數字表示形式似乎不太適合 SCoReS，因為它們缺乏可追溯性。因此，基於搜索的技術通常在矩陣或矢量表示之上而不是文本表示之上進行操作。
3.6.7 分析技術
下一個關鍵決策是選擇實際算法或者說技術，該算法或技術將從提取的數據中產生相關推薦。
傳統推薦技術通常基於要推薦的項目和這些項目的用戶。推薦系統旨在通過確定用戶的需求或偏好，然後找到滿足這些需求的最佳項目，從而將用戶與項目匹配。為了確定用戶的需求，推薦技術可以考慮當前用戶的先前評分（社會標籤），人口統計信息，商品功能或商品對當前用戶的適用性。匹配完成後，可以根據用戶評分對項目進行優先級排序。這些策略結果的組合導致了不同種類的推薦技術。 Rascal 是依賴傳統推薦技術的典型示例。
但實際上，除非 SCoReS 推薦的 API 調用具有大量示例應用程序，否則通常很難依靠傳統的推薦技術，因為使用同樣或相似代碼的用戶群體是棧少數的。因此，SCoReS 最流行的分析技術是通過使用傳統的分類技術（如聚類分析，關聯規則挖掘，頻繁項集）來計算輸入和其他待分析實體之間的相似度。其他一些方法依賴於基本的或高級的搜索技術，從機器學習或邏輯推理中獲得靈感，或者像 Hipikat 和 Strathcona 一樣依賴於啟發式技術。啟發式方法是一種流行的選擇，因為它們可以挖掘頻繁關係未描述的實體之間的預期相似性。在分類技術中，那些對次要異常有彈性的技術（如頻繁項集分析和關聯規則）優先於那些考慮了所有信息的技術（如形式概念分析），在區分不同源碼實體的特質的同時不會影響結果。
3.6.8 過濾
過濾（也稱為數據清除）目的是避免在結果中產生噪音（誤報）。許多 SCoReS 使用兩階段過濾方法。第一階段查找與用戶上下文有關的實體或屬性。在第一階段中丟棄信息也稱為預過濾。常見的預過濾包括：使用停用詞黑名單、排除手動導入的庫，排除系統類或生成的代碼等。第二階段從第一階段中選擇最合適的結果。在第二階段中丟棄信息稱為後過濾。後過濾旨在消除瑣碎、無關或錯誤的推薦，按相關性對它們進行排序，並僅顯示最合適的推薦。
過濾常常是通過將源代碼實體或其他工件與當前開發上下文進行比較來完成的。可以通過基於某種相似性度量，基於出現次數的頻率（如 FrUiT 和 Strathcona）或基於某些評分機制（如 CodeBroker）來完成比較。可以使用相似性，頻率或等級信息來完成預過濾和後過濾。頻率是評級的一種形式，但是頻率往往比評級更可取，這樣即使在推薦系統的早期階段（當尚未給出評級時）也可以提供推薦。不過，要使用頻率這一指標，必須先有幾個示例，這也是 API 推薦作為推薦系統支持的首選任務的原因之一。評級被較少採用的另一個原因是，早期的 SCoReS 報告稱它們是侵入性的，並且是引入噪聲的來源。但評分可能是收集方法有用性數據以及進一步邁向傳統推薦技術而不僅僅是挖掘技術的好方法。
3.7 詳細輸入/輸出
有關詳細輸入/輸出的決策涉及 SCoReS 所需的詳細信息（通常從開發上下文中提取或明確請求）以及 SCoReS 提供的結果數量。
3.7.1 輸入類型
除了語料庫（3.4 小節）之外，SCoReS 的構建者還需要確定系統分析所需的其他信息。該決策是對輸入機制和 3.5 小節中描述的輸入決策性質的改進。
某些推薦系統（如 Hipikat）從用戶給出的搜索查詢開始，而其他推薦系統可能從特定的源代碼實體開始（部分實現，例如 Strathcona 和 Rascal 或者空實現，例如 CodeBroker），或者某種方式映射的成對的實體或工件，又或者是共同表示某種更高級別概念的實體集。
如果用戶沒有明確的起點，則某些系統允許從提供的信息中（例如，當前正在編輯的文件中的任何標識符或文字）來找到它。
3.7.2 輸出的數量
應該謹慎選擇 SCoReS 提出推薦的數量。在推薦系統的設計中，提供簡潔準確的結果至關重要。將結果限制在一個合理的範圍內，可使開發者評估其適當性和價值，相應地去選擇或丟棄它們。如果 SCoReS 產生單個結果，則可以避免用戶選擇最相關結果的負擔，但也可能丟失其他相關結果。當返回多個結果時，可以通過對它們進行優先排序來減輕選擇最合適的結果的負擔，而不是顯示無序的結果列表。
3.8 支持
這一決策著重於與 SCoReS 所支持任務的適用性相關的方面。它有助於預見驗證系統有用性或正確性的方法。
3.8.1 經驗驗證
如果 SCoReS 的構建者希望從示例論證之外評估他們的系統，則重要的是使用哪種經驗驗證來評估其系統。驗證 SCoReS 的典型方法是案例研究（或對特定應用程序的深入分析）、基準測試、自動模擬系統使用、將系統的結果與某種 Oracle 或行業標準進行比較、具有因變量和自變量的受控實驗、從業人員進行的驗證或實地研究等。
驗證的最常見類型包括分析開發者如何使用系統，或與類似系統進行比較。大多數方法選擇開源系統進行驗證。在這種情況下，必須準確提及所使用的版本，以使驗證結果易於複製。還應考慮是否提供收集的語料和獲得的結果。向其他人提供此信息的訪問權限，使他們可以驗證和複製每個論證步驟，並有助於構建基準和模擬。還需提供驗證語料庫是否能正確構建的可能性，並可以識別使用同一語料庫的不同 SCoReS 給出的推薦之間的差異。
3.8.2 有效性
可以從三個方面驗證 SCoReS 與它支持的任務的相關性：評估 SCoReS 是否使用戶以更快地完成給定任務，或者說花費更少的精力。
大多數情況下，為了驗證系統，SCoReS 構建者僅進行案例研究來論證其系統推薦的實用性，而不進行定量的驗證。但是，無論選擇哪種驗證類型，都應注意特定驗證選擇的要求。例如，針對任務被令人滿意的完成了，就需要對任務進行明確說明，何時完成，以及唯一正確的響應是怎樣的。最後還要意識到，用戶忽略的推薦不一定表示不正確或無效的推薦。通過對現有 SCoReS 的分析及其驗證，我們認為仍然存在很多機會可以更好地評估推薦系統的有效性。
3.8.3 正確性
關於 SCoReS 產生結果的質量，典型的正確性度量包括精度（正確推薦的百分比）和召回率（推薦在多大程度上覆蓋了所需功能）。相關性也可以測量，但是通常是用戶的主觀看法，因此很難自動收集。
請注意，為了測量精度或召回率，有必要針對每個用戶上下文建立正確的推薦進行比較。實際上，根據推薦的性質，可能無法獲得理想的正確答案。此外，在進行這種類型的驗證時，重要的是能夠斷言所分析的用戶上下文是典型用戶上下文的重要示例。
3.9 交互
最後一組決策集中於不同類型的用戶如何與 SCoReS 進行交互。第一類用戶是使用 SCoReS 作為其工作支持的開發者。對於此類用戶，重要的是評估他們與 SCoReS（進行交互的難易程度以及在多大程度上可以輕鬆掌握 SCoReS。第二類用戶是研究人員，他們可能想將自己的方法與 SCoReS 進行比較。這些用戶擔心繫統的可用性，但更擔心數據的可用性，因為他們希望可以重現和比較結果。
3.9.1 易用性
關於 SCoReS 對預期的終端用戶（通常是開發者）的易用性，應仔細評估幾個標準，如系統的響應時間、結果的簡潔性，使用的容易程度和可伸縮性。但衡量 SCoReS 的易用性並非易事。簡單的方式是度量簡潔性或響應時間。但即使如此，除非將 SCoReS 的測量結果與類似系統的測量結果進行比較，否則這些測量結果本身並不能為 SCoReS 提供可靠依據。
3.9.2 系統可用性
該決策描述了將以何種形式提供系統：僅提供源代碼如 FrUiT；僅作為二進制文件；僅提供系統描述的如 Hipikat 和 Strathcona，或像 Rascal 和 CodeBroker 一樣並不能直接使用。根據系統構建者的預期目標，此決策可能會有很大不同。
3.9.3 推薦數據的可用性
最後一個決策是，是否提供 SCoReS 經驗驗證的結果。將所有產生的數據公開，可以讓其他研究人員複製驗證並比較系統之間的結果。有幾個級別的數據可用性需要考慮： SCoReS 收集或使用的語料庫，或者 SCoReS 在不同目標系統上產生的結果。最後，還可以存儲目標系統的版本，以便將它們用於創建基準或將給定 SCoReS 與其他 SCoReS（或相同 SCoReS 的未來版本）產生的結果進行比較。
致謝
感謝國家重點研發計劃課題：基於協同編程現場的智能實時質量提升方法與技術（2018YFB1003901）和國家自然科學基金項目：基於可理解信息融合的人機協同移動應用測試研究（61802171）支持！
本文由南京大學軟件學院 2018 級碩士生袁陽陽翻譯轉述。
閱讀更多 慕測科技 的文章
