シラバスに込められた思い〜オブジェクト指向プログラミング演習(2013)

オブジェクト指向プログラミング演習(OOP演習)は学部3年次第2学期の科目です。私がインストラクショナル・デザインに基づいて新規開発した授業としては2作目にあたります。

近代的なソフトウェア開発を実践的に学ぶというコンセプトで始めました。ただ単に開発環境の使い方で終始するのではなく，ソフトウェア工学上重要な概念を強調することで，陳腐化しない知識も身につけられるように設計しました。強調しているポイントは，たとえばテスト駆動開発，Model-View-Controller アーキテクチャ，状態機械モデリングといった概念です。

2011年度までは開発環境と言語は Eclipse + Java でしたが，2012年度からは Xcode + Objective-C に変更しました。Objective-C は Smalltalk 由来の文法のため，メジャーな C++ や Java に見慣れた身からすると違和感を覚えるものですが，Xcode による支援もよくできていることもあって，慣れればスラスラと読み書きできるものです。

開発環境の変更にともなって授業内容についても2012年度に大幅なリニューアルをしました。2013年度は基本路線を踏襲しつつ教育内容を充実していく方向での改善を考えています。

もし，ご意見・ご感想などあれば，ぜひ右下の MessageLeaf にお寄せください。授業改善に役立てたいと思っています。

関連する教育実践研究の発表・論文


スパイラルカリキュラムという教育手法を取り入れています。詳細は下記を参照ください。まだまだスパイラルカリキュラムとしては未完成だと認識しています。

ランチョンセミナー
スパイラルカリキュラムによるソフトウェア工学教育
http://cvs.ield.kumamoto-u.ac.jp/wpk/?p=908

スパイラルカリキュラムによる
ソフトウェア工学 e-learning 教材の開発
http://cvs.ield.kumamoto-u.ac.jp/wpk/?p=1176

組込みシステム研究発表会
【中間報告】スパイラルカリキュラムによるソフトウェア工学教育
http://ci.nii.ac.jp/naid/110007993246

授業の概要(ねらい，テーマなど)

みなさんが「アプリ」という言葉を耳にした時に，たとえば Office， ウェブブラウザなどを連想するかもしれません。携帯のiアプリや， iPhone や Android などのスマートフォンで動作するアプリをイメージした人もいるかもしれません。このようなアプリを GUI アプリケーションと言います。

これからみなさんはオブジェクト指向プログラミング (Object-Oriented Programming: OOP) について演習を通じて学習します。OOPとはどのようなものなのか，全容を理解することはなかなか難しいのですが，「GUIアプリケーションを作るためには，OOPを習得することが必須だ！」といえば，みなさんは少なくともOOPの必要性について充分理解できるでしょう。実際，みなさんが本演習をすべて終えると，簡単なGUIアプリケーションが作れるようになれます。

実践的なソフトウェア開発ができる人材は，産業界からも強く求められています。単にプログラミングができるだけでは不十分です。ソフトウェア工学 (Software Engineering) の体系的な知見を実践に生かせる人材が求められています。また，最近は開発ツールの進歩も著しく，それらにある程度馴染んでおくことも，即戦力としては求められています。

このような要請を踏まえ，OOP演習では，最近の開発ツールを駆使したソフトウェア開発の全体像を体験すること，要所要所でソフトウェア工学との関連について触れることを重視しました。とくに品質の高いソフトウェアを開発するために必要な品質保証技術を重視するため，品質保証を重視した開発方法の一つであるテスト駆動開発 (Test-Driven Development: TDD) を取り入れることにしました。

次のような人はOOP演習を学習することを強く推奨します。

1. 将来，ソフトウェア開発の仕事に携わりたい人
2. 大学院に進学してソフトウェア工学を学びたい人


到達目標

1. GUIアプリケーションをオブジェクト指向，Model-View-Controller，テスト駆動開発に基づいて開発できる。
2. UMLのクラス図，アクティビティ図，状態機械図を Objective-C，Java, C++で実装できる。
3. 他の学習者が開発した成果物(UML図，プログラムコード)に対してレビューやテストを行い，問題点を指摘できる。
4. OOP演習に必要な概念(オブジェクト，クラス，継承，カプセル化，ポリモーフィズム，Model-View-Controller アーキテクチャ，テスト駆動開発，状態機械モデリング，パターン，リファクタリング) を，プログラムなどの実例を元に説明できる。

教科書

講義資料を Moodle で配布します。

参考書

E.ガンマ他著「デザインパターン」ソフトバンククリエイティブ

M.ファウラー著「リファクタリング 」ピアソンエデュケーション

授業計画・内容

2013年度も授業改善のため授業計画・内容を大きく変更する予定です。第1回のガイダンスでのアナウンスに注意してください。なお，下記の箇条書きの番号は必ずしも授業の回と対応していません。実際には学生の進捗に合わせて調整しています。

1. ガイダンス
2. はじめてのGUIアプリ開発〜Model-View-Controller アーキテクチャと状態機械モデル
3. UMLモデルとプログラミング
4. リファクタリング〜入門
5. リファクタリング〜モデルとコントローラーの分離
6. ソフトウェアテスト〜同値クラス
7. ソフトウェアテスト〜モック
8. ソフトウェアテスト〜状態機械モデルのテスト
9. テスト駆動開発
10. 状態機械モデリング〜電卓
11. リファクタリング〜電卓
12. ソフトウェアテスト〜電卓
13. 電卓開発実践
14. 電卓開発仕上げ
15. 振り返り

成績評価の方法

到達目標ごとの成績評価

到達目標1: 演習課題: 70%

