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 上の反応はこちらです．

ソフトウェア工学教育ワークショップ --- 求める人材像(技術スキル)

2010年2月27日(土)〜2月28日(日)に北九州にて，本学の「ソフトウェア工学概論」の授業で特別講師をお願いしている企業の方々をお招きして，ソフトウェア工学教育に関するプライベートワークショップを開催しました．

せっかく貴重な時間を割いていただいて合宿をするので，大上段に構え，大学におけるソフトウェア工学教育はどうあるべきか？という問題について議論を深めようと考えました．もっとも，そういうことは本来なら「ソフトウェア工学概論」の授業を始める前に議論すべきだったのかもしれません．しかし，前向きに解釈すれば，一通り講義がそろった段階で改めて振り返ってみることで，より深い議論になったと考えることもできます．

2日間の議論の成果として，企業が求める人材像，つまり大学でソフトウェア工学を学ぶ新卒学生に対して，企業が求めるスキルとは何かをまとめました．これをたたき台に，より深い議論ができたらいいなと思っています．

前提として，ワークショップ参加者が主に組込みソフトウェアに携わる技術者だったので，ここでいう企業とは組込みシステム開発を主たる業務としている企業だとしています．もしかすると業務系だと事情が異なるかもしれません．

また既に世にあるITSSやETSSなどのスキル標準を多少参考にしましたが，打ち出している方向性はだいぶ違います．

この内容は，学生さんが学習計画を立てる上でも参考になるでしょう．企業の方たちは，ソフトウェア技術者を目指す新卒学生に対して，こういうことを求めているのです．

スキル体系

大別して技術スキルと社会スキル，ヒューマンスキルの3種類があると考えました．ただし，これらは完全に独立しているわけではなく，互いに関連しあっています．今後，このあたりの関連についても考察していく必要があります．今回はこのうち技術スキルについて書きました．

技術スキル

実はワークショップで「ソフトウェア工学で大学が教えるべき技術スキルはない」とおっしゃった方がいました．ソフトウェア工学で話題になる技術は，陳腐化が速く，氷山の一角に過ぎないので，むしろ大学では流行にとらわれず，基礎となる数学や論理的思考，あるいは技術を獲得するためのスキルなどに注力すべきであるという主張でした．

それにたいし，現在どのような技術があって，それらはどういう問題意識で生み出されてきたのかという「土地勘」を身につけることは重要だという議論も出ました．土地勘を身につけるには，具体的な技術の事例を多く知っている必要があるわけです．

そういう議論を踏まえ，現在，企業で問題になっている事柄を意識しながら，基礎として身につけてほしい知識は何かを私たちは考えました．暫定的な結果として，モデリング，標準化，ソフトウェア開発技術，ドキュメンテーション，リーディング，位置づけの把握といった項目を挙げました．

モデリング能力

私たちは，モデリング能力が技術スキルの中で最も重要だと結論づけました．

ここでいうモデリング能力は，たとえば UML の読み方・書き方を知っているという狭い意味だけではありません．モデリング能力は，たとえば高校の物理でも扱われます．物理の授業では，文章題を読んで，図を書き，ニュートン方程式などの数式を立てて解を導くことをします．この行為は，実世界で起こる現象を抽象化し，モデルとしての図や数式を記述して問題を解決するという広い意味で，モデリングの一種だと考えます．今，このような広い意味でのモデリング能力が求められていると私たちは考えました．

モデリング能力につながる基礎的ドメインモデル


モデリング能力を養う観点，組込みシステム開発で必要なドメイン知識を理解する観点から考慮して，次のような基礎的なドメインモデルを知っておくと役に立つという議論になりました．

• 数学
• 物理
• 制御

それぞれについて簡単にまとめます．

• 数学

組込みシステム開発では，離散系(コンピューターの中の世界)と連続系(物理世界)を両方扱うので，どちらにも通じていると応用がききます．また，抽象化のセンスは，数学によって養われると考えられます．

• 物理

組込みシステムではセンサーやアクチュエーターで物理世界を扱うので，基本的な物理の法則や概念を知っておくことは必要です．次の制御理論を勉強するにも，物理を勉強することが重要です．

余談ですが，私は物理実験も担当しています．どうせ物理実験をやるならば，組込みシステムに関連した形で教えられたらと思っています．が，全学横断の科目であり，教材等を新規開発するコストもかかるので，改善をずっと見送っているところです．

• 制御

基本的なフィードバックなどの制御について知っておくと，主にアクチュエーターの制御をどうすればいいかが理解できます．

モデリング能力を鍛えるには何が必要か


モデリング能力を鍛えるには何が必要かという議論で，抽象・捨象，観点といった概念を教えることが必要だと私たちは結論づけました(それで全てだというわけではないです．他にも必要かもしれません)．

抽象・捨象の概念は，前述したような数学や物理の文章題によって鍛えられると考えられます．またモデリングには「ある観点に沿って思い切って捨象する勇気」が必要です．こういったことをモデリング教育で伝えるのが重要だと私たちは考えました．

機能・構造・振る舞いの3面モデリング

観点に関連して，UML で一般的な機能・構造・振る舞いの3面からモデリングをする考え方を身につけさせたいという意見がありました．特に，これらの間の因果関係を事例に結びついた形で身についていると，複数の観点を考慮した「いいモデリング」をしやすいです．

モデリングの教え方

