情報処理学会研究報告
IPSJ SIG Technical Report

Redmine プラグイン依存関係問題を解決する手法とシステムの試作
豊永民哉1,a)松下 誠1,b)

肥後 芳樹1,c)

概要：Redmine は広く用いられているプロジェクト管理用オープンソースソフトウェアである．Redmineには多数のプラグインが存在し，それによって機能の追加やテーマの変更外部サービスとの連携が可能となる．しかし，プラグイン同士の依存関係による問題が発生し，プラグイン利用を阻んでいる．本報告では，整数非線形計画問題を用いて，Redmine プラグイン依存関係問題を解決する手法について述べる．本
手法では，事前にソースコードを解析し，ソフトウェア同士の互換性について評価を行って，その結果をデータベースに保存する．そのデータに対して整数非線形計画問題を適応することで依存関係問題の解決を行う．また，手法に基づいた依存関係問題解決システムの試作について述べる．
キーワード：Ruby，Redmine，依存関係問題，互換性問題

1. まえがき
ソフトウェアの依存関係 [9] とは特定のソフトウェアを実行する際に必要となる別のソフトウェアとの関係のことなる．しかし，複数のプラグインをインストールした際などに依存関係問題が発生することがあり，プラグイン依存
関係問題においても，ビルドエラーや実行エラー，想定外の動作がしばしば発生し，ユーザーを苦しめている．

である．ソフトウェアの依存関係は一般に依存するソフト

本報告では，Redmine の依存関係問題に対して整数非線

ウェアの名前とバージョンを用いて静的に指定される．開形計画問題を用いた手法とそれに基づいた実装について述

発者がソフトウェアの依存関係についてメタデータなどでべる．あらかじめ，依存関係のあるソフトウェアコンポー

指定することで，利用者は開発者のソフトウェア構成を再ネントの互換性について事前にソースコードベースの解析

現することができる．しかしながら，ソフトウェア依存関を行い，その結果を互換性評価値としてデータベースに保係の記述に関して，誤りやメンテンスの不足などがあった

存しておく．保存された互換性評価値を用いて依存関係問

場合には依存関係問題が発生することがある [3]．依存関

題を整数非線形計画問題に帰着させる．整数非線形計画問係問題の発生により，ソフトウェアのビルドエラーや実行

題をソルバーに入力することで依存関係のあるソフトウェ

エラー，想定外の動作が発生するため，ソフトウェアを利アコンポーネントの実行可能性の高いバージョン構成を取用できないことがある [11]．本報告では，ソフトウェアの得することができる．

依存関係問題，その中でも，Redmine [5] における依存関係問題を扱う．

以降，2 節では本報告の背景として，Redmine プラグイ
ン [6] の依存関係問題について紹介する．さらに，3 節でRedmine は Ruby [12] で作成されたプロジェクト管理用は本報告における関連研究について，4 節では，提案したのオープンソースソフトウェアで，様々な企業のプロジェ手法について，5 節では，実装ツールの詳細について述べ

クトで採用されている．Redmine にはサードパーティ製のる．また，6 節では評価実験について述べる．最後に 7 節

プラグインが多数存在し，それを利用することにより，機では，まとめと今後の課題について述べる．

能の追加やテーマの変更，外部サービスとの連携が可能と

1

a)
b)
c)

大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology,
Suita, 565–0871, Japantyngtmyn@ist.osaka-u.ac.jp
matusita@ist.osaka-u.ac.jp
higo@ist.osaka-u.ac.jp

c 1959 Information Processing Society of Japan⃝

2. 背景
本節では，本報告における背景として Redmine とその依存関係，Redmine プラグインの依存関係問題について説明することで，今回取り扱う課題を明確にする．

1

情報処理学会研究報告
IPSJ SIG Technical Report

2.1 Redmine
Redmine とは，Ruby で作られたプロジェクト管理用のウェブアプリケーションフレームワークであり，Ruby on

Rails (Rails)*1 を利用して作られているオープンソースソ
フトウェアである．Redmine は Ruby 本体の開発を含めて
図 1

様々なプロジェクトで採用されている*2 ．

Redmine における依存関係の例

Redmine には中核とされるチケットを利用した課題管理機能をはじめとして，作業の進捗を管理するためのガント
チャート機能，文書管理のための Wiki 機能，バージョン
管理システムとの連携機能，フォーラム機能などが備えられている．ここで，チケットとは主にソフトウェア開発において用いられる，タスク管理方法の一つでチケットには

図 2

Redmine プラグイン依存関係問題の発生

図 3

Redmine プラグイン依存関係問題の解決

タスクの発生内容や日時，担当者，期日が記載されている．

