JP2008186244A - プログラム開発装置、プログラム開発方法およびプログラム - Google Patents

Abstract

【課題】少資源ソフトウェアとして高効率な実装を行われたソースコードに対する保守作業を容易にすることができる。
【解決手段】本発明のプログラム開発方法は、第１のソースコードに含まれる各コード群を複数のグループに分割し、各グループに含まれるコードを前記第１のソースコード内での実行順序に従って並べ、各並べられたコード群を、各々に連続して実行されるべき１つ以上のコードが含まれる１つ以上のセクションに区分し、各区分されたコード群を記憶部に格納し、前記第１のソースコードをもとに前記各区分されたコード群間において各セクションに対する実行順序の制約を設定し、前記記憶部の内容と、前記実行順序の制約を表す制約情報をユーザに提示し、ユーザからの編集指令に基づき前記記憶部または前記制約情報またはこれらの両方を編集し、編集された記憶部と編集された制約情報とを用いて第２のソースコードを生成する。
【選択図】図２

Description

本発明は、メモリやプロセッサといった計算機資源の限られた組込み機器に用いるファームウェアのようなソフトウェアを、実行時の性能を維持したまま効率よく保守するためのプログラム開発装置、プログラム開発方法およびプログラムに関する。

少資源の組込み機器に用いるファームウェアの開発においては、性能要求が優先される余り、低レベル言語での開発を行ったり、ソフトウェアの保守性を高めるための非機能品質を犠牲にした実装を行ったりするなど、実行効率優先の開発が行われることが多い。

ここでいう「資源」とはメモリやプロセッサ性能のことであり、例えばこれらが極端に限られている組込み機器のファームウェア開発においては、性能重視の実装が行われることが多い。即ち機械語で直接コーディングが行われることもあるし、C などの高級言語を用いる場合でも、移植性、保守性、及び可読性と言った非機能要求を犠牲にして、凝集度が低く、結合度が高いモジュール群で実装されることもしばしば見受けられる。このような実装に対して機能追加や修正を行おうとすると、どの部分を修正することが適切なのかというような見通しが立てにくく、多くの工数を必要としたり不具合を多発させてしまうことが頻繁に見られた。

ちなみに結合度、凝集度というのはソフトウェアの品質を評価する尺度の例である。結合度とは、プログラムの構成要素間の繋がり・相互依存性の強さを測る尺度である。ソフトウェアの保守性の観点からは、構成要素の結合度は低い、即ち相互依存性が少ない方が望ましいとされている。なぜならば他との結合度が高い構成要素の保守作業を行う際には、他の構成要素への影響を考慮する必要があるからである。結合度尺度の例としては、CK メトリクスのCBO という尺度が挙げられる。

一方凝集度とは、プログラムの構成要素の機能のまとまり具合を測る尺度である。やはりソフトウェア保守性の観点からは、凝集度が高い、即ち機能のまとまり具合が大きいことが望ましいとされている。凝集度が低い構成要素とは、即ち複数の役割や機能が重畳している状態であり、構成要素内のある機能を修正しようとしたときに含まれる他の機能や役割に影響を及ぼす可能性が高いということになる。凝集度尺度の例としては、CK メトリクスのLCOM という尺度が挙げられる。

上述のように非機能要求を犠牲にした実装では機能追加や修正にあたり種々の問題があったが、反対にソフトウェア工学的に理想とされている冗長性の高い実装では、ファームウェアに求められる微妙な性能要求に対応できるような性能制御の自由度が限られてしまい、性能未達に陥るという問題もあった。

この様な問題に対する本質的な解決策は、これまで提案されたことは無かった。例えば複雑なソースコードを読み解くためのソースコード解析技術は数多く提案されている。スライシング技術などはソースコードの機能分解を行うための技術として定着しており、これを用いてソースコードを可読性の高い状態に変換するという研究も行われてはいる。ただしこれは一方向の変換であり、あくまでソースコードを読み解くだけの機能しか提供し得ない。

逆に可読性の高いコードから実行効率の高いコードを生成するという技術も、コンパイラの最適化技術を始め数多く提案されている。しかしながら機械的な最適化はやはり限界があり、人がソースコードレベルで細かな調整を行った結果には及ばない。逆にソースコードレベルで極端に最適化してしまって、コンパイラの最適化オプションを使わない方が、デバッグや機能検証の際に紛れの無い開発が出来るといったケースもあるため、コンパイラの最適化技術はあまり適さない技術である。

