プログラミング指導における上流工程の重要性について...1．はじめに 2017...

研究論文

プログラミング指導における上流工程の重要性について

About the Importance of the Upstream Process in Programming Guidance

喜家村奨Susumu Kiyamura

要約

2020年から小学校でもプログラミング教育が実施されることが決まり，プログラミングをい

かにして指導するかが注目されている．しかし，その議論の多くは，どのようなプログラミング

言語を利用するか，どのような題材でプログラミングさせるかという内容が多いように思う．し

かし，ソフトウエア開発のより上流工程について，どう指導するかということも非常に重要な問

題であると思う．そこで本稿では，上流工程の設計手法の例として，状態遷移系を用いたシステ

ムのモデリングとその実装方法について紹介する．加えてモデリング手法で導出した状態遷移モ

デルをイベント駆動型の実行環境に実装する上での問題点とその解決方法についても述べる．

キーワード：プログラミング指導，ソフトウエア設計法，モデリング手法，イベント駆動型プロ

グラム

Abstract

It is decided that programming education will be carried out in elementary school from 2020, and how

to teach programming is gaining attention. However, most of that discussion seems to have a lot of con-

tent on what kind of programming language to use and what kind of subject matter to program. How-

ever, I think that it is a very important matter to consider the upstream process of software development.

Therefore, in this paper, as an example of the design method of the upstream process, I introduce a

model of the system using the state transition system and its implementation method. In addition, I de-

scribe problems and solutions for implementing a state transition model derived by this modeling

method in an event-driven execution environment.

Keywords : Programming guidance, Software design method, Modeling method, Event-driven program

人間科学部研究年報平成 29年

― １５ ―

1．はじめに

2017年に公示された小学校の学習指導要領に「プログラミング（的思考）」が盛り込まれ，現

在，ますます，プログラミング教育が注目されている．しかし，プログラミングを教育現場でそ

れぞれの教員がどのように指導していくかは，ソフトウエア工学の知識のない教員にとっては大

きな問題である．このような理由からプログラミング指導について，現在多くの議論がなされて

いるが，その多くは，どのようなプログラミング言語を利用するか，どのような題材でプログラ

ミングさせるかということに注力されているように思う．

本稿では，プログラムを指導するために，どのようなプログラミング環境を使い，どのような

プログラミング言語を使うかということではなく，より上流工程の設計方法について考察する．

その理由は，どのようなプログラミング言語を利用するにしても，ソフトウエア開発の上流工程

の作業は共通の技術として利用可能であり，設計ができれば，ソフトウエアの構造を決めて，そ

れが正しく動くという検証方法も身に付けることができるからである．また将来，プログラムが

仕様（設計書）から自動生成されるようになったとしても，上流工程の設計手法を身に付けてい

くことは学習者にとって有用であると思う．

ソフトウエアを数学的に正しく検証する手法のことを形式的手法といい，古くは 1960年代の

一階術語理論から始まり，チューリング賞を受賞した C. A. R. Hoare の「ホーア理論」は有名で

ある［1］．さらに 1970年代には形式仕様記述言語の「VDM」や「Z」により実際のシステムが設

計，検証される事例が生まれてきた．そして 1980年代には並列システムの記述，検証のために

プロセス代数が使用されるようになり，実際にプロセッサーの設計と正当性の検証に利用され

た．プロセス代数は状態遷移系をプロセスという概念で定義し，その振る舞いの検証をする．本

稿で示すモデリング手法もこのプロセス代数の考え方が一部取り入れられている．具体的には仕

様を状態遷移系として表現し，その仕様を満たす実装を考える（実装は仕様の詳細化となる）．

その例として本稿では，自動販売機の制御システムのモデリング例を示す．

モデリングの手順としては，まず，文章で書かれた要件定義からモデルを作成するための条件

を出力する．次にその条件を満たすモデルとして状態システムを構築する．これが実装するシス

テムの振る舞いを表すモデルとなる．最後にその状態遷移モデルからプログラムを実装する．実