到達目標2: 演習課題: 10%

到達目標3: 演習課題: 10%

到達目標4: レポート:   10%

授業に対する準備事項

• UMLのうちとくにクラス図，状態機械図，コミュニケーション図を読み書きできる必要があります。3年次第1学期のソフトウェア設計論をよく復習しておいてください。
• UML のクラス図と状態機械図を基にオブジェクト指向プログラミング言語で実装できる必要があります。3年次第1学期のソフトウェア設計論をよく復習しておいてください。
• C言語で関数内部を実装できる必要があります。1年次第1学期の計算機演習IのC言語プログラミングをよく復習しておいてください。
• 上記の準備事項で挙げた能力の習得が不十分である場合には補習をします。授業開始前に担当教員に相談してください。

履修上の注意

3年次第1学期のソフトウェア設計論を必ず履修しておいてください。オブジェクト指向プログラミング演習では，ソフトウェア設計論の内容を理解していることを前提とします。教務システムの都合上，ソフトウェア設計論を履修していなくてもオブジェクト指向プログラミング演習を履修できますが，その場合はソフトウェア設計論の内容を補習してもらいます。

キーワード

オブジェクト指向プログラミング，ソフトウェア開発，ソフトウェア工学，ソフトウェア・モデリング，テスト駆動開発，リファクタリング， UML

object-oriented programming, software development, software engineering, software modeling, test-drived development, refactoring, UML

OOP演習の成果を熊本で発表します！

12月6日(月)に熊本大学で開かれる組込みシステム研究会で，当ブログでも連載しているOOP演習の成果を発表します．

http://www.ipsj.or.jp/09sig/kaikoku/2010/EMB19.html

意外かもしれませんが，今回が私にとって組込みシステム研究会初の発表です．しかもなぜか教育という，研究会の本流から外れたテーマです．
そういうわけで，事前に教育に関心が高い人を集めないと議論が盛り上がらない恐れがあります．それではせっかく発表してもつまらないので，ソフトウェア工学教育に関心のある多くの人に来て頂けたら幸いです．

OOP演習の進捗 (2)

授業が始まって3週目が終わりました．
今週はスケジュール的に厳しく，連載作家のように「落ちる！落ちる！」という恐怖に駆られていました．でも，たぶん来週は少しはプレッシャーが弱まると思います．

OOP演習の進捗(1)

ついにαテスト開始．まだまだ序の口．
あっという間に追いつかれたらどうしよう．
でも，どんなに自転車操業が苦しくても，品質を妥協するのはやめよう．

ADDIE モデル

教育の世界では，ADDIE モデルというのがあります．どんなものかを紹介します．

1. 分析(Analysis)
   
   
   
   1. インストラクションが解決策となるようなニーズを決定する．
   2. コースが対象とする認知的，情意的，運動技能的なゴールを決定する教授分析を実施する．
   3. 学習者の前提スキルと，そのいずれがコースでの学習に影響を与えるかを決定する．
   4. 利用可能な時間や，その時間にどの程度を達成できるかを分析する．
2. 設計(Design)
   
   
   1. コースの目標を行動目標や主要なコース目標(単元目標)に変換する．
   2. 取り上げるトピックと単元と，それぞれにどれだけの時間をかけるかを決定する．
   3. コース目標を考慮して単元を系列化する．
   4. 単元を具体化し，それぞれの単元において達成すべき主要な目標を特定する．
   5. それぞれの単元に対するレッスンと学習活動を定義する．
   6. 学習者が何を学んだかを評価するための指標を開発する．
3. 開発(Development)
   
   
   1. 学習活動と教材の種類について意思決定する．
   2. 教材や活動の草案を準備する．
   3. 対象とする学習者に教材や活動の試用を依頼する．
   4. 教材と活動を改善，精緻化，あるいは作成する．
   5. 教師の研修を実施し，付属教材を開発する．
4. 実施(Implementation)
   
   
   1. 教師や学習者に教材を採用してもらうために市場に出す．
   2. 必要に応じて支援を提供する．
5. 評価(Evaluation)
   
   
   1. 学習者評価の計画を実施する．
   2. プログラム評価の計画を実施する．
   3. コースの保守や改訂の計画を実施する．

なんか，ソフトウェア開発ライフサイクルみたいですね．

ADDIE では，特に分析のところで，教材開発者が答えるべき問いがいくつか設定されており，それらに答えることで分析を進めていきます．

次回から OOP 演習に関して ADDIE にしたがって整理して進めていこうと思います．

抽象化とは何か？

SWEBOK 2004 に挙がっている Software Design Enabling Techniques の1つ，Abstraction (抽象化) について考察してみました．

僕が考えた抽象化の定義は次の通りです．

抽象化は，(1)複数の具体的な概念や現象の共通性を見いだして，(2)不要な枝葉の情報をそぎ落として一般化し，(3)それに適切な名前をつける行為である．

これら3つの要素が備わらないと抽象化とは呼ばないような気がしました．まず第1に，抽象化の対象は複数あること．もし対象が1つしかなかったら，抽象化する必要はなく，具体的なまま扱えばよろしい．なおかつそれらを共通化して扱いたいという動機がある．第2に，複雑なまま扱うのではなく，ある観点にしたがって不要な情報をそぎ落とすプロセス(捨象)が大事です．そして第3に，あとで再利用できるように適切な名前をつけることが重要です．

そう思って SWEBOK 2004 を読むと， Liskov と Guttag の書籍[Lis01]を引用して次のように書かれています．

Abstraction is "the process of forgetting information so that things that are different can be treated as if they were the same." [Lis01]

