SWEST6 セッションSD-7 議事録 構造(アーキテクチャって何だろ?) 2004年7月23日 進行 川口 パネラ 杉浦(富士ゼロックス) 橋本(ソニー) 赤星(ロジックリサーチ) 奥村(ナレッジ・エッジ) 参加人数 10名弱 主旨 構造という言葉の意味がまちまちであるので,この言葉を整理する.「構造」という言葉をどのように使っているか 議論前提1 構造は対象をモデル化したもの 構造とアーキテクチャは動議 今回,対象は組み込みシステムに限定する システム,ハード,ソフト含む 前提2 利害関係者 ユーザ:対象を使用する人 発注者:対象の開発を発注する 開発者:対象を開発する 議論のゴール 構造のうれしさを整理する ユーザにとってのうれしさ 発注者にとってのうれしさ 開発者にとってのうれしさ 議論の流れ モデル化に関する議論 構造の利用に関する議論 5W1Hで整理 よい構造,悪い構造とは まとめ 自己紹介とポジショントーク <赤星> ハードウェアの設計をしている ADCで動作合成ツールを作っていた.現職はSOCおよびハードウェア設計. *PowerMacG4を例にアーキテクチャとは何かを考える. アーキテクチャとはパフォーマンスを重視するためにあるのか?という感想を得た *SOCアーキテクチャ CPU,DSP,メモリ,バス,などが集まったものをアーキテクチャ 使用するCPUが決まると制約が出てきていろいろ決まる *カスタムハードウェアアーキテクチャ *アーキテクチャ設計作業 機能を実現+非機能要求をどれだけ満足するかの評価を行う 非機能要求をバランスよく満足する <奥村> 上流設計をしているので,その視点からアーキテクチャを見る. 顧客の仕事を整理することが私の仕事である.アーキテクチャ的視点でその顧客が何をしているかを確認する. <杉浦> *アーキテクチャへの疑念 T−Engineの100年ソフトというのはよいアーキテクチャなんだろうか? コンピュータを使った産業自体の歴史が100年にも満たないのに100年ソフトができる理由は? 100年間の技術の進歩や発展を今から予測できるのか? アーキテクチャは,たとえ制御対象が同じでも寿命があるといわれているが,本当なのか? 採用技術の変化に伴う仕様や要求の変に伴い,アーキテクチャを無視した実装が行われる傾向がある アーキテクチャを無視する傾向があるということは,アーキテクチャ自身に問題があるといえる ハードウェアを含めたシステムアーキテクチャは, 技術の進化に柔軟に対応できる仕組みを持つべきである アーキテクチャーを構成する要素に変更があった場合にそのよう齟齬と似交換可能な仕組みを持つべきである アーキテクチャ自身の問題を解決できる仕組みを持つべきである 前提:技術の進化・進歩においては突拍子のないことが起こる <橋本> アーキテクチャの評価と戦略的構築・利用 *アーキテクチャの評価とは アーキテクチャの評価は,「ビジネス・シーン」により決定される アーキテクチャ評価は,アーキテクチャ単独で評価しても意味がない・できない アーキテクチャ評価は,要求仕様,技術的制約などで大きく影響を受ける 学術的な一般論やアーキテクチャ・パターンはガイドにすぎない *アーキテクチャに期待されること 一般に 保守性,可読性,拡張性,開発の優しさ,など. *アーキテクチャに影響を与える要素 経営目標 製品の売り上げ目標 製品のシェア拡大 製品の選択と集中 製品の今後のロードマップ 経営的なアーキテクチャへのニーズ 生産性の向上 品質の向上 再利用への期待 *アーキテクチャの表現 コラボレーション図 シーケンス図 状態図 コンポーネント図 パッケージ図 クラス図 ソフトウェアは動的に動くものを静的に表現しなければならない *アーキテクチャの再利用 製品の進化に伴い,アーキテクチャも改良が可能 商品のスコープにあわせて選択 優れたアーキテクチャを複数のプロダクトに採用 生産性の向上 品質の向上 開発者の不足の軽減 *組織戦略におけるアーキテクチャへの取り組み SEIのプロダクトラインに代表される戦略 製品を分析することでどういうものが自分のアーキテクチャとして必要かが見えてくる *プロダクトラインの導入と効果 アーキテクチャのメリットはたくさんある よいアーキテクチャができても再利用されなければ意味がない. 奥村・橋本 組織やビジネス寄り 杉浦・赤星 ものづくり寄り *モデル化に関する議論 1.アーキテクチャがモデル化するものは何か? 奥村:これから作りたいものである.システムにやらせたいこと. 赤星:ハードウェアの場合は,機能を持ったモジュールに分けてそれらをつなぐ. 橋本:モデル化するとは複雑なものを抽象化すること.可視化すること. 杉浦:単純にモデル化というだけでは意味が広すぎる.ハードとソフトに分けて考えるべきではないか? 結論 箱と箱の関係をモデル化する レベルがある 要求 ハード ソフト 2.モデル化するメリット・デメリット -メリット 橋本:複雑なものを抽象化できること.可視化できること.モデルをどのように表現したいかを知っていれば,デメリットはない 奥村:数えられることー>表にできる,全体が見渡せる 情報を整理できること 杉浦:情報を共有できる -デメリット 奥村:モデルは所詮絵に描いた餅である. 3.アーキテクチャの利用 5W1Hによる分析 WHAT:構造の何を利用するのか 発注者 箱の開発規模 箱と箱の接続の難しさ,開発難易度 箱の切り方でおよそ判別できる 開発者 ホットスポット,フローズンスポット 可変性や拡張性を求められる場所を知るため 余分な可変性はいらない 可変清雅な久手港即処理,性能要求 ユーザ WHEN:いつ利用するのか? 発注者 開発者 プロセス最適化の時 ユーザ WHY 発注者 再利用の効果がどこに出るのかを知りたい 拡張できるところを知りたい 精度の高い計画が立てられる 開発者 精度の高い計画が立てられる ユーザ 相互運用性 構造を寝ることによって商品性があがる 一般のユーザはソフトウェアにあまり興味がない 質疑応答 Q.要求を決める人(発注者)よりも,アーキテクチャを知っている人の方が,よく要求を理解しているのでは? A.アーキテクチャにノウハウが蓄積されているのだと思う. HOW 発注者 開発者のドメイン構造知識から,必要工数を見積もる 開発者 ドメインの構造知識からリバースして要求を抽出できる エンジニアといえども市場でどう使われていくかを知らなければならない 人と人の信頼関係が重要.構造として現れるが,スキルとしては現れない. 古参が作る構造と新参が作る構造は全く違う. 特に冗長性や洗練度 Q.よいアーキテクチャ,悪いアーキテクチャについて聞きたい A.杉浦:非機能要求や品質が反映されていることがよいこと 奥村:様式美がある.動きがわかるものがよいアーキテクチャである 赤星: 何らかの利益を供与するのがよい 楽しくなる方がよい 理解しやすい方がよい 無駄がない方がよい 誰にでも受け入れられるのがよい よいアーキテクチャ:利用者に利益を与える ユーザ,発注者,開発者の信頼関係を築く.