************************************************************************* セッションS チュートリアル テーマ：Ｃ言語だけでの開発の現状を打破しよう -プロトタイピング−リファインメント−Ｃ言語実装のアイテレーションが 開発の本来あるべき姿,との立場で提起します- 講師：鈴村延保さん(アイシン・コムクルーズ) 日時：2014/8/29 参加人数：38名(終了時)　 ************************************************************************* 最初に日頃の考え方を変えてみましょう -ボトムアップ 疑って疑って,それを納得して積み上げていく -トップダウン 肯定から始める→どんどん取り入れていける 速読のイメージでよい ただ吸収する情報をタグ付けして整理していくべき 自分がどちらの考え方か分かりますか. ・自己紹介 　機能安全に取り組み 　製品開発 　経産省の海外の自動車の動向を調査 　今年４月までアイシン精機におり30年近く働いてきました. 　ハード・ソフト・コンピュータ好き 　もう一つの側面として考え方はあまのじゃく ・時代の見方 　10年ごとにのパラダイムシフト 　今はH&H＆H(heterogeneous&hybrid&hierarchy)の特徴の時台 　では何に取り組む？→3つある. 　E,I,Pが大事で,その３つが重なり合ってきている. 　⇒詳しい資料に関しては連絡すれば提供 ・弘法大師式プログラミング技法 　それは声を出そう,体を動かせ,心で念じろ,ということ 　このセッションでは声を出そうということで質問をどんどんしてください 　 ・本題に戻りますと 　C言語で開発されているわけですが 　組込みアプリケーションは大規模になりすぎた 　→次世代プログラミングに移行すべき 　モデルベースもプログラミングです 　モデルベースにシフトしていることもその移行といえる ・C言語開発ではなにが足りないのか 　そこでMDD＆MBDではなにができるのか整理していく 　足りないことを認めつつどうしていくべきか考えていく ・プロトタイピングからリファイメント(形式手法の世界の言い方で少し拡大 解釈した表現)でC言語で実装していく 　　・アイテレーションが必要 　　　(アジャイル,リーンプログラミング,トヨタ式開発手法) 　　 ・進め方 ①イントロ—共通認識を整理 ②C言語の欠点を把握 ③apple swiftからC言語に足りないものを見つめる ④パラダイムシフト ⑤MBD&MDDとはなんなのか　 ⑥じゃあ明日からはどうすべき ・開発がどんどん非会話的に 　プログラムもデータもどんどん大きくなってきている 　そのプログラムを動かすのが難しい,その場その場で確認がやりづらい状況 　　プログラムの結合が必要だったり,テストを作る必要がある ・プロトタイピング−リファインメント−Ｃ言語実装のアイテレーション 　どこでどういう意味がまとめていきましょう ・コンパイラとIDE 　かつてTurbo-C１パスコンパイラと 　スクリーンエデイタの統合環境(IDE)の発明が隠れた革新だった. 　昔はテキストエディタでIDEは発明だったがいまでは当たり前になっている 　IDEは死語にさえなっている ・組込みシステムの大規模化 　携帯は6年で10倍に 　BMW/SMシリーズに関してEUプロジェクトでまとめられている 　自動車60年代～80年代今に至り昔はメカトロもサチュレーション 　現在はソフトウェアの時代に 　実際SAEもクルマは全体で１億行以上といっている ・プロトタイピング・リファイメント・C言語実装を表でまとめました. 　(多少,車を意識した説明になっています) 　開発初期→開発途中→製品化を意識した最終段階という流れ 　・必要なキーワード 　　とにかくはやく開発・フィードバックがある 　　Visual化 　　高品質・高信頼なものに作りこんでいく 　　⇒ほんとにC言語だけでOKなのか(C言語とその環境ですべてまかなえるか) ・C言語の欠点と解決策を考える 　キーワードはフルスタック 　C言語の弱さはMISRA-C指摘にすでに出ているが,それだけでは不十分 ・開発に各種支援ツールが補完されていて,もちろん昔のC言語 　だけのままでは無い,ことは承知だが,それでも時代遅れになっていないか？ ・オブジェクト指向の欠点と対応の方向. ・C言語開発の現状を補完するには,あしたからまずどうする？ほんとに正しいのか 　オブジェクト指向の欠点と対応 ・フルスタックプログラミング言語 　ソフトシステム構築⇒階層化が必要 　ハードウェア・プラットフォーム・ミドルウェア・アプリケーション (さらに階層化) 　アプリケーションのコンポーネントなどもある 　階層化ともスタックとも呼ぶ 　REDというプログラム言語があり,フルスタック対応 ・各言語のレイヤ説明 　アセンブラ・Cに対してruby pythonはもっと上の領域を記述できるよね 　上流はC言語では厳しい 　３０年前の仕様書との比較すると現在の仕様書とおおきく違う 　どういう状況？ 　⇒ソフトウェアどんどんおおきくなってる 　⇒日本語の仕様書とC言語の間のギャップ拡大 ・C言語の長所と短所(C言語の欠点が非常に多い) 　コントロールフロー表現は得意 -データフロー表現は苦手 -部品化が苦手 -階層化が苦手 -アーキテクチャ表現が苦手 -会話型開発,プロトタイピングが苦手 -抽象化記述が苦手. -データの状態属性が苦手(nil概念(Liveness),mutable,参照透過性) 　⇒日本語の仕様書とC言語の間を埋めるためにいろんな手法がある 　　形式手法やMBD,ADLなど ・C言語部品化が苦手に関して整理 　関数で部品化できていると思いがちだが制御フローを示すためであり 　関数は部品をつくるためではない. 　制御構造のライブラリ化は可能だがソフトウェアの部品化はできない. ・データフローどう表現するの？ 　例：3入力2出力のコンポーネント 　3入力は引数でできるけど,出力が困る 　return x, yできない 　global変数 ,struct使わないといけない　 　そうするとglobal変数をだれが管理するのか問題になる ・最近の言語はできる！じゃあどうする？ 　C言語は明日からどうすべきか. 　C言語は機能の低い,危険な言語です.機能安全の認識) 　スタイルガイドとガイドチエッカーを利用しましょう(機能安全の認識) 　静的解析ツールを利用しましょう(型整合を含む) 　設計にはモデリングを併用しましょう(機能安全の認識) 　欠点あることを認識したうえで従来のモデリング(例UML)を併用しても, 見える化は,十分ではありません. 　(UMLは2.0以上またはSysMLを利用しましょう) ・ツールで補完しましょう 　上記style_guide,static_analysisを含む 　部品化をグローバル変数で支援するツールがあります(Matlab/Simulink, Autosar周辺) 　アーキテクチャADLを意識した見える化ツールを利用しましょう. - 　広義の階層化,依存関係の見える補完手段など,UMLでは不十分で,さらに改良 (イノベーション)が重要です. -DSM手法は新しいモデリング提案ともいえます.利用しましょう.(matrix, 表表現は欧米ではモデリングと言いませんが) -プロダクトラインではフィーチャー図がある(未だＵＭＬ標準化されていませんが, 欧州提案EAST-ADLでは標準提案されています) 　UMLを使っても足りない階層化の図に関してはUMLに入っていないEAST− ADLのフィーチャー図を使ったほうがよい 　UMLに今後フィーチャー図が入ってくると思われる ・DSM手法 　階層を縦と横に並べる 　表によってきれいな階層化を明らかにできる 　→アーキテクチャの見える化 　→階層を壊してる開発者が誰かすぐわかる 　理想論になおせ→すぐにはできない 　基準となる線を作っていけばよい 　そういったツールを使っていくことでC言語の欠点をフォローしていく.　 ・番外編 　状態遷移図が完全でもユーザ目線で漏れがある 　状態遷移表で完全であっても,安全分析をすると, 　システム目線では漏れがあります.だれかが安全分析をやらないといけない 　誰がやるか決めておかないとだれもやらない 　これらはＣ言語開発の課題ではありませんが,カスタマー目線の基本課題 ○質疑応答①------------ ＜質問者１＞ DSMにおけるマトリックモジュールはどういう単位か <回答> 基本的にはファイル・関数・ディレクトリ ＜質問者１＞ ユーザ目線・システム目線とはどういう意味？ ＜回答＞ 商品は最後に使うお客さんからクレームがくる.そういう商品は不完全な商品. そうならないように商品としての要求仕様書だったり設計仕様書を誰かが書く必要がある. 以上のことをユーザ目線と表現している. システム目線とはどこかで問題あるときに何か対策しておきなさいということ 機能安全で安全分析という言葉が出てきたが, CMM,SPICEのプロセス定義には安全分析について定義されていない(安全分析以降の話) ------------ ・なにが重要か 　C,C++を見ても分からないので複数の言語比較 　Rust, Rubyを意識している,その本質は？ -REPLとPlaygroundsという言葉を使っている,appleではこういった表現をしている -RuPyデイレクションがサイレントパラダイムシフトの方向 ・swift言語とはappleで開発された言語. 　開発者はChris Lattner(LLVMの中心的開発者ですごい人) 　作者のブログみたらわかる 　From his Blog -the experiences from Rust, Haskell, 　Ruby, Python, C#, CLU -PlaygroundsとREPLを取り入れる情熱を持っていることが記載されている. ・REPL(Read Eval Print Loop) 　REPLとは,コマンドラインからコマンド(プログラミングの命令)を入力して, その場でインタープリターが解釈して実行してくれるもの. 　ちょっとしたプログラムを試したい時に重宝する.(LISP由来の環境) ・Playgrounds (道場) 　会話的に動作を確認する環境. 　Control-Flow Debug とData-Flow Debug 両方が便利 ・通常のデバッガ 　自動車の世界labmonitor 　結局両方いるがplaygroundは両方できる. 　C,C++,Javaは軒並み× ・REPL and Playgroundsはプロトタイピングのための環境 ・今度はMATLAB/UMLと比較 　結局MATLABは使われているのは会話型プログラミングが便利だから 　世の中はrupy direction 　rupyは私の言葉ではない(鈴村さんが作った言葉ではない) 　swiftもjavascriptもruby,pythonの方向へ 　webの意見を見ていると,rubylikeがよいっという意見が多数 ・まとめ② 　従来のモデリング(例UML)を併用しても,見える化は,十分ではありません 　(UMLは2.0以上またはSysML,MATLABを利用しましょう) -プロトタイピング− リファインメント− Ｃ言語実装のアイテレーションが 本来あるべき姿と確信します. -プロトタイピングを意識して,そうであるべきタイミングでは,プロトタイピングに 便利な言語,ツールで取り組みましょう. 　しかしその言語,ツールで最後まで量産に利用するわけではありません. -開発スルーで異なる言語／モデリングを併用するわけですが,トータル効率では, 効果的. -MATLAB開発が,モデルベース開発ーＣ言語生成量産であり,その意味で同様　 　MATLABの世界でもBCDの演算にfloatingを落としたり,handでなおしたりなど プロトタイピング・リファイメント・実装を意識している. ・パラダイムシフトの認識 　QS9000→ISO16949→(CMM,SPICE)→ISO26262(機能安全) 　10年ごとに起きる 　効率的で,高信頼な開発手法変革が求められている. 　パラダイムシフトが見えない,コンセンサスはネット上で起きている. (サイレントパラダイムシフト) 　本にならないでインターネット上で話が進んでいる. ・自動車の世界のパラダイムシフト 　機能安全 　モデルベース開発(MBD) 　システム・エンジニアリング ○質疑応答②------------ ＜質問者2＞ 記述性高い言語を使うとソフトウェア開発は楽になるのはわかるが マイコンの部分はアセンブラかCでしか書くしかなくC言語のほうが記述性が 高いのは分かるがそこはどう考えているのか <回答> 現状のまま,そこは変わらない. 高級な言語は出てくるとは思うが, プラットフォーム化がより進む(MCALのように抽象化レイヤーを提案するなど) 階層化で固めていく動きはある. スタックの上のほうをどういう言語で開発するのかということを主張している しかし,swiftでアセンブリも書く動きがあるので(ブログ上で) もしかしたらそういった言語が他にも出てくるかもしれない ＜質問者3＞ MATLABとUMLはREPLに対応しているが UMLはplayground対応してない 今後はどうなるのか <回答> 実行するのは難しい ラプソディなど一部のツールではシミュレーションが動くが UMLはてんこ盛りの仕様であまり発展しないのではないか 今後も書くための道具としての存在 <質問者4> モデリングとしてMATLABとUMLを挙げているが 対象や使う領域は違いますよね？ どういう対象？(ターゲットは限定しているのかどうか) <回答> どういうシステムを作るか絞っているわけではない. UML/SysMLのほうが上流なので(MATLABと比較して) で記述できる書けるパターンは決まっており,書きやすくはなっている, ------------ ・MBDとMDDとはどういうことか 　ソフトウェアのレベルの仕様書は,なかなか完成していない. (出来るものでは無い) -仕様書も,開発過程で完成されるべきもの？ -動かしながら,visual化しながら,フィードバックをもらいながら(型情報, メトリックスだけでも重要),完成に向かっていく. -ソフトウェアだけが在ってもシステムが検証できない. -だからMBSE(モデルベースシステムエンジニアリング) -MATLABはシミュレーションが得意.動かして,visual化して気づくことの大切さ. 　なにを優先するかをVisual化して気付くことで改善していく ・日本流のすり合わせ開発と融和性の高い開発方法論の国際規格を提案 　〜高信頼なコンシューマデバイスを効率的に開発〜(IPA) 　トヨタ自動車の方も参加している 　MBDはMATLAB/simulinkを使っているところから出てきた言葉 　UMLを使っている開発をMDDと呼んでいる. ・オブジェクト指向もUML2.0を使うべきと言ったが, 　C言語の欠点をあげたが,UMLでも同じような欠点が出てきている 　オブジェクト指向だけのモデルで不足点がある 　 ・MBDとMDDの概要 　UMLはソフトウェアの表記は得意,それ以外はできない 　MBDソフトウェアもメカもハードもシステムも表現できる.　　 ・当初UMLは,ただのオブジェクト指向記述モデリング手法(欧州認識：そのため UML2.0へ改良折込したが不十分) -コントロールフロー表現が苦手(UML2からSDL概念：アクテイビテイ図追加) -データフロー表現が苦手(UML2からコンポジットダイアグラム追加) -部品化が苦手,デザインパターンのみを部品化手段として提供(UML2より コンポジットダイアグラム追加) -階層化が苦手(UML2からコンポジットダイアグラム追加したが不十分) -アーキテクチャ表現が苦手(UML2からコンポジットダイアグラム追加) -ＡＤＬ概念が弱い(UML2からコンポジットダイアグラム追加) -抽象化記述しにくい.(UML2からメタモデルインフラを追加) -メタプログラミング(ドメイン固有な抽象的な記述)が弱い -プロダクトライン表現が弱い(未対応：EAST-ADLではフィーチャー図を追加) -ヘテロジニアス,ハイブリッド記述が弱い(未対応：sysMLではパラメトリック図を追加) -この理由もあり,MATLAB/Simulinkの応用が拡大している. -ＤＳＭモデリングや依存性表現モデリングも必要で拡大. -さらにプロダクトラインのフィーチャー図,説明能力側面でGSN,D-CASEも ・ADL workshopの指摘 　ADL概念の弱さ,階層化概念欠落 　UML1.0の致命的欠点→オブジェクト指向一辺倒のモデルでそれだけでは不足 しているということ. ・ではどうする？？ 　プロトタイピング− リファインメント− Ｃ言語実装のアイテレーションが 本来あるべき姿. -うまく回っていますか？会話的開発ＩＤＥも本当にうまく回っているか, よく考えて対応しよう. -その上で,ＭＢＤ，ＭＤＤ,シミュレーション,ＩＤＥ,言語,ツールをうまく 組み合わせて選択(システム領域はC言語) -ひとつの言語で,すべて(フルスタック)開発するのがベストと言えるか, 場面場面で考える必要がある -ＡＤＬを意識しアーキテクチャ設計を意識しよう(機能安全でも意識している). 　プログラム＝アーキテクチャ＋振る舞い→部品化しやすい 　UML普及していない -Ｃ言語で最初から最後まで開発にとどまらないように,プロトタイピングを意識しよう ・まとめ 　MATLAB開発は,モデルベース開発ーＣ言語生成量産であり,その意味で同様 (プロトタイピング− リファインメント− Ｃ言語実装 　開発初期は, 早くフィードバックすることを意識⇒プロトタイピング,会話型 　キーワードは,動く,見える(ヴィジュアライズ),反応をもらう(型情報, コンパイルエラー情報,静的解析情報,メトリックス) 　MATLAB/simulinkはもちろんお奨めですが,私は,プロトタイピング段階では, Ruby言語も適していると感じています. 　(MATLAB/simulinkの動いているM言語はRubyそっくりの言語) ・scilab 　無料で利用可. 　フランスの政府が教育用に開発 　MATLABそっくり使ってみて,どこがどう違うかみてみるのも面白いかもしれません. ○質疑応答③------------ <質問者5> フルスタックに興味を持っていまして もう少しシステムプログラミング自体の階層化の部分に関して詳細を聞きたいです. <回答> リターンの戻り値の問題などCベースの整合性の残した拡張が本当にできるのか 疑問がある. C++などCのファミリがreturnの戻り値の問題などまだ引きずっているので　 C++は中々認知されない. そうしているうちにswiftがガンガン広まるのではないか <質問者6> UMLを推している印象をもちましたが, 開発者間のコミュニケーションとしての手段なのか, システムの検証・分析としての手段なのか <回答> UMLを薦めているわけではない MATLAB/simulink⇔UML スタンダードノーテーションということを意味している. <質問者6> 同じような話でruby言語(スクリプト言語)推しているが 保守対象として見なした時に大規模な開発に向いていないため保守しづらいが どう考えているか <回答> ruby的とはLess Noise、Less Celemony, Less Magic Spelling-java使いたくない (javaのようにおまじないのような記述を書きたくない) rubyではテストドリブン,ecosystemが出来上がっている そういった面で総合的に判断されるべき <質問者7> DSMでハードの設計で使ってるが いくつか欠点があるので過信しすぎるとよくない事例 などありましたら教えていただきたい <回答> まず,DSMにも限界があり,それを知ることが大事 ソースアーキテクチャの見方によい <質問者7> 以前の経験では,直行化進みすぎてパフォーマンスに影響が出る (たとえばボード上に部品をいろいろ部品を配置していくときにマイコンある ところに集約させすぎて配線がうまくいかないなど) マルチコアでたとえばソフトの配置など考えてみてください. DSMについて経験を積むコミュニティがあれば良い <回答> そうですね 以上