装に関しては，状態遷移モデルを Scratch などのイベント駆動型システムで実装する上での問題

点とその解決方法についても述べる．

2．状態遷移系を用いたモデリング手法の概要

この章では本稿で示す状態遷移系を用いたモデリング手法の概要について説明する．


― １６ ―

2.1 本稿で扱う状態遷移モデル

状態遷移系には，ラベル付き遷移システム，オートマトンなどがあるが，本稿では以下の示す

ような状態遷移系として仕様をモデル化する．

システムとその環境との相互作用，つまりシステムが従事する動作をイベントという．それぞ

れのイベントの発生回数を記憶する変数を状態変数とし，イベント名に$をつけて表す．状態は

イベント変数の組で区別することとする．定義は以下のようになる．

状態遷移システムは（S, s0, Σ, δ, S ）の組で表す．

S ：状態の空でない有限集合（状態変数の組で表現）

s0 ：初期状態（0 , ・・・, 0）（s0∈S）

Σ ：ラベル（イベント）の有限集合

δ ：遷移の集合

S ：正常終了状態の集合

例として，図 1に a, b, c の 3つのイベントに従事する状態遷移モデルを示す．この状態遷移モ

デルはそれぞれの状態変数が$a＝0,1, $b＝0,1, $c＝0,1,2の値をとるとき，初期状態から正常終了

状態へ遷移可能な全ての遷移を実行する状態遷移モデルである．つまり状態変数の取りうる範囲

内で，最大の状態空間をもつ状態システムをあらわしている．以後，このような最大の状態空間

をもつ状態遷移モデルを DF1と呼ぶこととする．仕様を表す状態遷移モデルをこの DF1より導

出することが本稿の示すモデリング手法の考え方である．

S＝{($a, $b, $c) : $a＝{0,1}, $b＝{0,1}, $c＝{0,1,2}}

s0＝(0, 0, 0)

Σ＝{a, b, c}

δ＝{ ((0,0,0), a, (1,0,0)), ((0,0,0), b, (0,1,0)), ((0,0,0), c, (0,0,1)),

((1,0,0), b, (1,1,0)), ((1,0,0), c, (1,0,1)),

((0,1,0), a, (1,1,0)), ((0,1,0), c, (0,1,1)),

((0,0,1), a, (1,0,1)), ((0,0,1), b, (0,1,1)), ((0,0,1), c, (0,0,2)),

((1,1,0), c, (1,1,1)), ((1,0,1), b, (1,1,1)), ((1,0,1), c, (1,0,2)),

((0,1,1), a, (1,1,1)), ((0,1,1), c, (0,1,2)), ((0,0,2), a, (1,0,2)), ((0,0,2), b, (0,1,2))

((1,1,1), c, (1,1,2)), ((1,0,2), b, (1,1,2)), ((0,1,2), a, (1,1,2)) }

S ＝{(1,1,2)}


― １７ ―

2.2 モデルの構築手法の違い

ものを造形する場合，粘土工作のように粘土をくっつけてだんだんと全体を形作る方法（合成

法とよぶ）と，木工彫刻のように，丸太を削っていって形作る方法（削除法とよぶ）の 2つの方

法がある．通常，仕様を元にモデルを導出する場合，合成法を用いて，初期状態から仕様に従っ

て順番に遷移を合成してモデルを完成させるほうが人間の思考にあっており，自然なように思

う．しかし，この合成による仕様から状態遷移系を導出する方法には問題がある．例えば，今回

の自動販売機の例で，お釣りと商品が出力される順番は，どちらか先に出力されても問題ないと

考えられる．このように仕様とは矛盾しないどちらでもよいような状態を合成法で導くことは容

易ではない．そこで，今回は，文献［2］で示したように最も大きな状態空間をもつ状態遷移系から

仕様と矛盾する状態と遷移を削除する方法でモデルを導出する．

2.3 モデルリングの手順

本稿で示すモデリングの手順は以下の通りである．