Redmine にはサードパーティ製のプラグインが多数存在
し，その数は 1000 以上である．ユーザはプラグインを利用することで，Redmine に標準では備えられていない機能の追加，テーマの変更，標準でサポートされない外部サー
ビスとの連携が可能となる．様々な Redmine プラグイン
が多くのユーザに利用されている．
不整合が発生している場合は，エッジが破線として表さ

2.2 Redmine における依存関係れる．

ここでは Redmine におけるソフトウェアの依存関係に

図 1 では redmine-4.0 が libraryC に対してバージョン制

ついて紹介する．ソフトウェアの依存関係は依存関係図と約 “>=2.0”，つまりバージョン 2.0 以上を求める．また，呼ばれる図を用いて表される．依存関係図はノード，エッliraryA-1.1 は libraryC に対してバージョン制約 “=1.5” つジ，制約の三つの要素で構成される．

まりバージョン 1.5 以上を求めていることが分かる．こノードはソフトウェアを表し，ノードの中にはソフトウェのとき，redmine-4.0 と pluginA-1.1 からの libraryC へのアの名前とそのバージョンが書かれている．図 1 においバージョン制約は矛盾したものになり依存関係問題が発生ては，Redmine のバージョン 4.0(redmine-4.0)，pluginA-する．

1.1，pluginB-2.1，libraryC-1.5，libraryD-2.2 がインストー

こ こ か ら は ，Redmine の 依 存 関 係 問 題 に つ い て 実

ルされていること，また Redmine の依存関係においては

際 の 例*3 を 用 い て 紹 介 す る ．以 下 の 図 2 は 具 体 的 な

Redmine とプラグイン，ライブラリが関わっていることがRedmine プ ラ グ イ ン 依 存 関 係 問 題 の 例 を 表 し た も の分かる．

で あ る ．図 2 で は redmine-4.1*4 と プ ラ グ イ ン で あ る

エッジはソフトウェアの依存関係を表す．エッジの出る

redmine hourglass-1.1.1*5 が イ ン ス ト ー ル さ れ て お り ，ソフトウェアから向かうソフトウェアに対して依存関係がredmine-4.1 は i18n*6 に 対 し て “=1.6.0” を 要 求 し て いある．図 1 の redmine-4.0 は pluginA，plguinB，libraryCる．対して，redmine hourglass-1.1.1 は faker*7 に対してに対して依存関係があることが分かる．ここで，Redmine“=1.7.3” を要求しており，faker-1.7.3 は i18n に対しての依存関係においては Redmine はプラグインとライブラ“>= 0.5, <0.6” を要求している．この時，Redmine-4.1

リに依存しており，プラグインはライブラリに依存していから i18n に対する制約と faker-1.7.3 に対する制約は解決

ることが分かる．また，ライブラリはライブラリに依存す

不可能となる．実際には，redmine hourglass の開発者にることがある．

よって，より新しい faker に対応するように制約を “>=

制約はソフトウェアの依存関係において，依存元のソフ

2.15.1,<2.6” に変更する修正を行うことにより対応していトウェアが依存先のソフトウェアに対して要求するバー

るが（図 3），利用者からの報告を受けてから実際に変更を

ジョンを表す．依存先のソフトウェアが依存元からの制約行うまでにおよそ 4 か月の時間がかかっている．

を満たしていない場合は制約の不整合が発生する．制約の

*3
*4

*1
*2

https://rubyonrails.org/
JAXA スーパーコンピュータ活用課では，チケット管理システ
ムとして Redmine をベースにした CODAhttps://www.jss.
jaxa.jp/about_coda/ を運用している．

c 1959 Information Processing Society of Japan
⃝

*5
*6
*7

https://github.com/hicknhack-software/redmine_hourgl
ass/issues/139
https://www.redmine.org/news/127
https://github.com/hicknhack-software/redmine_hourglass/
https://github.com/ruby-i18n/i18
https://github.com/faker-ruby/faker2

情報処理学会研究報告
IPSJ SIG Technical Report

3. 関連研究
本節では C#言語と Python 言語に関する依存関係問題を扱った研究について紹介する．

3.1 Nuﬁx
Nuﬁx [7] における例は C#エコシステムのライブラリ間の依存関係問題を取り扱った研究である．.NET エコシス
図 4

テムにおいてはプラットフォームが複数あるため，１つの手法の概要

プロジェクトの中で複数の依存関係問題が発生することもあり，開発者の頭を悩ませている．また，ライブラリのバージョン組み合わせ探索空間も非常に大きいため単純なアプローチでは解決が難しい．
この研究では実際の.NET における依存関係問題を調査

4. 提案手法
本節では，前節で紹介した Redmine プラグインにおける依存関係問題を解決するための手法について紹介する．

