astahによるUMLモデリング

2016/04/24

豆蔵ソフト工学ラボのモデリング記事のリンク

豆蔵ソフト工学ラボのモデリング記事がいつも参考になるので、リンクをメモ。
自分が考えていることをラフなメモ書き。

【参考1】
誤解しがちなモデリングの技:目次 | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第1回:コンポジションにまつわるアレコレ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第2回:隠れた曖昧さ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第3回:ステートマシン図(I) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第4回:ステートマシン図 (II) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第5回:ユースケース図にまつわるアレコレ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第6回:初心者にありがちな間違い | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第7回:モデルの意味的な誤り(I) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第8回:モデルの意味的な誤り(II) | 豆蔵ソフト工学ラボ

【参考2】
組込み開発のためのモデリングワンポイントレッスン:目次 | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第1回:対象を明確に | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第2回:デバイスのモデリング | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第3回:クラスとインスタンスの区別 | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第4回:ドメインと制御の区別(前編) | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第5回:ドメインと制御の区別(後編) | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第6回:状態って何? | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第7回:イベントいろいろ | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン:第8回:状態遷移 | 豆蔵ソフト工学ラボ

【1】一つのシステム、一つの業務を分析する時、複数の観点でモデルを描いて、重要な箇所やキーとなる部分を把握したい時にUMLは役立つと思う。
但し、いくつかの注意点があると思う。

業務システム、業務の設計では、UMLの観点の分析は役立つが、ER図とDFDがやはり必要。
ER図で帳票の項目がどのように配置されるか分かるし、DFDで業務フローとデータの関連が一瞥できる。

個人的に注意している点は、エンティティがイベント・リソースだけでなく、サマリテーブルとして保持すべき部分はどこであるか、という所。
リアルタイムに表示したい時に時間がかかるならば、バッチ処理で集計したデータをサマリテーブルに生成し、そのデータを表示させるように設計する。
すると、その表示のタイミングによって、データは最新でないから、ユーザが戸惑う時がある。

また、業務システムのモデリングでも、組込システムと同様に、データのライフサイクルという観点で状態遷移図を考えたい時があるが、ER図・DFDではそれを表現しにくい。
いつもしっくりこない。

【2】組込システムのモデリングでは、UMLの観点の分析はすごく役立つと思う。
クラス図で必要な処理がオブジェクトに集約されるし、シーケンス図やアクティビティ図でオブジェクトの動的な処理をプログラムとほぼ一致させることもできる。

個人的に注意している点は、組込みシステムを状態遷移図として表現する時に、複雑な要件や仕様をどこまで状態遷移図で表現できるか、という所。
システムを状態遷移図に表現できれば、事実上、プログラムに自動生成することは可能。
だが、実際のシステムでは、イベントを待っていて発火する、とか、イベントの履歴を保持してどの状態に遷移させるべきか使用が決まっている、とか、色んなパターンがあって、状態遷移図に全ての仕様を盛り込むのも難しい。

UML2.xの状態遷移図の仕様を調べると、かなり複雑な仕様を表現する事はできる。
「H」のような履歴というモデル要素などを考えてみると、過去の人達が苦労して編み出した概念なんだな、とか分かる。

また、組込み開発のためのモデリングワンポイントレッスン:第4回:ドメインと制御の区別(前編) | 豆蔵ソフト工学ラボの記事のように、ドメインと制御の部分を区別して設計するのもかなりに熟練の業を必要とすると思う。
ユーザ側の観点ではドメインの要素しか見ないが、実際のシステム内部では、たくさんの制御装置があって、それら装置が連動して整合性が取れて初めて、システムが正常動作する。
ドメインと制御装置の依存関係、制御装置同士の関係を表現するのが難しいと思う。
どうしても、Controller部分が肥大化してしまうので、Mediatorパターンのように表現したくなるが、何となくいつもうまくいかない気がする。

【3】豆蔵さんの上記の記事はどれもとてもよく考えられている記事なので、astahでUMLをモデリングしていて、何となくしっくり来ない時に読み直している。
自分も、モデリングのパターンを整理してみたいと思う。

| | コメント (0)

2016/04/05

Enterprise Architectの使い方のリンクとメモ

古い記事だが、Enterprise Architectの使い方のリンクがあったのでメモ。

IT設計で使っているツール:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その1:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その2:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その3:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その4:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その5:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)をこのように使ってます。その6:気になっていることのメモ:So-netブログ

Enterprise Architect(EA)はこんな事もできる:気になっていることのメモ:So-netブログ

ドキュメントを作成する時に:気になっていることのメモ:So-netブログ

スパークスシステムズジャパン フォーラム - ユーザー掲示板 CRUD図の表の中身の逆生成は可能ですか?

UML再考: プログラマの思索

日本でモデリングツールが使われない背景: プログラマの思索

EnterpriseArchitectはとても多機能なモデリングツール。
僕はまだ使いこなせてない。

上記の記事では、EAの使い方としてUMLにこだわらず、要求→ユースケース→機能→テストケースまでのラフな絵を描いて想像を膨らませたり、要求→ユースケース→機能→テストケースまでのラフな絵を階層化した構造ツリーを表示することで変更要求の影響箇所を一瞥できるのが便利だ、と述べている。
その点は、EAに限らず同感だ。

モデリングツールはastahをずっと使い続けているが、モデリングツールに期待する機能はたくさんある。
ステートマシン図から状態遷移表を自動生成したり、機能(ユースケース、プロセス)とテーブル(ER図)を組合せたCRUD表の自動生成、とか。
状態遷移表は組込みシステムのイベントフロー設計で使えるし、デシジョンテーブルのテストケースとしても流用できる。
CRUD表は、サブシステムの分割基準に使えたり、FP法による簡易見積りにも使えるだろう。

