SysML 中級講座： 第6回 要求図（１）

都会の涼の取り方

梅雨明け以降、全国的に猛暑が続いているようです。
こう暑いと何もやる気がせず、動作も緩慢になって来ます（普段から、そうだと言われそうですが）。
以前車を持ってた頃は、時間があると信州あたりにさっと行けたのですが、今の場所に越して来て以降、全く乗らなくなり手放してしまったので、こういう時は不便です。

今回は、筆者が時々やっている都会の涼の取り方を紹介したいと思います。
自宅の近所を走る都営新宿線は京王線と乗り入れしており、そのまま乗っていると、調布とか府中とか言う奈良時代を彷彿とさせるような地名の場所に連れて行ってくれます。
さらに乗っていくと、「高尾山」と言う京都にありそうな名前の山の麓まで行きます。

ケーブル地上駅前

このあたりは京都の高雄と同じく紅葉の名所です。
さらに、高尾山周辺は、京都風の地名が多い事でも有名です。
筆者は、時間がない時は山に登らず、名物の蕎麦だけ食べて帰る事もあります。
ここまで来ると空気は山の涼気を含み、普段なら十分に涼しいのですが、孟夏の今週は、ここでさえ暑く感じますので、さらに足を伸ばして、ケーブルかリフトに乗って高度を上げます。

高尾山リフト

ケーブルカーの方が速度は速いのですが、リフトは山の風を切って走り、爽快感が違いますので、今回はリフトに乗ります。

ケーブルの頂上駅付近

麓の駅との標高差270メートルで、頂上の駅を降りると、木陰は結構涼しげな風が吹いています。
昨年、ミシュランの三つ星（最高ランク）に登録されてからは、外国人の姿も結構見かけます。

参道をぶらぶら歩いて、薬王院まで散策しても良いですし、サル園野草園もあります。
また、夏の夕方限定ですがビヤガーデンも営業中です。





要求図　（１）
SysMLには、UMLにはなかった図がいくつか登場しますが、要求図はその1つです。
しかし、全く新しい図ではなく、言語的にはクラス図の一種となります。
UMLのプロファイリングの機能を用い、新しいステレオタイプ　≪requirement≫　等を追加して図を構成します。

プロファイリングを用いて言語拡張を行う事に賛否両論がありますが、現状は賛成派が多数派を占めているようです。
何と言っても、便利なのは、何の断りをする必要なく、同じクラス図の系統を引く他の図、例えばブロック図、との混在・併用が可能になる点です（広い意味で、要求であろうが、ブロックであろうが、クラス図です）。
これは、オブジェクト指向言語（プログラミング言語の方）の性質と似たようなものですが、複雑な設計を行う時には大変便利です。

不思議なもので、人間の脳は具体的なものほど理解は進みますが、具体的なままでは複雑な操作に耐えられなくなります。
喩えて言うと、コンピュータの動作原理を理解する上では二進法表記は役立ちますが、複雑なシステム設計では二進法表記は具体的すぎて人間の脳では耐えられなくなります。
対象が複雑になればなるほど、抽象化しないと議論が出来なくなります。

神戸旅行

三連休は母校の同窓会があったので、故里の神戸へ帰りました。
ちなみに、神戸生まれの人間は神戸に帰る事を”帰神”と略します。また、東京へ行く事を上京とは言わず、江戸へくだると言います（冗談です）。

友人が、どこか案内してくれるというので、ブログ用の写真が撮れる神戸旅行らしい場所と所望したところ、次の3つの候補地を挙げてくれました。

1. 「北野工房のまち」→「北野の異人館」→「布引ハーブ園」を回る。
2. ハーバーランド〜モザイク方面に移動し、神戸の港の風景を見物（ポートタワーに上る？）
3. 変わったところでは、ポートアインランドにある神戸花鳥園に行ってみる

 筆者は、3番目の花鳥園が初耳でしたので、迷わずそこを選びました。

帰神の当日、神戸花鳥園の前で、友人と、友人の知り合いの美女の2名にお出迎え頂き、美女の案内で花鳥園を巡りました。
彼女は、花鳥園のファンだそうで、あちらこちらに我々を引率してくれました。
この花鳥園は予想以上と言うよりも、むしろ最高の場所でした。半分を廻らないうちにカメラのメモリーが無くなってしまいました。

さて、約束通り、写真をブログに貼ります。
かなりの枚数を撮り、もちろん美女の写真も撮りましたが、代表してフクロウの写真をアップロードします。
まるで縫いぐるみのようですが、本物のフクロウです。
フクロウは頭が良く、飛行ショーでも活躍してますし、カメラを向けるとこのようにちゃんとポーズも撮ってくれます。