し，開発者の対処プロセスにおける共通点を発見した．この共通点に基づいて対処プロセスを 0-1 線形計画問題にと4.1 概要して定式化を行った．また，線形計画法のパラメータを実

以下の図 4 は本手法の全体像である．本手法は 2 つのス

際の依存関係問題事例を基にチューニングすることで開発テップで構成される．ステップ 1 では前処理として依存関者の対処プロセスに近いバージョン組み合わせを出力する係にあるプラグイン-ライブラリ，ライブラリ-ライブラリ

ことができる．Nuﬁx を実際の依存関係問題事例 262 件にの各バージョンにおける互換性に関する評価を行いスコア

適応し，その出力を得た．その結果，73.3%においてテスを算出し，データベースに保存する．このスコアを互換性

トの通過，さらに内 20 件においては実際のプロジェクト

評価値と呼ぶ．

にマージされた．

ステップ 2 では入力されたプラグインリストに基づいて依存するライブラリとその互換性評価値をデータベース

3.2 PyCREから取得する．取得されたスコアを基により実行可能性のPyCRE [2] における例は Python ライブラリの依存関係高いと考えられるバージョン組み合わせを探索する．バー問題を取り扱った研究である．Python のオープンソース

ジョン組み合わせの実行可能性は互換性評価値の平均値に

コードは様々なオンラインプラットフォーム上で公開さ基づいて評価されるこれを互換性評価値平均と呼ぶ．ここれている．しかし，ソースコードが利用するライブラリので，解となり得るバージョン組み合わせはライブラリの増依存関係が適切に指定されていないため，プログラマはし加とともに急速に増加する．そのため，互換性評価値平均

ばしばランタイム環境の再現に苦労する．この問題に対しを目的とした整数非線形計画問題を作成し，それを入力すて，Python 依存関係の自動推論ツールが先行研究 [4] におることで求めるバージョン組み合わせを取得する．

いて実装された．しかし，このツールは Python の依存関係を推論するための情報を十分に持っておらず，推論の成功率は低くなっている．

4.2 ステップ 1：互換性の評価
ステップ 1 では依存関係にあるプラグイン-ライブラリ

そこで，この研究では，事前の知識収集により作成されまたはライブラリ-ライブラリの互換性について各バージョたグラフ状のデータベースを用いた新しい Python ランラ

ンにおける評価を行い，スコアの算出を行う．このスコア

イム環境推論ツール PyCRE を実装している．PyCRE はを以降では互換性評価値と呼ぶ．また，プラグイン-ライブ

PyPI でホストされている 10000 以上の Python ライブラ

ラリ間の互換性評価値をプラグイン-ライブラリ互換性評

リに対する事前調査を行い，ライブラリの名前，バージョ価値，ライブラリ-ライブラリ間の互換性評価値をライブラ

ン，保有しているモジュールの名前を取得する．そのうえ

リ-ライブラリ互換性評価値と呼ぶ．

で，ソースコードを解析することで依存しているライブラ

ここからは，プラグイン互換性評価とライブラリ互換性

リの名前とバージョンを推論する．その後，ライブラリが評価について紹介する．

依存するライブラリの依存関係を依存関係制約と独自のステップ 1-1：プラグイン互換性評価

ヒューリスティックアルゴリズムで解決する．PyCRE を

プラグイン互換性評価とは，依存関係のあるプラグイン

既存の依存関係問題例 10250 例に適応することで，既存手とライブラリの互換性に関する評価を行うことである．ス

法よりも 447 件多くインポートエラーを解決し，337 件多テップ 1-1 では，プラグイン-ライブラリ間の互換性評価値

く実行に成功している．

を依存関係にあるプラグイン-ライブラリの各バージョン

c 1959 Information Processing Society of Japan⃝3

情報処理学会研究報告
IPSJ SIG Technical Reportについて，プラグインの Gemﬁle とライブラリの利用可能なバージョン一覧を解析することでプラグイン-ライブラ
リ評価値の算出を行う．Gemﬁle とは，Ruby のソフトウェ
アの依存関係について記述されたファイルで，依存するライブラリの名前とバージョン制約が書かれている．プラグインの特定バージョンに対して互換性のあるライブラリのバージョンとの互換性評価値を 1，互換性のないバージョンとの評価値を 0 とする．

Gemﬁle の 解 析 に つ い て 紹 介 す る ．図 5 は redmine hourglass-1.1.0 の Gemﬁle から coﬀee-script との依存関係について記述した行を抜き出したものである．ここ

図 5