その他予めモジュール性の高い、即ち凝集度が高く結合度の低いコード片を組み合わせることで保守性を高めるといったアプローチは存在するが（例：米国特許明細書第6694505号）、そもそもモジュール性が低い場合には利用できないような技術であり、ここで示したような課題には適さない。また対象ソフトウェアのアーキテクチャを視覚化して提示することで生産性を向上させるような技術も存在するが（例：米国公開公報2004-0031015号）、これも今回対象としているように明示的に整頓されたアーキテクチャが存在しないケースには適用できない。
M.Weiser, Program Slicing, IEEE Trans. on Software Engineering, SE-10(4), p.p. 352.357, 1984.

基本的に少資源ソフトウェアの開発においては、人手によるソースコードレベルでの最適化の出来に依存する部分がかなり大きい。問題はこの様に最適化されたソースコードの保守性が極端に低いことであり、第三者はおろか、場合によってはオリジナルの作者でさえ保守をすることは非常に困難になっている。

本発明は、少資源ソフトウェアとして高効率な実装を行われたソースコードに対する保守作業を容易に行うことができるプログラム開発装置、プログラム開発方法およびプログラムを提供するものである。

本発明の一態様としてのプログラム開発装置は、
第１のソースコードに含まれる各コードを所定のアルゴリズムにより複数のグループに分割する分割部と、
各グループに含まれるコード群を前記第１のソースコード内での実行順序に従って並べ、各並べられたコード群を、各々に連続して実行されるべき１つ以上のコードが含まれる１つ以上のセクションに区分する区分部と、
各区分されたコード群を格納する記憶部と、
前記第１のソースコードをもとに前記各区分されたコード群間において各セクションに対する実行順序の制約を設定する設定部と、
前記記憶部の内容をユーザに提示する第１の提示部と、
前記実行順序の制約を表す制約情報をユーザに提示する第２の提示部と、
ユーザからの第１の編集指令に基づき前記記憶部を編集する第１の編集部と、
ユーザからの第２の編集指令に基づき前記制約情報を編集する第２の編集部と、
編集された記憶部と編集された制約情報とを用いて第２のソースコードを生成するソースコード生成部と、
を備える。

本発明の一態様としてのプログラム開発方法は、
第１のソースコードに含まれる各コードを所定のアルゴリズムにより複数のグループに分割し、
各グループに含まれるコード群を前記第１のソースコード内での実行順序に従って並べ、各並べられたコード群を、各々に連続して実行されるべき１つ以上のコードが含まれる１つ以上のセクションに区分し、
各区分されたコード群を記憶部に格納し、
前記第１のソースコードをもとに前記各区分されたコード群間において各セクションに対する実行順序の制約を設定し、
前記記憶部の内容をユーザに提示し、
前記実行順序の制約を表す制約情報をユーザに提示し、
ユーザからの第１の編集指令に基づき前記記憶部を編集し、
ユーザからの第２の編集指令に基づき前記制約情報を編集し、
編集された記憶部と編集された制約情報とを用いて第２のソースコードを生成する、
ことを特徴とする。

本発明の一態様としてのプログラムは、
第１のソースコードに含まれる各コードを所定のアルゴリズムにより複数のグループに分割するステップと、
各グループに含まれるコード群を前記第１のソースコード内での実行順序に従って並べ、各並べられたコード群を、各々に連続して実行されるべき１つ以上のコードが含まれる１つ以上のセクションに区分するステップと、
各区分されたコード群を記憶部に格納するステップと、
前記第１のソースコードをもとに前記各区分されたコード群間において各セクションに対する実行順序の制約を設定するステップと、
前記記憶部の内容をユーザに提示するステップと、
前記実行順序の制約を表す制約情報をユーザに提示するステップと、
ユーザからの第１の編集指令に基づき前記記憶部を編集するステップと、
ユーザからの第２の編集指令に基づき前記制約情報を編集するステップと、
編集された記憶部と編集された制約情報とを用いて第２のソースコードを生成するステップと、
をコンピュータに実行させる。

本発明により、少資源ソフトウェアとして高効率な実装を行われたソースコードに対する保守作業を容易に行うことができる。

本発明に関わるソフトウェア高生産性開発環境の実施形態について、図面を参照して説明する。

