知識から設計へ, 設計から知識へ ~ UMLやアスペクトを用いた 設計知識の活用 ~ 山田正樹 / メタボリックス [email protected] 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 アジェンダ 1. 知識変換プロセスとしてのソフトウェ ア開発 2. ドメイン・エンジニアリング 3. モデル駆動開発 (MDD) 4. アスペクト 5. まとめ 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 1 組込みソフトウェア開発の 問題点 (1) • 顧客の要求も技術も新規性が高く, 非常に複雑になってきている. – 従来の自然言語による要求表現だけでは顧客との意思疎通がうまく図れな い. • よりよい表現方法はないか? – 顧客の要求とソリューション (解決技術) の間の対応関係 (追跡可能性) がい つの間にか不明になってしまう. • うまく対応づけられないか? – いったん獲得したノウハウはできるだけ再利用したいのだが, 従来の成果物 の再利用は限界に来ている. • もう少し高レベルの再利用はできないか? • 何が新しくて何が既知なのかを明確にできないか? • オープンな現実世界との関わりがさらに強くなっている. – 今まで「現実」を扱ってきた方法 (実時間性, 例外処理) などだけでは扱いき れなくなっている. • 現実世界を表現して, それをシステム設計へとうまくつなげることはできないか? 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 組込みソフトウェア開発の 問題点 (2) • 短期間で市場に提供しなければならない. – 既にあるノウハウを再利用しなければ追いつかない. • 自分たちは何を知っていて, 何を知らないのか? • 自分たちが知っているはずのことをどうやったらうまく使えるのか? – 製品のファミリー化が進んでいるが, ソフトウェアはそう簡単にファミリー 化できない. • 不変で普遍な部分と変わる部分をあらかじめ知ることはできないか? • どうやら「何を作るか」だけではなく, 「何を知っているか / 知るべき か」「どうやって作るか」を真剣に考えないとこの先は厳しいのでは ないか ... → – – – – • プロダクト・ライン ドメイン・エンジニアリング アスペクト モデル駆動開発 これらの背後にあるのが設計における知識の重視という考え方 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 2 「知識」とは... ある事項について知っていること. また, その内容. 知られている内容. 認識によって得られた成果. 厳 密な意味では, 原理的・統一的に組織づけられ, 客 観的妥当性を要求し得る判断の体系. 1. 2. (岩波広辞苑第5版より) もっとも広い意味では「暗黙知」(知っているかどうか明 確でないような知識:-) さえ含まれる. – – 我々は日々「知識」を使って仕事をしている (はず) である. • 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 ではなぜ今「知識」か... • 我々の日常的に意識する知識は製品 (モノ) に 関する知識に偏っている. – – – – – デバイスに関する知識 プロトコルに関する知識 プログラミング言語に関する知識 プラットホームに関する知識 ... • これらの知識 (モノ知) は非常に重要であるけ れど, 実はモノ知だけでソフトウェアが作れ るわけではない. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 3 モノ知以外の知識とは... コト知 • モノを作る過程に関する知識 できたモノの背景に潜む知識 「プロセス知」といってもいいかもしれない. コト知 = 「どうやって」「なぜ」 コト知とは学ぶ対象となる知識であるだけでなく, 学び 方についての知識である. モノ知は形式化しやすいが, コト知は形式化しにくい. モノ知は伝播しやすい (≒ 模倣されやすい) が, コト知 は伝播しにくく固有の価値を持つ. モノ知は相対的に表層的な知識で, コト知は相対的に深 層的な知識と言える. 1. 2. – – – – – – 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 コト知は... ソフトウェアだけではない, すべてのエンジニアリ ング分野においての問題意識となりつつある. • – 新工学知シリーズ, 吉川弘之監修, 1997, 東京大学出版会 1. 2. 3. • • 技術知の位相 - プロセス知の視点から 技術知の本質 - 文脈性と創造性 技術知の射程 - 人工物環境と知 「能力構築競争 ~ 日本の自動車産業はなぜ強いのか」, 藤 本隆宏, 2003, 中公新書, 中央公論社 最近の (アジャイルを含む) 「ソフトウェア・プロ セス」「プロジェクト管理」ブーム (?)もその問題 意識の表れの一端かもしれない. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 4 知識変換プロセスとしての ソフトウェア開発 • コト知という考え方を念頭に置いて, ソ フトウェア開発を次のように捉え直し てみよう. コト知 問題領域の 知識 変換 解決領域の 知識 モノ知 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 知識変換プロセスとしての ソフトウェア開発 • ソフトウェア開発とは問題領域の知識を解決 領域の知識に変換すること. • モノ知は各領域に存在するモノや概念に関す る知識である. • コト知はモノの背景にある知識であり, 変換 過程に関する知識である. • 問題領域 / 解決領域は多重化している. – つまりある解決領域は見方を変えれば別の変換過 程の問題領域になっている. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 5 知識変換プロセスとしての ソフトウェア開発 • 変換過程を時間に沿っ て展開してみると... • モノ知 ←→ コト知 の往復運動を繰り返 しながら, モノ (ここ ではソフトウェア) が作られていく. • 「知識創造企業」, 野中+竹 内, 1996, 東洋経済新報社 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 そこで重要なのは... • どのように知識の塊を括り出すか? – 一挙に変換するのは多分無理だし, – あらゆる知識を一緒くたには扱えない. • どのように知識を変換するか? – 知識の変換過程そのものが重要で価値の高い知識である. • 括り出され, 変換された知識をどのようにしてつなぐ か? – 最終的な製品にとって重要なのはintegrity (まとまりの良さ, 手触り感) である. • プロセスそのものをどうやって知識化するか? 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 6 ひとつの解答例は... • 例えばオブジェクト指向 – どのように知識の塊を括り出すか? • オブジェクト = 知識のモジュール形式 – どのように知識を変換するか? • ユースケースから実装オブジェクトへのパターンに基づ いた (半) 連続的な変換 – 知識の塊をどのようにつなぐか? • メッセージ交換 (自律的疎結合) • アーキテクチャ・パターン – プロセス自身をどうやって知識化するか? • アジャイル開発プロセスなど 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 別の解答例... • どのように知識の塊を括り出すか? – ドメイン・エンジニアリング • どのように知識を変換するか? – モデル駆動開発 • 知識の塊をどのようにつなぐか? – アスペクト • プロセス自身をどうやって知識化するか? – (今回の範囲外) • ただしこれらはオブジェクトの考え方を排斥するも のではないし, このセットがあれば完全というもので もない. あくまで考え方の例. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 7 ドメインとは... • 領土, つまり固有の法体系, 言語, 文化, 経済が支配す る地域. • 固有の知識 (言語, モデルなど) が通用する分野, 領域. • “システム開発に有効な, 共通の対象領域” – 「ドメイン分析・モデリング」, 伊藤他編著, 1996, 共立出版 • 特徴的な規則と方針に従って振る舞う概念的エンティ ティによって形成される, 自律した, 現実的, 仮想的, 抽象的な世界である. – 「Executable UML」, メラー+バルサー, 2003, 翔泳社 • オブジェクトやモジュールがシステムの均質な分割 を目指しているのとは異なり, ドメインはそれぞれが 固有なものである. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 ドメイン・エンジニアリング とは... 分析 - モデリング - 再利用ループ • 1. 2. 3. ドメインを分析して抽出する. ドメインをモデリングする. インフラストラクチャを構成する. – (Arangoによる, 1992) 「あるドメインで, そのドメインのエキスパー トが重要と考えるオブジェクト, 操作, 関係 づけを識別しようとする試み」である. • – (Neighborsによる, 1981) 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 8 ドメイン・エンジニアリング とは... • 本来は再利用を目的としたパラダイムで, 1990年前後に盛んであっ た. – 再利用を目的とした流れは, 現在ではプロダクトライン・エンジニ アリングに受け継がれている. • しかしこの考え方は再利用だけではなくシステム開発全体に適 用することができる. 例えば – – – – ExecutableUMLにおけるドメイン (S. Mellor) Catalysis Approach / UML2提案におけるパッケージ (D. D’Souza) マルチ・パラダイム・デザイン (J. Coplien) Aspect-Oriented Domain-Specific Modeling (J. Gray) • 設計知識を知識領域ごとに適切なモデルとして表現すること. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 ドメインを抽出する • ドメインの抽出方法は無数にある. – 何を対象にするか – どの程度の粒度にするか – 概念的か, ツール支援か – などなど • 例えば – 自動車開発全工程におけるドメイン – 一般組込みシステム設計工程におけるドメイン (Executable UML) 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 9 自動車開発の (仮想) ドメイン 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 オントロジ (存在論) • ある種の実世界モデリング. • 対象となるドメインの背景知識を表す. • 例えば – 「右折する前にはウィンカを点滅させなければならない」 – 「窓を開けると外気が流入する」 – 「ドライバ, 助手その他の乗員がいる」 • オントロジにもさまざまな種類がある. – フィジカル・モデルは物理的な法則に関するオントロジ. – エルゴノミクス・モデルは人間の振る舞いに関するオントロジ. • オントロジは何らかの形式性を持ち, 推論エンジンを持つ場合も ある. • オントロジは実際に例えば原子力プラントの制御システム開発 などに用いられている. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 10 ドメインの自律性 • それぞれのドメインは独自の表現を持つ. 例 えば – サービス・ドメインはユースケース記述とシナリ オ (シーケンス図) で表現される. – プラットホーム・ドメインはアーキテクチャ図と クラス図,で表される. – デバイス・ドメインはスペック・シート, クラス 図, 状態遷移表で表される. • これらはUMLメタモデルという共通基盤を通 じて接続されている 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 Executable UMLのドメイン • ドメイン・チャートと呼ぶ. • 点線矢印は依存関係を表す. • 各ドメインは意味的に自律 していて, 置き換え可能でな ければならない. • アーキテクチャとは変換ルー ル (モデル・コンパイラ) の こと. • “executable UML - A Case Study”, L. Starr, 2001, Model Integration, LLC.より 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 11 ドメイン間をつなぐ • ドメインは自律したものなので (異なる文化を持つの で) 努力してつなぐ (翻訳する) 必要がある. • これをExecutable UMLではドメイン間の「ブリッジ」 と呼ぶ. – ドメイン・チャートの点線矢印に相当する. • ブリッジはドメイン間の対応関係を指定する. – 例えば • ElevatorドメインのCabinオブジェクトは, Transportドメインの Loadオブジェクトに対応する. • TransportドメインのmoveComplete状態は, Elevatorドメインの cabinArrivedシグナルに対応する. • “A Framework for Aspect-oriented Modeling”, S. Mellor, 2004より 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 ドメインの利点は... • 知識をドメインとして明示的に表現し, 扱うことがで きる. • 多様な領域の知識を無理に統一せず, その多様性のま まに扱うことができる. • ドメインの間の対応関係もまた独立した明示的な知 識として表現し, 扱うことができる. • 今まで暗黙的だった知識を明示し, 継承することによっ て能力構築能力を得ることができる. • 知識レベルの再利用性が高まる. • 後述するモデル駆動開発などと組み合わせることに よって生産性が飛躍的に向上する可能性がある. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 12 ドメインの欠点は... • ドメインの経験を蓄積し, 方法論が成熟する までコストなどの大きな負担が発生する. – どのようにドメインを切ればいいのか. – ドメインごとに最適な表現 (言語, モデルなど) を どのように選択すればいいのか. – 選択した表現を支援するツールをどうやって用意 すればいいのか. • 従来の設計能力 / プログラミング能力とは異 なる抽象化能力が要求される. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 モデル駆動開発 (MDD) とは... • 狭い意味ではモデル記述とその変換ルールから実行可能なソフ トウェアを生成する, ソフトウェア開発方法論. – したがってOMGのいわゆるMDA (Model-Driven Architecture) はモデ ル駆動開発とは言い難い. – 多くのMDAツールは単なるスケルトンを生成するのみで, 実行可能 ソフトウェアを生成しない. – また変換ルールがツールにベタに埋め込まれてしまっているもの まである. • つまりエンジニアは変換ルールをチューニングすることはおろか, 知識 として参照することもできない. • 設計知識をモデルとその変換ルールとして集約し, モデル・コ ンパイラによってモデルや実装を生成すること. – モデルには複数のビューや階層がある. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 13 モデルとは... • 一般的にはUMLモデルを思い浮かべるだろう. – 静的構造図と振る舞い図の両方が必要. • 本来は「対象のある側面に関する抽象的な記述を, 一 貫性を持ってまとめたもの」. – 地図, 設計図, 模型... – 図で表すものとは限らない – 一部のプログラミング言語はモデルといってもいいかもし れない. • Zなどの形式的仕様記述言語 • Smalltalkなどの高水準プログラミング言語 • UMLを一定のルールに基づいて拡張したものも変換 可能な場合もある. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 MDDにおけるUML2の役割 • MDD (OMG的に言えばMDA) を可能と するためにUMLを改良することが必要 になった. • ただしユーザから直接見える部分につ いてはMDAを実現するために特に大き く変わった部分はほとんどない. • 主にUML仕様の厳密化, メタモデルのリ ファクタリングなど. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 14 UML2と組込みシステム開発 • モデル駆動開発とは直接関係ないが, UML2では特に組込みシス テム開発で使われるであろう, 多くの機能が追加 / 拡張された. その主なものは – Composite Structure Diagram • アーキテクチャや構造を表しやすくなった. – Activity Diagram • 並行性などの記述能力が大幅に強化され, UMLアクション言語の図的表 現ができるようになった. – Sequence Diagram • SDL2000の記法が大幅に取り入れられた. – Timing Diagram • タイミング・チャートが描けるようになった. – Statemachine Diagram • プロトコル状態機械が区別された他にいくつかの機能が拡張され, 継承 関係が取り入れられた. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 Composite Structure Diagram Unified Modeling Language: Superstructure version 2.0 Final Adopted Specification, OMG, 2004より 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 15 Activity Diagram Unified Modeling Language: Superstructure version 2.0 Final Adopted Specification, OMG, 2004より 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 Sequence Diagram Unified Modeling Language: Superstructure version 2.0 Final Adopted Specification, OMG, 2004より 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 16 Timing Diagram Unified Modeling Language: Superstructure version 2.0 Final Adopted Specification, OMG, 2004より 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 MDDにとって重要なのは... • モデルという抽象度と形式性の高い記述. – モデルを動かすためには何らかのアルゴリズムの記述が必 要だが, 通常Action SemanticsとしてOMGで標準化されている 抽象機械 (データフロー・マシンの一種を想定) を用いる. • エンジニアが参照したり, 作成 / 変更することが可能 な変換ルール. – Executable UMLではArchetypeと呼ばれる. – 現在OMGでMOF/QVTという標準化案を策定中. – 誤解を恐れずに言えば超高級マクロ・アセンブラ. • この二つによってMDDはまさに知識変換過程に相当 する. – そして変換ルールが一つの独立したドメイン. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 17 具体的な話は... • この後の二上さんの講演に譲ります. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 アスペクトとは... • 知識の塊の別の切り方 / つなげ方. • さまざまなレベルでアスペクトを考えることができる. – プログラミング・レベルのアスペクト • Aspect/Jなど – モデリング・レベルのアスペクト • Aspect-Oriented Domain-Specific Modelingなど – 要求分析レベルのアスペクト • Early Aspectsなど • 「関心に応じたドメインの切り出し」と考えてもよい. – 例えば機能性, 性能, 品質, 資源利用など • 設計知識をアスペクトごとにまとめて表現し, 後でツールによっ て一つの設計にまとめ上げること. – ドメインが異なる論理によって支配される領域に応じて切り分け るのに対して, アスペクトは品質属性などに応じて切り分けている. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 18 例えば... • クラスやコンポーネントは機能性というアスペクト (視点) からの分割. • ところが例えば資源利用 (デバイスAへのアクセス) というアスペクトはこれとは直行している. – つまりクラスAからもクラスCからもデバイスAへのアクセ スがある. – したがって「デバイスAへのアクセス」という知識は分散し て, 機能性の中に埋め込まれてしまっている. – 本来ならばデバイスAへのアクセス制御はどこかでまとめて 面倒を見たいのに... • → 知識の再利用性 / モジュール性が低い! 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 ならば... • 直行するアス ペクトを分け て, この表の ように考えて みよう. アスペクト→ 機 能 性 ↓ デバイス Aの利用 応答時間 制約 クラ ス1 クラ ス2 X X クラ ス3 ... 2ms 1ms ... 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 19 例: 資源アスペクトの定義 • resource Device device_A; – 共有される資源を資源アスペクトとして宣言する. • resource Device { void setRegA(short i); ... }; – 資源アスペクトのインタフェースを定義する. – 通常のインタフェース定義と同様. *ここではプログラミング言語風に記述しているがモデルでも同様 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 例: 資源アスペクトの利用 • class Class1 { void method1(...) { ... device_A.setRegA(0x2D); ... } } – 利用する側は通常どおりに資源アスペクトを呼び出す. – 競合や同期についてここでは心配する必要はない. – そういう心配は資源アスペクトの側が行う. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 20 例: 資源アスペクトの記述 • • 資源アスペクトの利用のされ方は, 資源アスペクトの側に書く. さまざまな資源アスペクトの記述法があり得る. 例えば – – – – • • 優先度による 手続き的記述 ルール記述 ...... 例えばここでは優先度にしたがって資源アスペクトの競合管理を行う ものとする. aspect resource Device priority_table { ... } – “...”には優先度表が記述されている. – 手で記述する場合もあるし, 優先度表エディタが立ち上がる場合もある. • もちろんこのままでは, 資源アスペクト側の記述は機能に書いた資源ア スペクトの呼び出しには反映されない. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 例: アスペクトの織り込み • 織り込み (Weaving) とは, 資源アスペクトの記 述を資源アスペクトが呼び出されている箇所 に埋め込むこと. – ある種の知識変換と考えることができる. – 手でやってはあまり意味がないので, 基本的にツー ルによって行われる. – 変換結果は基本的に人が見るものではない. – このときにメタ情報が利用できることが重要にな る. • どのクラスがどのメソッドを用いて資源アスペクトにア クセスしているかなど 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 21 その他のアスペクト • ここでは資源アスペクトの例を見てみたが, 他にも次のようなアスペクトを考えることが できる. – – – – – – – アクセス権制御 スケジューリング 事前 / 事後条件のチェック 最適化分散 (プロセッサ割り当て) 時間制約 メモリ使用量 など 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 まとめと注意 • アスペクトはクラスやコンポーネントとは直行する 知識領域を切り出して, それに関する知識をモジュー ルとして表現できるようにするもので, ドメイン・エ ンジニアリングの一種と考えることができる. • 現時点ではシステムとしてまとまって広く使われて いるのはAspect/Jくらいしかなく, 資源アスペクトの 例がそのまま実現されているわけではない. – 特に上流でのアスペクトはまだこれから. • しかし, 必要に応じてマクロ・プロセッサ, コンパイ ラ・コンパイラなどを使った小さなツールを自分で 作って利用することは可能である. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 22 全体のまとめ • 組込みソフトウェア設計作業を「知識変換プロセス」として捉 え直すことによって, さまざまな利点がある. • 特にこのセッションで紹介した以下の技術は, 従来システム中に ばらまかれていた設計知識をうまく集約して形式的に表現し, 知 識としての価値 / 再利用性を高める方法を提供している. – ドメイン・エンジニアリング – モデル駆動開発 – アスペクト • これらは組込みシステム開発においても有効性がある. • ただしこれらの技術が現状ではすぐに開発に応用できるほど成 熟しているわけではないが, 自分なりの方法で応用することは 可能だし, これらの技術が実用になるのはそんなに遠くのことで はない. 第７回組込みシステム開発技術展 専門セミナー ©Metabolics,Ltd.,2004 23
© Copyright 2026 Paperzz