redmine hourglass-1.1.0 の Gemﬁleで “gem coﬀee-script” はライブラリである coﬀee-script に依存していることを示し，“ ˜>2.4.1” は redmine hourglass-1.1.0 が coﬀee-script に対して 2.4.1 以上，2.4.2 未満のバー
ジョンというバージョン制約を導入していることを示している．このとき，coﬀee-script の利用可能なバージョン
一覧が “...,2.2.0,2.3.0,2.4.0,2.4.1,2.4.2” として与えられたとすると，redmine hourglass-1.1.0 と coﬀee-script-2.4.1 の

図 6

互換性評価値は 1，redmine hourglass と coﬀee-script-2.4.1

API 照合以外との互換性評価値は 0 となる．

使 っ て ま す ．例 え ば ，ラ イ ブ ラ リ E-1.1 が ラ イ ブ ラ リステップ 1-2：ライブラリ互換性評価

F-1.1 を 呼 び 出 す 場 合 を 考 え る（ 図 6）．E-1.1 は F-1.1

ライブラリ互換性評価とは，依存関係にあるライブラリに対して，“ModuleA::ClassB.new，ModuleC.MethodD，同士の互換性に関する評価を行うことである．ステップ

ModuleC.MethodE，ModuleF.ClassG.new” を 呼 び 出 し

1-2 では，ライブラリ-ライブラリの互換性評価値を依存関た い 一 方 で ，F-1.1 が “ModuleA::ClassB.new，Mod-係にあるライブラリペアの各バージョンについてソース

uleC.MethodD，ModuleC.MethodE” だけを API としてコードへの解析を行うことで算出する．ソースコード解析

持っていたとすると，4 つの API 呼び出しのうち 3 つをでは依存関係にあるライブラリペアの各バージョンにおけ

F-1.1 が満たしているので，E-1.1 と F-1.1 の互換性評価値

る互換性を 0 から 1 の間を取る小数で評価する．スコアをは 0.75 となる．このような解析をライブラリ E とライブ

小数で評価することで本来インストール不可能となるソフ

ラリ F の各バージョンについて行うことで，ライブラリ E

トウェアの構成であっても可能なかぎり実行可能性の高いとライブラリ F 間の互換性評価を行う．

バージョン構成を探索することができる．ソースコード解
析は提供 API 抽出，呼び出し API 抽出，API 照合で構成

4.3 ステップ 2：ソルバーによるバージョン探索

される．ここからは架空のライブラリ E のバージョン 1.1

ステップ 2 ではまず，利用したいプラグインを入力としとライブラリ F のバージョン 1.1 を用いた簡単な例を紹介て与え，データベースから依存するライブラリと互換性評する．

価値を取得する．その後，互換性評価値平均の最大化を目

提供 API 抽出

的とする整数非線形計画問題を作成し，それをソルバーに提供 API 抽出では依存先ライブラリが保持している API

入力する．ソルバーからの出力をソフトウェアバージョンの完全修飾名をソースコードの AST を解析することで取リストと互換性評価値平均に変換することで，最終的な出得する．

力を得る．ここからは互換性評価値平均の求め方と整数非呼び出し API 抽出

線形計画問題，互換性評価値平均の最大化を目的とする整呼び出し API 抽出では依存元ライブラリが呼び出す依存数非線形計画問題の作成，ソルバーによる探索と出力変換

先ライブラリの API の完全修飾名をソースコードの ASTについて紹介する．

を解析することで取得する．

互換性評価値平均の求め方

API 照合ここではスコアが与えられた場合の互換性評価値平均算

API 照合では抽出された依存元の API 呼び出しを依出手順を，ごく簡単な例を用いて紹介する．例えば，プラ

存 先 ラ イ ブ ラ リ の API を ど れ だ け 満 た し て い る か に

グイン A がインストールされており，プラグイン A が依ついて解析を行う．ライブラリーライブラリの方で実存するライブラリ B とライブラリ C がインストールとす

例を持ってくると大きくなりすぎるので，架空の例をる．さらに，プラグイン A ーライブラリ B ペアの各バー

c 1959 Information Processing Society of Japan⃝4

情報処理学会研究報告
IPSJ SIG Technical Report
表 1

プラグイン A-ライブラリ B の各バージョンペアに与えられた
スコア

表 2

HH
B
1.0
H
HH
A
H

1.1

2.0

2.1

1.0

1

0

0

0

1.1

0

1

0

0

2.0

0

0

1

0

2.1

0

0

0

1

表 3

H

取得された互換性評価値例

HH A 1.0
H
B
H
H

プラグイン A-ライブラリ B の各バージョンペアに与えられた
スコア

1.1

1.0

0.66

0.50

1.1

1.00

0.75