（1）仕様をもとにシステムが従事するアルファベット Σ を抽出し，最大の状態空間を持つ

遷移モデル DF1を求める．

（2）仕様から不必要な状態と遷移を削除するための条件を抽出する．

（3）各削除する条件を条件式に変換する．

図 1 本稿で扱う状態遷移モデルの例（DF1）


― １８ ―

（4）DF1Σ から（3）の条件式によって，不要な状態と遷移を削除し仕様モデル SP1Σ を導出

する．

上記，モデリング手順を図 2に示す．

3．自動販売機のモデリングの例

この章では，前章で紹介したモデリング手法を用いて実際に状態遷移モデルを導出する．

3.1 設計する自動販売機の仕様

設計する自動販売機の仕様は以下の通りである．

ドリンク A の自動販売機がある．コイン（in.100 e）を投入し，購入ボタン（btn.A）を押

すと，ドリンク A がでてくる．

返却ボタン（btn.R）があり，押されるとコイン（out.100 e）が返却される．

コインは 2枚まで投入できるが 1度に 1缶しか買えず，2枚投入し，購入ボタンを押すと

ドリンク A がでて，1枚コイン（out.100 e）が返却される．

コインの種類は 100円硬貨だけであり，他の種類の硬貨は投入されないものとする．ま

た，ボタンを押した後に，コインが投入されることはないものとする．

図 2 仕様から状態遷移モデルを導出する手順の概念図


― １９ ―

3.2 イベントの定義

まず，最初に上記，仕様をもとに，自動販売機システムの従事するイベントを定義する．イベ

ントを定義する場合，特に注意しなければならないのは，どれくらいの抽象度で定義するかとい

うことである．抽象的すぎると完成したモデルを元に実装する場合，実装の正当性を保つことが

難しくなり，具体的すぎるとモデルの状態空間が増加してモデリング自体が困難になる．このよ

うなことを考慮して，今回は以下の 5つのイベントをモデリングする自動販売機システムのイベ

ントとする．

3.3 最も大きい状態遷移系 DF1の定義

続いて，モデリングする自動販売機システムの状態および，モデリングの元となる状態遷移モ

デル DF1を定義する（図 3）．

状態変数は 1回の購入が終了するまでの個々のイベントの発生回数を表すものとする．各イベン

トの取りうる値は表 1の通りなので，全ての状態数は，それぞれのイベントの取りうる値の掛け

算となる．つまり 3×2×2×2×3＝72（状態）である．初期状態は全ての状態変数が 0のときで

あり，そこからイベントが実行されるごとに状態が遷移していく．モデリングの作業はこの全て

の可能性を持つ最も大きな状態遷移モデル DF1から仕様をもとに不必要な状態および遷移を削

除することで導出できる．自動販売機の最も大きな状態遷移システムを図 3に示す．図 3におい

て各状態内の値は，それぞれに状態変数の値を（$in.100e, $btn.A, $btn.R, $drink.A, $out.100e）の

順番に並べて表している．この DF1から，要求仕様に合わない状態と遷移を削除し，仕様状態

遷移モデル SP1を導出する．

3.4 正常終了状態について

一人の自動販売機の客に対する処理（1度の購入（または返却）処理）が完了した状態は以下

のように 4つある．初期状態からこの 4つの状態へ遷移する可能なイベントの実行列を求めるこ

とでモデリングが完成する．図 4に初期状態から 4つの正常終了状態へ遷移する導出すべき状態

表 1 例とする自動販売機のイベント

イベント名用途最大発生回数（状態変数のとりうる値）

in.100 e コインが投入される 2回（0, 1, 2）

btn.A ボタン A が押される 1回（0, 1）

btn.R ボタン R が押される 1回（0, 1）

drink.A ドリンク A が出てくる 1回（0, 1）

out.100 e コインが出てくる 2回（0, 1, 2）


― ２０ ―

遷移モデルの概念図を示す．