花鳥園のあと、3人で三宮神社の近くのレストランで和食を食べ、そのあとジャズのライブ演奏の店に行き、最後は手打ち蕎麦が食べられる和風バーへ行き、神戸の夜を堪能しました。
すべて、友人がこの日のために事前に予約を入れて置いてくれた店ばかりでした。
有り難うございました。

SysML 中級講座： 第５回 MBSEの利点 その３

筆者も最近はiPadを手に入れ、会社のメール・システムも社内サーバーからグーグルに換えて、一応世の中の流れを実感しようと言う努力を続けています。

iPad+Googleの使用感は噂通りやはり良く、今までは外出時は重いMacを鞄に入れて運んでたのですが、最近ではたいていの場合、iPadだけで済むケースが多くなってきています。

筆者のような人間でさえこんな状態ですから、最近のビジネスマンが高機能な携帯や小型の情報端末を持つ理由は非常によく分かります。

 一言で言うと遊び感覚で、いつもオンラインにアクセス出来る所でしょうか、メリットは。

さて、前回、前々回に引き続き、MBSEのメリットについて議論します。

3. 設計品質の向上が図れる

3-1 　設計をモデル表現する事により、エラーと曖昧さの低減が期待できます。

3-2    モデル図を組み合わせる事により、より一貫性のある設計が行えます。

４．早い段階から継続的にベリフィケーションとバリデーションを行う事が出来、リスクの低減が図れる

ベリフィケーションとバリデーションと言う言葉は、日本語に直訳すると共に検査ぐらいの意味になってしまいますが、システム工学に限らず、品質に関連する分野では、このベリフィケーションとバリデーションと言う2つの言葉は厳密に使い分けられています。

一言で言うと、ベリフィケーションはHowに焦点を当て、バリデーションはWhatに焦点を当てた検査と言ったあたりでしょうか。

言い換えると、ベリフィケーションは正しく作られたかをチェックし、バリデーションは正しいもの、つまり顧客が真に望んでいるもの、を作ったかをチェックします。

例を挙げると、顧客はiPadのようなものを欲しがっていたが、設計部隊は高品質のクッション付き眼帯を作って仕舞ったとすると、ベリフィケーションは通るかも知れませんが、バリデーション・テストは不合格です。

５．ライフサイクルを通して価値を提供

モデル図は、単に設計製造の時に使うだけではありません。

FCS後のメンテナンスや、トレーニング、改造、廃棄の際にも有用です。

６．知識の獲得を容易にする

洋の東西を問わず設計スキルを身につける事は時間のかかる事です。

モデル図により、情報の明確化が計れ、知識の習得をある程度容易にします。

SysML 中級講座： 第４回 MBSEの利点 その２

あちらこちらで雨の被害のニュースを聞きますが、皆様のお住まいの地域はいかがでしょうか？

前回に引き続きMBSEの利点について議論します。

２．複雑なシステム設計過程の管理を容易にする

2-1  統合モデルを様々な視点で捉え関心の分離が行える。　

モデリングというのは情報の抽象化を伴います。

そして、モデラーが最も留意しなければならない所は、この抽象化の過程で大部分の情報が捨てられてしまっている点です。

モデルは通常、ある一定の視点から描かれますが、複雑なシステムであればあるほど異なる複数の視点でモデリングを行います。

例えば、自動車と言う1つの対象をとってみても、機械屋の視点から見たモデルと、電気屋の視点、ソフト屋の視点とでは全く異なった絵になります。

そして、各々の分野の専門家が独立して行える部分と、他分野の専門家と協調しなければならない分野があり、統合モデルは、その分離と管理を容易にします。

２−２　階層的なシステムモデルを用いてトレーサビリティをサポートする。

筆者が前回のOMG技術会議に出席した際、NASAの安全品質担当の一人の博士が、要件のトレーサビリティが機械的にツールで行える事の重要性を訴えていた事が印象に残っています。

上位の概念設計のレベルから、下位の実装設計のレベルに行くに従って、情報はどんどん変形して行きます。

セマンティックなアプローチでは、対象のシステムの大きくなるにつれ、複雑さが人間の注意力を完全に超えてしまいます。

情報のトーレスが機械的に行えるような言語とツールが必要になってきます。

３−３　要件や設計の変更の影響分析を容易にする

要件が変わったり、設計変更を行ったりする事は、良いか悪いかの問題ではなく、そもそも人生がそうなっているのであり誰にも止められない問題です。モデリングにより、変化の影響分析が容易に行えます。

3−4　インクリメンタルな開発にも、進化論的獲得（革新的進化）にも役立つ