僕の訳文は次の通り． 

抽象化とは，複数の異なるものを，あたかも同じものであるかのように扱うために，捨象するプロセスである．

やはり抽象化の対象は複数あり，それらを共通化して扱いたい動機があります．forgetting information を捨象すると訳しましたが，不要な情報をそぎ落とすことですね．ただし，名前をつけることは含まれていないようです．

SWEBOK 2004 によると，抽象化の道具立ては下記の通りです．

In the context of software design, two key abstraction mechanisms are parameterization and specification. Abstraction by specification leads to three major kinds of abstraction: procedural abstraction, data abstraction, and control (iteration) abstraction. [Bas98:c6; Jal97:c5,c6; Lis01:c1,c2,c5,c6; Pre04:c1]

 箇条書きで書くと次のように整理できます．

• 抽象化(abstraction)
• パラメーター化(parameterization)
• 仕様化(specification)
• 手続き抽象(procedural abstraction)
• データ抽象(data abstraction)
• 制御(繰り返し)抽象(control (iteration) abstraction)

これらをそれぞれ教材化すればいいわけですね．さっそく参考書籍をそろえましょう！

SWEBOK 2004

Chapter 3 Section 1.4.1 Abstraction

http://www.computer.org/portal/web/swebok/html/ch3#Ref11

[Lis01] B. Liskov and J. Guttag, Program Development in Java: Abstraction, Specification, and Object-Oriented Design, Addison-Wesley, 2001.

[Bas98] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998.

[Jal97] P. Jalote, An Integrated Approach to Software Engineering, second ed., Springer-Verlag, 1997.

[Pre04] R.S. Pressman, Software Engineering: A Practitioner's Approach, sixth ed., McGraw-Hill, 2004.

Twitter のコメント

教材アーキテクチャ: 原理原則・ケーススタディ レイヤーモデル

ブログは久しぶりですね．第1学期の授業もついに始まってしまいました．でも今日は時間が取れたので，OOP演習の教材開発を再開したいと思います．

以前，OOP演習にスパイラルカリキュラムを適用することを提案しましたが，1つ問題があります．1枚岩で作ってしまうと，用いるケーススタディを変更したときに教材全体を開発し直す必要があるからです．毎年毎年同じケーススタディを行うのは飽きてしまうし，時代や学生さんの関心にケーススタディを合わせる必要があると考えられます．

そこでソフトウェアアーキテクチャの1つであるレイヤーアーキテクチャを適用することを考えました．

レイヤーアーキテクチャ(layered architecture)とは階層アーキテクチャともいい，全体を階層構造にすることで変化に対応させるときの変更箇所を最小限にしようという考え方です．レイヤーアーキテクチャでは，各層のインターフェースをきちんと定義し，下の層を基礎として利用することで，上の層の機能やサービスを実現します．そうすると，インターフェースを守っている限り，1つ1つの階層を入れ替えることが可能になります．

OOP演習では次のような階層構造を考えました．

原理原則層は，教授項目をそれぞれ独立に教材として提供します．たとえば抽象化を学習する教材を，簡単な例題を用いながら説明します．

一方，ケーススタディ層は，大きめの例題を開発し，原理原則層で提供される教材を使いながら，スパイラルカリキュラムを実現します．ケーススタディを入れ替えたとしても，原理原則層は再利用できるというわけです．

十分性，完全性，プリミティブ性

SWEBOK 2004 の設計の章で次の基本原理が挙がっていました．

• 抽象化(Abstraction)
• 相互結合と凝集強度(Coupling and cohesion)
• 分割とモジュール化(Decomposition and modularization)
• カプセル化・情報隠蔽(Encapsulation/information hiding)
• インタフェースと実現の分離(Separation of interface and implementation)
• 十分性，完全性，および基本性(Sufficiency, completeness and primitiveness) 

このうち，最後の十分性，完全性，基本性(プリミティブ性)について原典をあたってみました．SWEBOK 2004 によると [Bus96] 第6章と [Lis01] 第5章でした．このうち [Bus96]は既に持っていたので参照しましたが，[Booch90] を引用していました．


[Booch90] には十分性，完全性，プリミティブ性について下記のように書いていました(改段落は僕が入れました)．

By sufficient, we mean that the class or module captures enough characteristics of the abstraction to permit meaningful and efficient interaction. To do otherwise renders the component useless. For example, if we are designing the class Set, it is wise to include an operation that removes an item from the set, but our wisdom is futile if we neglect an operation that adds an item. In practice, violations of this characteristic are detected very early; such shortcomings rise up almost every time we build a client that must use this abstraction.

By complete, we mean that the interface of the class or module captures all of the meaningful characteristics of the abstraction. Whereas sufficiency implies a minimal interface, a complete interface is one that covers all aspects of the abstraction. A complete class or module is thus one whose interface is general enough to be commonly usable to any client. Completeness is a subjective matter, and it can be overdone.

Providing all meaningful operations for a particular abstraction overwhelms the user and is generally unnecessary, since many high-level operations can be composed from low-level ones. For this reason, we also suggest that classes and modules be primitive. Primitive operations are those that can be efficiently implemented only if given access to the underlying representation of the abstraction. Thus, adding an item to a set is primitive, because to implement this operation Add, the underlying representation must be visible. On the other hand, an operation adding four items to a set is not primitive, since this operation can be implemented just as efficiently upon the more primitive Add operation, without having access to the underlying representation. Of course, efficiency is also a subjective measure. An operation is indisputably primitive if we can implement it only through access to the underlying representation. An operation that could be implemented on top of existing primitive operations, but at the cost of significantly more computational resources, is also a candidate for inclusion as a primitive operation.

