プログラムの大海に溺れないために
•
11 likes•2,961 views
システムの利用者にヒアリングしてもシステムのことが分からず、メンテナンスされたドキュメントもなく、最新のプログラムソースもない状況での、、 大規模な既存システムを調べるモデリング手法の紹介
More Related Content
Viewers also liked
Similar to プログラムの大海に溺れないために
Similar to プログラムの大海に溺れないために (20)
More from Zenji Kanzaki
More from Zenji Kanzaki (20)
Recently uploaded
Recently uploaded (16)
プログラムの大海に溺れないために
- 1. プログラムの大海に溺れないために 大規模な既存システムを 調べるモデリング手法 JavaFesta 2011 株式会社バリューソース
- 2. • ㈱バリューソース • 代表取締役 社長 要件のツボ • 神崎 善司 • zkanzaki@vsa.co.jp • はてな：good_way • twitter：zenzengood • 仕事の領域 • 要件定義を中心としたコンサルティング • オブジェクト指向、要件定義などのセミナー講師 • 要件定義ツールの開発
- 3. 上流工程勉強会 主催 • ２０１１年 開発プロセス 保守性 アーキテクチャ 要件定義 • 第１１回 DDD助走編 クラス図 モデリング演習 第１０回 要件のツボを使った要件定義演習 第 ９回 アーキテクチャ設計 演習 第 ８回 ２時間で要件定義 第 ７回 現状分析のモデル化手法 第 ６回 保守に必要なドキュメント 第 ５回 保守性コストを下げる具体的な方法を考えよう！ 第 ４回 開発コストを下げる具体的な方法を考えよう！ 第 ３回 開発プロセス第３段 「包括フレームワークを分析する」 第 ２回 開発プロセス第２段 「包括フレームワークを分析する」 第 １回 開発プロセスの工程の考え方 • ２０１２年 テーマ：Domain Driven Design • 上流工程のための基礎的なテクニックの習得 • • １１月１９日 • 既存システムの分析モデリング 演習 • 申込：ATND http://atnd.org/events/21040 要件のツボ
- 4. 既存システムを取り巻く状況は プログラム ドキュメント 利用者
- 5. キングファイルが積み上がる ドキュメント 書き 写す プログラム 調べる対象がはっ きりしている
- 6. プログラム単位のドキュメント化 • 混沌とした一枚岩のシステムをプログラム単位で調べてもシス テム化の判断には役に立たない Prg
- 7. 札幌市にはどのような機能・働き がありますか？ プログラムを調べる ことは、家を一軒々 調べるのと同じ
- 8. そんな現場では • 何を書くんですか？ • どの範囲まで書くんですか？ • どの粒度で書くんですか？
- 10. そして… AS-ISの資料作成がいつのまにかTO-BEの資料作成に この部分は君が詳しい から次期システムもこ こは君が担当してくれ
- 11. このようなときのフレーズ 既存のシステムとほぼ同じ….. 実際は ほとんど同じ
- 12. 既存システムと同じで なんでこんなにコストがかかるの？ コスト コストに対する認識の差 コスト 新規 既存 既存 システム システム システム システム利 とほぼ同 システム開 用者の視点 じ 発者の認識 保守限界が来たのでシステムを再構築する！
- 13. どうやって認識の差をうめるの？ 仕様を定義する時間を圧縮する 既存システムから効率的に情報を取得する 仕様を決 めるため のコスト 新規 既存 既存 新規 システム システム システム とほぼ同 システム じ ビジネスルールを取得する
- 14. 仕様を決 めるため のコスト 新規 新規 システム システム コストをかけずに既存システムから情報 を取り出す 14/54
- 15. 何を調べたいのか • 現在のシステムはこうなっている • 次のシステムの方向性はこうだ！ • だから次のシステムはこうする • 必要なことを 判断出来る情報が重要！ • 判断するためには何を何のためにが分かる必要がある • そのために つじつまのあう説明ができる • 詳細な情報は必要なときに調べる
- 16. ルール 都市設計における道路整備 そのために… 宅地造成等規制法 ～ 宅 地 商業地 宅地 住所が現実と 結びつける
- 17. 目指すべきは • プログラムに左右されずにシステムが何を行っているかを明らかにする • システムに関わるビジネスルールを整理する • 既存システムを調べる時に大事なことは • 何ができればいいのか • どう整合しているのか • 主要な機能は？ • 主要なデータは？ • 機能とデータの関係は？ • そこからシステムに埋もれたビジネスルールを掘り起こす • そこで… • システムを捉えるための地図が必要だ！ • 地図の代わりになるものは？
- 18. システムの地図はモデルだ！
- 19. えっ モデリング ほんとか？ • 既存のシステムを調べているんだ モデリングしたいわけではない • モデルと既存のシステムの関係は？ • 既存のシステムは綺麗ではない • 綺麗なモデルは現実と離れていく • 綺麗なモデルは結局何を表しているんだ！
- 20. 既存のシステムとは • 様々な制約によってプログラムが混沌としている Prg Prg Prg Prg
- 21. どうモデルを活かす • 現実とつながりながら現実の混沌に 影響されずに 整理する • そのためには… • 前提 • 細かなロジックにこだわらなくていい • 既存システムの仕組みは無視していい
- 22. 現実と つながりながら現実の混沌に影響されずに整理する 入力 モデル 出力 情報 情報 タイミング タイミング 機能 機能 機能 機能 機能 機能 システム境界のレベルで一致させる 主要なテーブルを意味的なつながりで整理 入力 既存システム 出力 情報 情報 タイミング タイミング Prg 物理制約 時間制約 開発時制約
- 23. 何を捉える • システム境界とデータを捉える だから～ 情報のない中でどうやってやるんですか？
- 24. 資料がないと言っても….. • たいてい以下のドキュメントはある • テーブル定義書 ⇒ RDBスキーマ • 電文レイアウト • ファイル交換のファイル定義書 • 稼働しているシステムがある • 画面・帳票を確認できる • 保守されているシステムについては • データと他システムにつながる部分の情報はある
- 25. システムをよく知らないといっても • 保守を行っている人は • この機能はこういうことを行っている • ここでこうするとあそこに影響する • こうしたいときはここをこうすればいんだよ • 制約の説明 • ここは時間がなくてこうしちゃったんだ！ • この時代はこういうルールだったんだ Why
- 26. 分析 どう分析するのか？ 26／54
- 27. 分析方針 • 集められる情報から集める • 抜けたピースを探す • 抜けたビースを創造する • 集めた情報の特徴から切り込む • 分類する • 関係をつかむ • そこでビジネスしている人のノウハウを体系的に視覚化する
- 28. ビジネスルールの表現 • ビジネスルールの表現方法 • 構造的なルール • 情報の関係性 • 振る舞いのルール • 状態の変化 状態 状態 • 条件 • 表 • デシジョンテーブル
- 29. システムの種類を意識する • データ集約的なシステム • 入れポン 出しポン • 入力と出力を把握できればいい • 状態監視的なシステム • 監視対象があって今を意識 • 一連の手続きの管理 監視 • プロセス管理 対象 • ロングトランザクション管理 • 状態としてルールを整理
- 30. ビジネスルールを捉える サービス 規約 機能 機能 機能 機能 入出力のタイミング 機能 と情報から振る舞い のルールを導き出す 情報構造を整理し 主要な情報と制約、 ルールを導き出す 外部システム
- 31. 材料を揃え・構造化してノウハウを視覚化する • 入出力情報 • ビジネスルール • データ 利用規約 パンフレット ノウハウ
- 32. どうやってモデルを作る 32/54
- 33. 認識する情報 • 入出力 • データ • 画面 使用している画面 • テーブル定義書 • 帳票 〃 • ファイルレイアウト • 通信 電文レイアウト • データ交換 • ビジネスルール • File Fileレイアウト • パンフレット • DB テーブル定義書 • サービス規約 利用規約 ….
- 34. 手順 • 材料を集める • ビジネスルールを掘り起こす • 画面 画面をハードコピー • 補助的情報をもとに関係を • 帳票 〃 • XX規約 • データ RDBのスキーマ ファイルレイアウト • サービス利用規約… • 通信 通信電文 • パンフレット • 材料を記録する • 情報を分類する • 材料をアイコンとして登録する • パッケージング • 関係をつなげる • 構造化 • パッケージ間の関係を整理する • 材料を情報化する
- 35. モデルの全体イメージ 画面 機能 データ 受信 機能 データ データ システム 電文 送信 機能 A機能 電文 定周期日
- 36. ビジネスルールを明らかにする 条件 画面 機能 構造のルール データ 受信 機能 データ データ システム 電文 送信 機能 A機能 振る舞いのルール 電文 定周期日
- 37. 記述のパターン 画面処理 Fileによるデータ交換 画面 機能 File交換入 機能 File File交換出 機能 File 通信 システム 受信 機能 DBによるデータ交換 DB交換入 機能 データ 電文 DB交換出 機能 データ 送信 システム 機能 電文 定周期 定周期日 A機能 送信 YY機能
- 38. 材料を集める：システム境界を捉える データ交換 DB 受ける 帳票 送信 システム 通信 受信 画面 渡す File データ交換
- 39. 入出力をイベントで統一的に扱う • システム境界をイベントとして扱う 画面 • ポイント 受信 • 画面やデータ交換 送信 は実体に合わす 送信 File 受信 DB 画面 システム イベント
- 40. 材料を集める：データを捉える データ交換 DB 受ける 帳票 データ 送信 システム 通信 受信 データ データ 画面 渡す File データ交換
- 41. データと機能の整理 • データ • ほとんどの場合DBのテーブル整理 • ER図の作成：主要なテーブルを識別 • 機能 • イベントに対応付ける • バッチに対応付ける • 機能とデータを結びつける • CRUD <CRUD> イベント 機能 データ 画面 機能 データ
- 42. システム境界とデータから 機能を洗い出す 画面 システム 機能 受信 <CU> 受信 <U> 機能 機能 <R> 受信 システム <R> 機能 送信 データ <RD> 機能 送信 送信 CRUD File
- 43. 状態を整理し振る舞いをルール化する A画面 DB 受信 受ける A画面 開始前 開始済み A_File 受信 B_File B画面 システム 解約待ち 送信 送る A_File XXX / YY機能 状態 状態 状態の遷移として整理
- 44. システムが関心をもつ状態を捉える • ユーザが認識している状態を把握するために • 画面上の情報 • オペレータが画面の振る舞いとして認識しているもの • テーブル上の区分やフラグなど • テーブルの関係 • ビジネス上の概念 • ユーザ認識しているID・No
- 45. 隠れた情報をあぶり出す • 隠れた情報 • 複数の意味をもつデータ • 意味の違うものを一つのレイアウトで扱う • 複数のイベントを一度に扱う • タイミングが隠れる システム 情報
- 46. サブシステムに分類する 画面 機能 受信 機能 受信 受信 機能 システム 機能 送信 送信 機能 送信 File
- 47. 分け方にはパターンがある 共通系 会員管理 …. …. 横展開
- 48. 掘り起し岩を砕く 46/54
- 49. プログラムからモデルの分類の確度を測る プログラム
- 50. ボトムアップの分析 共通系 横展開 データ（テーブル）を分類 A プログラムとテーブル の関係を調べる A プ ロ グ プログラム データ CRUD ラ ム を 分 類
- 51. パッケージ間のインターフェース化 • 次期システムのパッ ケージ化の参考にする • 段階的なシステム再構 築の対象を決める
- 52. モデルイメージ モデル名はRDRAベース 画面・帳票モデル イベントモデル プロトコルモデル データモデル 機能複合モデル（CRUD）
- 53. まとめ ビジネス モデル ルール • システム境界とデータで合 機能 機能 わせる 機能 機能 機能 機能 • 特徴をつかみ洗練化する • 分類し整理する • 得られる情報から切り口を 探し整理する 既存システム Prg • ビジネスルールを Prg Prg 把握する