今日の設計の現場は、いわゆるウォーターフォール型ではなくインクリメンタルな開発が主流です。モデリングはもともと、そう言った開発論と共に発展して来た方法です。

また、同時に、抽象化したモデルから、革新的なアイディアが生まれる事も良く報告されています。

（次回に続く）

SysML 中級講座： 第３回 MBSEの利点 その１

最近は太りすぎで血圧が高めなので、一念発起して、一日最低５００メートルの水泳を自分自身に義務付けています。
また、食事も暴飲暴食はやめ意識的に軽く済ますように心がけた結果、始めてから一週間で3キロ痩せました。
この分で行くと3ヶ月もしないうちにベストの状態に行けるんじゃないかと思いますが、毎日泳ぎに行くのは結構辛い・・・

MBSE モデル・ベースト・システムズ・エンジニアリングの利点 　その１

システム工学の歴史は古く、コンピュータ発明以前から存在していた事は先に述べたとおりです。
またシステム工学とモデリングの親和性はむしろ本質的です。
しかしながら、システム工学用のモデリング言語はソフトウェア系に比べるとかなり後発でした。
これは、いくら好条件がそろった商品でも需要がなければ全く売れないのと同じで、いくらモデリングと親和性の高い分野だと行っても、モデリングのニーズやメリットがなければ誰もモデリングなんてしないのは理の当然でしょう。

ところが2007年のSysML1.0の登場以来（わずか3年前）、システムズ・エンジニアリング分野はモデル・ベースのものに急速にシフトしていっています。
この普及の急速さは、UMLの時とは比べものにならないくらいです。
もちろんUMLの時と比べ環境的な条件が遥かに整っている事は事実ですが、何かメリットがあるはずです。
今回はMBSE(Model Based Systems Engineering)の利点を見て行きましょう。

1. 要件や設計の共通理解が容易
      モデルではなく従来の文書によるシステムズエンジニアリングの欠点の1つは、表現の曖昧さでした。曖昧な表現のままコミュニケーションを行うわけですから、時には大きな誤解を生み出します。　その結果様々な問題が発生します。

1-1 　文書ベースでは、要件そのものを間違えやすい、あるいは正しい事を検証できない（バリデーションの問題）のに対し、モデル・ベースでは検証が容易になる。

1−2　昨今のシステムの開発では、要件の分析と設計は一体となって行われる事が多いが、
モデルはその分析設計の共通基盤を提供してくれる。

1-3   モデル分析により、リスクの発見が容易になる。

まずは文書ベースのアプローチに比べMBSEは以上のような基本的なメリットがあります。

（次回に続く）

SysML 中級講座： 第２回 システム工学とSysML

SysML言語の詳細に入る前に、システム工学とモデリング、そしてSysMLの関係を概観しましょう。

まず、システム工学ですが、これ はコンピュータが発明される以前から存在する学問分野で、最初は人間系が主な対象でしたが、機械系、電気系システムの発展とともに対象が広がり、かなり広 範囲な学際的特徴をもつ分野です。
近年、コンピュータの登場とともにますます対象エリアは広がり、かつ非常に複雑なシステムを扱うようになってき ました。

システムズ・エンジニアと言うと日本ではITシステムを設計する技術者、特にソフトウェア技術者を指す言葉として定着しています が、これは日本固有の現象で、欧米ではシステムズ・エンジニアと言うと、第一義的に船舶とか航空機、ロケットなんかを思い浮かべる人が多いようです。
こ れは、システムズ・エンジニアと言う言葉が、それぞれの国で、どのような対象とともに登場して来たかを暗示しているのではないかと思います。
おそ らく日本では、IT系のシステムズ・エンジニアの登場以前には、システムズ・エンジニアと言う言葉が一般には馴染みのないものだったのではないかと想像し ています。

MBSE モデルベースト・システムズ・エンジニアリング

そして、モデリングとシステム工学も古くて新しい話題です。
そもそ も、システム工学にはモデリングというコンセプトを始めから包含していたとも言えます（例えば、数学モデル）。
また、モデリングと言う概念も拡張 しようと思えばいくらでも拡張できる訳で、例えばニュートン力学なんかは、自然対象を非常に高い精度で近似できる数学モデルという見方も可能です（もちろ んニュートン卿は、けっして近似モデルを発明発見したとは思ってなかったと思いますが）。

さて、現代的な意味でのモデリングはここ十数年 の間に急速に発達してきました。

始めは組込みソフトウェアの現場から

