pblに基づくオブジェクト指向...

1

芝浦工業大学工学部情報工学科古宮誠一

ＰＢＬに基づくオブジェクト指向

ソフトウェア開発技術の演習授業

PBL教育への取り組み事例4

2011年9月24日(土)

2

目次1. はじめに

2. PBLの学習対象

3. PBLを成功させるための様々な工夫

4. ソフトウェア開発演習のための支援環境EtUDE

・ EtUDEの機能概要とEtUDEを構築するための基本方針

5. メンバの役割を考慮したチーム編成適化ツール： EtUDE/GO

(1) GAによるこの問題のモデル化

(2) メンバーの役割遂行能力とチームの能力の評価方法

6. グループ演習に埋没する個人指導が必要な受講者の自動検出

・OOSEによるモデリング作業における指導のポイント

7. 個人ごとに異なる課題達成への貢献度の差異を反映させた採点法

8. おわりに

・参考文献

3

1. はじめに

(1) PBLとは

・Problem Based Learning学習者自身が中心となり、反省的反復の作業をともないながら、実践される少人数グループの教育手法ことを、「問題にもとづく学習」とよぶ。PBLとは, Problem Based Learningのアクロニム（頭文字による略記法）である。医学・歯学・看護学・環境科学・法律実践・工学などのように実践の場での問題解決などが職業的スキルとして重要視される教育課程でしばしば採用される。

・Project Based Learningややこしいことに、具体的な学習課題を立てて少人数グループでプロジェクトを完遂させる「プロジェクトにもとづく学習」もまたPBL、すなわち Project-Based Learning と呼ばれて、しばしば混乱することがある。「プロジェクトにもとづく学習」は、これまで実習や演習と呼ばれてきた学習課題のより発展形態だと考えればよく、ほとんどあらゆる学問分野の教育課程で採用することが可能である。

ここでは，PBLという言葉を後者の意味で使用する。

4

受講の対象者：情報工学科の学生

受講の時期： 3年生の後期授業(選択科目)

学習対象：オブジェクト指向の概念に基づきソフトウェアを開発するソフトウェア開発の全工程を演習の対象としている5名程度をプロジェクトチームに見立てて演習を実施

使用するソフトウェア設計法： OOSE法

前提となる授業：

1年生：プログラミング入門1(前期)，プログラミング入門2(後期)

2年生：基礎情報演習1A，｛基礎情報演習2A，基礎情報演習2B｝