図1 は本発明の実施形態に係わるソフトウェア高生産性開発環境の働きを示す概念図である。今編集の対象となるソースコード104 が与えられているとする。ソースコード104 に適切な機能追加や修正を施して、改良されたソースコード105 を得ることが目的であるとする。ソースコード104 や改良されたソースコード105 は実際にコンパイルの対象となる最終プロダクトであり、実コード空間101 に存在すると定義される。

従来のソフトウェア開発では、実コード空間101 上でソースコード104 を直接編集することで機能追加や修正が行われていたが、ソースコード104 の保守性が低いことが問題であった。

理想的にはソースコード104 に含まれる各機能が独立して実装されている状態、例えばソースコード104 には機能単位（グループ）109 〜 113 が含まれていると考えたとき、ユーザビュー103 にあるような環境で、例えば機能単位108 の追加を行ったり、機能単位112 に対する修正を行ったりといった各種保守作業が行われれば生産性が上がると考えられる。

このユーザビュー103 のような表現を仮想的に与え、機能追加や修正の結果を実コード空間101 上に反映するために、仮想コード空間102 を準備し、実コードと、機能追加や修正とを結合することが必要である。仮想コード空間102 上の分割ソースコード106、および107 は、それぞれソースコード104、および105 を機能単位に切り出して仮想的に分割された状態を保持するものである。

本実施形態は即ち、ソースコード104 を分割して分割ソースコード106 を仮想的に準備し、これに基づいて機能単位109 〜 113 をユーザビュー103 として提供することを可能とするものである。ユーザビュー103 上では機能単位108 を追加したり、機能単位112 に対する修正作業を行ったりということが出来るような機能が提供されており、元のソースコード104 に対する直接の編集作業よりも格段に生産性が向上されている。ユーザビュー103 上で行われた編集結果は、仮想コード空間102 上で分割ソースコード106 に対して直列化されることにより、新たな分割ソースコード107 が生成される。この分割ソースコード107 の情報に基づいて実コード空間上のソースコード104 に自動的に変更を反映し（合成）、最終的に改良されたソースコード105 を得ることが可能になる。

次に上記で述べたような概念を具体化するための、本発明の実施形態のひとつを図2 に示す。オリジナルソースコード201 は図1 のソースコード104 に対応し、修正後ソースコード209 は図1 の改良されたソースコード105 に対応する。

本発明の実施形態としてのプログラム開発装置210は、五つの独立な機能部202,204,205,207,208と二つの独立なデータベース（DB）203,206とを備えている。データベースはたとえば記憶部に相当する。各機能部による処理はたとえばそれぞれに対応するプログラムモジュールの実行として実現されてもよい。

機能抽出部（分割部、区分部）202 は、本発明の中核をなす機能の一つである。この機能の実装例については後ほど詳述するが、基本的にはオリジナルソースコード201 から独立な機能単位を切り出すことにある。機能単位を切り出すときには、各機能単位の機能がそれぞれ独立であるように切り出し、各機能単位がどのような内部状態（後述）を取り得るかということも認識する。具体的にはプログラムスライシングやdef-use解析などの技術を応用することで可能になる。例えば模式的ではあるが、図1 中の機能単位109 を例にとると、この機能単位は四つの内部状態を持っている（四つのセクションに区分されている。たとえば１つのセクション内では内部変数の値は一定である）ことを示している。この各機能単位の内部状態の認識は、具体的にはdef-use 解析と呼ばれる技術を応用することで可能になる。機能抽出部202 によって切り出された各機能単位は、機能DB203 に登録され、管理される。機能DB 203 に登録された各機能単位間、および１つの機能単位内では、オリジナルのソースコードの行単位の実行順序関係が保持されている。

機能編集部（第１の編集部、第１の提示部）204 は、ユーザとのインターフェイスを取りながら、図1 のユーザビュー103 を提供する。機能編集部204 は機能DB203 から機能単位を取り出してユーザが自由に編集できるようになっている。機能編集部204はユーザからの編集指令（第１の編集指令）にしたがって編集を行う。編集としては、機能単位の変更および削除のほかに、新たな機能単位の追加も出来るようになっており、ここで作成された機能単位は機能DB203 に登録され、管理されるようになっている。