UMLは最初はソフトウェア開発、なかんずく上流行程で発生する様々な問題に対処するために誕生し ました。
しかしながら、組込み系ではいわゆるIT系のUMLでは事足らず、ソフトウェアを取り巻くシステム環境がモデリング出来ないと分析設計そ のものが不十分であるという壁にぶつかり、９０年代後半あたりから独自の拡張をUMLに付け加えるようになってきました（当時、OMG内には、そう言った 問題に対処するSIGも誕生しました）。
このような「システム」を記述するためのUMLの拡張は、その後、UML2.0に取り入れられた形で発展 して行きます。
恐らく、IT系のみを担当するソフトウェア技術者の中には、UML2.0とともに登場した図の中に、何のためにあるのか分からない 表記法の存在に当惑した経験をお持ちの方が少なからずいらっしゃると思いますが、その多くは「システム」を記述するための（UML2.0の）拡張部分で す。

INCOSEとOMGの協同体制の発足

この様に、最初は組込み系システムの現場から誕生したシステムのモデリングと言う概念は、 ２０００年代に入ると、より大きな問題、より広範なシステムに対処するべくOMGという組織の枠を超えて広がって行きます。そして、システム工学の本家、 INCOSEとOMGの共同作業が始まります。
次の表はINCOSEとOMGの協同体制の発足からSysMLの誕生までの年譜を示しています。

• 2001年 INCOSEとOMG間で協議開始
• 2002年 RFI 発行 ー 市場から広く情報を集める
• 2003年 RFP発行 ー 市場に提案を求める
• 2007年 SysML 1.0
• 2008年 SysML 1.1
• 2010年 SysML 1.2

初期の段階では、システムをモデリングするための言語としてUML以外のものも検討されましたが、様々な理由、例えば、組込み系がUMLを使っ てシステム・モデリングを先行させている、既にUMLは学校等で教授されていて市場に馴染みがある、ソフトウェア設計との親和性、UML以外の言語でメタ モデル構造が標準化されている言語が無かった、等々の理由で、比較的すんなりとUMLをベースに言語を開発する事については合意されました。
しか しながら、その後のSysMLの詳細を詰める過程では議論は大もめにもめ、対立するグループが二派に別れて、それぞれが別々の言語仕様を作ると言った事態 にまで陥り、一元化するまでの間、半年以上の日月を空費するような事もありました。
SysML 1.0の誕生までに発足から約６年かかりましたが、関係者の努力の賜物と言えるでしょう。


誕生の経緯からお分かりの通り、 SysMLはモデルベースのシステム工学のための言語、道具です。目的か手段かと問われると、あくまでもMBSEを行うための手段です。
本講座で は、SysMLの言語的特性に焦点を当てて議論を進めますが、あくまでも道具である事を忘れないようにしていきたいと思います。

次回は、 システム工学をモデルベースで行う事に、どんなメリットが有るのかについて議論します。

SysML 中級講座： 第１回 開始！

本日から、SysML中級講座を始めます。
最初に、何をもって中級と名付けたかについて触れておきたいと思います。

SysMLとOCSMP

現在、INCOSE(International Council Of Systems Engineering)とOMGの協業でOCSMPと言う資格試験の開発が進んでいます。
このOCSMPですが、OMG Certified Systems Modeling Professional と言う名称が示すようにシステムをモデリングする専門家のための認定試験です。
従っ てSysML言語そのもののテストではなく、システムのモデリングに関する知識を問う設問が中心となっています。
しかしながら、モデリングとモデ リング言語は極めて密接な関係があり、喩えて言うと日本文学と日本語の関係、あるいは数学と数式の関係のようなものであり、言語を理解せずに文学を学ぶ事 が実際不可能なように、モデリング言語を知らずにモデリングを実践することは殆ど不可能です（少なくとも、他人が書いたモデル図を読む事は不可能）。

OCSMP は全部で４つのレベルから構成されていますが、試験体系の設計に関しては、このモデリングとモデリング言語の関係、及び、個人の学習に関する成熟度が強く 意識された形になっています。
下の図は、OCSMPの４つのレベルを示しています。

 OCSMPには２つのグループがあり、１つはモデルユーザー、もう一方はモデルビルダーと名付けられていて、モデルビルダーはその名前の通りモデルを構築 する人、つまりシステムを設計する人間を対象とした区分であるのに対し、モデルユーザーは、システム設計者に対し情報を提供したり、あるいは逆に情報をも らったりする人たちです。

実際の現場でもこの区分は良く当てはまり、システム設計を行う人間・グループを中心として、その周辺にはハード ウェア設計者（例：筐体や電子回路）やソフトウェア設計者、そして各々の分野の専門家、例えば社会学者や原子力科学者、物理工学者等々、が取り巻 いています。