また、クラス図、アクティビティ図、ステートマシン図、ER図、DFDなどあらゆるダイアグラム間で、整合性を担保したり、トレーサビリティを維持する仕組みは、モデリングツールで自動チェックしてくれなければ実現は不可能。
最終的にはモデリングツールでモデルのトレーサビリティを保証することで、要件や仕様の漏れをなくしたいのだ。

つまり、モデリングツールを使いこなせれば、見積り・設計・テストの作業効率化に適用できるはず。

設計ツール | system-enablers日記にはこんな文章がある。

(引用開始)
また、有用なツールは、開発手法も教えてくれます。
例えば、今現在、注目しているICONIXプロセスではEAを使うことを推奨していて、EA用のアドインを提供しています。
(中略)
「プロは腕も持っているが、道具も持っている」ものです。
わたしたちもプロの道具を上手に使って、いい仕事をしたいものです。
(引用終了)

個人的には、関西でastahを使ったモデリングの勉強会を開いて、情報共有したいなあと思ったりする。

| | コメント (0)

2015/08/25

「ビヨンド ソフトウェア アーキテクチャ」は買い?

ビヨンド ソフトウェア アーキテクチャ」がもうすぐ販売されるのでメモ。
興味がそそられる。

【参考】
ビヨンド ソフトウェア アーキテクチャ(LukeHohmann 岡澤裕二 和智右桂) | 翔泳社の本

おおお『Beyond Software Architecture』訳されたのか! これはとても良い本でした。 - t-wada のコメント / はてなブックマーク


(引用開始)
「アーキテクチャ」について技術的な観点から書かれている本は数多くありますが、ビジネスの視点からシステムを商品として見た時に考えるべきことを教えてくれる本が、実はありませんでした。
本書は、アーキテクチャにおけるビジネス(マーキテクチャ)と技術(ターキテクチャ)をつなぐ架け橋として、情報システム部の方全員に読んでほしい本(情シス必読書)です。
エンジニアにとっては、マーケティングの基礎を学ぶ上でも役に立ち、かつ、技術面でのアーキテクチャ論としても、経験豊富な著者の実体験に根ざす優れた考察に富んだ一冊となっています。

原書は2003年にMartin Fowlerシグネチャシリーズの一冊として刊行されました。Jim Highsmith、Mary Poppendieck、Ed Yordon、Craig Larman他から多数の賛辞が寄せられています。著者のLuke HohmannはOOPSLAやUML Worldの常連スピーカーとして、QUALCOMMなどを経て現在はConteneo,Inc.のCEOに就いていますが、それ以前には全米フィギュアスケート選手権のジュニアチャンピオンでもあった異色の存在でもあります。

最後に、訳者より一言「情シスの方はアジャイルやスクラムもよいですけど、こういうアーキテクチャのこともきちんと考えてみませんか?」
(引用終了)

(引用開始)
目次

第1章ソフトウェアアーキテクチャ
第2章プロダクト開発入門
第3章マーケテクチャとターキテクチャ
第4章ビジネスとライセンスモデルの共益関係
第5章インライセンステクノロジー
第6章可搬性
第7章デプロイメントアーキテクチャ
第8章統合と拡張
第9章ブランドとブランド要素
第10章ユーザビリティ
第11章インストール
第12章アップグレード
第13章コンフィギュレーション
第14章ログ
第15章リリース管理
第16章セキュリティ
補遺A:リリースチェックリスト
補遺B:戦略的プロダクトマネジメントのためのパターン言語
(引用終了)

本棚を見返すと、和智さんの翻訳本はほとんど購入している。
エリック・エヴァンスのドメイン駆動設計」「組織パターン」「エッセンシャル スクラム」「実践テスト駆動開発」然り。
どれも分厚くて、何度も読み直して咀嚼し直すたびに、新しい発見がある。

今度の本もすごく楽しみだ。

翻訳された本の分野を見ると、アーキテクチャ設計やアジャイル開発にフォーカスされている。
僕が興味を持っている分野にドンピシャリだなと思ったりする。

ビヨンド ソフトウェア アーキテクチャ」でググってみると、下記のPDFが見つかる。
目次がそっくりなのだが、関係あるのかな?

/ - alimnova - Grupo de trabajo ingenieria de software - Google Project Hosting

| | コメント (0)

2015/08/18

ユースケース駆動ではなくロバストネス駆動開発?

「ロバストネス駆動開発」という言葉を見つけたので思わずメモ。

【参考1】
天使やカイザーと呼ばれて ≫ ロバストネス駆動開発?

天使やカイザーと呼ばれて ≫ ロバストネス図113枚!!

OOAD講座:第5回「ロバストネス分析を設計・実装につなげる」 | artisan edge thinking

ロバストネス図の使い道: プログラマの思索

ユースケース→ロバストネス分析→クラス設計という順に開発していくスタイル。
この時、ロバストネス分析が最も重要であるという認識から、「ロバストネス駆動開発」とネーミングしたらしい。
確かに、ロバストネス図がきちんと書ければ、バウンダリ・コントローラ・エンティティを多少変形するだけで実装に近いクラス図を設計できる。

ロバストネス図を1日中書いたら113枚になった、という記事は確かにすごい。
単なるテーブル保守画面ではなく、背後に複雑なロジックがあったり、バッチ処理があったりすると、ラフな設計がいるのだろう。

【参考2】
ソフトウェア開発の匠(1):「ITエンジニアは職人気質を取り戻すべき」 (2/3) - @IT

ソフトウェア開発の匠(1):「ITエンジニアは職人気質を取り戻すべき」 (3/3) - @IT

ユースケースの疑問: プログラマの思索

UML再考: プログラマの思索

ユースケースの善し悪し: プログラマの思索

でも、萩本さんの記事によれば、「ロバストネス分析に多大な工数をかけたが成果が出ない」という問題もある。