機能状態依存関係分析部（設定部）205 は、機能DB に登録された各機能単位間における内部状態の依存関係を分析する（各内部状態を規定するコード群（各セクション）の実行順序の制約を設定する）。ここで依存関係として認識されるのは、内部状態間の半順序関係（各内部状態の順序関係を示すが、一部の内部状態間には順序関係がなくてもよい）や時間制約などもある。時間制約としては、例えば特定のレジスタに値が書き込まれたあとで無いとあるポートの操作が出来ないとか、場合によってはハードウェアの動作完了を待つために特定の時間動作を遅らせる、などが考えられる。半順序関係および時間制約は内部状態間の有向グラフとして表現すること（前記機能単位間において各セクション同士を方向付きアークにより結ぶこと）が可能である。すなわち機能状態依存関係分析部205は、各セクションの実行順序の制約を設定する。ここでのポイントは主としてオリジナルソースコード201 に含まれる情報を元に依存関係を分析しているということである。ここでは依存関係編集部207 が内部状態の依存関係の編集手段を提供していることを考慮して、冗長と思われるような依存関係も省略せずに抽出することが適当と考えられるが、必要に応じて最適な依存関係セットのみを検出できるようなアルゴリズムを実装することも可能である。この様にして分析された内部状態の依存関係は、機能状態依存関係DB206 に登録され、管理される。

依存関係編集部（第２の編集部、第２の提示部）207 は、ユーザに対して内部状態依存関係（機能単位間においてセクションに対する実行順序の制約）の編集のインターフェイスを提供する。依存関係編集部207はユーザからの編集指令（第２の編集指令）にしたがって編集を行う。編集には、たとえば変更、追加、削除がある。この依存関係編集部207が必要な理由は大きく分けて二つある。一つは機能状態依存関係分析部205 の検出した依存関係の中で冗長と思われるような関係を除去したり付け替えたりするためである。もう一つは機能編集部204 により新たな機能が付け加えられたり機能の修正があった場合に、適切に依存関係を付け加えたり変更・削除したりするためである。

以上のようにして、機能DB203 に登録された機能単位と、機能状態依存関係DB206 に登録された内部状態依存関係のセットとに対して必要な保守作業（編集作業）が行われた後、機能直列化合成部（ソースコード生成部）208 によって修正後ソースコード209 を生成する。編集前の機能DB203と、編集前の機能状態依存関係DB206と、ユーザにより入力された編集指令とから、修正後ソースコード209を生成してもよいし、オリジナルソースコード201 に対して必要な修正差分情報を編集後の機能DB203 や編集後の機能状態依存関係DB206 から取得し、取得した修正差分情報をオリジナルソースコード201に適用することにより修正後ソースコード209を生成してもよい。後者の場合、オリジナルソースコード201 に対する変更を必要最小限にとどめることが可能である。すなわち、各機能単位間の内部状態は半順序関係を有するため（一部の内部状態間には順序関係の制約がないため）、前者のように編集前の機能DB203と、編集前の機能状態依存関係DB206と、ユーザにより入力された編集指令とから修正後ソースコードを生成すると、オリジナルソースコードと実行順序が変わることがある。したがって実行順序の変更を最小限にとどめたいときはオリジナルソースコード201に対して差分情報を加えるのがよい。

次に本発明の実施形態を利用したソースコードの修正作業の様子を、例を用いて示す。図3 中のソースコード301 がオリジナルソースコード201 に対応し、図4 中のソースコード401 が修正後ソースコード209 に対応する。

図3 中の302 〜 304 は、機能抽出部202 によってソースコード301 から切り出された機能単位の例である。互いに依存関係のない出力変数を扱う機能単位でソースコード301が分割されている。Ｍ１、Ｍ２が出力変数であり、これらがユーザにより指定され、スライシング技術（所定のアルゴリズム）を適用することで、機能単位302〜304が得られる。図中で横破線により各機能単位は複数のセクションに区分されている。１つのセクションが１つの内部状態に相当し、１つの機能単位内において各セクションはソースコード301の実行順序に従って上から下方向に並べられている。１つのセクションには連続して実行されなければならないコード群が含まれる。たとえば機能単位302におけるtmp1=*S1と、*M1=M1_CTRL[2][tmp2]とは必ず連続して実行されるべきであり、これらの間に他のコードが挿入されることは認めるべきでない。tmp1,tmp2,は内部変数であり、内部変数が一定である間は関数controlの状態が一定であるとみなす。そして１つのcontrolの状態を１つの内部状態（セクション）として扱う。機能単位間でセクション間を結ぶ矢印は、機能状態依存関係分析部205 で分析された依存関係であり、依存関係編集部207 により編集可能である。矢印は、その出先のセクションのコード群が、その出元のセクションのコード群よりも時間的に後に実行されることを示す。図3 でソースコード301 が実コード空間上で管理されているソースコードであり、機能単位302 〜 304 がユーザビューとして与えられるものの例である。