そして、モデリングの学習は、他人が書いたモデル図を正確に、過不足なく読み取る事から始まります。

実際、 OCSMPのエントリーレベルであるモデルユーザーの試験は、モデル図を読む能力に主眼が置かれ、モデル図を読み取る上で必要なスキル、知識が試されま す。

言い換えると、エントリー・レベルでは言語の解釈能力を問う問題が中心的です。

一方モデルビルダーは、モデル図を描く人を想 定した出題群からなります。

モデルビルダー初級は、モデル図を描く上で必要な基礎知識が試され、中級、上級になるとモデリングを行う上で必要とな る知識・スキルが試される傾向にあります。

また、中級、上級となるにつれ言語に関する問題も高度化していく傾向がありますが、モデル図を描く上で 必要な知識に限定され、決して単純な文法問題になってしまわないよう配慮されています。

本講座では、モデルビルダー中級程度で必要となる ようなSysMLの知識を想定して進めて行きたいと考えています。

これは、モデルビルダー中級は、一般のシステム製品の設計者を想定した試験区分 である事、そして上級はSystem of Systemsと言うような巨大もしくは複雑なシステム設計者を想定した出題でありMBSE(モデル・ベースト・システムズ・エンジニアリング）中心の出 題になる事が予想され、言語色が薄れる事、等を勘案して設定しました。

また、前提としてUML初級（ファンダメンタル）程度の知識を読者 に想定しています（SysML言語は、UMLを拡張した言語であり、一種のUMLとも言える。）

UMLの入門的な知識に関して知りたい人 は、各種書籍や iStudyシリーズの「iStudy for OCUPファンダメンタル」などのE-ラーニング教材などをお奨めします。

アーキテクチャー：メタモデルのすすめ ⑥

９０年代以降、アーキテクトは、その方向性を大きくモデリングの方へ舵を切って行き、またそのモデリングも具体的なものから抽象的なものへとシフトして来 ています。
また、アーキテクトの基礎知識として、モデリング技術は当然として求められますが、最近ではメタモデリングの知識も必須項目となって来 ています。

恐らく、このブログを読んでいる人にメタモデルの重要性を訴える事は、釈迦に説法だと思いますので、ほどほどにしたいと思いま すが、そもそも、何で日本ではアーキテクチャーとかメタモデリングが発達しないのかは、筆者にとっても最大の関心事ですので（あるいは、日本にとっても非 常に重要な問題だとも思いますので）、少し触れてみたいと思います。

先日、友人と寿司屋に行った際にもこの事が議論になりました。
ど うも今の日本のカルチャーの中では、無形なものに価値を見いだす事が難しい、と言うよりも、さらに悪い事に、無形なものに対して、ニュートラルではなく負 の評価を行う傾向があるんじゃないか、と言う命題が議論の中心でした。

概念的、あるいは抽象化した議論は、ややもすると言葉遊び的に捉え られ、具体性がないとか、（具体的な）結論を先に言え、と言うような否定的な評価につながり易い傾向があるのは、ITに限った事ではなく、殆ど日本のすべ ての分野で見られる傾向です。
筆者も海外で仕事をする前までは、具体性を好む人間の一人でしたので他の日本人を批判する資格は全くありません。

し かしながら、海外での仕事を通じて、考え方の違いや仕事のアプローチの違いを見るにつけ、日本のやり方が必ずしもベストではない事、結果を生み出さない事 を痛感するようになって来ました。

よく言われる事ですが、哲学（西洋哲学）は欧米では、結構身近な話題です。存在論メタモデルなんて言う話題は、ビジネスマンでも好んで口にします。（余談 ですが、哲学用語は、使うと話が高級そうに聞こえるため営業トークでも頻出しますが、これはやり過ぎでしょうね。）

もっとも欧米人と言っ ても、人によりますので、具体的な話しか好まない人も多くいます。ただ全体的に言って、抽象的な議論に対してネガティブな見方をしない、概念的な作業に価 値を見いだしている傾向があります。
それに対して、日本では「もの」が価値の中心であり、サービスは「もの」に付随する「おまけ」的な見方が相変 わらず続いています。

しかしながら、昨今、日本企業の経営陣の世代交代が進みつつあり、それにつれて考え方も少しずつですが、変わって 行ってる事を実感しています。

貴重な時間を割いて、このアーキテクチャーやメタモデルに関するブログを読んで頂いている方達ー世代が、今 後の新しい時代を作る、と期待しています。


次回からは、OCSMPの資格試験も近々始まる事から、SysMLに関してシリーズで 書いて行きたいと思います。