(引用開始)
ロバストネス分析から、シーケンス図などを使って動作検証を図り、分析モデルを作り上げる作業までには多くの工数を要した。
しかし、その結果作成された分析モデルは設計モデルにつながりにくく、何のためにシーケンス図などを使って検証したのか、作成したエンジニアたちにも分からなかった。

(1)ユーザーも開発者も理解しづらい産物を作りかねない
(2)分析モデルを作るまでに多くの工数を要する
(引用終了)

オブジェクト指向分析(OOA)の弱点は、分析モデルと実装モデルの乖離があるために、実装モデルに辿り着くまでの工数が大きくかかることだろう。
分析麻痺症候群に陥りやすい弱点があるのではないか。

概念モデル→論理モデル→物理モデルみたいな流れだと、中間成果物がやたらと増える。
しかもその成果物の保守も大変。

ロバストネス図がユースケースとクラス図の間を結ぶミッシングリンクであることは分かるが、仕様変更やソース修正と同じタイミングでロバストネス図も保守していくのは結構大変だ。
つまり、ロバストネス図も設計書やソースと同じく、構成管理の配下に置くべきである。
しかし、構成管理と連動したモデリングツールは結構使いづらい。

但し、astahは個人的には設計のスケッチツールとして使いやすいし、Subversionと連携して構成管理も可能だ。

【3】ロバストネス駆動開発は、個人的には結構イケているのではないか、と思ったりする。
簡単に書けるし、書いていくうちに、処理の粒度に気づいたり、他の人とのコミュニケーションにすぐに使えるからだ。

もう少し考えてみる。

| | コメント (0)

2015/08/14

ユースケースの善し悪し

ユースケースの善し悪しについて、良い記事があったのでメモ。

【参考】
良いユースケースを書くための発想法

ユースケースの疑問: プログラマの思索

ロバストネス図の使い道: プログラマの思索

ユースケース駆動開発実践ガイド: プログラマの思索

ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき

ユースケース駆動開発実践ガイドを読んでわかったこと、その2 - paz3のおもいつき

最近、ユースケース記述を読む機会があり、システム要件がシンプルに上手く書かれていた。
その理由を考えている時、良いユースケースを書くための発想法を読んで、なるほどと思った。

僕もよく間違えるけれど、ユースケースを機能仕様としてシステム観点で細かく書いしまいがち。
本来のユースケースは、利用者の観点で、システムスコープを明確にすることだ。
また、ユースケースは、利用者とシステムの相互作用の観点として書かれるべきなので、シーケンス図でシステムと応答するような形で書くイメージになるべき。

| | コメント (0)

2015/07/21

UMLの概念モデルで法律を理解するアイデア

UMLのモデルで法律を理解するアイデアをメモ。

【参考】
UMLモデリングレッスン - サポートページ

第1回 編集者ガチンコバトル、お勧めモデリング本! | Think IT(シンクイット)

【1】「UMLモデリングレッスン」のレッスン50に、刑法の犯罪要件について、UMLのクラス図で概念モデルを描いている事例がある。
このクラス図を見ながら、刑法の条文を読むと、ああなるほど、と何となく腑に落ちた。

【1-1】上記では、「刑罰法規が犯罪構成要件を規定する」「~という行為が犯罪構成要件に該当する」という文言がそのままクラスとその関連名に当てはまる。
犯罪になる行為として、「違法行為」「非違法行為」の2種類があり、非違法行為になる条件として「違法性阻却事由」を持つことが当てはまる。

つまり、刑法の条文はとても冗長な文章であるが、その本質となる文章をそのままクラスと関連名に当てはめれば、概念モデルになりうる。
これは面白い。
おそらく理系の人は、こういう法律の文章はとても苦手だと思うので、こういうやり方で理解する方法もあるのかもしれない。

【1-2】上記の概念モデルをER図としてRDBに落とし込んだ場合、どのようなテーブル構成になるか?
僕の勝手な憶測では、下記のようになるだろう。
IDEF1Xで書けば、「●---」の向きで外部キーによる参照制約、「△---」の向きで派生関係を表す。

刑罰法規マスタ●---犯罪構成要件マスタ
行為トランザクション---●犯罪構成要件マスタ
(※但し、行為テーブルには、複数個の犯罪構成要件マスタを外部キーとして持てる)

行為トランザクション△---違法行為トランザクション、非違法行為トランザクション
非違法行為トランザクション---●違法性除却理由マスタ

UIとしては、行為データを登録・検索する画面と各マスタ保守画面がいるかな。
帳票としては、ある期間の行為データを印刷する帳票がいるかな。

【1-3】また、「UMLモデリングレッスン」を読んで興味深い部分は、上記のようなモデリング技法が、ソフトウェア開発で使われる場面が意外にあることだ。

例えば、上記のような概念モデルを用いて、政府や裁判所の要請に基づき、犯罪履歴や事例を検索したり保守するシステムを作る案件はもちろんありうる。

似たような例として、電力・ガス・電話などの事業会社やクレジットカード・保険会社の契約条文をビジネスルールとしてソフトウェアシステムに実装する場合がある。
これらの会社では、ビジネスの基本的な約束事は約款として定められており、そのビジネスルールがシステムの要件や制約に反映されるからだ。

例えば、クレジットカード会社や携帯電話会社では、カードやスマフォの契約時に、違法性がないか、ビジネスルールを課しており、そのルールを満たす人だけが契約できる。
そしてその契約情報は記録され、後から検索したり、契約延長や契約破棄などの保守ができるように、システムを作る必要がある。

そう考えると、携帯電話会社や銀行・カード会社と契約を結んだ時に約款として渡される大量の資料の背後には、彼らの会社の基幹システムにはビジネスルールとして実装されているのだろうと推測できる。