このうち機能単位304 は出力変数に寄与しない特殊な機能単位である。本例では単なる時間稼ぎのループ（所定時間の待機を行う処理）が切り出されている。この様に出力に寄与しない変数は一括りにして切り出されている。機能単位304 については、単純にもとのソースコード上の、出力変数に寄与しないコードが切り出され、もとのソースコードの実行順序に従って並べられ、１つのコードが１つのセクション（内部状態）を規定している。また機能単位304内の各内部状態の依存関係（実行順序の制約）については、これも単純に元のソースコードにおいて隣接する機能単位の内部状態に依存することが示されている。

図4 中の402 〜 404 は、ユーザビューで編集作業が行われた結果を示している。ここでは新たに機能単位404 が追加されており、それに伴って依存関係（実行順序の制約）が削除されたり（破線矢印）、また新たに追加されたり（太線矢印）している。また機能単位402 は一部修正されている（下線Ｌ１参照）。

これらユーザビュー上で行われたソースコード修正作業から、オリジナルソースコードに対する修正差分情報を生成し、この情報を用いてオリジナルソースコード301 を修正した結果（追加された機能の各コードを、オリジナルソースコードの適切な位置に挿入した結果）がソースコード401 である。修正された内容は図中では下線Ｌ２で示されている。

次に機能抽出部202 の処理の詳細について、図5 および図6 に示すフローチャートに沿って説明する。

ステップ１：出力変数リスト（注目出力リスト）を生成する（Ｓ１１）。出力変数リストとは、ソースコード中で外部に対して何らかの値を出力している出力変数（注目出力）の集合である。これは機能単位を切り出す元になる情報となる。図３の場合、Ｍ１、Ｍ２が出力変数に相当する。

ステップ２：出力変数のそれぞれに対して、スライスを計算し、計算したスライスをスライスリストに登録する（Ｓ１２〜Ｓ１５）。スライスの計算とは、プログラムに含まれる関数や、変数の参照・代入関係などを解析し、プログラム内の注目すべき部分だけを抽出する技術である（非特許文献１参照）。１つの出力変数に対してプログラムから抽出されたコード群が１つのスライス（グループ）になり、１つのスライスは、図３の例では、１つの機能単位（302、303あるいは304）から内部状態を規定する横破線を除去したものに相当する。なお上述したように302〜304間の内部状態の依存関係（セクションの実行順序の制約）を表す矢印は機能状態依存関係分析部205により付されるもので現時点では当然ながら存在しない。以上の操作を、全ての出力変数について実施する。出力変数に影響しないコード群は１つのグループにまとめている（図３の例では304）。

ステップ３：抽出された全スライスを入力として、一次独立なスライス群を求める（Ｓ１６）。スライスが一次独立であるとは、スライス間で共有されるコードが無いことを示す。一次独立なスライス群を求めるとき、スライスの数が最大になるようにスライスの依存性を解決するようにする（Ｓ１７）。

ステップ４：全てのスライスが互いに一次独立となったら、スライスに含まれる変数（内部変数）に対してdef-use 解析を行って、内部状態を検出する（Ｓ１８〜Ｓ２０）。def-use 解析とは、変数に値が代入されてから参照されるまでをその変数の特定の値の寿命とみなし、各変数の値の寿命を算出する解析手法である。スライスに含まれる特定の変数群が一定の値をとっている間は、スライスの内部状態が変化していないと定義できるため、この解析によって内部状態を解析することが可能になる。

例えば図3 の機能単位302 を例に取ると、二行目のtmp1= *S1; と三行目の*M1= M1 CT RL[1][tmp1]; は、tmp1 という内部変数に関してdef-use の関係がある。即ち二行目ではtmp1 に対して代入が行われており（def(ine)）、ここで代入された値が三行目で参照されている（use）。この二行の関係は緊密であり、基本的に連続して行われる必要がある。なぜならばこの二行の間にtmp1 の値を変更する別の操作が割り込むと、三行目での結果の正しさが保証されなくなるからである。以上のように各内部変数についてdef-use 関係をトレースし、これが保存されるように状態の切り分けを行っていくのがステップ４のポイントである。