3x21 + 4x22 + 5(2)−5 < x1 < 5, −2 < x2 < 2(3)整数非線形計画問題の作成
ここでは依存関係問題を互換性評価値平均の最大化を目

HH

C

1.0
H
HH
A
H

1.1

2.0

2.1

的とした整数非線形計画問題へ変換する方法についてごく

1.0

0.75

0.50

0.33

0.10

簡単な例を用いて紹介する．例えばプラグイン A がイン

1.1

0.75

0.80

0.70

0.50

ストールされており，プラグイン A が依存するライブラリ

2.0

0.50

0.75

0.85

0.75

としてライブラリ B が存在したとする．また，プラグイン

2.1

0.50

0.55

0.80

1.00

A とライブラリ B の互換性評価値が表 3 のように定義されていたとする．このとき，互換性評価値平均を目的関数とジョンにおけるスコアとプラグイン A ーライブラリ C ペ

してとる整数非線形計画問題は以下の手順で作成される．

アの各バージョンにおけるスコアが以下の表 1，表 2 よう変数の生成: 変数は各プラグインや各ライブラリの各に与えられたとする．ここで，表の 1 行目は依存先ライブバージョンに割り当てられる．表 3 のような互換性評価値

ラリのバージョン，1 列目は依存元ライブラリのバージョが与えられた場合，生成される変数は以下の式 4 のようにンを表す．

なる．ここで，VA−1.0 はプラグイン A のバージョン 1.0 がこのとき，プラグイン A-1.0，ライブラリ B-1.0，ライブ

選択されるかどうかを表す．

ラリ C-1.0 がインストールされていたとすると，互換性評
価値平均は 0.88 となる．また，プラグイン A-1.1，ライブ

VA−1.0 , VA−1.1 , VB−1.0 , VB−1.1(4)

ラリ B-1.1，ライブラリ C-1.0 がインストールされていたと定数の生成: 定数は各プラグインや各ライブラリの互換

すると，互換性評価値平均は 0.75 となる．このように，算性評価値に基づいて生成される．生成される定数が以下出される互換性評価値平均を最大化するバージョン組み合の式 5 のようになる．ここで CA−1.1B−1.0 はプラグイン

わせを見つけることで可能な限り実行可能性の高いと思わ

A-1.1 のライブラリ B-1.0 の互換性評価値を示す．

れるバージョン組み合わせを探索することができる．バー
ジョン組み合わせ探索における解の候補は依存するライブ

CA−1.0B−1.0 = 0.66

ラリの増加とともに急速に増加し単純なアルゴリズムではCA−1.1B−1.0 = 1.00

解を見つけることが難しい．そのため，依存関係問題を整CA−1.0B−1.1 = 0.50

数非線形計画問題へ変換しソルバーへ入力することで解空間の探索を効率的に行う．

(5)

CA−1.1B−1.1 = 0.75
目的関数の生成: 目的関数は生成された変数と定数を基

整数非線形計画問題
ここでは，本手法で利用する整数非線形計画問題 [1] にに互換性評価値平均を算出する．

ついて述べる．非線形計画問題とは目的関数もしくは制約

obj =CA−1.0B−1.0 ∗ VA−1.0 ∗ VB−1.0 +条件の中に線形ではない式が含まれているような最適化問

CA−1.1B−1.0 ∗ VA−1.1 ∗ VB−1.0 +題のことであり，資源配分問題や交通流割当問題などの最適化などで用いられる．その中でも，変数が整数に限られるものを整数非線形計画問題という．計画問題には変数，

CA−1.0B−1.1 ∗ VA−1.0 ∗ VB−1.1 +(6)

CA−1.1B−1.1 ∗ VA−1.1 ∗ VB−1.1

目的関数，制約式が含まれる．以下に簡単な例を紹介する．

制約の生成: 制約は，変数を基に生成され，各ソフトウェ

変数が式 1，目的関数が式 2，制約式が式 3 のように定アのバージョンのうち１つのみが選択可能となるように制まったとする．この問題を最大化するようにソルバーで最限する役割を持つ．ここで，V = 0 or 1 は変数が非選択，適化を行うと，目的関数の値は 60，x1 の値は 5，x2 の値

選択で表されること，VA−1.0 + VA−1.1 = 1 はプラグイン

は 2 となる．

A のうち 1 つのみが選択可能であることを示す．
V = 0 or 1

x1 , x 2
c 1959 Information Processing Society of Japan
⃝

(1)

(7)

VA−1.0 + VA−1.1 = 1, VB−1.0 + VB−1.1 = 1

5

情報処理学会研究報告
IPSJ SIG Technical Report

