1
Download 【SysMLへの対応】
Transcript
最近の組込みソフトウェア開発においては、機能 やサービスの多様化により、複雑and/or大規模化し ています。 【SysMLへの対応】 時には矛盾したユーザ要求を正確に把握し、そし てそれをいかに機能に落とし込み、設計に移行する かという上流設計の課題が大きくクローズアップさ 一般社団法人 組込みシステム技術協会 れつつあります。 専務理事 門田 浩 この工程において、定式化に大きな役割を果たす のがモデリング言語であり、テスト、制約条件などを 取り込めるSySMLには大きな期待を抱くものです そう言うわけで・・・まず などと申し上げましたが、私はSysMLどころかUMLで 組込みシステム開発における 設計図を描いたこともない、しろーと SysML そこでちょっと勉強しようかと心にもなく思い立ち、 Amazonをみてみたらぁ・・・・ UML ３４２件ヒット IPA調査を中心に SysML 13件（しかもMBDでもひっかかっかている） UMLはともかく、これはあまり、認知されていないぞ・・・・ 組込みシステム技術とは あらゆる電子機器、装置を 作り上げるための スマートエ ネルギー オートモ ティブ IT(ソフトウェア）と エレクトロニクスによる 「電子ものづくり技術」 モバイル/ クラウド ロボティクス スマートヘ ルスケア スマート アグリ Embedded Technology 3 製品開発費と組込みソフトウェア開発費の推移 組込み製品開発費（1,000億円） 組込みソフトウェア開発費（1,000億円） 製品開発費に占める組込みソフトウェア開発費の割合 100 い つ も の お 話 で す み ま せ ん 60% 50.0% 50% 49.6% 49.0% 80 46.2% 43.6% 42.4% 40.6% 40.4% 40% 36.3% 60 30% 85.9 82.8 40 73.9 70.8 67.5 59.4 57.2 20% 62.2 54.9 42.1 20 20.7 24.1 27.3 32.7 35.1 30.4 26.7 30.3 0 10% 0% 2002会計年度 2003会計年度 2004会計年度 2005会計年度 2006会計年度 2007会計年度 2008会計年度 2009会計年度 2010会計年度 出典：本調査、経済産業省「組込みシステム産業の実態把握調査」 「組込みソフトウェア産業実態調査」、 一般社団法人 日本機械工業連合会（JMF）「機械工業生産額見通し調査」 Copyright © 2012 Information-technology Promotion Agency, Japan. All Rights Reserved. 4 出番となるべき 設計、ものづくりは？ 使用しているプログラミング言語（生成コード行数ベース） 使用しているプログラミング言語（人手） Java 7.4% 使用しているモデルベース言語（自動コード生成） その他 11.4% COBOL その他 アセンブリ言語 6.5% 3.6% Ruby 0.4% 0.5% UML 18.5% コンフィギュレータ系 6.8% SysML 1.7% XML系 8.6% C++/C# 24.3% C 57.4% 連続系 22.5% 画面・HMI作成系 15.5% 形式手法系 0.5% ADL系 0.9% プログラムコード作成方法の推移 0% 10% 20% 30% 40% 50% 60% 70% 80% 状態遷移系 13.7% 90% 100% 人手 自動コード生成 少々意味不明です その他 2010 2011 2012 Copyright © 2012 Information-technology Promotion Agency, Japan. All Rights Reserved. 6 モデルベース開発技術の利用状況 ほとんどのプロジェクトで使用 0% 一部のプロジェクトで使用 10% 20% 30% 40% 試験的に使用した 50% 状態遷移モデル（図/表等） 前頁のとお りほとんど UML UML/SysML 制御モデル 形式的仕様記述 形式検証（含モデル検証） アーキテクチャ記述（ADL等） ユーザモデル/運用モデル 60% 使用していない 70% 80% 未記入 90% 100% ま だ 主 役 で は な い ・ ・ ・ SILS HILS 外界モデル/プラントモデル Copyright © 2012 Information-technology Promotion Agency, Japan. All Rights Reserved. 7 ツールの利用状況（経済産業省2006年版との比較） 複数回答 2012年版 要件・要求管理ツール 2006年版 2006年版データなし 分析・設計支援ツール 数値解析ツール ソースコード解析ツール 自動コード生成ツール モデルベース 言語では？ 2006年版データなし 僅 か に 上 流 ツ ー ル 増 加 の 兆 し ！ 静的コードチェックツール コンパイラ/デバッガ テスト支援ツール 検証ツール（シミュレータ等） 評価ボード インサーキットエミュレータ アナライザ・測定機 統合開発環境 構成管理ツール プロジェクト管理ツール 品質管理ツール ドキュメント管理ツール 0% 10% 20% 30% 40% Copyright © 2012 Information-technology Promotion Agency, Japan. All Rights Reserved. 50% 60% 70% 80% 90% 8 不具合の原因工程/発見工程とレビュー・インスペクションの実施状況 不具合の原因工程/発見工程 不具合原因比率 0% レビュー・インスペクションの実施状況 完全に実施 不具合発見比率 10% 20% 30% 部分的に実施 0% 40% 企画・仕様 企画・仕様 システム設計 システム設計 ソフトウェア設計 ソフトウェア設計 ソフトウェア実装・デバッグ ソフトウェア実装・デバッグ ソフトウェアテスト ソフトウェアテスト システムテスト システムテスト 運用・実機テスト 運用・実機テスト Copyright © 2012 Information-technology Promotion Agency, Japan. All Rights Reserved. 20% 実施していない 40% 60% 未記入 80% 100% 9 製品出荷後に発生した不具合の原因 不具合の原因（製品数ベース） 運用・保守 3.2% 不具合の原因（件数ベース） 取扱説明書・表示等 運用・保守 その他 0.6% 0.9% 4.4% 他製品・他システム との接続 3.3% その他 6.9% 取扱説明書・表示等 4.7% 他製品・他システム との接続 5.7% ソフトウェア 27.7% 操作・使用環境等使 用者 15.6% 操作・使用環境等使 用者 6.1% 製造上 5.5% 製造上 7.4% 製品企画・仕様 4.3% ハードウェア 15.2% 製品企画・仕様 11.0% ソフトウェア 22.9% システム設計 4.8% システム設計 12.0% 仕様、企画で抑えられていない部分は? ひょっとして Copyright © 2012 Information-technology Promotion Agency, Japan. All Rights Reserved. ハードウェア 37.8% 要求仕様に原因が・・・ 10 要求とSysML JASAの安全性向上委員会では 要求を定める（仕様化）プロセスで UML/SysMLに着目 その前に 一般社団法人 組込みシステム技術協会(JASA) のご紹介 JASAとは 1986年 日本システムハウス協会として設立 ・ ・ ・ マイコン応用SI事業者、ツール業者で構成 所轄官庁 経産省情報処理振興課 企業分類コード ３９１２ 業界の性格 ・ 経産省が強化推進をはかる組込みシステム技術を代表する業界 団体 活動目的 ・ 組込みシステム技術に関する普及、啓蒙、教育・資格認定など 様々な事業を展開し、会員・業界の便を図るのみならず、地域振 興等、広く公益に資すること 現状 ・ ・ ・ 正会員 185社 賛助会員 36社 （H25年3月末現在） 会長 簗田 稔 （コア社長） 主な事業 ET展示会、ETEC試験、ETロボコン、技術委員会活動、 国際化推進事業など JASAの活動 世界にはばたく 技術者育成と 産業、ひいては 国力の強化 展示会、国内・海 外協業等 ビジネス マッチング 技術力 向上 各種 委員会活動 人材 育成 ETロボコン、技術 者試験、セミナー 等 JASA組織図 総 会 監 事 顧 問 理 事 会 会 長 副 会 長 専 務 理 事 事務局 事業推進本部 ＥＴ事業本 部 支部統括本部 近 畿 支 部 北 陸 支 部 中 部 支 部 東 京 支 部 東 北 支 部 ET-WEST 九 州 支 部 北 海 道 支 部 実 行 委 員 会 Ｅ Ｔ 実 行 委 員 会 技術本部 ハ ー ド ウ ェ ア 研 究 会 応 用 技 術 調 査 委 員 会 技 術 高 度 化 委 員 会 運営本部 教育事業本部 安 全 性 向 上 委 員 会 研 修 委 員 会 Ｅ Ｔ Ｅ Ｃ 企 画 委 員 会 Ｅ Ｔ ロ ボ コ ン 実 行 委 員 会 15 協 業 推 進 委 員 会 国 際 委 員 会 広 報 委 員 会 総 務 委 員 会 技術委員会活動 委員会 活動テーマ 委員長 顧問 活動地域 安全性向上 SSQ 漆原（JFP） 兼本（会津大） 東京 アジャイル アジャイル適用 ガイドライン 全員制 なし 名古屋 実装品質 開発プロセス 秋保（アルパイ ン） 野中（東洋大） 東京 状態遷移設計 SPLE、状態遷 移設計 竹田（CATS） 中西（九州大） 東京 モデルベース設 計・検証 普及・啓蒙 福田（九州大） 久住（九州大） 福岡 プラットフォーム ロボット技術標 準化 中村（アップウ インドウ） 武居（首都大） 東京 ハードウェア 次世代組込み 技術 小西（ソーワ） 坂巻（都立産技 研） 東京 技術セミナー セミナー開催 冨岡（ユークェ スト） なし 東京 安全性向上委員会の紹介 17 要求の仕様化に関する活動計画 目標とする成果物 ・ 要求の仕様化に関する要求事項や課題 ・ 要求の仕様化を支援するプロセスと手法やツール ・ 各層における発注・受託関係者に役立つ報告書 活動方法 ・ 機能安全や情報セキュリティ関連の規格を対象として、 要求事項を洗い出す。 ・ REBOKや要求工学などの専門書を調べて、要求の仕 様化のプロセスと課題を整理する。 ・ モデルベース開発で使われている手法やツールを調べ る。 ・ 実際に使われている形式手法とそのツールを調べる。 ・ JASA会員を対象としてアンケートを取り、プロセス、手 法やツール、課題に関する実態を調査する。 18 問題(要求）はつかみがたい • 問題は定義自体が難しい 問題は状況により様々に変化していく 問題は視点により変わる 問題は自分の思い込みでも起こる 問題は他者自身の問題である • D.ゴース/G.ワインバーグ共著 – ワインバーグ は作家、心理学教師、そして ソフトウェア開発の人類学者。彼の有名な 著作、『プログラミングの心理学』、『一般シ ステム思考入門』の二冊は、情報科学分 野の古典となっている。 ワインバーグの著 作は、人を魅了する文体とユーモアにあふ れた警句で知られている。 1997年6月に、 エドワード・ヨードン、チャールズ・バベッジ、 シーモア・クレイ 、ジェームス・マーティン 、 グレース・ホッパー、そしてビル・ゲイツとと もにコンピューター殿堂入りした 要求の仕様化における課題を図式すると この表現だと、幾つかの解 釈が出来るんだけど・・・。 言ったことがうまく伝わって ないなぁ。 要求 そんな事、確認しなくていい よ、常識で判断して。 発注者 不明点は確認すべきか、手 を煩わせない為に、解釈す べきか？ 受注者 意図が分かれば、仕様化 しやすいんだけど・・・。 ここは、逆に聞いて欲しかっ た。 分厚い仕様書貰っても、隅 々まで確認できないよ。 動くモノが出来てから、再検 討しよう。 要求仕様 仕様書作っても、全部は読 んでもらえないだろうなぁ・・ ・。 何をすればこれらの課題の幾 つかを解決することが出来るか ？ あれ？似たようなことを幾 つか書いてしまったけど、 矛盾してないかな？ 安全性向上委員会の活動テーマ 2012年度から 情報セキュリティ 機能安全 SSQ (セキュリティ、 セーフティ 品質) 最初の活動 セキュリティも安全も、意図したものが 実現できる要求定義ができなくては、、、 要求の仕様化 21 例：ISO 26262: 安全要求の定義と管理 対象分野 要求事項 表記法 特徴の実現のため、自然言語と別表の手法を組み合わせる 特徴 曖昧さを避けるため、安全要求は分離されている 安全要求は、曖昧でなく、理解しやすく、不可分で、矛盾せず、実現可 能で、検証可能である(要求の特性) 属性 識別番号、状態、ASIL 管理 安全要求は階層構造をとり、組織的に体系づけられ、完全性を持ち、 外部一貫性を保ち、重複なく、保守容易である 安全要求は上下方向に追跡可能であり、設計、検証とも追跡可能 別表の手法を組み合わせて検証する 安全要求は構成管理に従う 表記法 ASIL-B ASIL-C ASIL-D 形式的でない表記法 HR R R 半形式手法 R HR HR 形式手法 R R R © Japan Embedded Systems Technology Association 2012 半形式手法 英語表記 Semi-formal methods 手法分類 欠陥撲滅 ○ 障害検出 適用工程 分析 ○ 設計 目的 設計が仕様を満たしていることを証明するため 概要 仕様定義、設計又はコーディングの段階におけるシステムを記述す るための手段を提供する。システムの振舞いが見えるように図示で きる。 備考欄に列記するいくつかの手法が該当する。 備考 論理/機能ブロック図 シーケンス図、メッセージシーケンス図表 データフロー図 有限状態機械/状態遷移図 時間ペトリネット 決定/真値表 UML 参考資料 IEC 61508-3-ed2、表B.7 障害回復 ○ 検証 © Japan Embedded Systems Technology Association 2012 危害抑制 ○ テスト 形式手法:適用プロセスと目的 目的 仕様記述 コード生成 VDM Event-B Z B SCADE 特性検証 バグ検出 プロセス 要求分析 設計 SPIN LTSA UPPAAL 実装 テスト ESC/Java2 Spec# VARVEL 注1 注1 注1:テストケース生成。 © Japan Embedded Systems Technology Association 2012 使用したプロセスと手法 プロセス 要求を分析し、 仕様化するために システム要求設計プロセス 手法 要求を整理し、 構造と動作を記述 するために 要素要求に分解 するために 動作仕様を記述 するために 要求仕様に対する ハザード分析に SysML SLP VDM HAZOP 備考: システム要求設計プロセスはレンタコーチ社が推進する開発技法の一部。 SLPはジェーエフピー社が販売している要求仕様記述ツール。 25 システム要求設計の作業概要（案） 手順 要求分析 アーキテク チャ設計 制約評価 要求割当て 作業項目 表記法の例 SysML 要求を獲得する ○ システムとその境界を決める ○ システムの使われ方(機能)を定める ○ ユースケースの動作を表現する ○ システムを構成要素に分解する ○ 部品の相互作用を定義する ○ 部品の相互接続を定義する ○ システム特性に関する制約を獲得する ○ 性能等を評価し、アーキテクチャを修正 ○ 構成要素の要求仕様を定める ○ 要求の追跡性を確立する ○ VDM SLP ○ ○ 26 © Japan Embedded Systems Technology Association 2012 要求の仕様化プロセスと基本スキル 手 順 作業項目 発注者 表記法とスキル 受託者 1 要求を記述 2 要求分析 3 仕様書作成 4 仕様を確認 自然言語 非形式 手法 W W R＆W R 半形式 手法 形式 手法 W W W W W R R R 5 要求仕様を合意 スキルの表記は、W: 書く能力、R: 読む能力！！！ © Japan Embedded Systems Technology Association 2012 技術ドキュメント能力の向上は基本スキル 国語力の修得 文法が間違っている 未言語 単語が間違っている 分野知識の獲得 曖昧で正確に理解できない 論理的な思考 形式的記述手法 未文書 必要なことが記述されていない 記述項目の定義 アシュアランスケース 内容をすぐに理解できない 必要な情報がすぐに見つからない 分かり易く効率的に読める 利用者・利用シー ンの明確化 未技術文書 文書構造の設計 理想的な技術文書 利用品質 情報アーキテクチャと トレーサビリティ 品質メトリックス Copyright © 2011 ＩＰＡ, All Rights Reserved 28 最後に • 要求は実は最後まで決まらない • なぜなら要求する側も最終形がわからない • 開発側の立場では、できるだけ証拠を残すだけ でなく、要求のリファインをする必要がある • 技法は様々だができるだけ標準を使いたい • 最後はリファインの結果を要求側に説得し確認 合意してもらわなければならない • その間、整理整頓には技法とツールは不可欠 • なんと最後の最後は、やはり技術者の基本的な 能力、読み書き抽象化能力に依存する。