3年生：ソフトウェア工学，｛高度情報演習1A，高度情報演習1B｝，{高度情報演習2A，高度情報演習2B，高度情報演習2C｝

2．ＰＢＬ教育の学習対象

5

3. PBLを成功させるための様々な工夫

(1) UMLの説明： 3年生前期の授業「ソフトウェア工学」の毎週後ろ30分を割いて実施

(2)ソフトウェア設計法OOSEやテストやデバグの方法のなどの説明：

2コマ続きの演習時間の1コマ目を使って，必要な技術の説明をした。

(3)演習時間の不足を補うために：

演習課題の達成に必要なすべての作業が，時間と場所の制約を受けずに実施できる

ようなツールEtUDEを開発して，授業時間外でも演習ができるようにした。

(4)期限までに課題を達成できないチームがでないようにするために：

ソフトウェア開発に必要な各スキルをそれぞれ持つ学生が，各チームにそれぞれ1人以上存在し，かつ，チーム間での総合力の差が小になるように，学生を割り当てた。また，このような割り当てを可能にするツールを開発した。

(5)チームごとに研究室の学生を割り当て，受講生の相談に乗るようにさせた。

(6)個人ごとに異なる課題達成への貢献度の差異を反映させた採点法の採用：

チーム単位で行う演習において，個人ごとに異なる課題達成への貢献度の差異を反映させた個人成績の採点を可能にするための方法を提案して，成績評価に利用した。

6

4．ソフトウェア開発演習のための支援環境EtUDE(1)演習課題の達成に必要なすべての作業が，時間と場所の制約を受けずに

実施できるようなツールをWebアプリケーションシステムとして開発した。

(2)プロジェクトのメンバーが協力してソフトウェアを開発する演習なので，そのような演習に合うように，このツールは次のような機能を持つ。

① 作成した中間成果物の版管理を容易にするとともに，仲間が作成した中間成果物を互いに自由に閲覧できるようにする機能:(成果物管理機能，ソースコード管理機能)

② 仲間同士でのコミュニケーションを支援する機能：(報告書作成支援機能，掲示板機能，メール通知機能)

③ 活動ログの自動取得機能

(3)ツールを改変しながら永続的に改良して行けるようにするための実装の基本方針

①再利用し易い，②メンテナンスがし易い，③複数人での開発に適している，④テストがし易い，⑤ログが取得し易いまた，これらの基本方針を実現するために，次のような実装方法を導入した。(a) POJO (Plain Old Java Objects)による(軽量な)実装(b) インタフェース(ポルモリフィズム)を活用した実装(c) AOPの導入による横断的関心事の分離(d) デザインパターンの活用

7

(1)POJO (Plain Old Java Objects)による(軽量な)実装

POJOという言葉は，JavaEEに見られるような特定のクラスの継承を必要とするような重量級のクラスとの比較語であり，APの実現において，特定のインタフェースの実装やクラスの継承を強制されないクラスの総称である。EtUDEではすべてのコンポーネントがPOJOで構成されている。 POJOによる実装の利点は，コンポーネント間の依存度を低くすることができることである。このため，新たなアーキテクチャに対してもシステムを容易に適応させることができるという利点がある。

(2)インタフェース(ポルモリフィズム)を活用した実装

R.C.Martinは，インタフェースを用いたポルモリフィズムの重要性を指摘している。インタフェースを活用して実装すれば，依存性を外部から操作することが可能となるので，モックを使ったテストなどが容易に実現できるようになる。

(3) AOPの導入による横断的関心事の分離

AOP (Aspect Oriented Programming)を採用すれば，どのモジュールにも横断的に存在する共通機能を他のモジュールから分離することができる。これによりモジュールの強度(凝縮度)を高くすることができる。

ソフトウェア開発演習支援環境EtUDEの実装方法

8

ユーザ情報の登録

登録

適正であることをチェック

ログの出力

エラー処理

書籍の検索


検索

ログの出力

エラー処理

本質的関心事(Core Concern)

横断的関心事(Crosscutting

Concerns)

オブジェクト指向言語のみによる実現

Weaving(編み合わせ)

アスペクト指向言語による実現

オブジェクト指向言語による実現

図1 アスペクト指向プログラミングの原理

検索

登録

ログの出力

エラー処理


9

(4)デザインパターンの活用

デザインパターンとは，Gammaらがオブジェクト指向プログラム設計時に起こる典型的な問題と，それに対する解決策を整理してまとめたものである。

デザインパターンを用いれば，同じ問題に対する解法を初から検討することを何度も繰り返さなくても済むようになるので，工期の短縮などの効果をもたらす。また，設計について多くの人と共通の理解が得られるので円滑に作業が進む。

EtUDEでは，デザインパターンのほかに，AlurらのJ2EEパターンやFowlerのPatterns of Enterprise Application Architectureを用いて設計を行っている。

これらの中でも重要なのはDI (Dependency Injection)パターンである。このパターンを用いれば，設定ファイルなどを使ってオブジェクト間の依存性を自由に設定できる機構を実現できる。

DIパターンを用いることのメリットは次の通りである。①並行開発が促進されることによる開発期間の短縮②コンポーネントごとにユニットテストが完結することによる品質の向上③コンポーネント間の依存性が無くなることによる保守性の向上④コンポーネントが特定の環境に依存しなくなることによる過般性の向上

10

図2 ソフトウェア開発演習のための支援環境EtUDEのシステムアーキテクチャ

11

ソフトウェア名種別Java2 Platform Standard Edition ｖ１．5．0_08 開発・実行環境

MySQL 4.1.21 RDBMSMySQL Connector/J3.0 JDBCドライバー

Tomcat 5.0.25 Servletコンテナ

Struts 1.2.4 Webアプリケーション・フレームワーク

Hibernate 2.1.6 ORM (Object-Relation Mapping)Seasar 2.2.10 DI (Dependency Injection)コンテナ

CVS (Concurrent Versions System) 版管理システム

Velocity 汎用テンプレートエンジン

ozacc-mail library メール送信ライブラリ

JUnit 3.8.1 単体テストドライバー

Ant 1.6.5 ビルドツール

Eclipse 3.1.1 統合開発環境

(参考) 表1 EtUDEの開発に利用したソフトウェアプロダクト

12

5. メンバの役割を考慮したチーム編成適化ツールEtUDE/GO(1)開発の背景

当初は，プロジェクトメンバーの決定を学生達の自由に委せていたので，課題を達成出来ずに演習を終えるチームが少なくなかった。このため，課題達成に必要な能力を有すると考えられる学生が，必要な能力ごとに低一人はそのチームに存在し，かつ，

チーム間での能力差が小となるようなチーム編成にしたい。

(2)支援ツールに求められる条件①課題の達成に必要な役割を遂行可能な適性を持った受講者を，各チームに少なくとも一人以上割り当てる。

②教育的見知から，どの役割も遂行できそうもない人も参加できるようにする。③チーム間の能力差をできるだけ小さくする。④チーム間の人数差を1以下とする。

(3)上記(2)の条件を満足するツールを開発するために①遺伝的アルゴリズム(GA: Genetic Algorithm)を用いて開発する。②プロジェクト遂行のための(役割・適性・代用特性)の関係は次表(表2)の通り。

役割適性代用特性の例

リーダＰＭとしての能力ＰＭに関する問題の成績

分析・設計の担当分析・設計の能力ソフトウェア設計に関する問題の成績

コーディングの担当プログラミング能力プログラミングに関する問題の成績

品質保証の担当品質管理の能力ソフトウェアテストに関する問題の成績

13

GAによるこの問題のモデル化

図3 GAにおける遺伝子のコーディング

14

メンバーの役割遂行能力とチームの能力の評価方法

図4 メンバーの役割遂行能力とチームの能力の評価方法の説明図

15

Objectory (Ivar Jacobson et al, 1988-1995) OOSE (Ivar Jacobson et al, 1992)

Objectory (Object Factory for Software Development) という設計法は， 1978年頃からスウェーデンのエリクソン社で開発が始り， Jacobsonが1987年にエリクソン社を離れObjectory AB社を設立して，同社が1995年の秋にRational Software社に吸収されるまでの8年間に亘って継続的に開発が進められた。

その間の1988年にObjectory 1.0がリリースされ，1995年に初のオンラインバージョンであるObjectory 3.8がリリースされた。

OOSE (Object Oriented Software Engineering) は，Objectoryの基本概念と，その単純化した版を示したものである。

6. グループ演習に埋没する個人指導が必要な学習者の自動検出

16図 OOSEの設計プロセス

分析要求モデル

分析モデル

実装モデル

(実装)

テストモデル

(テスト)

構築

設計モデル(設計) インタラク

ション図状態遷移グラフ

OOSEの設計プロセスとその特徴

特徴：１．仕様変更の際のソフトウェア修正箇所の局所化に重点を置いたモデリング

２．追跡可能性に重点を置いたモデル変換とそのプロセス

17

図5 実装作業が困難なクラス図から実装作業が容易なクラス図への変換の例

OOSEによるモデリング作業における指導のポイント

18図7 多重度の設定誤りの例図8 誘導可能性の設定誤りの例

グループ演習に埋没する個人指導が必要な学習者の自動検出の対象

図6 実装が困難なクラス設計の例

EtUDEは実装が困難なクラス設計，多重度や誘導可能性の設定誤りを自動検出することにより，グル－プ演習に埋没する個人指導が必要な学生を自動検出する機能を持っている。

19

7. 個人ごとに異なる課題達成への貢献度の差異を反映させた採点法

1. 採点方法ある課題に対してプロジェクトチームを組んで取り組む各学生の成績は，

成果物そのものに対する評価（チームに所属するメンバー共通の持ち点）と，課題達成に向けた各個人の貢献度（個人毎に異なる）のとの和であるとし，

それらを評価するための評価項目と，その評価を容易にするための意思決定

支援システムとで構成されている。

2. 意思決定支援システム

意思決定支援システムからとして，良く利用されているAHP (Analytic Hierarchy Procedure)と,ケプナー・トリゴー法(Kepner-Tregoe Program）を利用する。前者は利用者の主観的判断に基づき意思決定する過程を支援する手法であり，後者は利用者の客観的判断に基づき意思決定する過程を支援する手法である。

参考文献：＜AHPに関するもの＞(1) Saaty, Y. L., “The Analytic Hierarchy Process,” MacGraw-Hill, 1996.＜ケプナー・トリゴー法に関するもの＞(2) C.H. Kepner, B.B. Tregoe, “The New Rational Manager, Princeton Research

Press, 1981. (産業大学出版部刊行の邦訳あり)

20

成績評価方法に求められる条件

１・チーム共通の成果物（P）に対する評価・個人の課題達成への貢献度（C）

の両方を評価して成績に反映させることが望ましい．

２評価は，より客観的であることが望ましい．

３評価項目ごとに重要度が設定できることが望ましい．

４採点作業に対する担当教員の負担が軽減されることが望ましい．

５複数のTAの意見を成績評価に反映できることが望ましい．

６評価する人(TA)が変わることによって，評点が変わること

が少ないような採点方式であることが望ましい．

Copyright © 2008-2010 EtUDE Project. Reina Hara.

成績評価方法に求められる条件として，以下の6つを選んだ．

意思決定法を用いる

21

■ 意思決定法

有力な方法として

21

・AHP法は，一対比較（評価項目相互の重要度を，総当たりで比較する）という方法を用いて各評価項目の重みを決定する．・KT-DAは，評点を求めるときの視点を与え，その視点に立ったときの各評価項目の達成度によって評点を与える仕組みになっている．

・AHP法を使って，各評価項目の重みを決定する．・KT-DAを使って，各評価項目の評点を決定する．

個人で評価する方法であること．

本研究では，評価者が複数の場合でも評価できるようにしたい

用途

両者に共通なこと

Copyright © 2009 EtUDE Project. Reina Hara.

「KT-DA」と「AHP法」の特徴

KT法の決定分析（KT-DA）

AHP法とがある．

22

AHP法(Analytic Hierarchical )「問題」「評価項目」「代替案」の階層構造として捉え，階層ごとに一対比較を行った上で代替案の中からどれが好ましいかを決定

する手法である

本研究では，KT-DAにおける評価項目の重みを決定する為に用いる

KT法目的の違いによって「問題分析」「決定分析」「潜在的問題分析」「状況分析」の4つの分析方法が用意されている

目的達成のために複数の選択肢の中から適なものを選出する問題なので「決定分析（DA）」を用いる

手順①目的の明確化②目標の設定③目標の分類（MUST／WANT）④評価項目への重み付け（重要度の

設定）と評点（スコア付け）⑤重みと評点の積和計算

AHP法とKT法

23

成績評価方法に求められる条件

１・チーム共通の成果物（P）に対する評価・個人の課題達成への貢献度（C）

の両方を評価して成績に反映させることが望ましい．

２評価は，より客観的であることが望ましい．

３評価項目ごとに重要度が設定できることが望ましい．

４採点作業に対する担当教員の負担が軽減されることが望ましい．

５複数のTAの意見を成績評価に反映できることが望ましい．

６評価する人(TA)が変わることによって，評点が変わること

が少ないような採点方式であることが望ましい．

Copyright © 2008-2010 EtUDE Project. Reina Hara.

成績評価方法に求められる条件として，以下の6つを選んだ．

KT法を用いる

AHP法を用いる

評点の種類を4段階にすること

より，評点の「ゆらぎ」を防ぐ．

24

事例による評価方法の提案


本学“高度情報演習2B”を例とし，1班の学生Aさんの成績

を評価する方法を以降より示していく．

TAらの投票によって MUST／WANT条件に項目を分類する

候補の評価項目を列挙

START

P：C の比率決定

PとCの評価項目の選出と各々の重みを決定【AHP法】

PとCの評価スコアを決定【KT法】

各学生の成績評価決定

END

25

■ 評価項目の決定


チーム共通の成果物に対する評価項目[P-1] 要求仕様の完備性

[P-2] 設計ドキュメントの完成度・詳細化具

合[P-3] レビュー会での活躍度合い

[P-4] コーディングの完成度[P-5] 全工程での修正の回数・改良した度

合い[P-6] テスト項目の完備性

学生個人の，チームに対する貢献の評価項目

[C-1] 授業の出席率・参加率[C-2] 各ドキュメント作成の分量・出来

[C-3] テスト項目の列挙数・適切さ[C-4] コーディングの割合・出来[C-5] コミュニケーションの良さ

・投票したTA全員が重要と考えた項目はKT-DAのMUST条件1人でも重要だと言わなかったものはWANT条件に分類する．

・WANT条件に分類された項目を対象に，一対比較により重みを決定する．

MWWWW

WW

W

WWW

WM

学習者やTAらに直接意見を聞いたところ，200項目ほど挙げられた．TAらによる投票により，その中から以下の項目を選んだ．

26

C-2 C-3 C-4 C-5C-2C-3C-4

C-2 C-3 C-4 C-5C-2C-3C-4C

■ 評価項目への重み付け(AHP法を用いる)


AHP法の階層図を描くと以下2つのようになる．

Pについても同様の手順で一対比較を行っていく．

C-2 C-3 C-4 C-5C-2 1 5 2 3C-3 1/5 1 1/4 1/3C-4 1/2 4 1 2C-5 1/3 1/3 1/2 1

“P”を求めるための評価基準の選定

P-1

1班

P-2 P-3 P-4 P-6

2班 … n班

P-5 C-2 C-4

学生B 学生C 学生D

“C”を求めるための評価基準の選定

学生A

C-1 C-3 C-5

チーム共通の成果物に対する評価項目[P-1] 要求仕様の完備性

[P-2] 設計ドキュメントの完成度・詳細化

具合[P-3] レビュー会でのチームで生成した成

果物[P-4] コーディングの完成度[P-5] 全工程での修正の回数・改良した

度合い[P-6] テスト項目の完備性

個人の，成果物貢献の評価項目[C-1] 授業の出席率・参加率[C-2] 各ドキュメント作成の分量・出来

[C-3] テスト項目の列挙数・適切さ[C-4] コーディングの割合・出来[C-5] コミュニケーションの良さ

「TA1」が評価項目を，重みの尺度で一対比較した結果…

重みの尺度定義内容

1 同じくらい重要

3 やや重要

5 かなり重要

7 非常に重要

9 極めて重要

（※中間値2,4,6,8も利用する）

WW

W

WWW

MWWWW

[C-2]は[C-5]よりも，

「やや重要」なので，“3”と記入する

複数のTAが一対比較を行う

27Copyright © 2009 EtUDE Project. Reina Hara.

0.492 0.484 0.533 0.4740.098 0.097 0.067 0.0530.246 0.387 0.267 0.3160.164 0.032 0.133 0.158

0.4960.0790.3040.122

元のマトリクスの各要素を各列の合計で割る

①④②③

C-2 C-3 C-4 C-5C-2 1 5 2 3C-3 1/5 1 1/4 1/3C-4 1/2 4 1 2C-5 1/3 1/3 1/2 1

TAらが一対比較したものを基に，重みを決定していく

小数点以下第3位までのマトリクスで表現し，列の合計を求める

各列の合計 [2.033 10.333 3.750 6.333]

1.000 5.000 2.000 3.0000.200 1.000 0.250 0.3330.500 4.000 1.000 2.0000.333 0.333 0.500 1.000

[C-2][C-3][C-4][C-5]

各行の合計1.9830.3151.2160.487

順位整数

各行の合計の平均が重みベクトル

実際使う重み

7143

※今回は「TA1」（1人）のみの数値を例に用いる

28

TAの人数

「TA1」が[P-5]の項目に対して付けた重み

複数のTAが一対比較した重みを1つにまとめる方法

ex) 「TA1」「TA2」「TA3」の3人が付けた[P-5]の重みを1つにまとめる場合


幾何平均（べき乗根）をとる

29

■ P，C それぞれの評価項目に対する評点の決定ex）「TA１」が「１班のAさん」の成績を評価する場合

値評価内容3 良い

2 どちらかというと良い

1 どちらかというと悪い

0 悪い

Pの評価 1班 m班

評価項目TA1の重み(W)

TA1の評点スコア(S) W×S TA1の評点

スコア(S) W×S

[P-5] 8 3 24 * *[P-1] 7 3 21 * *[P-3] 6 3 18 * *[P-2] 5 2 10 * *[P-4] 5 2 10 * *[P-6] 3 2 6 * *

合計 89 *

Cの評価 Aさん Nさん

[C-1] MUST 満足／否満足満足

評価項目TA1の重み(W)

TA1の評点スコア(S) W×S TA1の評点

スコア(S) W×S[C-1] 10 3 30 * *[C-2] 7 3 21 * *[C-4] 4 2 8 * *[C-5] 2 3 6 * *[C-3] 1 3 3 * *

合計 68 *

値評価内容

3 貢献した

2 どちらかというと貢献した

1 どちらかというと貢献していない

0 貢献できていない

87.31／100 点

94.44/ 100 点

MAX 102

MAX 72

30

TAの人数

「TA1」が[P-5]の項目に対して「X班のYさん」に付けた評点スコア（S）

複数のTAでの評点スコア（S）付けを１つにまとめる方法

ex) [P-5]の項目に対して「TA1」「TA2」「TA3」が「X班のYさん」に付けた評点スコア(S)を1つにまとめる場合