Algorithm 1 情報収集
plugins = input()libraries = list()
for plugin ← plugins do
getDepencyInf o(plugin) #依存関係情報の取得
end forfor library ← libraries dodownloadLibrary(library) #ライブラリのダウンロード
end for
図 7

試作システムの概要

Algorithm 2 プラグイン互換性判定
ソルバーによる探索と出力変換
整数非線形計画問題を数理計画ソルバーに入力し，その出力結果を得る．整数非線形計画問題の作成で紹介した問題をソルバーへ入力した場合は出力として，目的関数 obj = 1.0，
変数 VA−1.0 = 1, VA−1.1 = 0, VB−1.0 = 0, VB−1.1 = 1 が得られる．これをソフトウェアバージョンリストと互換性評

gemf iles = input(1) #各プラグインの Gemﬁlevers = input(2) #各ライブラリの利用可能なバージョン
for gemf ile ← gemf iles docompatilities ← procGemf ile(gemf ile, vers) #プラグイ
ン-ライブラリ互換性評価値の算出
storeCompatibility(compatibility) #互換性評価値の保存
end for

価値平均に変換すると，リストの内容は “A-1.0,B-1.1” になる．また，依存関係の数は１であるため，互換性評価値
平均は 1.0 となる．これを本手法の出力とする．

5. ツールの試作

5.2 利用するリポジトリ
RubyGem リポジトリは Ruby の公式ライブラリリポジ
トリである．API を利用して依存関係情報の取得，バージョン情報の取得，ソースコードのダウンロードが可能で本節では 4 節で述べた手法を基にして試作した依存関係

ある．本システムではこのリポジトリに対して API を通問題解決システムについて述べる．はじめにシステムの全じて依存関係情報，バージョン情報，ソースコードの取得

体像について紹介したのち，その詳細について紹介する．

を行う．

Redmine プラグインリポジトリは，Redmine が提供し5.1 概要ている公式のリポジトリであるが，これは API を利用し以下の図 7 は試作した依存関係システムの全体像であての情報取得，ソースコードのダウンロードが不可能である．プラグインリストを入力として受け取り，それに基づる．そのため，本実装では Redmine プラグインリポジト

いて依存関係情報，ソースコードとプラグインの Gemﬁleリからクローリングによりソースコードを取得して，ローの収集を行う．

カルプラグインリポジトリを形成した．この際，取得する情報収集モジュールは取得したプラグイン Gemﬁle とラ

プラグインは redmine-3.0 以上に対応しており，なおかつイブラリの利用可能なバージョン情報をプラグインーラ

Redmine プラグインリポジトリにおいて１つ以上の評価をイブラリ互換性評価モジュールへ，依存関係とライブラリ得ているものとした．その結果，対象とするプラグインはのソースコードをライブラリーライブラリ互換性評価モ

合計で 364 となった．

ジュールへ提供する．提供された Gemﬁle，依存関係情報，
ソースコードを基に互換性評価を行い，評価値をデータ

5.3 ライブラリ情報収集モジュール

ベースへ保存する．バージョン探索モジュールはプラグイ

情報収集モジュールでは入力として利用するプラグイン

ンリストを受け取り，それを基にデータベースに問い合わの名前を入力することで依存するライブラリの依存関係せを行い，ソフトウェア依存関係と互換性評価値の取得を情報とソースコードを RubyGem リポジトリから取得する行う．取得した依存関係と互換性評価値を基に依存関係問（Algorithm 1）．

題を整数非線形計画問題に変換し，それを解くことで互換性評価値平均が最大となるバージョン構成を得ることがで

5.4 プラグイン互換性判定モジュール

きる．なお，情報収集モジュール，プラグイン互換性評価

プラグイン互換性評価モジュールでは利用するプラグイ

モジュール，ライブラリ互換性評価モジュールは Ruby を

ンの Gemﬁle と利用可能なライブラリのバージョンを与え用いて実装し，バージョン探索モジュールは Python を用ることで，プラグインとライブラリの各バージョンにおけいて実装した．

る互換性評価値を 4.2 節のステップ 1-1 で説明した手法で以降，利用するリポジトリとシステムの各モジュールについて説明する．

c 1959 Information Processing Society of Japan⃝算出し，互換性情報データベースに保存する（Algorithm

2）．

6情報処理学会研究報告
IPSJ SIG Technical Report

Algorithm 3 ライブラリ互換性判定
sourcec odesp airl ist = input() #依存関係にあるライブラリのソースコードのペアをリストにしたもの
for sourcec odesp air ← sourcec odesp airl ist do
dependencyc odes = sourcec odesp air[0] #依存先の各バー
ジョンのソースコード
dependantc odes = sourcec odesp air[1] #依存元の各バージョ
ンのソースコードfor depc ode ← dependencyc odes dofor dantc ode ← dependantc odes doscore = getCompatibility(depc ode, dantc ode) #互
換性評価値の算出
storeCompatibility(score) #互換性評価値の保存
end forend forend for