ステップ５：機能DB203 に、各スライス/グループと、各スライス/グループを複数の内部状態に区分する情報（図３の横破線参照）との組を機能単位として登録する（Ｓ２１）。

以上のように、本実施形態によれば、少資源ソフトウェアとして高効率な実装を行われたソースコードを対象としながらも、編集作業を行う者に対して保守作業を容易にすることができ、開発効率の向上が期待される。

すなわち、保守作業として考慮しなくてはならないのは、デバッグ、機能変更（含む削除）、機能追加等であり、本実施形態では、機能単位を認識して適切な修正が出来るとともに、保守性の低いソースコードに適切なビューを与えることができる。またシビアなタイミング制約などを適切に扱うことも可能である。また、オリジナルのソースコードの変更を最低限必要な範囲にとどめることができるため、プログラムの実行効率が犠牲にされることもほとんどない。

このように、本実施形態では、ソースコードの保守を行う際には機能単位に分割された低結合度・高凝集度のビューを提供して編集作業を容易にしつつ、実際はオリジナルのソースコードに対して最低限の変更によって機能の追加や修正などを行うことが可能となる。

本発明の実施形態の概念を示した図である。 本発明の実施形態の基本構成を示したブロック図である。 図２の基本構成への入力となるプログラムコードの例を示す図である。 図２の基本構成の出力となるプログラムコードの例を示す図である。 図２の基本構成に含まれる機能抽出部のアルゴリズムを説明したフローチャートの前半部分を示す図である。 上記フローチャートの後半部分を示す図である。

符号の説明

２０１：オリジナルソースコード
２０２：機能抽出部（機能分割部）
２０３：機能データベース（ＤＢ）
２０４：機能編集部（第１の編集部）
２０５：機能状態依存関係分析部（分析部）
２０６：機能状態依存関係データベース（ＤＢ）
２０７：依存関係編集部（第２の編集部）
２０８：機能直列化合成部（ソースコード生成部）
２０９：修正後ソースコード

Claims (21)

1. 第１のソースコードに含まれる各コードを所定のアルゴリズムにより複数のグループに分割する分割部と、
   各グループに含まれるコード群を前記第１のソースコード内での実行順序に従って並べ、各並べられたコード群を、各々に連続して実行されるべき１つ以上のコードが含まれる１つ以上のセクションに区分する区分部と、
   各区分されたコード群を格納する記憶部と、
   前記第１のソースコードをもとに前記各区分されたコード群間において各セクションに対する実行順序の制約を設定する設定部と、
   前記記憶部の内容をユーザに提示する第１の提示部と、
   前記実行順序の制約を表す制約情報をユーザに提示する第２の提示部と、
   ユーザからの第１の編集指令に基づき前記記憶部を編集する第１の編集部と、
   ユーザからの第２の編集指令に基づき前記制約情報を編集する第２の編集部と、
   編集された記憶部と編集された制約情報とを用いて第２のソースコードを生成するソースコード生成部と、から構成される
   プログラム開発装置。