算術平均をとる

31

となり，P：C=9：1 と設定した場合，

P= ， C= となり， P+C=1班Aさんの高度情報演習2Bの成績は，

／100点と決定する．

31

「TA1」が付けた，１班のAさんに対する成績評価は，


■成績評価の決定

・１班の成績評価（P）が 87.31／100点・ Aさん個人のチームに対する貢献度（C）が 94.44／100点

32

候補の評価項目を列挙

TAらの投票によってMUST／WANT条件に項目を分類する

START

P：C の比率決定

PとCの評価項目の選出と各々の重みを決定【AHP法】

PとCの評価スコアを決定【KT法】

各学生の成績評価決定

例1) P：C = 6：4に設定したとき．例2) P：C = 9：1に設定したとき．

例1と例2に，仮に「Pが80／100点，Cが20／100点であった学生i」の終成績を求め，比較すると

例1) での学生i の成績評価点

例2) での学生i の成績評価点

このように例1と例2の場合，56点，74点と差が表れ，落第か否か大きく変動するため，P：C = 9：1を目安に設定することが望ましいと言える．

Copyright © 2009 EtUDE Project. Reina Hara. 32

END

本学での成績評定基準

成績評価の合計値

評価レベル

合否

100～80点 A 合格79～70点 B 合格69～60点 C 合格59～0点 D 不合格履修放棄 K 不合格