--- Grady Booch: Object Oriented Design with Application

僕が訳してみました．突っ込み歓迎．

十分であるとは，そのクラスやモジュールが意味のある効率的な相互作用をするのに十分な抽象化の特性を捉えていることを意味する．十分でなければ部品が役に立たなくなる．たとえばもし Set (集合)クラスを設計しているときに，集合から要素を削除する操作を加えることは賢明であるが，もし要素を追加する操作を無視してしまうと役に立たなくなる．実際には十分性に反することは早期に検出できる．そのような欠点はたいていこの抽象化を使う顧客から指摘される．

完全であるとは，そのクラスやモジュールのインタフェースがその抽象化の全ての意味のある特性を捉えていることを意味する．十分性が最小のインタフェースを意味するのに対し，完全なインタフェースはその抽象化の全ての観点をカバーする．その結果，完全なクラスやモジュールのインタフェースはあらゆる顧客が共通的に利用できるくらい十分一般的である．完全性は主観的な事柄であり，やりすぎになることもある．

多くのハイレベルな操作はローレベルな操作から構成することができるので， ある特定の抽象化に対して全ての意味のある操作を提供することは，ユーザーを困惑させ，一般には不必要である．この理由からクラスやモジュールがプリミティブであるということが導かれる．プリミティブな操作とは，その抽象化の基礎となる表現形式へのアクセスが与えられたときのみに，その操作が効率的に実装できることを意味する．その結果，集合に要素を加えることはプリミティブである．なぜならば，この操作 Add (追加)を実装することにより，その基礎となる操作は明らかになるからである．一方，集合に4つの要素を加える操作はプリミティブではない．なぜならば，この操作はよりプリミティブな操作 Add によって，基礎となる表現形式に対するアクセスをすることなく，効率的に実装できるからである．もちろん，効率性も主観的な尺度である．ある操作を基礎となる表現形式へのアクセスを通してのみ実装できるとき，その操作は議論の余地なくプリミティブである．あらゆる操作は，既存の最上位のプリミティブな操作で実装できるが，より多くの計算資源を犠牲にしてプリミティブな操作として包含する候補にもなる．

[Booch90] Grady Booch. Object Oriented Analysis and Design with Applications. Benjamin-Cummings Publishing Company, Subs of Addison Wesley Longman, Inc.
  

[SWEBOK2004]  英語版 

[Bus96] F. Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996. 

[Lis01] B. Liskov and J. Guttag, Program Development in Java: Abstraction, Specification, and Object-Oriented Design, Addison-Wesley, 2001.

スパイラルカリキュラム: 鈴木先生との議論

教材設計マニュアルの鈴木先生にOOP演習を見てもらいました．議論は多岐に渡り，たくさんのアドバイスとヒントをいただきました．改めて感謝します．

今回の記事では，鈴木先生からいただいた，OOP演習の核となるアイデアを紹介します．それが，スパイラルカリキュラムという考え方です．

話の発端は，以前「OOP演習で学ばせたいこと(2)」で紹介した学習目標(上図)を見せて，僕が「でもこの学習目標は，そのまま順番通りに教えるのではなく，例題を演習していくうちに，順番が前後しながら重要な学習目標が繰り返し登場して『ほらね，この原則は重要でしょ？』と定着を図りながらすすめていきたい」と言ったことから始まります．すると鈴木先生は「それは良い．それをやるならスパイラルカリキュラムだ！」とおっしゃいました．

僕の理解では，スパイラルカリキュラムは文字通り，まず基礎的な学習目標を一通り習得させ，その後らせん状に発展的な学習目標を習得していくモデルです(上図)．ポイントは1回目の学習では基礎的な学習目標やシチュエーションを厳選し，かつ例題の中でそれらの基礎的な学習目標で完結するように構成することです．2回目以降は，それに発展的な学習目標や例外的なシチュエーションなどを追加してレベルアップしていき，だんだん大きな例題に取り組めるようにしていきます．

例題の設定のしかたはさまざまです．

1. 例題そのものが1つのテーマに沿っていて，最初の例題を部品の一部として発展的な学習を進める方法．学習効率はいいのですが，一貫した適切な例題を考えるのが難しいです．
2. レベルアップするごとに，より複雑な例題に取り組む方法．学習目標に合わせて適切な例題を設定することができますが，例題そのものを理解する時間がかかり効率が悪くなります．
3. 上記の折衷案もあり得ます．たとえば5段のレベルを設ける場合，2,3個の例題を用意して，複数のレベルで例題を共有するなど．

具体的な例として，GDM (Graded Direct Method) による語学の学習を挙げていました．例えば英語だったら，学習中に日本語を含むその他の言語を一切使いません．そして毎回の授業で習う英語とジェスチャーで全ての会話が完結するように構成します．なんでも最初は You と I から始めるそうです．そして第3者が登場して he や she を学ぶ，という具合に発展していきます．面白いのが一般的に中学英語で割と最初に学ぶ "This is a pen." よりも先に "This is my pen." を学習するんだそうです．「これは僕のペンだ」「あれは君のペンだ」と会話をして，そこへひょっこり新たなペンを登場させます．「これは君のペンか？」「いいや」「これは僕のペンではない」ときて，そこで "This is a pen." と来るわけです．こうすると，不定冠詞 a の意味が自然と体感できます．