【2】この発想を推し進めれば、例えば、日本の特許庁のシステムリプレースでも、こういう概念モデルが必要だったのだろうと勝手に推測する。
実際のニュースを見ると、破綻した理由は他にもあるみたいだが。

News & Trend - 2012年の特許庁システム開発中止、開発費全額返納のなぜ:ITpro

【ITブラック】特許庁システムにまつわる黒い話が色々ヤバイ - NAVER まとめ

UMLのモデリング技法を用いて、ビジネスルールを概念モデルで表してみる手法は今後考えてみたい。

| | コメント (0)

2015/04/25

astahプラグインのタスク一覧が良い感じ

astahプラグインのタスク一覧が良い感じなのでメモ。

【参考】
astah*プラグイン タスク一覧(拡張タブビュー表示) 0.9.1公開 | 響雲

ノートに「TODO」と書いておけば、下部にTODOリスト一覧が表示される。
EclipseのTODOタグと同じ機能。
TODOリスト一覧をダブルクリックすると、TODOが記載されているダイアグラムが開くのもいい。

モデリングは1回では終わらない。
TODOを残しながら、1つずつ解決して描いていく時が多いから、重宝しそう。

| | コメント (0)

2015/01/25

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーに行ってきた。
要件定義の考え方がすごく参考になった。
感想をラフなメモ書き。

【元ネタ】
さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナー - アジャイルウェア | Doorkeeper

要件構造の見える化 #RDRAセミナー: ソフトウェアさかば

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

【1】要件定義の問題。
いつまで経っても、システムの全体像が見えない。
大量のドキュメントばかりで、肝心のシステムが説明されない。
分析と言う名の転記作業ばかりで、要件定義が完了しない。

では、どうすればいい?

要件定義、要件分析では、個人作業は非効率。
レビューと修正反映の繰返しでは、要件定義書の品質は上がらない。

その場で皆で合意を積み上げて進める方がいい。
ステークホルダーの合意のベースを作る方が重要。

議論を積み重ねる時に、使われる手法として、リレーションシップ駆動要件分析RDRAがある。

リレーションシップ駆動要件分析RDRAでは、要件定義書の元ネタとしてモデルを作る。
その時、システムよりも、システムを取り巻く環境に注目する。

システムは、エンジニアがこだわりがち。
その中身の説明は、最終的にはプログラムであり、ユーザは理解しにくい。
エンジニアの立場では、システムの設計は自力で何とかなる。

しかし、システムを取り巻く環境の方が要件定義では重要。
先に、システムを取り巻く環境から、要件を先に固める。
いかにプログラムレスで表現して、エンジニアがユーザと会話できるようにするか?

【2】リレーションシップ駆動要件分析RDRAの構造は、「システムの価値」「システムの外部環境」「システム境界」「システム(内部)」の4つ。

【2-1】システムの価値は、例えば、システムリプレースでは語られない時が多い。
AsIsは分かるが、ToBeが分からない。
ユーザから見れば、既に動いているシステムが要件そのもの、と言うが、実際は何のために作ったのか、その理由や背景が忘れ去られている。

【2-2】システム外部環境は、業務フロー、概念モデル(または用語集)、利用シーンから成る。
利用シーンは、業務フローがない場合に使う。
例えば、初めて作るユーティリティツールのように、まだ実際のシステムがない場合に、そのシステムがどのように使われるのか、という利用状況を描き出す。
業務フローがない場合、誰がどう使うのか、というイメージが湧きにくい。

利用シーンは、ユースケースとは違う。
ユースケースは、アクターとシステムの相互作用を表すから、システム境界に含まれる。
利用シーンは、システムを使って何が嬉しいのか、を表す。
利用シーンは、ユースケースが何故存在するのか、という理由や根拠になる。

【2-3】システム境界は、UIのような画面・帳票、外部I/Fのような外部システム連携などがある。

【2-4】リレーションシップ駆動要件分析RDRAは、モデル同士のリレーションに注目する。
リレーションシップ駆動要件分析RDRAでは、モデル同士の依存関係を表したい、という目的がある。

問題意識としては、混乱している要件定義フェーズを収束させたい。
その鍵は、モデルの依存関係にある。

よくある問題は、いきなり機能一覧を洗い出すものの、要件が発散してしまうこと。
特にリプレース案件で多い。
現状のシステムから、機能一覧はすぐに洗い出せるが、それだけでは要件定義は終わらない。

何故、その機能やデータがいるのか?
AsIsではなく、本来のあるべきシステム像は何なのか?
例えば、昔は汎用機やCobol、10年前はVBでガリガリ作られたデスクトップアプリだったろうが、現代では、クラウドの上のWebシステムや、工場でも作業者がタブレットを持って歩きまわるように実現すべきではないか?
AsIsの要件にひきずられると、高い費用を払ったのに、昔と変わり映えしないシステムになってしまい、ユーザにとって価値がない。

まずは、システムそのものではなく、システム境界を定めよう。
システムのスコープは何か?
システムとユーザのインターフェイスは何か?

システム境界の話で要件定義がまとまらないなら、システム外部環境に話を移そう。
どんな業務フローでシステムが必要なのか?
どんな利用シーンでシステムが使われると嬉しいのか?

それでも駄目なら、システムの価値を探ろう。
なぜ、システムは必要なのか?
誰にとって、システムは必要なのか?

「システムの価値」「システムの外部環境」「システム境界」「システム(内部)」という4つの視点が重要。
でも文章では分かりにくい。
だから、図ないしモデルで描こう。

但し、リレーションシップ駆動要件分析RDRAで描いたモデルは、ユーザ向け資料の元ネタであり、ユーザ向け資料は別途作成する必要がある。

【3】Q.価値を考える人とシステムを考える人は別々になりがちだが、リレーションシップ駆動要件分析RDRAではどのように対応すべきか?