33

9. 終わりにPBLによる演習授業を成功させることは容易ではない。2004年度からPBLによる演習授業を開始して以来，試行錯誤の繰り返しであった。PBLを成功させるための様々な工夫が必要である。(1)学生には先ず問題の解くのに必要な知識・技法を示し，それを真似る形で

演習させなければ，学生は着いて来れない。(2)演習時間の不足を補うための措置が必要であり，そのためには時間と場所の

制約を受けずに演習できる環境が必要である。例えばTtUDEのように。(3) 演習においては，複数のTeaching Assistant (TA)が必要である。 TAには

演習授業の受講経験者を割り当てるのがよい。(4）所属したグループによって，充実した演習が受けられるか否かが決定するの

で，受講者のグループ編成も重要である。そのためにEtUDE/GOを開発した。（5）グループ演習に埋没する個人指導が必要な受講者へのケアーも大切である。そのために，個人指導が必要な受講者を自動検出するツールを開発した。

(6) グループ演習では，一所懸命頑張った学生が報われるような配慮がひつようである。そのためには個人ごとに異なる課題達成への貢献度の差異を反映させた採点法が重要である。

(7) PBLにおいて，演習課題として提示してきた課題は次のとおりである。2004～2006 会議室予約システム2006～2008 書籍販売システム2009～2010 ニュース編集管理

34

[参考文献][1] 橋浦弘明, 桑原徹，秋玉梅，石川達也，山下公太郎，古宮誠一，”ソフトウェア開発グル－プ演習のためのチーム編成の適化支援，”メディア教育研究，Vol.3, No.2, pp.61-69, 2007.[2] H. Hashiura, K. Yamashita, T. Ishikawa, Y. Isozaki, R. Chiba, Y. Inoue,S. Komiya, “A System for Supporting Project-Based Exercise in Software Development with Facilities to Detect Students AutomaticallyWho Are Required Individual Tutoring,” WSEAS Transactions, Issue 4,Vol.5, pp.187-199, April 2008.[3] Yuichi Inoue, Hiroaki Hashiura and Seiichi Komiya, "A Method for Detectingand Avoiding Many-to-Many Relationship in Class Design of Software Object-Oriented Development,“ Communications of SIWN Journal, Vol. 6, pp. 158-165, April 2009.[4]原令奈，八重樫理人，橋浦弘明，古宮誠一,"PBL参加者の成績の評価方法－課題達成への貢献度を反映した，参加者ごとに異なる成績を導く方法の提案－,"CE-103, March 6-7, 2010.

pblに基づくオブジェクト指向...

Documents