Fujitsu Standard Tool

Size: px

Start display at page:

Download "Fujitsu Standard Tool"

みずきありの
5 years ago
Views:

1 実践 MBSE ~SysML で設計意図を相伝できるか ~ 2014 年 8 月 28 日富士通コンピュータテクノロジーズ組込みシステム技術統括部アーキテクチャ部石田晴幸 1271karch02

Windows 用プリンタドライバ ( 仕事で C++ を使い始めた ) 2001~2004 FOMA 端末のアプリ制御 2006~ UML を使用実装は C++ RAID

2 自己紹介氏名 : 石田晴幸 ( 経歴入社以来ずっとファームウェアソフトウェア開発に従事 1989~1995 3D グラフィックアクセラレータドライバ 1995~2001 Windows 用プリンタドライバ ( 仕事で C++ を使い始めた ) 2001~2004 FOMA 端末のアプリ制御 2006~ UML を使用実装は C++ RAID 装置内蔵の WebGUI フレームワーク 2011~ WebGUI 本体は C++ コード生成ツール等は Java モデル駆動開発ツール BricRobo VDM++ のコード生成を試作 2014 SysML 認定 OCSMP-Fund 取得 2009~ UML モデリング推進協会で組込みモデルカタログ執筆

3 本日のメインテーマ設計書を読んでもその設計意図は伝わらないことがある設計意図がわからないと変更できないうまく変更できないと機能拡張に支障が出る昔頑張って作った人が定年になったときソースコードだけで技術を継承できるのか UML/SysML で書いたモデルはこの問題を解決できるか?

4 開発現場にありがちな問題

5 上流設計の意図通り実装されないシステムテストで障害を検出しました! なぜ今までわからなかった? 相手のモジュールは別部署で作ってました! そもそもどうあるべきなんだっけ? 他人の書いた資料を理解するのは大変です上流の資料ほど内容は抽象的で解釈にブレが出やすいものです

5% 新規ソフトウェア開発方法の比率不具合の原因工程の比率 IPA SEC 田丸喜一郎 (2013) ソフトウェア産業の実態把握に関する調査による組込み産業の現状より

6 実装工程で混入する障害 91.7% のソースコードが人手により作られた 27.1% の不具合がソフトウェア実装で作りこまれた自動コード生成 7.0% その他 1.3% ソフトウェア実装デバッグ 27.1% システム設計 15.8% 人手 91.7% ソフトウェア設計 33.5% 新規ソフトウェア開発方法の比率不具合の原因工程の比率 IPA SEC 田丸喜一郎 (2013) ソフトウェア産業の実態把握に関する調査による組込み産業の現状より IPA SEC 村松昭男 (2013) IPA/SEC が提案するソフトウェア品質指標の解説より半分でもコーディングを減らせないかなぁ? Copyright 2013 FUJITSU COMPUTER TECHNOLOGIES LIMITED

7 それって最適設計なのですか? よくある話他社より性能の高い装置なのにあまり売れないなぁ成功した人の話 ipod はソフトウェアだ by スティーブジョブズ ipod 本体は音楽再生機器 itunes というダウンロードソフトウェア itunesストアという販売経路これらが組み合わさって ipodを構成している NHK スペシャルメイドインジャパン逆襲のシナリオより各製品名は各社の登録商標または商標です

8 仕様変更です To: 開発者殿機能 x の仕様を変更します明日までに影響範囲と対応工数を教えてくださいトレーサビリティが確保されていれば仕様変更による影響範囲はわかります要件から設計までトレーサビリティを確保することは大変やるからには少しでも楽にやりたいトレーサビリティの情報を活用したいですね

9 モデル

10 モデルとはモデルある事象について諸要素とそれら相互の関係を定式化して表したものデジタル大辞泉よりモデルには手本見本という意味がありますがここではその意味では用いませんモデルの例 UMLやSysML MATLAB/Simulink VDM SPIN(Promela 言語 ) 数式 etc システムの構造と振る舞いを図で示す制御の数式を図で示すライトウェイトな形式手法の代表格もともとはプロトコルの検証用モデル検査の代表格モデルの原点

11 モデルを使うメリット日本語より厳密書く人が厳密に考えないと書けない良く考えて書くので誤りに気がつく読む人によって解釈がブレない手戻りが減るコンピュータが解釈できるシミュレーションにより早く障害を検出できるモデルからソースコードに変換できる品質生産性が上がる

12 読む人によって解釈がブレないあいまいな日本語の例各チームが作成する成果物をレビューする解釈の例例 1 class 曖昧さ日経 SYSTEMS よりチーム 1 作成する * 成果物 1 * 例 2 class 曖昧さチーム 1 作成する * 成果物暗黙のレビューアレビューする 1 * 要素や多重度をいじるとさまざまな解釈の仕方を生み出すことができます

13 シミュレーションにより早く障害を検出できる従来の開発要求分析モデルを使った開発受入テスト基本設計システムテスト障害検出機能設計結合テスト詳細設計単体テスト実装

モデルからソースコードに変換できる BricRobo モデル <<RunnableEntity>> + Initialize() :void uart :Uart Λ <<RPortEv>> send <<PPortEv>> packetout <<TopLevel>> SensorNode packetbuilder

temperature temperaturesensor : TemperatureSensor 簡単に始められる!

14 モデルからソースコードに変換できる BricRobo モデル <<RunnableEntity>> + Initialize() :void uart :Uart Λ <<RPortEv>> send <<PPortEv>> packetout <<TopLevel>> SensorNode packetbuilder : SendPacketBuilder CompositionType <<RPortEv>> infraredsensor : count CeramicInfraredSensor Λ <<PPortEv>> count <<RPortEv>> temperature Λ <<PPortEv>> temperature temperaturesensor : TemperatureSensor 簡単に始められる! 組込みソフト向けモデル駆動開発ツール BricRobo <<PPortEv>> recv <<RPortEv>> in <<BricRoboKeyElement>> SenseTask :Task elapse = 1 inittimer = 0 Λ parser : RecvPacketParser <<BricRoboKeyElem... LedTask :Task elapse = 100 inittimer = 0 <<PPortEv>> led Λ <<RPortEv>> in <<BricRoboKeyElement>> SendTask :Task elapse = 1000 inittimer = 0 led :Led BricRobo コードジェネレータ <<BricRoboKeyElement>> SendTask :Task Run() infraredsensor :CeramicInfraredSensor Run() Run() temperaturesensor :TemperatureSensor packetbuilder :SendPacketBuilder uart :Uart 設計と実装が乖離しませんソースコード RunSend() FUJITSU Embedded System BricRobo FujitsuBricRobo 検索

15 モデル駆動開発

16 モデル駆動開発 MBSE MDD MBD 等よく似た言葉がありますここでは以下の観点で定義します扱う領域自動コード生成人社会サブシステムメカエレキソフトウェアエレキソフトウェア MBSE モデルベースシステムズエンジニアリング ( 実装しない?) MDD モデル駆動開発半自動 + ハンドコードディング MBD モデルベース開発ほぼ自動コード生成

17 従来はドキュメント駆動開発生産物要件定義書コピペ参照基本設計書コピペ参照詳細設計書? ソースコード

18 モデル駆動開発はモデルが原本マスターモデル変換ソースコード

$Zip; namespace WebMasterLogCollector { class LogFilter : IDisposable { private const string ZIP_FILE_NAME_TEMPLATE = "{0:0000}{1:00}{2:00}.zip"; private Regex _regexhttpurl = new Regex("^.*?$

19 多分野の専門家による議論メカエレキソフトなど多分野の専門家が議論できるグラフィカルな記法で直感的に理解全体から詳細まで任意のスコープでシステムを俯瞰 using System.Collections.Generic; using System.IO; using System.Text; using System.Text.RegularExpressions; using Ionic.Zip; namespace WebMasterLogCollector { class LogFilter : IDisposable { private const string ZIP_FILE_NAME_TEMPLATE = "{0:0000}{1:00}{2:00}.zip"; private Regex _regexhttpurl = new Regex("^.*? " S+ s+( S*?) s"); private TextWriter _writer; public LogFilter(string logfile) { string logdir = Path.GetDirectoryName(logFile); if (Directory.Exists(logDir) == false) { Directory.CreateDirectory(logDir); } _writer = new StreamWriter(logFile, false, Encoding.UTF8); } <<RunnableEntity>> + Initialize() :void uart :Uart Λ <<PPortEv>> recv <<RPortEv>> in <<BricRoboKeyElement>> SenseTask :Task elapse = 1 inittimer = 0 <<RPortEv>> send <<PPortEv>> packetout Λ <<TopLevel>> SensorNode packetbuilder : SendPacketBuilder parser : RecvPacketParser <<BricRoboKeyElem... LedTask :Task elapse = 100 inittimer = 0 <<RPortEv>> count Λ <<PPortEv>> count Λ <<RPortEv>> temperature <<PPortEv>> temperature <<PPortEv>> led Λ <<RPortEv>> in <<BricRoboKeyElement>> SendTask :Task elapse = 1000 inittimer = 0 CompositionType infraredsensor : CeramicInfraredSensor temperaturesensor : TemperatureSensor led :Led public void Filter(TextReader reader, Regex urlfilter) { string line; while ((line = reader.readline())!= null) { Match m = _regexhttpurl.match(line);

関連線を使ってトレーサビリティを確保できる req トレーサビリティ要件マトリックスに変換して見ることが可能

20 トレーサビリティトレーサビリティ要件が漏れ無くどのように設計されどこに実装されたのかそれらの設計実装がどのようにテストされたのか第三者にわかる形で説明できるか SysML なら関連線を使ってトレーサビリティを確保できる req トレーサビリティ要件マトリックスに変換して見ることが可能 <<refine>> ユースケース <<refine>> アクティビティアクター <<allocate>> クラス <<instanceof>> オブジェクト

<<derivereqt>> PID 制御を行う <<derivereqt>> PC

<<derivereqt>> てんとう虫ヘリコプター <<derivereqt>>

21 モデル駆動開発のイメージ req 要求分析 uc ユースケースラジコンヘリコプターを自律飛行させたいヘリコプター自律飛行システム自律飛行制御 PC から操作できるラジコンヘリコプター <<include>> ヘリコプターの位置を計測するヘリの位置を計測する制御を行う PC から制御できるインターフェースヘリ本体操作者ヘリコプターが自律飛行する <<include>> <<derivereqt>> カメラ画像を用いた位置計測 <<derivereqt>> PID 制御を行う <<derivereqt>> PC からの命令によりプロポのスティック操作検出部に電圧をかけスティック操作と認識させる <<derivereqt>> てんとう虫ヘリコプター <<derivereqt>> ヘリコプターを制御する composite structure 構造 sd シーケンスてんとう虫ヘリコプター操作者 USBカメラ制御 PC 擬似操作発生機プロポてんとう虫ヘリコプタープロポ loop 設計意図 ref ヘリコプターの位置を計測する USB カメラ擬似操作発生機 ref ヘリコプターを制御する派生製品の開発制御 PC cv : 画像から位置計測 pid :PID 制御 pout : 擬似操作変換ソースコード生成仕様を変更したときの影響範囲各製品名は各社の登録商標または商標です

22 UML と SysML

23 UML (Unified Modeling Language) OMG が策定したソフトウェアオブジェクト指向設計のための表記方法初版 :UML 1.1 (1997) 最新 : UML 2.4.1(2011) 矩形や線を使って構造振る舞いを表す 9 種類の図 UML ツール間でデータを交換するための XML データ形式 OMG (Open Modeling Group) 国際的な非営利的なコンピュータ業界の標準策定コンソーシアム uc ユースケース class クラス Class1 Class3 sd シーケンス Use Case1 act アクティビティ Object1 Object2 Actor1 pkg パッケージ Class2 Package1 Activity1 <<merge>> Package2

24 SysML (System Modeling Language) INCOSE が UML をシステムエンジニアリング向けにカスタマイズ後に OMG と INCOSE が共同して策定初版 :SysML 1.0 (2006) 最新 :SysML 1.3 (2012) 矩形や線を使って要求構造振る舞いを示す 9 種類の図 INCOSE (The International Council on System Engineering) システムエンジニアリングの非営利業界団体 req 要求 Requirement1 class ブロック定義 Block1 Block2 sd シーケンス Object1 Object2 Requirement2 Requirement3 Block3 uc ユースケース pkg パッケージ Package1 composite structure 内部ブロック Block1 Actor1 Use Case1 <<merge>> b2 :Block2 Package2 b3 :Block3

25 UML と SysML の違い SysML OMGの策定したシステムモデリング用言語 UMLをベースにして策定 UML と SysML の違いクラス図オブジェクト図コンポジット構造図配置図コンポーネント図コミュニケーション図タイミング図相互作用概要図 UML パッケージ図ユースケース図ステートマシン図シーケンス図アクティビティ図 SysML 要求図ブロック定義図内部ブロック図パラメトリック図但しクラス図ブロック定義図コンポジット構造図内部ブロック図

26 なぜ SysML が求められたのか UML の 3 大弱点石田の主観 UMLはソフトウェアに寄り過ぎた UMLは部品化ができなかった UMLで示したシステムで要件が充足されたか不明だった UML が使い物にならないわけではありません SysML の利点を知っていればこれらの UML の弱点をうまく回避することも可能でしょう

27 UML はソフトウェアに寄り過ぎた UML SysML ソフトウェアのオブジェクト指向設計を表すのに重宝されたクラスを格納するコンポーネントがありコンポーネントをサーバー等に配置するための配置図があったシステムの構造はブロック ( 定義 ) とパート ( 用法 ) によって示すメカエレキソフトを同じ表記で扱い多分野の専門家が議論する土台にできるシステム m1 : メカ e1 : エレキ s1 : ソフト

28 UML は部品化ができなかった UML SysML クラス図が巨大な図になりがちだったクラス図では再利用可能なクラスの塊を明確に表現できなかったブロック定義図と内部ブロック図を組み合わせて何層でも掘り下げられる部品と部品を接続できる接続点としてポートの使い方が明確になったブロック A ブロック B ブロック D b1 : ブロック B d1 : ブロック D f1 : ブロック F d1 : ブロック D e1 : ブロック E g1 : ブロック G

29 UML で示したシステムで要件が充足されたか不明だった UML SysML そもそも要件を描く正式な記法がない要件の充足性を示す記法もない要件図で要件の関係性を示せる親子関係に限らない要件がどのように充足されたかを示す関連線がある子要求 A1 <<refine>> ユースケース U1 親要求 A ユースケース U1 で詳細化親子関係子要求が全て充足されると親要求も充足される子要求 A2 <<derivereqt>> 派生要求 X 派生要求 X はブロック B1 が充足 <<satisfy>> ブロック B1 より具体化された要求

30 システムエンジニアリングプロセス

31 Dual Vee システムエンジニアリングの開発プロセスピンクのV 字アーキテクチャ観点からシステムを分割するプロセス水色のV 字各システム要素を設計実装評価するプロセス二つのV 字が直交している

32 要求から構造を抽出するプロセス例要求分析 req 要求要求 A 要求図ユースケース分析要求 A1 要求 A2 uc ユースケースユースケース図システムユースケースシナリオ作成 [else] Use Case1 アクター sd シナリオシーケンス図システムアクティビティ分析 : アクター act アクティビティアクティビティ図構造分析 [ 完了した ] Action1 composite structure 内部ブロック class ブロック定義ブロック定義図ブロック A ブロック A 内部ブロック図 b1 : ブロック B c1 : ブロック C ブロック B ブロック C

33 モデルに意図を込める #1 騎馬戦

34 運動会の騎馬戦をモデリングしてみる class 騎馬戦 1 騎馬騎馬 1 騎馬 1 騎馬 1 騎馬 1 騎手 1 前 1 右後 1 左後 1 騎手役持ち主 1 騎馬役自鉢巻 1 鉢巻この図は誤りではないが騎馬戦とは言いがたい何かが欠けている

35 騎馬戦 ( 発展形 1) class 騎馬戦 [ 発展形 1] stm 騎馬競技場競技場 0..1 騎馬 0..* 騎馬生存騎馬 0..1 騎馬 1 騎馬騎馬 1 1 騎手 0..1 騎手役前 1 右後 1 左後 1 騎馬役場外騎手が落ちた鉢巻が取られた持ち主 0..1 自鉢巻 0..1 死亡鉢巻騎馬について掘り下げてみたもの騎手が騎馬から落ちるかもしれない騎手の鉢巻を取られるかもしれない競技場の外に出るかもしれない

36 騎馬戦 ( 発展形 1 補足 ) object 落馬 A グラウンド : 競技場騎馬 1 号 : 騎馬鈴木 : 騎手役佐藤 : 騎馬役山田 : 騎馬役渡辺 : 騎馬役 object 場外 A グラウンド : 競技場 : 鉢巻騎馬 1 号 : 騎馬 object 鉢巻喪失 A グラウンド : 競技場鈴木 : 騎手役佐藤 : 騎馬役山田 : 騎馬役渡辺 : 騎馬役騎馬 1 号 : 騎馬 : 鉢巻鈴木 : 騎手役佐藤 : 騎馬役山田 : 騎馬役渡辺 : 騎馬役 : 鉢巻

37 騎馬戦 ( 発展型 1 補足 2) composite structure 騎馬戦 _ 発展形 1 補足 2 競技場騎馬 A: 騎馬騎手 A: 騎手役鉢巻 A: 鉢巻前 : 騎馬役右後 : 騎馬役左後 : 騎馬役騎馬 B: 騎馬騎手 B: 騎手役鉢巻 B: 鉢巻前 : 騎馬役右後 : 騎馬役左後 : 騎馬役落馬オブジェクト図よりコンポジット構造図の方が構造が分かりやすい

38 SysML で表すと bdd [Package] SysML [ 騎馬戦 ] <<block>> 競技場競技場 0..1 ダイアグラムフレームに注目! ここを見るとモデルのどの部分の図なのか分かる騎馬 0..* <<block>> 騎馬騎馬 0..1 騎手 0..1 <<block>> 騎手役騎馬 1 持ち主 0..1 前 1 右後 1 騎馬 1 騎馬 1 左後 1 ibd [Block] 競技場 [ 競技場 A] 騎馬 A: 騎馬騎手 A: 騎手役前 : 騎馬役 [1] 鉢巻 A: 鉢巻自鉢巻 0..1 <<block>> 鉢巻 <<block>> 騎馬役右後 : 騎馬役 [1] 左後 : 騎馬役 [1] このくらいの記述内容では UML との差は小さい? 騎馬 B: 騎馬前 : 騎馬役 [1] 騎手 B: 騎手役鉢巻 B: 鉢巻右後 : 騎馬役 [1] 落馬左後 : 騎馬役 [1]

39 騎馬戦 ( 発展形 2) class 騎馬戦 [ 発展形 2] 競技場競技場 0..1 騎馬 0..* 軍 / 生存騎馬数 : int 所属 1 騎馬 1..* 騎馬 {self. 生存騎馬数 = self. 騎馬 ->select(a a. 生きている )->size() -- 生存騎馬数は軍に所属する生きている騎馬の数 } / 生きている : bool 騎馬 0..1 騎手 0..1 騎馬前 1 1 騎馬 1 右後 1 騎馬 1 左後 1 {self. 生きている = (self. 騎手 ->isempty() = false) and (self. 騎手. 自鉢巻 ->isempty() = false) and (self. 競技場 ->isempty() = false) -- 生きているとは騎手が居て鉢巻を所有していて競技場内に居ること } 騎手役騎馬役持ち主 0..1 自鉢巻 0..1 鉢巻騎馬の集合体として軍について考えたもの騎馬戦とは複数の軍で争い生存騎馬数を競うものだが

40 騎馬戦 ( 発展形 3) class 騎馬戦 [ 発展形 3] 参加戦 0..* 参戦軍 1..* 騎馬戦勝戦 0..* 勝軍 1..* { let 最大生存騎馬数 :int = self. 参戦軍. 生存騎馬数 ->max() in self. 勝軍 = self. 参戦軍 ->select(a a. 生存騎馬数 = 最大生存騎馬数 ) -- 勝軍は最大生存騎馬数を持つ軍すべて } 競技場競技場 0..1 騎馬 0..* 軍 / 生存騎馬数 : int 所属 1 騎馬 1..* {self. 生存騎馬数 = self. 騎馬 ->select(a a. 生きている )->size() -- 生存騎馬数は軍に所属する生きている騎馬の数 } / 生きている : bool 騎馬 0..1 騎馬騎馬 1 騎馬 1 騎馬 1 {self. 生きている = (self. 騎手 ->isempty() = false) and (self. 騎手. 自鉢巻 ->isempty() = false and (self. 競技場 ->isempty() = false) -- 生きているとは騎手が居て鉢巻を所有していて競技場内に居ること } 騎手 0..1 前 1 右後 1 左後 1 騎手役持ち主 0..1 自鉢巻 0..1 鉢巻騎馬戦 :: 騎馬役生存騎馬数が最大の軍はいくつでも勝軍とするどうなったら勝ちか分かったがこれが騎馬戦の肝だったのか?

41 騎馬戦 ( 発展形 4) class 騎馬戦 [ 発展形 4] 参加戦 0..* 騎馬戦勝戦 0..* { let 最大生存騎馬数 :int = self. 参戦軍. 生存騎馬数 ->max() in self. 勝軍 = self. 参戦軍 ->select(a a. 生存騎馬数 = 最大生存騎馬数 ) -- 勝軍は最大生存騎馬数を持つ軍すべて } 参戦軍 1..* 勝軍 1..* 競技場競技場 0..1 軍 / 生存騎馬数 : int 所属 1 {self. 生存騎馬数 = self. 騎馬 ->select(a a. 生きている )->size() -- 生存騎馬数は軍に所属する生きている騎馬の数 } 騎馬 0..* / 生きている : bool 騎馬 0..1 騎馬騎馬 1 騎馬 1..* 騎馬 1 騎馬 1 攻撃者 0..* 1 仕掛けた攻撃攻撃対象 1..* 0..* 仕掛けられた攻撃攻撃騎馬戦の肝は騎馬による攻撃だろう騎手 0..1 騎手役持ち主 0..1 自鉢巻 0..1 前 1 右後 1 騎馬役左後 1 {self. 生きている = (self. 騎手 ->isempty() = false) and (self. 騎手. 自鉢巻 ->isempty() = false) and (self. 競技場 ->isempty() = false) -- 生きているとは騎手が居て鉢巻を所有していて競技場内に居ること } 鉢巻

42 騎馬戦 ( 発展形 4 補足 ) class 騎馬戦 [ 発展形 4] 参加戦 0..* 騎馬戦勝戦 0..* { let 最大生存騎馬数 :int = self. 参戦軍. 生存騎馬数 ->max() in self. 勝軍 = self. 参戦軍 ->select(a a. 生存騎馬数 = 最大生存騎馬数 ) -- 勝軍は最大生存騎馬数を持つ軍すべて } 参戦軍 1..* 勝軍 1..* 競技場競技場 0..1 軍 / 生存騎馬数 : int 所属 1 {self. 生存騎馬数 = self. 騎馬 ->select(a a. 生きている )->size() -- 生存騎馬数は軍に所属する生きている騎馬の数 } 騎馬 0..* / 生きている : bool 騎馬 0..1 騎馬騎馬 1 騎馬 1..* 騎馬 1 騎馬 1 攻撃者 0..* 1 仕掛けた攻撃攻撃対象 1..* 0..* 仕掛けられた攻撃攻撃この辺の関係が曖昧かも stm 騎馬生存騎手 0..1 騎手役持ち主 0..1 自鉢巻 0..1 前 1 右後 1 騎馬役左後 1 {self. 生きている = (self. 騎手 ->isempty() = false) and 場外 (self. 騎手. 自鉢巻 ->isempty() = false) and (self. 競技場 ->isempty() = false) 死亡 -- 生きているとは騎手が居て鉢巻を所有していて競技場内に居ること } 騎手が落ちた鉢巻が取られた鉢巻

43 騎馬戦 ( コンテキスト図 ) class 騎馬戦 [ コンテキスト ] 騎馬戦 0..* 1 0..* 0..* 1 1 競技場参加者 1..* 騎馬戦参加者 1..* 軍鉢巻 1..* 鉢巻 0..* 攻撃 1 騎手役騎馬役 1..* 騎馬 { self. 鉢巻 ->size() = self. 参加者 ->collect(a a->oclistypeof( 騎手役 ))->size() -- 鉢巻の数は騎手役の数と同じであること } { 騎手役.allInstances()->size() * 3 = 騎馬役.allinstances()->size() -- 騎手役の人数の3 倍が騎馬役の人数 } 最初に登場人物などをざっくり説明すると良い

44 騎馬戦 ( 振る舞い ) stm 騎馬戦 act 騎馬戦入場入場戦闘開始の合図戦闘戦闘戦闘終了の合図 / 勝利判定退場 when (1 つの軍を除いて全滅した ) / 勝利判定勝利判定退場ステートマシン図アクティビティ図シーケンス図表現力の違いを使い分けて

45 ここまでのまとめ最初に登場人物などを説明しようコンテキスト図価値を生み出すものをしっかり抽出しよう騎馬戦の攻撃クラス考える順と説明する順はちがいますコンテキスト図を最初に書けるとは限らない上流工程で問題領域をしっかりモデリングすることが大切です

46 OMG Object Constraint Language (OCL) UML に制約をつけるときに使う言語仕様書のありか : なぜ制約が必要なのか? 書きやすい範疇だけのモデルから意図を読み取るのは困難表したいもの外枠を定義して余計な部分を除く ( 制約を付ける ) 定義 : 赤い矩形ただしグレーの部分を除くや + + では直感的でないことがある

47 モデルに意図を込める #2 騎馬戦

48 これで良かったのか? class 騎馬戦 [ コンテキスト ] class 騎馬戦 [ 発展形 4] 0..* 1 騎馬戦 0..* 0..* 1 参加戦 0..* 騎馬戦勝戦 0..* 1 競技場参加者 1..* 騎馬戦参加者 1..* 軍 1 鉢巻 1..* 鉢巻 0..* 攻撃競技場競技場 0..1 参戦軍 1..* 勝軍 1..* 軍 / 生存騎馬数 : int 所属 1 stm 騎馬戦騎手役騎馬役 1..* 騎馬 stm 騎馬騎馬 0..* / 生きている : bool 騎馬 0..1 騎馬騎馬 1 騎馬 1..* 騎馬 1 騎馬 1 攻撃者 1 仕掛けた攻撃攻撃対象 1..* 0..* 0..* 仕掛けられた攻撃攻撃騎手 0..1 前 1 右後 1 左後 1 入場戦闘開始の合図戦闘戦闘終了の合図 / 勝利判定 when (1つの軍を除いて全滅した) / 勝利判定退場場外生存騎手が落ちた死亡鉢巻が取られた騎手役持ち主 0..1 自鉢巻 0..1 鉢巻 object 落馬 Aグラウンド : 競技場騎馬役 object 鉢巻喪失 A グラウンド : 競技場騎馬 1 号 : 騎馬騎馬 1 号 : 騎馬鈴木 : 騎手役佐藤 : 騎馬役山田 : 騎馬役渡辺 : 騎馬役競技場騎馬 A: 騎馬 : 鉢巻騎手 A: 騎手役前 : 騎馬役鉢巻 A: 鉢巻鈴木 : 騎手役佐藤 : 騎馬役山田 : 騎馬役渡辺 : 騎馬役 object 場外 A グラウンド : 競技場右後 : 騎馬役左後 : 騎馬役 : 鉢巻騎馬 1 号 : 騎馬騎馬 B: 騎馬騎手 B: 騎手役鉢巻 B: 鉢巻前 : 騎馬役鈴木 : 騎手役佐藤 : 騎馬役山田 : 騎馬役渡辺 : 騎馬役右後 : 騎馬役左後 : 騎馬役落馬 : 鉢巻

49 Goal Structuring Notation (GSN) で説明するゴール戦略コンテキストコンテキスト議論をモデルにする書式ゴールを戦略で複数のサブゴールに分解再帰的に分解して証拠までつなげる下記 URL で仕様を配布中サブゴールコンテキスト証拠

50 騎馬戦モデルを GSN で説明する GSN 騎馬戦騎馬戦モデルは適切である騎馬戦モデル要求にしたがって検証要求一覧競技進行できること勝利判定できること反則行為がわかること競技進行ができる勝利判定ができる反則行為がわかる stm 騎馬戦で競技進行できる騎馬戦クラスの制約で勝利判定できる! 反則行為をモデルにしていなかった先に要求を明確にしないから

51 先に反則行為を説明しよう GSN 反則行為がわかる反則行為がわかる反則行為ごとに説明する反則行為一覧顔から上を攻撃しないつかまない顔から上を攻撃しないつかまない

52 反則行為の追加 class 騎馬戦 [ コンテキスト ] 騎馬戦 0..* 1 0..* 0..* 参加者 1..* 1..* 鉢巻 1..* 0..* 0..* 競技場騎馬戦参加者軍鉢巻攻撃反則行為 1 1..* 騎手役騎馬役騎馬追加してみた

53 クラス or オブジェクト? class 反則行為 [ 案 1] class 反則行為 [ 案 2] 反則行為反則行為 + 行為 + ペナルティ顔から上を攻撃しないつかまない object 反則行為 [ 案 2] 反則行為 1: 反則行為行為 = 顔から上を攻撃するペナルティ = 違反した騎馬は失格ペナルティをうまく表せない反則行為 2: 反則行為行為 = つかむペナルティ = 違反した騎馬は失格騎馬に失格属性を足さないと

54 ここまでのまとめ GSN でモデルの正しさを議論 ( 説明 ) しよう偉い人に見てもらえば良いというのは甘え正しさの議論の中に権威が同意したという手法はあるしかしそれだけではお寒い説明がまともモデルが説明通りモデルはまとも正しいモデルを残すだけでなくどう説明できるかが必要になります ( 第三者検証の時代 ) 考える順序と説明の順序は異なることがあります

55 最後にモデルに意図を込めるには引き出しが必要多重度に気を遣う制約を付けるクラス or オブジェクト etc GSN を使って自分でモデルの正しさを説明しよう他人をまきこむ前に自己レビューなんでもモデルにしてみよう製品から離れてモデリングしてみると意外な気づきを得られます ( 私も騎馬戦モデルのために OCL を再勉強しました )

Copyright 2010 FUJITSU COMPUTER TECHNOLOGIES

ET2014 ミニセミナーフィーチャー図と BricRobo で簡単プロダクトライン 2014/11/19~21 ( 株 ) 富士通コンピュータテクノロジーズ伊澤松太朗 1294karch01 Copyright 2014 FUJITSU COMPUTER TECHNOLOGIES LIMITE

ET2014 ミニセミナーフィーチャー図と BricRobo で簡単プロダクトライン 2014/11/19~21 ( 株 ) 富士通コンピュータテクノロジーズ伊澤松太朗 1294karch01 Copyright 2014 FUJITSU COMPUTER TECHNOLOGIES LIMITE ET2014 ミニセミナーフィーチャー図と BricRobo で簡単プロダクトライン 2014/11/19~21 ( 株 ) 富士通コンピュータテクノロジーズ伊澤松太朗 1294karch01 目次 1. 当社のご紹介 2. 派生開発でよくある課題 3. フィーチャー図のススメ 4. フィーチャー図と BricRobo による簡単プロダクトライン開発 1 当社のご紹介 2 会社概要株式会社富士通コンピュータテクノロジーズ