価値を考える人=ユーザ、ドメインエキスパート。
システムを考える人=アーキテクト、エンジニア。

あるいは、価値を考える人=元請けSE。
システムを考える人=下請けPG。
日本のIT業界では、多段階下請構造によって、要件定義とシステム開発の工程が分断されがち。

A.攻め方が違う。
初めての新規システム案件なら、システムの価値→システムの外部環境→システム境界→システムのようにブレイクダウンしていく。

リプレース案件なら、AsIsのシステムがあるから、システム境界(or システム)→システム外部環境→システムの価値のように、リバースエンジニアリングしてシステムの構造やシステム境界を明確にしてから、システムの価値を探っていく。
リプレース案件では、機能一覧は普通にあるはずなので、そこからシステムの価値へ登っていく。

どちらにせよ、4つの観点のブレイクダウンやボトムアップで双方向に行き来する。

【4】コンテキストモデルでは、アクターとしてステークホルダーを洗い出す。
要求モデルでは、アクターの要求を洗い出す。

お金の権限を持つステークホルダーとその要求を洗い出せているか?

業務フローは作業フローではない。
業務フローは、普通、システムに大きく依存する。
作業フローは不要。
担当者の作業はコロコロ変わるから。
ロールや業務を洗い出したい。

ユースケースは機能分割しない。
ユースケースは機能ではない。
リレーションシップ駆動要件分析RDRAにおける「機能」とは、パッケージ製品のカタログの機能一覧の項目と同じレベル。
例えば、MSWordなら、こんな機能があります、というイメージ。

イベントモデルは2種類ある。
例えば、GoogleMapsのように、1回のやり取りでデータが確定するもの。
それは、機能モデルで表現できる。

一方、外部システムとのバッチ連携のように、データを何度もやり取りする場合がある。
それは、プロトコルモデルで、状態遷移図として表す。
イベントが発生したら、次の状態へ移る、という内容をプロトコルモデルで表す。

【5】リレーションシップ駆動要件分析RDRAでは、モデルをEnterprise Architectで描きます。

設計開発を強力に支援するUMLモデリングツール Enterprise Architect 概要と特徴

Enterprise Architectの良さは、設計情報がリポジトリに格納されるので、モデルの関連付けが自動付与されること。
また、モデルを描けば、設計リポジトリから機能一覧をすぐに出力できる。
機能一覧を元に、ユーザにヒヤリングして、要件を深堀りできる。

さらに、依存関係が不十分なモデルがある場合、クエリを使って設計リポジトリから対象モデルをすぐに検索できる。
要件定義レビューの前に、担当者にモデルを修正するように作業指示も出せる。

他に、Enterprise Architectはリバースエンジニアリングが強い。
JavaやC#だけでなく、RubyやActionScriptなどの軽量言語もサポートしているのが強み。

Enterprise Architectで、現状のシステムのソースを全部読み込み、クラス同士の関連をリバースエンジニアリングした後、モデルを整理していけば、システムの構造が見えてくる。
そこから、システム境界、システムの外部環境、システムの価値を探っていく。

【6】リレーションシップ駆動要件分析RDRAで作成したモデルでは、網羅性と整合性の根拠を説明できる利点がある。

アクター→要求→利用シーン→ユースケース→画面→機能→データ のように関連付けていくので、なぜその機能やデータが必要なのか、という根拠を説明することはできる。
つまり、ある要求に基づく画面や機能が網羅されているか、という根拠を説明はできるだろう。

また、モデルの整合性は、モデル同士のリレーション、依存関係で語れる。
例えば、機能一覧にあるこの機能は、このユースケースを実現したものであり、それはこの設計書に書かれている、など。

要件定義では、要件の網羅性、要件の整合性を語ることができれば、ステークホルダーを説得することができる。


【7】要件定義プロセスはタイムボックスで作業すると良い。
つまり、イテレーションごとに、要件定義を進めていく。

最初のイテレーションでは、荒い粒度のモデルしか作れないが、速く作れる。
3回ぐらいのイテレーションで、まずはシステムの全体像を把握できる。

その後のイテレーションで、モデル同士のリレーションを正しく書いていく。

つまり、前半のイテレーションでは、システムの全体像をつかむために速く成果物を作り、後半のイテレーションで成果物の品質を向上させていく。
すなわち、前半は漸進型開発、後半は反復型開発に切り替える。

【7-1】お客様は大量の成果物を好む。
詳細は見ないけれど。
お客様は根拠を聞きたがる。

お客様の打合せに合わせて、イテレーションを組み立てる。
お客様の打合せに合わせて、資料を作り、ブラッシュアップしていく。

まず、システム地図や機能一覧を作る。
そして、詳細を詰めていく。

マイルストーン(イテレーションの区切り)の単位で、成果物の範囲を決める。
そうすれば、要件定義が成果物の転記作業の繰返しにはならない。

【7-2】Q.リレーションシップ駆動要件分析RDRAでは、システムの実現可能性はどこで行うのか?

A.リレーションシップ駆動要件分析RDRAでは、要件定義とアーキテクチャの話を分けている。

・要件定義フェーズでアーキテクチャ設計は並行して行うが、要件定義とアーキテクチャ設計は別チームで行う

・要件定義チームから非機能要求を渡し、アーキテクチャチームでアーキテクチャ候補を返す

・二つのチームは手段で話をせずに非機能要求で話をする。

・後付けでもいいので「非機能要求があってアーキテクチャがある」という形は崩さないことが重要。そうすればアーキテクチャ決定の根拠が明確になる

要件定義チームとアーキテクトチームに分けた理由は何か?
アーキテクトが要件定義チームに入ると、ブレーキをかけがち。
例えば、その要件は、現在採用しているフレームワークやアーキテクチャでは実現できませんよ、とか。
あるいは、リプレース案件では、AsIsのアーキテクチャに引きずられて、ToBeのアーキテクチャを考えにくくなる。