もう1つのしかけとして鈴木先生が提案したのが，ソフトウェア工学の原理・原則のありがたみを体感させるような構成にしたらどうだ，ということでした．先ほどの GDM の例でも不定冠詞がなぜ必要かを体感する例題になっていましたが，同様のことをOOP演習でもやるべきだというのです．具体的には最初のレベルでは，とにかくグチャグチャで構造化されていないコードでも，とにかく気合いでできてしまうような形にします．そして高度なレベルの例題にトライさせて，何か手立てを打たないとやってられないという気分にさせておいて，構造化を教えるわけです．

この話を受けて1つ思いついたのが，派生開発をやらせるとありがたみを実感できるだろうというアイデアです．似たような製品を開発させてみて「なんか似たようなコードが複数現れるよね，これを何とかまとめたい」と思わせるわけです．

そういう教材設計をするにはどうしたらいいかというと，次の点がポイントです．

1. 教えるべきそれぞれの学習項目に対してどういうシチュエーションでありがたみがあるかを具体的に考える．
2. 学習項目にレベル付けをしてグルーピングする．
3. 上記を考慮して具体例を順番に並べて教材化する．

これらのアイデアがもし実現できたら，それはかなり面白い教材になるでしょう．そう思うとワクワクしてきました！ 問題は，うまくフィットする題材を思いつくかですが，案ずるよりも産む方がやさしいかもしれません．まずはいろいろ手を動かして考えてみたいと思います．

追記: Twitter 上の反応はこちらです．

OOP演習(2)教材企画書

• 教材設計マニュアル資料2「教材企画書の書き方」(p.164-165)を見ながら，学習目標「構造化できる」の教材企画書を書いてみました(学習目標の全体像はこちら)が，途中で詰まってしまいました．
• 行き詰まった原因は，教材のイメージがまだアイデアレベルで具体的ではないからです．具体的なイメージを思い描けない根源的な理由は，教材の4条件の1つ「自分がよく知っている内容／よくできることか？」を完全には満たしていないからだと分析しました．その結果，学習目標やテストの具体的なイメージが思い描けないのです．
• この教材は根幹的で重要な位置づけなのに対し，上記のように開発のリスクが高いので，早めに対策を練る必要があります．

OOP演習(2)


教材のタイトルと内容
ソフトウェア設計の原理・原則を理解しよう！
ソフトウェア設計で普遍的に用いられる6つの原理・原則(SWEBOK 2004)を UML のイメージとして理解する．

• 抽象化(Abstraction)
• 相互結合と凝集強度(Coupling and cohesion)
• 分割とモジュール化(Decomposition and modularization)
• カプセル化・情報隠蔽(Encapsulation/information hiding)
• インタフェースと実現の分離(Separation of interface and implementation)
• 十分性，完全性，および基本性(Sufficiency, completeness and primitiveness) 

対象者集団
次のことを学習済みの大学生・大学院生もしくは社会人

1. UML の基本的な図(ユースケース図，クラス図，状態機械図，シーケンス図，アクティビティ図)の文法を理解している．
2. 簡単な UML の図(同上)を書ける．

内容選択の理由

1. 自分がよく知っている内容／よくできることか？
• 次の問題がある．
• おおむね理解しているが， 細かいところで再確認したい点がある．SWEBOK 2004 に挙がっている文献を調べ，場合によっては内容について技術者と議論する必要がある．
• 原理・原則を体現する UML 図を考案する必要がある．
2. 教材作りの協力者が得られるか？
• 新たに研究室に配属された新4年生5名に協力してもらう．
• 事前テストの結果次第では新M1の4名にも協力してもらえる可能性がある．
• 場合によっては学生モニターを公募することも可能だろう． 
3. 短時間で学習できるか？
• 何をもって理解したとするかによる．言葉を覚えるだけならば短時間で学習できる．適切な UML 図を提供すれば直観的に意味を理解することもできるかもしれない．しかし，実際に知識を適用してモデリングに応用することまで求めるのは一朝一夕にはできないと思われる．このテーマは実に奥が深いので，開発現場の技術者でも徹底的に追求するのは難しい現状があるからである．
• 上記の理由から，学習目標をよく検討して細分化する必要がある．
4. 個別学習教材で，教材が「独り立ち」できるか？
• 原理・原則をいかにブレークダウンして体系化するか，どのようにテストを自己採点できるようにするかが鍵である．たとえば原理・原則がチェックリストのような形で提供でき，その基準にしたがってテストを自己採点できるならば，教材が独り立ちできる．

学習目標と目標の性質

事前事後テスト

教材利用者の前提条件とそのチェック方法

1. クラス図，状態機械図，シーケンス図，アクティビティ図の図形要素の名称を知っている必要がある．これらの図形要素に提示し，その名称を選択肢から選ばせる．全問正解すること．この前提テストは，OOP演習(1)の前提テスト1と同一である．
2. クラス図，状態機械図，シーケンス図，アクティビティ図の書き方を知っている必要がある．簡単な例題を与えて，これらの図を書かせる．それらしい図が書けていればよい(基準を明確にする必要がある)．

報告書作成者名と点検者名

• 作成者: 山崎 進
• 点検者: 未定

OOP演習(1)教材企画書

• 教材設計マニュアル資料2「教材企画書の書き方」(p.164-165)を見ながら，学習目標「UMLをもとにプログラムが書ける」の教材企画書を書いてみました(学習目標の全体像はこちら)．
• 計算機演習IIとソフトウェア設計論(科目関連図はこちら)をしっかり理解していれば，この教材からスタートできるので，教材の通し番号を1としました．
• 前提テストの結果，理解不足だった場合には，あとで作る補習用の教材を学習することになります．
• まだ具体的なテスト問題はできていないので，あとで作成します．
• 自分で見返してみると，1時間程度の1つの教材で完結させるには学習項目がちょっと多いかなと思います．あとで学習目標ごとに分割するかもしれません．