2. 前記第２の提示部は、前記各区分されたコード群間において各セクション同士を方向付きアークにより結ぶことにより前記制約情報をユーザに提示することを特徴とする請求項１に記載のプログラム開発装置。
3. 前記第１の編集部は、区分されたコード群を前記記憶部に新たに追加、または、前記区分されたコード群を変更または削除することを特徴とする請求項１に記載のプログラム開発装置。
4. 前記第２の編集部は、前記実行順序の制約を追加、削除、変更することを特徴とする請求項３に記載のプログラム開発装置。
5. 第１〜第ｎ(ｎは１以上の整数)の前記グループは、同一の出力変数に影響を与えるコードの集合であり、前記第１〜第ｎのグループに対応する出力変数は互いに独立していることを特徴とする請求項１記載のプログラム開発装置。
6. 第ｎ＋１の前記グループは、全ての出力変数と無関係であるコードの集合であることを特徴とする請求項５記載のプログラム開発装置。
7. 前記第ｎ＋１のグループは、要求される時間制約を満足するための処理を行うコード群であることを特徴とする請求項６記載のプログラム開発方法。
8. 前記区分部は、内部変数に対する代入および参照の関係に基づいて前記各並べられたコード群を区分することを特徴とする請求項１に記載のプログラム開発装置。
9. 前記ソースコード生成部は、前記編集された記憶部および前記編集された制約情報と、編集前の記憶部および編集前の制約情報との差分をもとに前記第１のソースコードを修正することにより前記第２のソースコードを生成することを特徴とする請求項１に記載のプログラム開発装置。
10. 前記ソースコード生成部は、前記編集された記憶部および前記編集された制約情報とから前記第１のソースコードを用いることなく前記第２のソースコードを生成することを特徴とする請求項１に記載のプログラム開発装置。
11. 第１のソースコードに含まれる各コードを所定のアルゴリズムにより複数のグループに分割し、
    各グループに含まれるコード群を前記第１のソースコード内での実行順序に従って並べ、各並べられたコード群を、各々に連続して実行されるべき１つ以上のコードが含まれる１つ以上のセクションに区分し、
    各区分されたコード群を記憶部に格納し、
    前記第１のソースコードをもとに前記各区分されたコード群間において各セクションに対する実行順序の制約を設定し、
    前記記憶部の内容をユーザに提示し、
    前記実行順序の制約を表す制約情報をユーザに提示し、
    ユーザからの第１の編集指令に基づき前記記憶部を編集し、
    ユーザからの第２の編集指令に基づき前記制約情報を編集し、
    編集された記憶部と編集された制約情報とを用いて第２のソースコードを生成する、
    プログラム開発方法。
12. 前記制約情報の提示は、前記各区分されたコード群間において各セクション同士を方向付きアークにより結ぶことにより前記制約情報をユーザに提示することを含むことを特徴とする請求項１１に記載のプログラム開発方法。
13. 前記記憶部の編集は、区分されたコード群を前記記憶部に新たに追加、または前記区分されたコード群を変更または削除することを含むことを特徴とする請求項１１に記載のプログラム開発方法。
14. 前記制約情報の編集は、前記実行順序の制約を追加、削除、変更することを含むことを特徴とする請求項１３に記載のプログラム開発方法。
15. 第１〜第ｎの前記グループは、同一の出力変数に影響を与えるコードの集合であり、前記第１〜第ｎのグループに対応する出力変数は互いに独立していることを特徴とする請求項１１記載のプログラム開発方法。
16. 第ｎ＋１の前記グループは、全ての出力変数と無関係であるコードの集合であることを特徴とする請求項１１記載のプログラム開発方法。
17. 前記第ｎ＋１のグループは、要求される時間制約を満足するための処理を行うコード群であることを特徴とする請求項１６記載のプログラム開発方法。
18. 前記区分部は、内部変数に対する代入および参照の関係に基づいて前記各並べられたコード群を区分すること含むことを特徴とする請求項１１に記載のプログラム開発方法。
19. 前記第２のソースコードの生成は、前記編集された記憶部および前記編集された制約情報と、編集前の記憶部および編集前の制約情報との差分をもとに前記第１のソースコードを修正することにより前記第２のソースコードを生成することを含むことを特徴とする請求項１１に記載のプログラム開発方法。
20. 前記第２のソースコードの生成は、前記編集された記憶部および前記編集された制約情報とから前記第１のソースコードを用いることなく前記第２のソースコードを生成することを含むことを特徴とする請求項１１に記載のプログラム開発方法。
21. 第１のソースコードに含まれる各コードを所定のアルゴリズムにより複数のグループに分割するステップと、
    各グループに含まれるコード群を前記第１のソースコード内での実行順序に従って並べ、各並べられたコード群を、各々に連続して実行されるべき１つ以上のコードが含まれる１つ以上のセクションに区分するステップと、
    各区分されたコード群を記憶部に格納するステップと、
    前記第１のソースコードをもとに前記各区分されたコード群間において各セクションに対する実行順序の制約を設定するステップと、
    前記記憶部の内容をユーザに提示するステップと、
    前記実行順序の制約を表す制約情報をユーザに提示するステップと、
    ユーザからの第１の編集指令に基づき前記記憶部を編集するステップと、
    ユーザからの第２の編集指令に基づき前記制約情報を編集するステップと、
    編集された記憶部と編集された制約情報とを用いて第２のソースコードを生成するステップと、
    をコンピュータに実行させるためのプログラム。

Images