【8】今日は、システム地図を書きます。
システム地図とは、アクター、ユースケース、画面、機能、データ、外部システムなどの項目を関連付けて、システムの全体像を表したもの。
システム地図は数時間で書ける。

RDRAのモデルは種類が多いので、丸一日かかる。
だから、今日はシステム地図を書きます。

【8-1】僕達のチームで作ったシステム地図はコチラ。
@spring_kumaさんのおかげで、かなり品質の高い成果物が作れたと思う。
@spring_kumaさんに感謝。

【9】システム地図を書いた感想:
僕の感想と、発表後に聴衆の方からあがった質問も書いておく。

【9-1】利用シーンとユースケースの使い分けが難しい。
混乱した。

利用シーンは、システムを使って嬉しいこと。
利用シーンは、ユースケースの根拠になる。
なぜ、そのユースケースは必要なのか、その理由は、こんな利用シーンが必要だったから、と。

【8-2】ユースケースは出しやすい。
ユースケースはアクターとシステムのインターフェイスになるから。

ユースケースは普通は画面で実現される。
つまり、ユーザがシステムとやり取りするI/Fが画面だから。
そして、画面のボタンが「機能(Function)」になる。

【8-3】要求が結びつくアイコンは?
それはアクターまたは利用シーン。

機能に要求を結びつけても説明しにくい。
モデルが複雑になる。

【8-4】メール送信や決済代行システムのモデルが表現しにくい。
バッチ処理で描こうとして、上手く書けない。
僕らのチームは、画面から予約ボタンを押したら、予約確認メールが飛ぶような仕組みで表現して逃げた。

神崎さんの回答は、バッチかどうかはアーキテクチャの話。
要件定義では、アーキテクチャの話は不要であり、システムと機能やデータがどのように関連付けられているか、が分かれば十分。

【8-5】システム地図を描く利点は、自分たちが弱い部分が判明するのが良い。
例えば、決済代行システムの部分が描きにくい、など。

システム地図が描きにくい部分のモデルを特定できれば、ユーザのヒヤリングをその部分に集中することで、ヒヤリングの精度を上げることができる。
不明点に重点を置いてヒヤリングすればいい。

【8-6】システムの地図の粒度は?

粒度はケースバイケース。
イテレーションごとに詳細化していく。
最初から細かく書く必要はない。

最初のイテレーションでは粗い粒度で、システム地図を描き、システムの全体像を把握し、自分たちの弱点を見出す。
その後のイテレーションで、ユーザにヒヤリングしながら、モデルを詳細化していけばいい。

【8-7】他チームのシステム地図で面白かった点は、利用シーンから考えたので、良い議論ができた、ということ。
例えば、貸会議室.comのお題は、利用者と貸主のマッチングサイトを作ること。

その利用シーンとして、貸主が空いている貸会議室を登録するだけでなく、貸会議室.comでは儲からないから、貸し会議室.comから貸会議室を予約取り消しする機能が必要だね、という議論があったらしい。
僕達のチームでは、そんな発想は出なかった。

つまり、利用シーンを元に、メンバー同士で議論していたら、そんな機能が必要である可能性まで深く議論できたことになる。

【8-8】貸会議室.comのお題というリッチピクチャがあったから、システム地図が描きやすい。
実際の要件定義では、貸会議室.comのお題のようなリッチピクチャは存在しない。
真っ白な所から、システム地図を描き出す必要がある。
要件定義は、そういうもの。

【9】リレーションシップ駆動要件分析RDRAの全体感想:

モデルベース要件定義テクニック―要件定義書がスラスラ作れる」を読んでいたから、4つの観点やモデルは理解していたが、実際の話を聞いてかなり理解できた。
神崎さんの話を聞くと、要件定義でよくある失敗を踏まえたノウハウがたくさん散りばめられている。

【9-1】要件定義フェーズでは、少人数の担当者が限られた期間で要件を収集し、ステークホルダーの合意を得て、要件を確定しなければならないプレッシャーがある。
また、作成した要件定義書は、その後の設計・開発フェーズの元ネタになるので、開発チームにとって非常に重要だ。

例えば、要件定義書で既に要件が漏れていたら、開発チームは対処できない。
受入テストになって初めて、要件漏れが発覚して、デスマーチになりがち。

あるいは、システムの価値は要件定義フェーズでしか得られない。
要件定義フェーズでシステムの価値を明確に定義できなければ、開発チームは、システムの価値を気にせず、ひたすら作ることだけに集中してしまいがち。
受入テストになって初めて、ユーザからこんなシステムが欲しいのではなかった、と言われる。
でも、開発チームにとって、そんなことを言われても、自分たちの責任ではないよ、と言いたくなる。

【9-2】リレーションシップ駆動要件分析RDRAのポイントは、二つあると思う。

一つ目は、モデル同士の依存関係に着目することで、要件の網羅性や整合性の根拠を説明しやすくなること。
ユーザからの質問や要件定義ビューで、要件の網羅性や整合性の根拠を語ることが出来れば、スムーズに要件分析できる。

2つ目は、要件定義もアジャイル開発のようなタイムボックス型の作業にすることで、要件定義の成果物をブラッシュアップしやすくなること。
最初から完璧な要件定義書を作るのではなく、イテレーションに応じて、粒度を変えて、詳細化するタイミングを設定すればいい。
例えば、2ヶ月間で要件定義を終わらせるならば、1週間毎にユーザヒヤリングの場を設けてマイルストーン化し、最初はシステム地図で全体像を把握し、機能一覧を作り、詳細化していけばいい。

このテクニックを実際の現場でも使ってみようと思う。

| | コメント (0)

2014/12/21