（$in.100e, $btn.A, $btn.R, $drink.A, $out.100e）とすると

（1, 1, 0, 1, 0）：コインが 1枚投入され，ボタン A が押されてドリンクが出力された状態

（1, 0, 1, 0, 1）：コインが 1枚投入され，ボタン R が押されてコインが 1枚返却された状態

（2, 1, 0, 1, 1）：コインが 2枚投入され，ボタン A が押されてドリンクが出力されコインが

1枚返却された状態

（2, 0, 1, 0, 2）：コインが 2枚投入され，ボタン R が押されてコインが 2枚返却された状態

つまり

S ＝{(1, 1, 0, 1, 0), (1, 0, 1, 0, 1), (2, 1, 0, 1, 1), (2, 0, 1, 0, 2)}

3.5 状態の削除条件

仕様を満たさない状態と遷移を削除するための条件を以下のように定義する．

C01：コインが投入される前に他のイベントが起こることはない

C02：コインが 1枚投入された状態で，ボタン A が押されてもコインが返却されることはな

い

C03：ボタン A とボタン R が押された状態にはならない

図 3 自動販売機の最も大きい状態遷移モデル DF1


― ２１ ―

C04：ボタン A が押されてないのにドリンクが出ることはない

C05：コインの和よりドリンクの出た数と返却されたコインの総和のほうが大きくなることは

ない

C06：ボタンが押されてないのにコインが返却されることはない

C07：ボタン A が押されてコインが 2枚返却されることはない

上記，文章による状態の削除条件を式で表すと以下のようになる．

式 C01 : $in.100 e ＝ 0 ∧ 0 < ($btn.A + $btn.R + $drink.A + $out.100 e)

式 C02 : $in.100 e ＝1 ∧ $btn.A＝ 1 ∧ $out.100 e > 0

式 C03： $btn.A ＝ 1 ∧ $btn.R ＝ 1

式 C04： $btn.A ＝ 0 ∧ $drink.A ＝ 1