OOP演習(1)

教材のタイトルと内容
モデル駆動プログラミング: UML をもとにプログラムを書こう！
与えられたUMLの図からオブジェクト指向プログラミング言語でプログラムを書く

対象者集団
次のことを学習済みの大学生・大学院生もしくは社会人

1. UML の基本的な図の文法を理解している
2. C言語の基本的な文法を理解している

内容選択の理由

1. 自分がよく知っている内容／よくできることか？
• UML 2.0 から JDK 1.4 頃までの Java 言語へ変換する方法はよく知っている．
• 最近の Java 言語や，他のプログラミング言語，ライブラリの活用方法については事前に調査が必要である．ただし，これらにあまり依存せずに教材を構成できる．
2. 教材作りの協力者が得られるか？
• 新たに研究室に配属された新4年生5名に協力してもらう．
• 事前テストの結果次第では新M1の4名にも協力してもらえる可能性がある．
• 場合によっては学生モニターを公募することも可能だろう． 
3. 短時間で学習できるか？
• 1時間程度で個別の変換方法を全て暗記するのは難しい．
• 小規模なモデルを個別の変換方法を見ながらプログラミングするならば可能である．
4. 個別学習教材で，教材が「独り立ち」できるか？
• 下記が満たされれば，用意したモデルを元に作成したプログラムを実行して動作を確かめることで，理解しているか確認できる
• 変換方法のアルゴリズムを理解しやすい形で明確に定義する．
• あらかじめ動作確認のためのテストコードを用意しておく．

学習目標と目標の性質

1. クラス図をもとにクラス定義のひな型を作成できる．変換ルールを適用しながら与えられたモデルをプログラムに変換するので，＜知的技能＞の目標である．
2. 状態機械図をもとにクラスの状態を記述できる．変換ルールを適用しながら与えられたモデルをプログラムに変換するので，＜知的技能＞の目標である．
3. シーケンス図を見ながらメソッドの概要を記述できる．変換ルールを適用しながら与えられたモデルをプログラムに変換するので，＜知的技能＞の目標である．
4. アクティビティ図をもとにメソッドの中の処理を記述できる．変換ルールを適用しながら与えられたモデルをプログラムに変換するので，＜知的技能＞の目標である．
5. 上記の図を組み合わせた UML モデルをもとにプログラムを完成させられる．上記を応用しながらモデルをプログラムに変換するので，＜知的技能＞の目標である．
6. (副次的な目標) コード実装の視点で UML で書かれた設計図のレビューができる．チェックリストを適用しながらモデルの問題点を指摘するので，＜知的技能＞の目標である．

事前事後テスト

1. 事前テストは，クラス図，状態機械図，シーケンス図，アクティビティ図からなる簡単な UML モデルを与えて Java 言語のプログラムに変換させる．これは学習目標5の事後テストと同じ問題である．うまく変換できなかった人を対象とする．
2. 事後テストは5題(副次的な目標を含めれば6題)からなる．
1. 関連を含む簡単なクラス図をもとに，変換ルールを見ながら Java 言語のプログラムを作成させる．これは学習目標1に対応する．
2. 信号機の状態機械図と各色の処理を記述したプログラム断片をもとに，変換ルールを見ながら Java 言語のプログラムを作成させる．これは学習目標2に対応する．
3. 簡単なシーケンス図をもとに，変換ルールを見ながら Java 言語のプログラムを作成させる．これは学習目標3に対応する．
4. 簡単なアクティビティ図をもとに，変換ルールを見ながら Java 言語のプログラムを作成させる．これは学習目標4に対応する．
5. クラス図，状態機械図，シーケンス図，アクティビティ図で構成される簡単な UML モデルをもとに，変換ルールを見ながら Java 言語のプログラムを作成させる．これは学習目標5に対応する．
6. チェックリストを見ながら，誤りを含んだクラス図の問題点を指摘させる．これは学習目標6に対応する．

教材利用者の前提条件とそのチェック方法

1. クラス図，状態機械図，シーケンス図，アクティビティ図の図形要素の名称を知っている必要がある．これらの図形要素に提示し，その名称を選択肢から選ばせる．全問正解すること．
2. C言語の変数型，制御構造，関数について理解している必要がある．これらを使った簡単なC言語のプログラムを提示し，与えられた入力に対しどのような出力をするかを答えさせる．

報告書作成者名と点検者名

• 作成者: 山崎 進
• 点検者: 未定

ソフトウェア工学教育の問題点(2)

ここ最近，複数の方とソフトウェア工学の教育について議論する機会がありました．

前回指摘した問題点で示唆されるのが，大学で行われているソフトウェア工学の教育は企業で求められる水準を満たしていないという点です．では大学で教えるべきソフトウェア工学の教育とはどのようなものでしょうか？

大学も産業界も納得しそうな落としどころとしては大学はすぐに陳腐化しない普遍的な基礎について教えるべきであるという考え方です．実際，他の工学分野ではそのような教育方針がとられており，うまく機能していると考えられます．

しかしソフトウェア工学の場合には，ここに本質的な問題点があると僕は考えます．情報とりわけソフトウェアの分野ではそもそも「陳腐化しない普遍的な基礎」と，それを教育する方法が確立されていないのではないかということです．

たとえば，他の工学から推論すると，古典的な構造化設計で重要視される原理・原則と，(ちょっと古いですが)オブジェクト指向設計で重要視される原理・原則は，何かしらの一貫性をもって説明できると考えられます．もし，それらに一貫して存在する原理・原則があれば，それは陳腐化しない普遍的な基礎である可能性が高いと思います．