「アーキテクチャについて知ってみる」の感想 #Devkan

DeveLove関西の「アーキテクチャについて知ってみる」に行ってきた。
感想をメモ。
後にスライド資料が公開されたら、リンクしておく。

【元ネタ】
アーキテクチャについて知ってみる - DevLOVE関西 | Doorkeeper

情報処理推進機構:日本型企業が目指すエンタープライズアジャイルの世界
~開発現場の苦労話を聞き、成功への道をイメージしよう化

アーキテクチャとアジャイル プロジェクトをまともに進めるための両輪について #DevKan #devlove - Togetterまとめ


アーキテクチャについて知ってみる 「ゆらぎのある決定」以降のまとめ #DevKan #devlove - Togetterまとめ

DevLOVE関西 アーキテクチャについて知ってみる 2014/12/20 Hiroya Blog

「アーキテクチャは組織構造に従う」という経験則には2つの意味がある: プログラマの思索

【1】僕の問題意識としては、「アーキテクチャは組織構造に従う」という経験則には2つの意味がある: プログラマの思索に書いたように、プログラマが考えている「あるべきアーキテクチャ」がサイロ型組織や政治的利害によって、複雑怪奇なアーキテクチャに変わってしまう理不尽さにある。

多数の利害関係者の要望を受け入れていくうちに、アーキテクチャは複雑怪奇になり、保守性も低くなる。
結局、保守コストが増大し、機能追加すらも多大な工数がかかり、顧客自身も不満を漏らす。
そして、同じような目的を持つ業務システムを4~5年おきにリプレース案件と称して、リビルドし直す開発サイクルを繰り返す。

そのやり方は、丁度、購入したマイホームを新規建築しても、30年おきに壊しては作り直す日本の土建業界の風景に似ている。

【2】講演では、@yusuke_arclampさんの講演がすごく参考になった。
@yusuke_arclampさんのスライドで興味深いのは、ITサービス運営モデルに、開発プロセス・業務プロセス以外にも、運用プロセスや企画プロセスが明示されている点。

【2-1】4つのプロセスは、僕は下記で理解している。

1)開発プロセス・・・プログラマによるシステム開発
2)運用プロセス・・・インフラ・アプリ保守チームによるシステム保守
3)業務プロセス・・・ユーザ企業の従業員・情報システム部門メンバーが利用者にサービスを提供するための業務
4)企画プロセス・・・情報システム部門が、利用者の行動履歴をKPIなどで分析し、システムの機能改善やシステムのあるべき姿を見出して、開発チームへ要件を渡す

【2-2】実際のシステム開発では、開発したら終わりではない。
業務システムの初期構築費用は数千万~数億円もかかるから、最低5~10年は使わないと減価償却で元が取れない。
だから、その後の運用保守を想定したシステム構築をしなければならない。

その場合、システム側の観点である運用プロセスとユーザ企業の観点である業務プロセスの整備が重要になってくる。
運用プロセスの目的は、システムを安定稼働させることだ。
普通は、SLAを運用チームとユーザ企業が結び、サービス品質を保つ。

業務プロセスの目的は、例えば、バックエンドで従業員の業務や利用部門の業務をサポートすること。
あるいは、ECサイトの問い合わせ窓口やヘルプデスク業務を支援すること。
業務プロセスを円滑に行うために、ユーザマニュアルないしオペマニというドキュメントが必要になってくる。

企画プロセスの目的は、実際のシステム利用ユーザの行動履歴や利用ユーザの要望を元に、システムの改善要望をまとめることだろう。

【2-3】しかし、普通の観点では、運用プロセスや業務プロセス、企画プロセスは当たり前すぎて、漏れてしまうような気がする。
システム開発時は、納期までに納品させるだけで精一杯だ。
その後の保守、業務プロセスはシステム企画段階で検討はするものの、開発案件になったら、とにかく作るだけで精一杯。
納品間際に、オペマニを作って、保守チームと業務担当に渡して、後は任せました、で終わってしまいがち。

だから、アーキテクトは、システム企画段階だけでなく、システム開発の各工程でも、現在作っている成果物が運用・業務・企画プロセスにどのように影響していくか、考えておくべきなのだろう。

【3】僕は、渡辺幸三さんのDOAの3機能モデルを念頭に、@yusuke_arclampさんのITサービス運営モデルでは、アーキテクチャの複雑さをどのプロセスに押し込めるか、という方針はあるのか、と聞いた。

【3-1】その意図としては、「販売管理システムで学ぶモデリング講座」によれば、渡辺幸三さんのDOAの3機能モデルでは、システムは業務・機能・データの3階層にレイヤ化されるが、業務とデータ層は複雑にし、機能レイヤはシンプルにする、という話があったからだ。
その理由は、機能に当たるプログラムは、開発保守にコストがかさむし、複雑過ぎる機能は業務体制の硬直化を招くから。
特に、めったに使わない機能を作りこむよりも、そんな状況ではどのように対処すべきかを業務マニュアルに書く方がシステムコストは安く付くから、と。

@yusuke_arclampさんの解答は、利用状況によって異なる、ということだった。
運用プロセスに負担を掛ける場合もあれば、開発プロセスを軽くしてシステムを作って業務プロセスでカバーする方法もありますね、と。

【3-2】僕としてはちょっと肩透かしを食らった感じだったけれど、確かに、@yusuke_arclampさんのコンテキストでは、こうあるべきという方針は言いにくいように思えた。

個人的には、渡辺幸三さんのDOAの3機能モデルが主張するように「データモデルと業務モデルは複雑にし、機能モデルは単純にする」方針が一番しっくりする。
機能モデルに相当するシステム部分は、長年のシステム改修によって、どうしても肥大化し複雑化して、手に負えなくなる。
また、業務システムでは、肝心のトランザクションデータやマスタデータの精度を維持していく方が重要であり、そのためには、業務プロセスの精度を上げてデータの精度を上げていく手法を取る方向になるだろう。

