2010年2月25日木曜日

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言語のプログラムを提示し,与えられた入力に対しどのような出力をするかを答えさせる.

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

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

2010年2月24日水曜日

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

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

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

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

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

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

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

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

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

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

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

2010年2月23日火曜日

ソフトウェア工学教育の問題点(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 によるモデルベースの検証方法の理論と実践.
つづく

2010年2月20日土曜日

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

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

2010年2月19日金曜日

教材設計マニュアル

今回紹介する本は,教材設計マニュアル―独学を支援するためにです.


熊本大学には e-learning を e-learning で教えるユニークな大学院があります.著者の鈴木克明先生は,その大学院の専攻長をされています.鈴木先生は Instructional Design (ID) という教育の方法論の専門家です.この本は,鈴木先生の豊富な知識と長年の経験に基づいた教材を作るための方法論を紹介しています.
ソフトウェア工学になじみのある人には,eXtreme Programming にノリが近いといえば分かるでしょうか.テストファースト,反復開発,オンサイト顧客といったプラクティスと共通性があります.


余談ですが, eXtreme Programming と共通性のある考え方は,ソフトウェア開発・教育だけではなく,経営戦略でも同時多発的に起こっています.経営戦略とソフトウェア開発については,起源は80年代の日本企業の強さを欧米が徹底的に研究したことに由来するそうです.これは僕の仮説ですが,おそらく ID の分野でも同時期に日本企業研究にヒントを得て欧米で研究が進んでいて,それを鈴木先生が逆輸入したのではないかと思います.真相はいかに?




2013/4/28 追記
鈴木先生に以前この話を伺ってみたところ,IDの分野では日本企業研究とは別個に進んでいたようです。ソフトウェア工学や経営学においても,日本企業研究とは別の由来で,反復開発的なプロセスを研究していた流れもあったようで,それがたまたま合流したということのようです。

2010年2月18日木曜日

製品指向とフィーチャー指向の可変性実現(3)

前々回前回で製品指向とフィーチャー指向がどういうものかを説明しました.おさらいです.

  • 製品指向で可変性を記述した場合,製品に対応したコードを生成するときには製品名のマクロを定義すればいいので楽ですが,そのかわり製品を追加するたびにプログラムコードを改変する必要があります.
  • フィーチャー指向で可変性を記述した場合,プログラムコードの変更は製品指向と比べて少なくてすみますが,ビルドするときにフィーチャーを細かく指定する必要があります.
両方のいいとこ取りはできないのでしょうか? 実はできます.フィーチャー指向で可変性を記述し,ビルドファイルで製品指向からフィーチャー指向への変換をすればいいのです.

たとえば次のような製品マップだったとしましょう.


製品 A をビルドするときにはフィーチャーX,Z を,製品 B をビルドするときにはフィーチャーX,Yを指定する必要があります.この対応関係をビルドファイル中に記述します.たとえば,PRODUCT_A が定義されていたときには FEATURE_X, FEATURE_Z を定義するように書くわけです.このような情報をコンフィギュレーションといいます.

このとき製品指向とフィーチャー指向は上の図のようなレイヤー構造(階層構造)にあります.まず可変性を具体的に記述するのはフィーチャー指向で行います(下の層).その可変性記述のメカニズムを利用して製品指向の可変性記述をコンフィギュレーションとして記述します(上の層).上の層が下の層の機能を使って実現されているとき,その構造をレイヤー構造といいます.

以上をまとめると,次のような表になります.


僕は,おそらくこの発見(製品指向の利点はフィーチャー指向でも実現できる)が,フィーチャー中心のプロダクトライン開発の原点ではなかったかと思っています.裏をとりたいので,何か情報をお持ちの方はお知らせください.


つづく

製品指向とフィーチャー指向の可変性実現(2)

前回は製品指向について説明しました.今回はフィーチャー指向について説明します.

フィーチャー指向は,フィーチャー(≒機能)に対応して可変性を記述する流儀です.もうみなさんだいたい想像がつくと思いますが,次のようなコードを書きます.


#ifdef FEATURE_X 
/* フィーチャー X 向けのプログラムコード */
#endif 

 このような書き方の場合,プログラムコードの変更は製品指向と比べて少なくてすみます.もちろん新たなフィーチャーを追加したときには変更が必要ですが,単にフィーチャーの組み合わせを変えただけの新製品を作成するときには.プログラムコードを変更しなくてもできます.

逆に欠点としては,ビルドするときにフィーチャーを細かく指定する必要があります.製品指向だと製品 A のビルドをするときにマクロ PRODUCT_A を定義してビルドすれば良かったのに対し,フィーチャー指向では製品 A が採用する全ての可変フィーチャーを指定する必要があります.これは可変フィーチャーの数が多いと,面倒ですし,間違いの元です.

しかしこの欠点は,少し改良すると解消することができます.次回はその話をしましょう.

つづく

2010年2月13日土曜日

製品指向とフィーチャー指向の可変性実現(1)

前回の最後にプロダクトラインにおける戦略について触れましたが,それを論じる前に,プログラムコードなどの開発成果物で可変性を実現する2つの流儀,製品指向フィーチャー指向を紹介します.


なお,この製品指向,フィーチャー指向という分類の呼び方は,僕独自の見解であって,文献などで裏をとっていません.類似のことを主張している文献は,いかにもありそうなので,もしご存じならコメントいただくと助かります.

可変性を実現するにはさまざまな方法があります.数々の技法を紹介するのは,また別の機会ということで,最も基本的な C 言語のマクロ(#ifdef)を使った方法を見てみましょう.


よくある定義のしかたは,開発する製品に対応して可変性を記述する方法です.この流儀を製品指向と呼びましょう.

#ifdef PRODUCT_A 
 /* 製品 A 向けのプログラムコード */
#endif /* PRODUCT_A*/
なお,「製品 A 向けのプログラムコード」とコメントされている部分には,実際には製品 A だけに実装するプログラムコードを記述します.

C 言語のコンパイラーは,#ifdef の直後に指定されているマクロが定義されているときに #ifdef から #endif までのコードを含めてコンパイルし,そうでないときには含めずにコンパイルします.したがって,製品 A をビルドするときには,コンパイルスイッチでマクロ PRODUCT_A を定義します.そうすると製品 A 向けのプログラムコードを含むソフトウェアが生成されます.

この方法の問題点は,製品の数を増やすときに,プログラムコードを改変する必要があることです.たとえば新たな製品 B を作るとします.そのとき上記の製品 A 向けのプログラムコードを製品 B にも使うとしましょう.この場合,次のようにプログラムコードを改変する必要があります.
#if defined(PRODUCT_A) \  
  || defined(PRODUCT_B) 
 /* 製品 A・B 向けのプログラムコード */
#endif /* PRODUCT_A, PRODUCT_B*/
#if defined(PRODUCT_A) は  #ifdef PRODUCT_A と同じ意味です.ただし, defined を使うと複数の条件を扱うことができます.また,バックスラッシュ(\) は改行があってもマクロが続くという意味で,縦棒ふたつ(||)は「または」という意味です.したがって,この例では,PRODUCT_A または PRODUCT_B が定義されていた場合に #if から #endif までのプログラムコードを含めるという意味になります.

まとめると,製品指向で可変性を記述した場合,製品に対応したコードを生成するときには製品名のマクロを定義すればいいので楽ですが,そのかわり製品を追加するたびにプログラムコードを改変する必要があります.



追記: あとで明かしますが,製品指向は可変性の表現としては悪い例です.このようなコードをあとで説明するフィーチャー指向に改めていく必要があります.

つづく

2010年2月2日火曜日

J-SPLEリストで Follow us!

SPLE を推進する技術者・研究者の Twitter リストを作りました.
J-SPLE リストはこちら


注意点としては,Twitter のシステムの都合上,僕がリストに入っていないという問題があります.ご面倒だとは思いますが,僕も合わせてフォローいただきますよう,よろしくお願いします.


「よくわかる経営戦略論」は経営戦略論の BOK ガイド?

今回もタイトルで言いたいことはほぼ言い尽くしたのですが.

ソフトウェアの世界では,PMBOKSWEBOKなど,さまざまな Body of Knowledge (BOK: 知識体系) ガイドがあります.

BOK ガイドは,主要キーワードとそれに関連する文献を網羅的に紹介していますが,経営戦略論においてそれに近い位置づけなのが,今回紹介するよくわかる経営戦略論です.この本は数ある経営戦略の本を選りすぐり,歴史的背景とともにそれらの文献の概要を紹介するものです.

BOK ガイド単独では,その分野のキーワードがわかるだけで内容についての深い知識が得られないのと同様,よくわかる経営戦略論でも,その真価を発揮するには,この本が推薦している書籍を一通り入手して読む必要があるでしょう.したがって,ガイド付きの推奨文献リストだと思えばいいです.

初学者がこの本だけ買って経営戦略について理解できるわけではないですが,ある程度の書籍を買うお金と読む時間があって,体系的に経営戦略について学びたいと思う人にはおすすめです.