Algorithm 4 ソフトウェアバージョン探索
plugins = input()compatibilities = getCompatibilities(plugins) #互換性評価値の取得
problem = createP roblen(comaptibilities) #整数非線形計画問
題の作成
results = Solve(problem) #ソルバーによる出力の取得
OutP ut(results) #ソルバー出力の加工

Algorithm 5 バージョンの選択
sorted versions = input()selected versions = list()
for i ← range(1..5) do
len = sorted versions.length()
selected versions ← sorted versions[int(len ∗ i/5)]
end forreturn selected versions

依存関係問題が解決するかを確かめる．ここからはデータセット，実験手順，実験結果，考察の順に紹介する．

6.1 データセット
実験で用いるデータセットについて紹介する．実験ではredmine-4.1，redmine hourglass とそれぞれが依存するラ
イブラリ 174 例を利用する．
依存するライブラリのバージョンに関してはセマンティッ
クバージョニングに基づき，基本的にはメジャーバージョ
ンのうち最新のもののみをデータセットに含めることとする．ただし，メジャーバージョンアップデートが極端に少ないライブラリ（本実験においてはメジャーアップデートが４回未満のライブラリとする．
）については，ライブラリの5.5 ライブラリ互換性判定モジュール

各バージョン文字列を RubyGem リポジトリにおけるバー

ライブラリ互換性評価モジュールでは依存関係にあるラジョン比較方法によってソートした結果に対してバージョ

イブラリのソースコードを与えることでライブラリ間の互ンの取得を行う（Algorithm 5）．ここで，sorted versions

換性評価値を各バージョンについて，4.2 節のステップ 1-2

はソートされた各バージョン文字列のリストである．

で紹介した手法で算出し，それを互換性情報データベース
へ保存する（Algorithm 3）．

6.2 手順ま ず 初 め に 前 処 理 と し て ，Redmine-4.1 と red-

5.6 互換性情報データベース

mine hourglass-1.1.0 の依存するライブラリとその依存互換性情報データベースには互換性判定で解析されたプ

関係を依存情報収集モジュールへ入力する．依存情報収集

ラグイン-ライブラリ，ライブラリ-ライブラリの互換性評

モジュールはプラグインの Gemﬁle と依存するライブラリ

価値は互換性情報データベースに保存される．互換性評価を収集する．プラグイン互換性評価モジュールは Gemﬁle

値は依存元ソフトウェアの名前とバージョン，依存先ソフと依存するライブラリの情報を基に互換性評価値を互換性

トウェアの名前とバージョンと共に保存され，ソフトウェ

情報データベースに保存する．また，ライブラリ互換性評

アバージョンの探索に利用される．

価モジュールは依存関係にあるライブラリのソースコー
ドを基に互換性評価値を互換性情報データベースに保存

5.7 ソフトウェアバージョン探索モジュールする．次に，Redmine-4.1 と redmine hourglass-1.1.0 のリ

ソフトウェアバージョン探索モジュールでは入力としてストをバージョン探索モジュールに与えることで，依存関利用したいプラグインのリストを与えると，4.3 で紹介し係にあるライブラリのバージョンリストを得る．最後に，た手法で整数非線形計画問題を作成してソルバーに入力

Redmine-4.1 と redmine hourglass をインストールしたのする．ソルバーから得られた出力を基にライブラリのバー

ちライブラリ出力されたバージョンリストの通りにライブ

ジョンリストと互換性評価平均値を出力する（Algorithm

ラリのインストール，redmine と redmine hourglass が正4）．

しく実行できるかテストを行う．

6. 手法の適応例

6.3 結果

本節では試作した依存関係解決システムを依存関係問題

以下の図 8 がバージョン推薦実行時に入力されたリスト

へ適応した例について紹介する．ここでは 2.2 節で紹介しであり，図 9 がその出力結果である．出力結果についてはた事例に対して試作したシステムを適応することで実際にその一部を示す．

c 1959 Information Processing Society of Japan⃝7

情報処理学会研究報告
IPSJ SIG Technical Report

謝辞

本研究は JSPS 科研費 22K11985 の助成を受けた

ものです．
図 8

入力リスト

参考文献
[1]

[2]

図 9

出力バージョンリスト

[3]

データセット，適応手順をもとに手法の検証を行った．
その結果，Redmine を実行するために必要な Rails コマ
ンドの実行時にエラーが発生した．このエラーは railties
ライブラリが依存する activesupport ライブラリの transe-[4]