【3-3】例えば、「販売管理システムで学ぶモデリング講座」では、出荷指示時に帳簿の在庫数と実際の倉庫での在庫数が違う場合、積極的に差数を認めて出荷指示する場合と、出荷指示を一旦取り消して在庫に応じた出荷予定を作り直す場合の2種類のどちらを選ぶべきか、という問題を提示している。

前者は業務モデルよりも機能モデルを複雑化する方向、後者は機能モデルよリも業務モデルを複雑化する方向の立場で異なる。

渡辺幸三さんの考えでは、後者のように、実在庫と帳簿在庫が一致するような運用品質を追求すべき、という立場を取る。
なぜなら、実在庫と帳簿在庫で差が発生する状況をずっと放置していては、在庫管理レベルはいつまで経っても向上しない。
だから、実在庫と帳簿在庫は一致すべきである、という運用になるように、業務プロセスがたとえ複雑になったとしても、業務プロセスの品質を上げるべきだ、と。

僕も渡辺幸三さんの考えに同調する。
その観点から考えると、データ重視の立場ならば、運用・業務プロセスが複雑化しても、企画・開発プロセスは軽く回すべき、という方向になるのだろうと推測する。

【4】他に気づいた点は、@yusuke_arclampさんのITサービス運営モデルでは、運用・業務プロセスは保守的かつ重厚になりがちで、企画・開発プロセスは変化に追随しやすく、軽量化の方向になりがちだという点だろう。

なぜなら、運用プロセスを担当する保守チームは、本番システムが安定稼働するのが最優先であり、頻繁な機能追加でシステムを不安定にさせたくない。
アジャイル開発のように、毎週・毎日のようにリリースするリスクは犯したくない。

また、業務プロセスを担当するユーザ企業の従業員も、バックエンドの事務作業の手順が頻繁に変わるのは好まない。
毎週のように新しい作業手順を覚えるのは苦痛だし、開発プロセスや運用プロセスでカバーしきれなかったデータ補正を担当させられるのは嫌だから。

一方、開発チームはアジャイル開発で小規模リリースを実現して、安定してリリースできるようにしたい。
最新の技術を取り入れたり、開発環境をブラッシュアップして、生産性を高めたいから。
そのためには、開発プロセスを作り直すことも厭わない。

また、企画プロセスでは、利用ユーザの行動履歴をデータマイニングして、新規事業を生み出したい。
リーンスタートアップのようなプロセスを導入して、システムの価値を高めるような方向へ持って行きたい。

すなわち、運用・業務プロセスの担当者と、開発・企画プロセスの担当者は、根本的に対立し合う状況にある。
前者は保守的であり、後者は革新的な立場になるからだ。

アーキテクトは、双方の利害を認識し、上手く調停する役割が求められるわけだ。

【5】最後に@yusuke_arclampさんへ質問した内容は、アーキテクトはユーザ向けにポンチ絵を描いて説明する時が多いが、アーキテクトが使うモデリングツールはお勧めの物があるか、聞いた。

解答は、パワポですね、と。
思わず皆笑ってしまった。

LibreぽざうねさんはTwitterを使っています: "質問:「使っているモデリングツールは何?絵で書いて意図を伝えるためにうまく使えるツールはある?」 #DevKan"

かわべ たくやさんはTwitterを使っています: "鈴木さん 「パワポ!(即答  これは理由があって、経営者の年齢層の方が見れるフォントサイズで作らざる得ない制約があるので、使ってます。」 #DevKan"

astahとか、Enterprise Architect、ERWinなどを期待していたが、やはりパワポだよね~と理解した笑

とはいえ、僕としては、astahを使って、アーキテクトが説明に使うモデルを表現できないか、色々試してみたいと思っている。


| | コメント (0)

2014/11/27

astah SysMLのROS連携プラグイン

astah SysMLのROS連携プラグインの記事があったのでメモ。
ROS(an open-source Robot Operating System)のモデルをastah SysMLでリバースしたりエクスポートできるらしい。

【参考】
astah* Users Community Site - フォーラム SysML - Ros連携プラグイン

[Project] ROS + SysML (astah-plugin) ≪ Sugar Sweet Robotics

自律ロボット開発にROSを使うべきいくつかの理由 - MY ENIGMA

ソフトとハードの交差点:ROSとRTミドルウェアの比較 - livedoor Blog(ブログ)

(引用開始)
ROS (Robot Operating System) は,ロボットシステムをプロトタイピングするのにはとっても便利なんですが,システムデザインを行う工程との親和性に関してはあんまり論じられてない感じがします.
この辺はRTミドルウエアがよく出来てる.
んで,文句ばかり言っても仕方ないので,SysML with ROSということで,作ってみました.
(引用終了)

最近のプログラミング技術の傾向として、Webサービス、クラウドなどのインフラ周り、ビッグデータと統計解析を含めたデータマイニングだけでなく、組み込みプログラミングも盛り上がっているように見える。
例えば、Kinectとか、iOSのヘルスケア・アプリとか、ウェアラブルデバイスと組み合わせたアプリが面白そうだろう。

だが、上記の記事では、自律ロボットのオープンソースのプログラミング環境としてROSというものがあるらしく、フリーの割にかなりのことができるみたい。
SysMLと組合せて、ロボットの動きをモデル化するのは面白そう。

この辺りは僕は全く知識がないけれど、お金の計算やくだらない業務のアプリを作っているよりも、ロボットを動かすためのプログラミングの方がはるかに楽しそうな気はする。
特に、家電メーカーとプログラマが手を組めば、面白い組込製品やデバイス、サービスを生み出すことができるかもしれない。

色々調べてみる。

| | コメント (0)

より以前の記事一覧