しかし古典的な理論と最新の理論をそのように関連づけて一貫性をもって論じている大学がどれほど存在するのでしょうか．コンピューター関連分野の技術進歩は日進月歩なので，古典的な理論との一貫性を考慮している暇がないのでしょう．

それでもソフトウェア工学を自らの議論ですすめている欧米ならば，最新理論も古典的な理論での議論を背景に積み上げているので，彼らの世界の中では一貫性を保っているのでしょう．しかし，それをキャッチアップする立場である日本ではついていくのが精一杯で，キチンと考察するのをサボってきたのだと思います．

産学連携がうまくいかなかったことも大きな要因だと思います．もし産と学が日常的に議論していれば，最新技術と既存技術の整合性についても議論されただろうと思います．その結果，理論・教育と実践に大きなギャップがあります．

とても遠い道のりですが，SWEBOK などを参考に，ソフトウェア工学理論の再解釈をしていく必要があるのでは，と思っています．それを踏まえた上で，最適な教育方法を議論していくのが本筋だと思います．

とはいうものの，今年OOP演習の教材を作らなければならない身としては，そんな悠長なことは言っていられないのも事実です．うまく落としどころを見つけて，ベストではないにしてもベターな教材を開発するしかないと思っています．この大きな問題を認識はしますが，完全な解決を性急に求めないようにしようと思います．

つづく

ソフトウェア工学教育の問題点(1)

前回の記事に対して，酒井さんより Twitter でコメントがありました．

これを教えられる先生は日本では何人ぐらいいると思いますか？ 10人、100人、1000人のうちだいたいどれ？

僕は数字に弱いので，正確な数字はもちろん知らないのですが，思うところあって次のように答えました．

何をもって教えたかというレベルによると思います．教科書に書いてあることを一通り教えるくらいならば，もしかすると100人以上いるかもしれないです．でも，産業界で求められている高いレベルまで教えるとなると，もしかすると日本の大学にはいないかもしれません．

実は僕は酒井さんの質問を額面通りには受け取りませんでした．つまり，現在大学で行われているソフトウェア工学教育には重大な欠陥があることを示唆していると受け止めたのです．もちろん酒井さんの真意がそうだったのかはわかりませんが，酒井さんの質問から連想してしまったのです．

どういう欠陥かを説明します．

前回の科目間の関連図ならびに教授項目は，理論面と実践面の一通りのことを教えているので，当初の計画通りに学生さんたちに教えることができれば，とても素晴らしい教育になり得ます．おそらく他大学でも同様のカリキュラムは持っていて，理想通りに教育できればソフトウェア工学の基礎をきっちり身につけた学生さんがたくさん巣立っていくことでしょう．

しかし，あくまで「理想通り」教えることができれば，という暗黙の前提があります．現実にはそうではないということが，この教育カリキュラムの欠陥なのです．

たとえば現行の C 言語プログラミング教育では，基本的な文法や，アルゴリズムとデータ構造の実装のしかたを一通り教えます．しかし，たとえば関数名・変数名やコメントをどう書くとよいかということは教えていません．学生さんたちは何の疑問も持たずに，次のようなコメントを書きます．

a = 0;  /* 変数 a に 0 を代入する */

もちろん，こんなコメントはナンセンスです．プログラムに書かれていることと全く同じ意味の内容を繰り返してコメントとして書いているだけで，冗長です．

冗長だとムダだというだけでなく，有害ですらあります．実際のソフトウェア開発でよく起こるのが，プログラムは変更したけれど，対応するコメントは変更し忘れることです．その結果，次のような混乱の原因になります．

a = 1;  /* 変数 a に 0 を代入する */

 こういう大事だが細かいことは，大学ではあまり教えていません．つまり，カリキュラムとしては一通り教えているのだけれど，それぞれの教授項目に抜け漏れが多く，企業で要求されるレベルに到達していない，ということになります．

原因としては，大学の先生は実開発の経験がない，もしくはその先生の専門がソフトウェアではないことが多く，そもそもそういう問題があることを知らない場合もあるでしょう．教授項目が多すぎて，細かいところまで行き届かないという問題もあるでしょう．あるいは研究で行っている最先端の技術に比べ，こういった教育内容は古いとされているので，探求するモチベーションがわかないのかもしれません．そもそもソフトウェア工学が未成熟で体系化されておらず，どんどん最新技術が投入されるので追いつくだけでも大変なので，何を教えるべきで何は教えなくてもいいのかの判断基準が不明確だという面もあるでしょう．

その結果，大学で習ったはずのことを企業で再教育する必要があり，大学でのソフトウェア教育は，何の役にも立たない，むしろ先入観を持つ分，有害ですらあるという話になります．

つづく

OOP演習で学ばせたいこと(2)

前回の説明では各学習目標の説明が抜けていたので，今回説明したいと思います．順番は基礎的なものから並べましたが，並列な学習目標については適当に並べました．