式 C05： $in.100 e < ($drink.A + $out.100 e）

式 C06： ($btn.A + $btn.R)＝0 ∧ $out.100 e > 0

式 C07： $btn.A＝1 ∧ $out.100 e > 1

図 5には，式 C 01により削除される状態が示されている（色のついているセルが削除すべき状

態を表している）．削除式によって，遷移先として存在しない状態は，もちろん遷移元の状態と

図 4 正常終了状態を示した状態遷移モデルの概念図


― ２２ ―

してもありえないので，遷移元の状態も削除できる．以下，その他の削除式に対応する不要な状

態を削除する．式 C 01～C 07をもとに不要な状態を削除した状態遷移表を付録 1に示す．

3.6 遷移の削除条件

図 6は付録 1で示した不要な状態を削除した状態遷移表の一部を拡大したものである．この表

のコインが 1枚入っていてボタン A も押された状態（1,0,1,0,0）からコインがもう 1枚，投入さ

れた状態（2,0,1,0,0）への遷移に着目する．まずこの 2つの状態は正常な状態であり削除すべき

状態ではない．しかし，この遷移はボタンが押された後に，さらにコインが投入されていること

を意味するので，あきらかに仕様と矛盾する．このように遷移元も遷移先も状態として正常な場

合は遷移に着目し，矛盾があればその遷移を削除する．以下，遷移の削除条件と削除式を示す．

C10：ボタンが押された後で，コインが投入されることはない．

式 C10： (($brn.A＝1) ∨ ($brn.R＝1)) ⇒ ref(in.100e)

式 C10の意味は，ボタン A またはボタン R が押されているなら，コインが投入されることはな

い．つまりボタンが押されている状態では，コインのイベントを拒否（refusal）するという意味

である．この遷移の削除条件で図 6に示した 5つの遷移を削除することができる．付録 1の状態

遷移表からさらに，ここに示した 5つの遷移を削除して完成した状態遷移表から作成した仕様を

満たす状態遷移モデル（SP1）を図 7に示す．

図 5 削除条件 C01により削除される状態と遷移


― ２３ ―

4．モデルから実装

この章では，前章で作成した状態遷移モデルから実際にプログラムを実装する．実装する環境

は Scratch を利用する．Scratch は教育向けのオブジェクト指向型のプログラミング環境で，グラ

フィックが簡単に扱え，ブロック型のビジュアルプログラミング環境で，プログラミング言語を

習得していない学習者でも比較的，平易に扱える．

図 6 ボタンが押された後にコインが投入された遷移

図 7 完成した仕様状態遷移モデル SP1Σ


― ２４ ―

4.1 状態遷移モデルのイベント駆動型実行環境への実装

ここでは，状態遷移モデルで表現した仕様モデルを Scratch などのイベント駆動型実行環境で

実装する問題点と実装の方法を説明する．

まず，実装の準備として，前章で導出した状態遷移モデルと Scratch のオブジェクトの関係に

ついて説明する．前章で導出した仕様状態遷移モデルは 1つの状態遷移系として表現されてい

る．システム全体の振る舞いは自動販売機の環境と自動販売機との相互作用として表現できるの

で，Scratch で実装する場合，自動販売機のオブジェクトに対して，その環境からメッセージを

送る形にすることが自然である．図 8にその概念図を示す．自動販売機オブジェクトは導出した

状態遷移モデル SP1に従って受理可能なイベントを受け取ると現在の状態から次の状態へと状

態を更新する．ここで 1つ注意しないといけないのは，Scratch のオブジェクトのイベントハン

ドラは並列で動作するということである．例えば 100円を投入された状態で，ボタン A とボタ

ン R をユーザが同時の押したとする．すると，その 2つのイベントのイベントハンドラは同時

並列に実行されてしまう．この問題の回避策としては文献［3］で示したように，イベントキューを

用いて複数のイベントハンドラによるイベント処理を待ち行列による逐次処理として，自動販売

機オブジェクトで処理することである．次にイベントキューにより処理する自動販売機オブジェ

図 8 状態遷移モデルとイベント駆動型実装環境の関係


― ２５ ―

クトのプログラムについて説明する．

4.2 自動販売機オブジェクトの説明

自動販売機オブジェクトのプログラムリストを図 9に示す．in.100e, btn.A, btn.R の各イベント

ハンドラは，イベントを受け取るとイベントイベントキューであるリスト vmreq に追加する．

メインループ処理では，イベントキュー vmreq を監視し，イベントキューが空でない場合，キ

ューの先頭からイベントを 1つ取り出し，そのイベントについて処理をしていく．この処理方法

によって，並列の起こりうるイベントを状態遷移モデルの仕様の通りに処理することができる．

また，コインが 2枚入っているときに，ドリンクを先に出すか，お釣りを先にだすかの非決定的

選択については，今回はドリンクを先に出すように実装した．この実装の正当性については，付

図 9 Scratch の実行画面と自動販売機オブジェクトのプログラム


― ２６ ―

録 2で説明しているので，興味がある読書はそちらを参考にしていただきたい．

5．今後の課題

この章では本稿で示した状態遷移モデルによる設計手法についての今後の課題についていくつ

か説明する．

5.1 トレース導入の必要性について

ある状態における遷移がその状態に到達するまでのイベントの実行順序（トレース）によって

異なる場合，今回示した状態を削除するという方法では，モデルを定められない．例えば図 9の

ように状態（1,1,0,0）における次の遷移が，それまでのトレースが＜a,b＞ならイベント c を許

可し，＜b,a＞なら許可するような条件である場合は，それまでのトレースを観測している必要

がある．これについては，状態変数をそのイベントの発生回数だけを保存するのではなく，それ

までのトレースを記憶するように拡張することによって解決できると考える．

5.2 仕様状態遷移モデルの半自動生成について

今回は，DF1から仕様状態遷移モデル SP1を導出する時，状態遷移表から，手作業で状態の

削除を行った．しかし，この処理は Excel などの VBA プログラムを利用すれば比較的容易に，

削除条件により状態遷移表から不必要な状態を削除することが可能である．また視覚的に状態遷

移系をみせるようなプログラムも実現可能であろう．そのようなツールを作成することにより，

図 10 トレースを考慮しないといけない例


― ２７ ―

学習者は削除条件を考えることに集中でき有効であると思われる．

6．おわりに

本稿では，プログラミング指導のために，ソフトウエア開発の上流工程である仕様から状態遷

移モデルを導出する方法について自動販売機を例に説明した．また，そのモデルから Scratch の

ようなイベント駆動型の実行環境への実装するときの問題点とその解決方法についても説明し

た．これらの例がこれからプログラミング指導に携わる教員やプログラミングを学習しようとす

る学習者にとってよいヒントになることを期待する．さらに，今後，ソフトウエア開発の上流工

程がプログラミング指導の重要な事柄として議論されることを期待する．

謝辞

本稿の作成にあたり，本学人間科学部情報メディア学科の高橋参吉教授が，的確なアドバイ

スと今後の研究に対する助言を与えてくださったことに感謝します．また，研究のための時間と

環境を与えてくださっている帝塚山学院大学人間科学部に感謝します．そして，いつも元気を

与えてくれる妻と子に感謝します．

参考文献［1］形式手法教科書赤間世紀著，株式会社工学社，2012［2］「CSP 理論における遷移と拒否集合の削除による形式仕様の導出」帝塚山学院大学人間科学部研究年

報第 15号（P.1-13），2013［3］「並列処理プログラミング教育における Scratch の可能性についての考察」帝塚山学院大学人間科学部

研究年報第 18号（P.33-49），2016［4］ソフトウエア科学基礎田中譲，他著近代科学社，2008［5］並行システムの検証と実装磯部祥尚著，近代科学社，2012［6］ホーア CSP モデルの理論，吉田信博訳，丸善株式会社，1992［7］The Theory and Practice of Concurrency, A. W. Roscoe, Prentice Hall, 1997


― ２８ ―

付録 1 削除条件 C01～C07により不必要な状態と遷移を削除した状態遷移表


― ２９ ―

付録 2 仕様プロセスにおける非決定性と実装プロセスの関係について

仕様を状態遷移モデルとして表現し，そのモデルを満たすように実装モデルを作成し，プログ

ラミングするという手法は古くから行われており，特にプロセス代数の分野では，この方法で，

設計，検証を行う．プロセス代数の一つ，CSP 理論では，まず，仕様を全てのイベント非決定

的に実行するプロセス（DF）といて表現し，そのプロセスを仕様を満たすのように状態，遷移，

非決定性を削除していき，実装モデルを導出する．これを Setwise Refiment という．以下の DF

と詳細化の式を示しておく．

DFΣ ＝ �{a→DFΣ｜a∈Σ}DFΣ �SPΣ �IMPΣ

本来，上記のように，最も大きな状態空間を持ち，最も非決定的なプロセス DF から状態と遷

移と非決定性を削除していき実装プロセスを導出するが，本稿では，非決定的な選択について

は，議論しなかった．本来なら，本稿で示した DF1は非決定性を含むべきであり，DF1から状

態と遷移を削除するだけでなく，非決定性を削除する必要がある．このことについて，理解を深

めたい読書は文献［1］を参考にしていただければと思う．

また，CSP 理論では非決定性に対して以下のような詳細化ルールが成り立つ．これは，非決

定的なプロセスの詳細は

((a→SKIP)�(b→SKIP))�(b→SKIP)が成り立つことを意味する．

つまりプロセス P とプロセス Q が非決定的に選択実行されるとき，P と Q どちらのプロセス

をその詳細化として実装してもよいということを意味する．詳しくは CSP の教科書として評価

の高い文献［5］～［7］を参考にしていただきたい．


― ３０ ―

プログラミング指導における上流工程の重要性について...1．はじめに 2017...

Documents