form valuesAPI が不足していたことによるものであった．
6.4 考察[5]Redmine 及び Redmine プラグインのテストを実行するには Rails コマンドの実行が必須となるが，インストール[6]

スクリプトの実行によって得られたライブラリ構成では，Rails コマンドの実行時にエラーが発生した．その理由としては，依存元ライブラリが必要とする依存先ライブラリ[7]の API の不足が考えられる．本手法では，すべての依存元
ライブラリが呼び出すすべての API を依存先ライブラリの提供する API が満たされない場合でも，可能な限り API[8]

呼び出しを満たすバージョン構成を出力する．この際，各API は同等のものとして扱われる．これによって，多くの[9]ライブラリやメソッドから呼び出される，API を含まないバージョン構成を出力することが考えられる．

7. まとめ
本報告では Redmine プラグイン依存関係問題を解決す[10]

る手法と試作システムについて述べた．また，試作したシステムを用いて既存の依存関係問題事例に対する本手法の[11]適応を行った．
今後は，ライブラリ間の互換性判定において API の照合をする際に依存先ライブラリの各 API に重みを付ける手法により，より実行可能性の高いバージョン構成を出力することができると考えられる．API の重み付けをする手法
として，メソッドをノード，メソッド呼び出しをエッジと[12]

Bretthauer, K. M. and Shetty, B.: The nonlinear knapsack problem – algorithms and applications, European
Journal of Operational Research, Vol. 138, No. 3, pp.
459–472 (online), DOI: 10.1016/S0377-2217(01)00179-5(2002).
Cheng, W., Zhu, X. and Hu, W.: Conﬂict-aware
inference of python compatible runtime environmentswith domain knowledge graph, Proceedings of the44th International Conference on Software Engineering, New York, NY, USA, p. 451–461 (online), DOI:
10.1145/3510003.3510078 (2022).
Fan, G., Wang, C., Wu, R., Xiao, X., Shi, Q. and Zhang,C.: Escaping dependency hell: ﬁnding build dependency
errors with the uniﬁed dependency graph, Proceedings ofthe 29th ACM SIGSOFT International Symposium on
Software Testing and Analysis, New York, NY, USA, p.
463–474 (online), DOI: 10.1145/3395363.3397388 (2020).
Horton, E. and Parnin, C.: V2: fast detection of
conﬁguration drift in Python, Proceedings of the 34th
IEEE/ACM International Conference on AutomatedSoftware Engineering, IEEE Press, p. 477–488 (online),
DOI: 10.1109/ASE.2019.00052 (2020).
Lang, J.-P.: Overview - Redmine, Jean-Philippe Lang(online), available from ⟨https://www.redmine.org/⟩(accessed 2024-01-26).
Lang, J.-P.: Plugins - Redmine, Jean-Philippe Lang (online), available from ⟨https://www.redmine.org/plugins⟩(accessed 2024-01-26).
Li, Z., Wang, Y., Lin, Z., Cheung, S.-C. and Lou, J.-G.:
Nuﬁx: escape from NuGet dependency maze, Proceedings of the 44th International Conference on Software
Engineering, New York, NY, USA, p. 1545–1557 (online), DOI: 10.1145/3510003.3510118 (2022).
市井 誠，松下 誠，井上克郎： Java ソフトウェアの部
品グラフにおけるべき乗則の調査，電子情報通信学会論
文誌 D， Vol. J90-D, No. 7, pp. 1733–1743 (2007).
Mukherjee, S., Almanza, A. and Rubio-González, C.:
Fixing dependency errors for Python build reproducibility, Proceedings of the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis,
ISSTA 2021, New York, NY, USA, p. 439–451 (online),
DOI: 10.1145/3460319.3464797 (2021).
Page, L., Brin, S., Motwani, R. and Winograd, T.: The
PageRank Citation Ranking : Bringing Order to theWeb, The Web Conference (1999).
Wang, C., Wu, R., Song, H., Shu, J. and Li, G.:
smartPip: A Smart Approach to Resolving Python
Dependency Conﬂict Issues, Proceedings of the 37th
IEEE/ACM International Conference on AutomatedSoftware Engineering, New York, NY, USA, (online),
DOI: 10.1145/3551349.3560437 (2023).
Ruby コミュニティ： オブジェクト指向スクリプト言
語 Ruby，Ruby コミュニティ（オンライン），入手先⟨https://www.ruby-lang.org/ja/⟩ （参照 2024-01-26）.

したソフトウェア部品グラフ [8] の構成を行い．ページラ
ンクアルゴリズム [10] などの各ノードの重要度を表す指標を算出することで API への重みづけを行うことが考えられる．

c 1959 Information Processing Society of Japan⃝

8