1. C言語プログラミングできる
• C言語の基本的な文法を使える
• 基本的なアルゴリズムとデータ構造を実装できる
2. モデリングの概念を理解できる
• モデルとは何か，モデルの重要性を理解できる
• 抽象，捨象の概念を理解できる
3. 基本UMLが読める
• 基本的な UML の図が文法的・意味的に理解できる
• UML の図のうち，何を基本的な図と定義するかは，検討が必要．
4. 基本UMLが書ける
• 上記の UML の図をつかって簡単なモデルを書ける
• 「1手詰め」くらいのレベルを想定．
5. UMLをもとにプログラムが書ける
• UMLからプログラムに変換できる
• 狭い意味でのOOP演習
• プログラミング言語は Java を想定しているが，他の言語にも通用する話を主体にしたい．
6. OOPLの API・言語仕様書が読める
• プログラミング言語でどう記述したらいいかを自習できるよう，ドキュメントの読み方を理解する
• ドキュメントを読むことは，初心者から脱皮するのに必要かつ重要なスキル
7. テストが書ける
• xUnit を使って，要求仕様をテストコードとして書く方法を理解する
• テスト駆動開発のノリを体験する
8. コードリファクタリングができる
• 開発したコードをきれいにリファクタリング(再構成)する方法を学ぶ
9. 開発環境を整備できる
• 統合開発環境を自分で一通りセットアップできるようになる
• ツール依存なので，インストールガイドやチュートリアルなどの読み方を説明する
10. UMLの仕様書が読める
• OMG が提供している UML の仕様書を読んで，UML の細かい使い方を自分で調べられるようにする
• 英語のドキュメントになじむ
11. 構造化できる
• OOA(Object-Oriented Analysis: オブジェクト指向分析)やOOD(Object-Oriented Design: オブジェクト指向設計)の元となった構造化分析・設計の重要な原則を学ぶ
• 構造化分析・設計の考え方を現代的にアレンジ
12. OOAができる
• OOA の基本的な原則を理解する
• 現実世界のことがらを自在にモデリングできる
• 何ができれば OOA ができたことになるのかは，要検討
13. OODができる
• OOD の基本的な原則を理解する
• OOA で記述した What (何を実現するか)を How (どのように実現するか)に落とし込むことができる
14. 品質モデルを理解できる
• 品質モデルを理解する
• 品質モデルに基づいてモデルやプログラムをレビューできる
15. テストケースを設計できる
• 実現したい品質要求をどのように保証するかの基礎を理解する
16. デザインパターンを使える
• デザインパターンに基づいて OOD ができるようになる
• パターンという概念を理解する
17. アーキテクチャ設計ができる
• アーキテクチャという概念を理解する
• アーキテクチャパターンを使える
• 品質要求をどのようにアーキテクチャとして実現するかを理解する

うーん，こうしてみてみると，実に盛りだくさんですね．これら全部を180分x14or15回で教えるのは，いかにも無理そうです．ただ，範囲を絞るのは当然としても，せっかく発展的な学習目標を考えたので，その広がりを感じさせるような，あるいは体感させられるような教材を作りたいですね．

OOP演習自体の位置づけを説明するのを忘れたので，次回はそれを説明しようかと思います．

つづく

追記: 「モデリングの概念を理解できる」の学習目標を追加しました．

OOP演習で学ばせたいこと(1)

このブログの新企画です．教材設計マニュアルに基づいて教材開発をする過程を公開してしまおうと思います．ソフトウェア工学の教育に関心のある企業・大学の方々だけでなく，先日熊本大学にて巡り会えた，熱い情熱を持ってそれぞれの分野で活躍されている教育者の方々などから意見をもらうことでブラッシュアップを図ろうというもくろみがあります．応援よろしく！

開発対象は，今年から開講する授業「オブジェクト指向プログラミング演習(OOP演習)」の教材です．OOP演習は，毎週2時限分(180分)を計14回行います(近々15回に増えるかもしれない)．

鈴木メソッド(教材設計マニュアルの方法論)は3つのステップで構成されており，第1ステップは教材企画書の作成です．資料2(p.164)によると教材企画書は以下で構成されています．

1. 教材のタイトルと内容
2. 教材の対象者集団
3. 内容選択の理由(教材の4条件に照らして)
4. 学習目標と目標の性質
5. 事前事後テスト
6. 教材利用者の前提条件とそのチェック方法
7. 報告書作成者名と点検者名

ただし，ここでいう教材は，1時間程度で学習できる内容のものを想定しています．今やりたいことは計14回の授業全体をどう構成するかです．つまり，どちらかというとシラバスをどう作るかという話です．教材設計マニュアルにはシラバスの例として，次のような構成要素を挙げています(p.180:資料9 一部の記述は一般化しています)．

1. テーマ
2. 内容
3. 講義を受けるための条件
4. 講義の目指すもの(学習目標)
5. 講義の進め方について
6. 評価方法について
7. スケジュール
8. 教室について
9. オフィスアワーについて

シラバスをどう作るかについては，教材設計マニュアルには明示的には書かれていませんが，類推できます．「教材の構造を見極める」にあるように，出口となる学習目標を定義したあと，入口に向かってさかのぼるように課題をブレークダウン(課題分析)し，1時間程度でおさまる分量に分割していくのでしょう．

そういうわけで，さっそく思いつくまま書いてみました．

下に行くほど基礎的，上に行くほど応用的な学習目標です．左右に並んでいるのは，並行して学べる学習目標です．図中の(pre)とあるのは，他の授業で習った(はずの)ことです．

これくらい一通りできないと，オブジェクト指向のソフトウェア開発について学びましたとは言えないだろうと思います．が，見ての通り，教えなくてはならないことがてんこ盛り．授業時間におさまるのか？教材を作りきれるのか？と不安です．

とりあえず優先順位をつけて，OOP演習では赤い字の学習目標だけでも達成できたら，ひとまずOKだろうと考えました．「UMLをもとにプログラムが書ける」「構造化できる」「OODができる」「OOAができる」の4つです．

仮にこれらの学習目標を設定し，さらに明確化・ブレークダウンして教材企画書の形に書いていこうと思います．

つづく