大きくわけて，抽象論から入って具体論に入る教え方と，具体論から入って抽象論に入る教え方があります．大多数の学生さんにとっては後者の方が理解しやすいだろうという意見でした．


標準化

この議論が始まって一番最初に挙がったキーワードが，実は標準化でした．例えば頂上人材としてCIO(Chief Information Officer) やアーキテクトが足りないことを考えると，プロセスやプラットフォームなどの標準化を推進できる人材を育成する必要があります．


ただ標準化を推進する立場の人は少数精鋭でいいかもしれないので，大学生や大学院生の教育を念頭に置いたときには，まずは「標準化についていける人」を育成すべしと結論づけました．その流れで，PSP (Personal Software Process)の話や，AUTOSAR (AUTomotive Open System ARchitecture)などの話，はたまた標準化戦略の話まで発展しました．


今後は，標準化に必要な知識が何かという議論が必要ですね(作る方もついていく方も)．


ソフトウェア開発技術


発端は「いろいろ技術スキルについて議論したけど，今時の新卒にプログラミング能力はどの程度要るの？」という話からでした．さまざまな話が出ましたが，ソフトウェア工学のありがたみが実感できる程度にはプログラミングをしててほしいね，という結論でした．規模としては1000行程度，できれば複数の人間で開発している経験があるのが望ましいでしょう．そこから派生して，せっかく複数の学生さんが同じ場に集まっているので，チームで働く能力を開拓するといいという話になりました(パーソナルスキルに続く)．

他には，基本的な設計手法，UML をつかった開発プロセスについて経験があると望ましいという意見がありました．


ドキュメンテーション


理系文章の基本的な作文能力は，社会で強く求められているにも関わらず，日本の教育では軽視されがちなスキルの1つです．日本における高校以前の作文教育は，感想文などの情緒的な文章ばかりで，いわゆるテクニカルライティングはほとんど教えていないのが現状です．

理系の大学ではまだマシな方で，レポートや卒業論文の作成を通してOJT的に指導をしていますが，指導が行き届いているかというとまだまだです．大学によっては卒業論文で初めて指導を受けたという学生も多く，しかもOJT的なので体系的な教育ではありません．

北九州市立大学では1年次必修科目の物理実験で工夫をしています．3週がセットになっていて，第1週で実験をしたあとレポートを作成し，第2週で教員のもとに来て査読を受けます．そこでいろいろ指導を受けて第3週に提出，という流れです．

私たちは，ソフトウェア工学におけるドキュメンテーションの重要性を考えると，もっとドキュメンテーション能力の開発に注力するべきだという結論を出しました．

リーディング


人が書いたコードやモデル，ドキュメントを読む能力を身につけた方がいいと私たちは結論づけました．まずどういうコード(モデル，ドキュメント)が良く，どういうのが悪いのか，実感できることが重要です．また知識習得の一手段として活用できるでしょう．品質モデルの理解にもなります．


コードリーディングを参考に教材を作るとよさそうです．



位置づけの把握


ここからは純粋な技術というよりはMOT(技術経営)的な話になります．CIOをイメージすると，技術動向の「勘」つまり自社・他社の SWOT 分析や技術ロードマップが書けるのは必須だねという話をしていました．そこで，新卒の時点では，自分や自分が研究した技術の強みや弱みといった位置づけを把握していることが重要だと私たちは結論づけました．


つづく

追記: この記事に対する Twitter 上での反応をまとめてみました．このリンクをクリック！

追記: Satohru さんが記事を書いてくださいました．このリンクをクリック！

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 を代入する */

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

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

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

つづく

ソフトウェア工学関連科目の関連図

本学のソフトウェア工学関連科目の関連を下図で示します．

太字は僕が直接関わっている科目です．各科目は次のような内容です．

• 計算機演習I: UNIX, シェルプログラミング，sed/awk, LaTeX, C言語プログラミング(データ型，制御構造)
• アルゴリズムとデータ構造: 配列，リスト，スタック，キュー，木，再帰呼び出し，アルゴリズムの解析，ソート
• 計算機演習II: C言語プログラミング(配列，構造体，関数，ポインタ，ファイル入力，データ処理，リンクリスト，スタック，キュー，木構造)
• 形式言語とオートマトン: 帰納的表現，形式言語，正規表現，有限オートマトン，非決定性有限オートマトン，文脈自由文法，プッシュダウンオートマトン，チューリング機械
• 数理論理学: 命題論理，述語論理
• プログラミング言語処理系: コンパイラの構成と原理を，講義・演習両面で学習する．「メタ」の概念がOOP演習につながっていないこともない．
• ソフトウェア設計論: UML の基本的な図の読み書き
• コンピュータアーキテクチャ: パターソン＆ヘネシー．ハードウェア系の科目だが，プログラミング言語処理系の出口なので記載．
• オペレーティングシステム(OS): 並列プログラミングの基礎．
• オブジェクト指向プログラミング演習(OOP演習): 本科目．
• ソフトウェア工学概論: ソフトウェア開発の各工程ごとの技術の知識体系を講義．企業講師の方から最新技術の説明もあり．
• 組込みソフトウェア: 組込みソフトウェアの基礎である状態機械モデルを，LTSA を使って演習
• 組込みシステム開発演習: 近未来のモデルベース開発を先取りし，演習．安全性・信頼性にフォーカス．
• ソフトウェア検証論: SPIN によるモデルベースの検証方法の理論と実践．

つづく

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つです．

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

つづく