組込み向けオブジェクト指向分析方法論 Octopus概説 ========== 会場の様子 ========== E会場にて。8x3x各席3名ずつくらい。どちらかというと若手〜中堅クラスの方が多い。 見た目ではほとんどSWEST参加者のようである。 ==== 導入 ==== ・簡単な自己紹介 ソフトにかかわって15年。もともとはOA機器メーカ。再利用を前提とした開発スタ  イルを世に広めたいと考えている。 ======== 話す内容 ======== ・現状の問題 ・オブジェクト指向の歴史 ・Octopusの概観 ・並行性の検討は いつ行なうのか ・オブジェクト指向と組込みシステムの将来 ========== 現状の問題 ========== 危機1:プラットフォームの多様化 ソフトを実行するハードやソフトの種類の増大 -> HW : メインフレーム、オフコン、PC、STB、携帯など -> OS : Win, UNIX, ITRON, Palmなど 必要とされているソフトの数、技術の数も増大 それらを適切に組み合わせるSIが要求されている 危機2:製品やSIの短期化 開発サイクルバージョンアップの短期化 ユーザーニーズの多様化 -> 迅速なマーケット対応 -> さらに短期化への圧力が 危機3: ネットワーク分散とEAI InternelとWebの大々的な普及 EAI (Enterprise App. Integration) 複数システムの連携 -> 自分の作っているものは小さいが、様々なものと連携して大きなもの        になる オブジェクト指向によるラッピング 危機4:インターネットがインフラ化 一般エンドユーザを含むe-Bussiness 情報交換のコストの低下と開発の国際化 国境をまたぐ分散開発 ソフトウェア危機を乗り切るには 要求の把握と明確化 段階的仕様追加に柔軟な開発体制であること -> ライバルを出し抜くための機能追加などがいきなり起る 規模や工数の正確な見積り -> 定量化したデータが必要 システム保守への柔軟な対応 信頼性の高いシステムを短期で製作 リスクの早期発見と回避 -> 新規技術の応用などで回避 インタフェース重視の設計 -> 部品の再利用性を高め、並行性を高める -> ほとんどがマネージメントと設計部分 -> これをオブジェクト指向で補う ========================== オブジェクト指向への道のり ========================== 機械の動作から人間の指向により近づいていく道程 -> より高いレベルでの抽象化を行なう 機械語 -> アセンブラ -> Fortran, COBOL -> C -> Ada, Modula-2 -> C++, Java -> ... 手続き型 構造化 モジュール指向 オブジェクト指向 第1期 :より速く,より小さく 背景 計算速度が遅い, メモリが高い 個人の職人芸によるアセンブラ記述。とにかく速く効率的。ただし他人が理解できない。 第2期 : 手続き抽象・構造化へ 背景 開発保守効率の向上(ライブラリ化), プログラマの大衆化, スタイルの統一 構造化や手続き抽象による高級言語による記述。小さい単位で再利用性の仕組みがあ   り、構造が明確。 構造化の限界 手続きを越えた部分での再利用性がない 構造の記述とやりたいことの関連付けるのが難しい -> 保守や拡張がやりにくい データ共通化やドメインの知識を共有化するまでの再利用は不可能 第3期 : オブジェクトへ 背景 大規模化、複雑化。ネットワーク分散や協調。潤沢で高速なリソース。 オブジェクト指向を用いた言語で記述。 組込み向けオブジェクト指向方法論 ・shlaer-meller法 モデルからソースを生成することを考慮 オブジェクトもデルにメソッド定義を行なわないモデル 有限状態マシンを利用 -> 非常に強力であるが、分析工程が長く、なれていないと非常に難しい ・Octopus ハードウェア依存部をラップするコンポーネント定義が特徴 イベント分析を行なうことでリアルタイム設計を強化 コラボレーション図を利用した並行設計に特徴がある 具体的な表記の例 : http://www.nrc.nokia.com/octopus/ +-- 具体的な表記例に対する質問 |Q: この表記のどこがリアルタイムか |A: 待ち時間があるなどの時間的な表記を行なえる点 +-- ・COMET H.Gommaが提唱したリアルタイムシステムを開発するための方法論 分析もデルから設計もデルへのマッピングを詳細に示している 有限状態マシン・コンラレンシタスク・情報隠蔽をキーに設計モデルを構築 ・ROPES 表記法はUML準拠でリアルタイム用に拡張したものがある(Realtime-UML) 開発フェーズを分離し、反復する (分析->設計->変換->テスト)。 ・ROOM     カプセルと言う概念が特徴。 強化ポイント ・ステートチャート強化 ・分析と設計が異なる +-- |Q: Realtime-UMLはどれになるのか |A: 一応ROPESになる。方法論と表記法は別物であり、UML自体は表記法なので | どれでもいい。現に対応が進んでいる。 +-- ============= Octopusの概観 ============= 要求分析 特徴 : コンテキストダイアグラム 開発対象とその外界に存在するシステムとの関係を示す (何を作ってそれは何からどんな操作・影響を受けるのかを明確化する) 機能要求はユースケースモデルで表現 システムの振る舞いを,ユースケースと外部アクターとの相互作用を中心に表現し  たモデル エンドユーザやドメインの専門家とのコミュニケーションツールとしても活用できる 機能要求と非機能要求 機能要求 : ユーザから見えるサービス 何をするかなど 非機能要求 : システム化に対する機能要求 制約条件など -> 組み込みの場合はこれがほとんど ============ システム分析 ============ イベント分析 対象システムと関係するイベント分析を行なう イベント発見、グループ分け、イベントの記述 システム分析時ではイベントの発見分類整理を行なう。設計時にモデルを活用     する。 ハードウェアを制御する部分は一つのコンポーネントとしてラッピング -> ハードウェアに対する柔軟性を確保 ============ システム設計 ============ タスク設計 (オブジェクトグループ分け) イベント分析された非同期イベントに着目して分割 (レベル0) #並行動作するオブジェクトグループの発見 -> それぞれを論理的なタスクに -> 論理から物理へ UMLではアクティブクラスを利用 #アクティブクラスとパッシブクラスを用いて、クラス図やコラボレーション図で表現 ======================== ハードウェアのラッピング ======================== 視点 ドメインモデルとハードウェア制御を分離 -> ハードの変更に対してドメインモデルが影響を受けなくする ありがちな問題 ドメインクラスが直接ハードウェア制御クラスを利用する 「エアコンをスタートすると、フラップ位置の制御をしてから開始する」と思った  らフラップの仕様に変更があり、 「エアコンをスタートすると、フラック状態を確認してから制御、開始する」とな  ったら... -> エアコンをスタートするという本質は変わらないのに、ドメイン側のアク  ティビティを変更しないとならない。 -> ドメイン側の変更は、新しいバグを生み出しかねない危険性を持っている ラッパークラス導入のまとめ ハードウェアの仕様確定まで時間がかかるので、 ドメインモデルとハードウェアを分離して、依存を疎にする Octopusではシステム設計 組込み向けオブジェクト指向方法論は、システム設計時に並行性を検討している 実際の開発時ではいつ決めているのか... ? -> 検討していない、経験的手法、並行動作が前提なので並行動作単位が開発対象... ? 並行性の欠陥は組込みシステムにおいては重大な欠陥 -> 一体誰が責任を取るのか?(アーキテクト?, 現場?) 誰が担当なのか? +--- 議論 : 並行性を何時決めるのか | 意見提供 「メッセージの非同期性を持って並行動作単位を調べる」 | -> 設計時に決めている | 意見提供 「アーキテクチャを決める段階で決定。変更に対する柔軟性を確保しつつ、 |      eUMLと従来の手法で対処。クリティカルな点をシーケンス図などで明確化」 | -> 設計時に決めている +--- -> アーキテクチャの作成時がきめ時。経験的な手法で行なうことは少ない。 +--- 質問 | Q: アーキテクチャとは ここでは何を指すのか | 全体を把握するためにここの機能を明確し、それぞれの関連性・類似性を定義したもの。 +--- ====================================== オブジェクト指向と組込みシステムの将来 ====================================== オブジェクト指向は組込みシステム向きであるのか? 向いている 高い再利用性、システム分割の容易さ クラスが責務ベースで構成されるので、ファームソフト開発技術者にも理解しやすい 向いていない 制御がメイン (制御は動作がメインであるので、対象オブジェクトが抽出しづらい) #組込みの分野だけ、方法論が乱発している。 # -> 考え方としては有効だという認識 なぜ普及しない? (教育面) 忙しすぎて勉強できない すぐに使えない 緊急性の高い技術を受講しないといけない (実装方法など) なぜ普及しない? (実装面) サイズが大きい (ROM/RAM) -> C言語でも実装できる フラグメンテーションの少ない管理方法の導入 経験上 C++でもROM使用量は縮小(7割程度)、RAM使用量は2.5倍に増大 性能が低くなってしまう -> 複雑なロジックを排除できるので、逆に高速化できる インスタンス生成・消滅の方法を工夫すればそれほど問題ではない 性能要求が厳しい点ではOOP以外を活用 (割込み処理など) なぜ普及しない? (運用面) オブジェクト指向開発が現状の開発プロセスとマッチしない -> 全てをやる必要はない 対象となる点では開発プロセスを見直す必要がある 進捗管理が行いにくい -> 工程毎で出る成果物が明確なので 把握はしやすいはず 上流工程はレビューで品質を確認することで、実装・テストが遅れても      カバーできる ====== 最後に ====== 組込みシステムでオブジェクト指向を適用する場合は、その「目的」を明確にすべき 生産性の向上に繋がる場があれば使うべき -> フレームワーク技術を使うことで、より再利用性を向上可能 方法論としては組込み向けが多いので、その中から選択すればよい ======== 質疑応答 ======== Q: 「分析」を要求分析とただの分析に分けた理由 A: 要求分析は特に重要なので分けただけ Q: 要求分析の中で性能要求以外に含まれるものはあるのか A: セキュリティに関してはグレー。 Q: ラッパーを導入するかどうかを決める際、リアルタイム制約やリソース制約 によって変わるが、その基準はどこにあるか A: 最初はターゲットがどの程度変化するかによる。余りにも制約が明確ならドメイン  に入れる。 Q: Octopus導入の具体的な使用例 開発の効率化の具体例 A: 開発効率は20%向上。オブジェクト指向を導入した直後は1.7倍に増大。その 次の開発は60%まで減少 (目標は半分)。事例は詳しくは知らない。 コメント - オブジェクト指向とオブジェクト指向方法論がごっちゃになっているが...? - 今回の指摘では、オブジェクト指向論は敷居が高いと感じるのでは...? - 過去にオブジェクト指向方法論は失敗を繰り返しているという事実を軽く見ている。 - 組込み向けという割にはリアルタイム制約などの話が出てこないのはおかしい。 Q: 実際に組込みシステムでは、クラス分析ではなくオブジェクトベースの設計になるのか? A: クラスとインスタンスの両方を考慮しなければいけないが、今回は割愛した。 基本的にはオブジェクトベースの設計になる。 Q: 新しいものを始めて設計するとHW/SWの境界が不明瞭であるので、この切り分 けにオブジェクト指向を導入したいが、このラッパー部が浮動するような設 計テクニックや知識などはあるのか A: これまで考えたことがないのでわからない -> Q: ソフトウェア側にとってこれは間違えたアプローチなのか A: 考え自体は正しい。コデザインを扱うための方法として興味がある。 ==== 感想 ==== チュートリアルの内容は、Octopusの話を踏まえつつ、組込みシステム向けオブ ジェクト指向設計の全般に渡る話であった。また聴衆の興味は、自らがかかわる 設計にどの程度本手法が適用できるのかなどに向けられていた。質疑応答では、 オブジェクト指向に関連した専門的な話で占められていた。チュートリアルの割 には意見交換も多く行われていたのも特徴的だった。今回はDAシンポジウムと合 同であったが、聴衆のほとんどはSWEST側に参加されている方で占められており、 ソフトウェアに関する知識ベースを持った方が多かったことが原因であると推測 できる。