astahによるUMLモデリング

2017/06/18

Redmine v3.3.3のER図をastahでリバースしてみた

Redmine v3.3.3のER図をastahでリバースしてみた。
自分のためにリンクを貼っておく。

【参考】
MAEDA, Goさんのツイート: "@flower_norn データベース設計のドキュメントは残念ながら見たことなくて、db/schema.rb でテーブルレイアウトが確認できるくらいです。 rails-erdというgemを使ってER図を作ってみました。 https://t.co/X7Ztl2AHos"

さやか/Sayakaさんのツイート: "@g_maeda Redmineのデータベース設計について記載されたドキュメントなどもしご存知であればご紹介いただきたいです。ブログやmastdonなどで紹介すると、意外と知りたい人がいるかもしれないです。私もDBを触ったことがあって、なぜインクリメントするのか不思議でした。"

RedmineのER図: プログラマの思索

【1】Redmineに蓄積されたチケット情報に対し、障害・課題・進捗・工数などの情報をある特定目的で集計したい場合に、ER図やDB設計書があると便利だ。
直接SQLを発行して、データを抽出した方が早いから。

そういう意図でRedmineのER図を見ると、どのテーブルもサロゲートキーなので、SQLは書きやすい気がする。

【2】なお、渡辺さんの記事では、Railsのようなサロゲートキーが強制されたデータモデリングに関する意見があり、参考になる。

「強制されたサロゲートキー」の事例を眺める: 設計者の発言

【3】astahのDBリバースプラグインはすごく優秀。
稼働中のDBに対し、JDBCがサポートされていれば、ほとんどすべてのスキーマ構造をリバースしてくれる。

DB リバースプラグイン | Astah

また、DB定義書もExcel出力してくれるので便利。
「Excel設計書を直す→DDL作成→DDLを環境へ反映」流れではなく、「DDLを作成→DDLを環境へ反映→astahでDBリバース→Excel設計書を出力」の流れの方がスムーズと思う。
Officeファイルの保守ほど面倒な作業はないから。

一方、ExcelのDB定義書からastahのER図をリバースするプラグインもあるので、astahは正直手放せない。

Excel-ERモデルインポートプラグイン | Astah

[pro] エンティティ定義書エクスポート

| | コメント (0)

2017/06/15

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク

astahの事例を探していた時に、設計書とモデル、プロセスをつなぐ為のアイデアが書かれた資料を見つけたのでメモ。
以下はラフなメモ書き。
間違っていたら後で直す。

【参考】
モデルへの参照を含む多様な設計情報の継続的統合ドキュメント化に向けて

【1】以前、Redmine大阪で宿口さんの講演を聞いた時、機能安全規格を満たすプロセスをRedmineで実現する話があった。
その実装方法を聞くと、Wordの要件定義書ドキュメントの目次の各タイトルに、チケット番号のリンクが貼られていて、そのリンクからRedmineチケットとWordドキュメントの整合性を取るような仕組みを実装されている、とのことだった。

第16回Redmine大阪の感想 #RedmineOsaka: プログラマの思索

その時は、なぜそんなやり方が必要なのだろうか?と不思議に思った。
確かに、WordドキュメントにRedmineのチケット構造が同期されるので、見通しは良くなるが、それはRedmineのプラグインのような一機能で実現した方が良いのではないか?と思ったからだ。

WordやExcelとRedmineを連携しようとすると、結局、VBAマクロを駆使することになり、VBAを扱うのが苦痛だから(笑)

一方、上記の資料を読むと、Wordの要件定義書やアーキテクチャ設計書でモデルや作業構造をまとめるのががなぜ必要なのか、その理由が書かれている気がした。

【2】Word文書で組込みソフトウェアのモデルの絵や説明文をまとめたとする。
しかし、モデルは改変されるので、Word文書に書いた内容やモデルの絵はどんどん古くなる。
改変のたびに、逐一、モデリングツールで描いた絵をコピペしなくてはならない。

一方、要件管理ツールにあるソフトウェアの要件もどんどん変わる。
要件、モデル、そしてそれらの正しさを保証するプロセスも影響を受けて、要件の変更のたびに、派生的に編集作業が発生してしまう。
ドキュメントの保守作業ほど、無駄なコストの発生源であるものはないだろう。

つまり、要件とモデル、設計ドキュメントのトレーサビリティと変更の同期が課題になってくる。
また、標準プロセスで必要とされる成果物やドキュメントが揃っているか、という成果物の保証も関わってくる。

これらの課題はどうやって解決すべきなのか?

【3】上記の資料のストーリーは以下のようなイメージ。

①astah製品でUMLやSysMLなどのモデルを描く

→astahのOfficeプラグインによって、astahで描かれたモデルは、ExcelやWordに埋め込まれる。
 Officeプラグインのお陰で、astah上のモデルの変更は、ExcelやWordに同期される。

Office連携 プラグイン | Astah

②astahのGSN製品で事前に、標準プロセスを描いておき、必要なドキュメントを洗い出しておく

→astahのGSN製品から、要件定義書や設計ドキュメントの雛形を出力する
 標準プロセスに必要なドキュメントは、それぞれのWordやExeclにマッピングされ、astahのGSN製品のD-caseに対応付けられている。

→WordやExcelのドキュメントに、ソフトウェアの要件や仕様を記述していく。
 ドキュメントの中のモデルは、astahのUMLやSysMLに連動されている。

すなわち、astahのGSN製品で機能安全規格が保証された標準プロセスを構築し、その標準プロセスに対応付けられたOfficeドキュメントは、astahGSNで同期されている。
さらに、Officeドキュメントに貼られたモデルの絵は、astahファイルから参照されており、astahのモデルが変更されたら自動的に同期される仕掛けになる。

以前、astahのOffice連携プラグインを使ってみた時、このプラグインのメリットがあまり感じられなかった。
しかし、上記のような使い方をするならば、Office連携プラグインはとても重要な一機能になる。

Office連携 プラグイン | Astah

Astahプラグインの資料のリンク: プログラマの思索

【4】理論的には、上記のようなやり方で、Officeファイルの設計書・UMLやSysMLやER図やDFDなどのモデル・機能安全規格を満たす標準プロセスの3つは、全てastah製品で連携・同期・統一されることになる。

平鍋さんは、たぶんそのようなイメージでastah製品シリーズを作られたのではないか。
そう考えると、非常に上手く考えられているなあ、と感じる。

但し、上記のやり方はあくまでも理想論であり、本当にうまくいくのかは分からない。
実際のソフトウェア開発の現場における要件定義、設計の作業はもっと泥臭いし、労働集約的な作業ばかりだからだ。

たとえば、プログラム開発はGitという非常に強力な構成管理ツールがあるので、大人数の共同開発がやりやすい。
そして、Jenkinsのような強力なビルド管理ツール、Redmineのような強力なチケット管理ツールを組合せた作業環境が既に一般的だ。

一方、要件定義や設計では、astahのモデルやOffice文書は、Gitのような構成管理を行う環境があまり整っていないために、差分やマージ作業、プルリクエストのような共同作業がやりにくい。
また、モデリング作業で発生するQAや課題が発生して、それを解決して、その内容をモデルに反映していく、という一連の流れとチケット管理が、まだ上手く連動できていない。

個人的には、astahのモデル自身も、SubversionだけでなくGitで構成管理できるようにするのが1つの課題ではないか、と思う。

Subversionプラグイン | Astah

astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索

TortoiseSVNでastahファイルのリビジョン間の差分を表示する方法: プログラマの思索

また、astahのモデルに要望や課題、仕様追加を反映していく作業と、astahのモデルの変更箇所をRedmineチケットを経由してリンクさせるような仕組みも必要ではないか、と思う。

Enterprise Architectでは、RedmineやTestLinkと連携するプラグインがあるので、astahでも実現してもいいはずだ。

Enterprise ArchitectとRedmineを連携するアドオン: プログラマの思索

TestLinkとEnterprise Architectを連携する: プログラマの思索

【5】astahには、たくさんの可能性があると思っている。
astahを使ったモデル、そのモデルを保証するプロセスの連携方法は、もっといろんなアイデアがあるはずだし、色んな実装方法があるはずだ。

近々、astahの勉強会を開くので、色々議論してみたい。

astah関西 第1回勉強会 - connpass

【追記】
似たようなことは既に他の人も考えている。

Astah*GSNより、ASCEのほうが、ビジネス的には、大きく出来る・・・ - ウィリアムのいたずらの開発日記

Astah GSNが、UML、SysMLと連携してほしい人! - いっぱい!! - ウィリアムのいたずらの開発日記

| | コメント (0)

2017/06/11

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai

astah関西 第1回勉強会を7/14金に開催します。

【参加申込み】
astah関西 第1回勉強会 - connpass

astah*Professionalファーストインプレッション: プログラマの思索

Enterprise Architectの使い方のリンクとメモ: プログラマの思索

astahによるモデリングのメモ: プログラマの思索

(引用開始)
関西圏でモデリングツールastahを使ったモデリング技法と実践事例に関する勉強会を開催します。

astahを使っている人、モデリング大好きな人が集まって、より良いモデリング技法や実践事例を共有する場として設けます。

モデリングの対象は、astah製品を使った設計技法が中心なので、UMLに限らず、ER図やDFDなどのデータモデリング、SysMLなどの組込ソフトウェア設計なども含む予定です。

興味のある方は、ふるってご参加ください。

<テーマ>
キックオフを兼ねた第1回勉強会を開催します。

チェンジビジョン(株)の方にも来阪して頂いて、astah製品の紹介と実際のモデリング技法について講演して頂きます。

次回の参加希望者が多ければ、勉強会スタッフを募集して継続します。
(引用終了)

【開催の発端】
僕自身は、Judeの頃から使い始めて、astah Professionalを2009年から使い続けています。
主な使い道は、UMLのお勉強が発端で、その後は、システム提案や要件定義の時のラフスケッチ、開発プロセスの運用ルール策定やプロセス分析です。

過去に、RationalRoseやEnterprise Architectを開発案件で使用した経験はありますが、正直使いづらかった。
2000年代中頃は、UMLがブームで、設計フェーズをUMLのダイヤグラムで代用する思想が多かったけれど、たくさんの修正が発生したら、ダイヤグラムのマージが面倒で、複数人でダイヤグラムを共有して作業するのも難しい。
結局、astahでも、個人で使用する場面が多いです。

astah Professionalの良い所は、頭の中にあるモヤモヤした内容をUMLの各種ダイアグラムでラフスケッチを即座に描ける点。
1つの問題や事象を、複数の観点の動的・静的ダイヤグラムで描いて、整合性や詳細を詰めていくことが自然にできる点が良かったと思います。
絵で描くと、このI/Fの仕様が甘い、とか、このプロセスは意外に複雑だな、とか、色々気づきが得られやすい。

また、Redmineの運用ルールを説明する時、運用フローをアクティビティ図やステートマシン図で描くと、他人に説明しやすい。
誰とキャッチボールするのか、何がトリガーになるのか、が明確になる点が良いです。

さらに、過去にアジャイル開発やRedmineコミュニティで数多くの発表を行った時、astahで事前に書き溜めたラフスケッチがとても役立ちました。
そういう経験をしてきて、astahによるモデリング技法を周囲の人達と共有したいという気持ちが以前からあって、周囲の後押しを元に、ようやく実現する運びになりました。

僕の周囲ではそもそも、astahを使っている人がいないので、この勉強会が継続できるか分かりません。
関西で、astahを使っている人、astahに興味がある人、UMLやDOAや組込ソフトウェアのモデリング技法に興味がある人が集まるといいな、と思います。


| | コメント (0)

2017/05/05

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。
ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。
以下は書きかけ。

【参考】
第0回:人月の神話とはなんなのか?(解説編)|本気で読み解く”人月の神話” | GiXo Ltd.

第2回:銀の弾は無いけど、”銃”はあるよね|本気で読み解く”人月の神話”(第16章) | GiXo Ltd.

ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ

ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間

【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の内容自体は10年以上前のWebやIT業界の話が多く、内容も古くなっているので、新たな知見が得られるという感覚はしない。
しかし、「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の中に、「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という言葉があって、すごくしびれた。

(引用開始)
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、3世紀にわたって偉大な進歩を遂げた。
この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。
複雑性が本質である場合には、この方法は使えない。
(引用終了)

上記の内容は、ブルックスの「人月の神話」の一節そのまま。
なぜ自分がすごく衝撃を受けたのか、考えてみると、ソフトウェア開発の本質に触れているものだから。
たぶん、僕の心のなかにある、ソフトウェアに対する楽しさだけでなく、ソフトウェアへの憎しみというか、なぜこう思い通りにソフトウェア開発をコントロール出来ないのか、という腹立たしさに触れている気がしたから。

「偶有的」という言葉も引っかかる。
この言葉は、古代ギリシャのアリストテレスの哲学から引用したものらしい。

(引用開始)
アリストテレスに従って、難しさを本質的なものと偶有的なものに分けて考えてみよう。
ここで、本質的な複雑さとは、ソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、目下の生産にはつきまとうが本来備わっているものではない困難のことである。
(引用終了)

自然科学、特に数学や物理学では、できるだけ単純なモデルを作り、そこから演繹される性質や定理を証明することで、自然現象を多面的に分析しようとする。
複雑なものを複雑なまま捉えるのではなく、理想的な単純なモデルに純粋化して、人間の思考に耐えられるレベルにして、数多くの観点で徹底的に分析するのが自然科学のやり方。
シンプルなモデルを「徹底的に」分析し尽くして、全ての特徴を洗い出し、全てを因果関係や演繹でまとめ上げて一つの理論体系にするのが自然科学のやり方。

すると、シンプルなモデルをどのように事前設定するか、どのパラメータを重視して選択しておくか、というのが重要になる。
その部分が、科学者の腕の見せ所。

たとえば、物理学では、理想気体みたいに、現実から離れるけれど、シンプルなモデルを設定することで、計算や実験を扱いやすくするモデル作りは一般的だ。
熱力学、相対性理論、量子力学など、色んな分野の物理学でもその手法を用いている。

物理学は一つの認識論: プログラマの思索

数学でも、一流の数学者は、自分で理論を打ち立てたい時、最も組合せの少ない公理や公準を直感的に選んで、そこから矛盾が生じないように設定しておく。
そこから、「誰々の定理」のような重要な結果を導き出す。
一流の数学者がすごいのは、最も組合せの少ない公理を直感的に把握できること、そして、重要な定理を導く時に、ロジックの穴になりそうな難しい場所を事前に察知して、それをくぐり抜けるために、あらかじめ「誰々の補題」みたいな補助的な公式を用意しておくのが上手い点。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

このやり方がすごく成果を上げているので、人文科学や社会科学でもそのやり方を真似ているように思える。
特に、経済学は典型的だろう。
マクロ経済学やミクロ経済学みたいに、人間は合理的に行動する、とか、市場の価格は恣意的な手段で決めても長続きせず、神の手(つまりは市場原理)で決まる、みたいに、現実とかけ離れた仮定をおいて、数多くの経済モデルを作り、そこから重要な経済学の定理を導き出す。
単純な経済モデルから得られた経済学の定理で現実に通用する場面が過去にあったから、経済のグローバル化が世間に言われ始めてから、世の中の経済事象は、市場原理で決まる、いや決めるべきだ、みたいな論調が多い気がする。

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

しかし、ブルックスの「人月の神話」では、ソフトウェアにはそのやり方が通用しない、という指摘をしている。
「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」からだ。
つまり、複雑性を排除したソフトウェアは、ソフトウェアの本質を意味しないからだ。

【2】ソフトウェアの本質的な複雑さと、偶有的な複雑さの違いは何か?
ソフトウェアの本質的な複雑さは、リーマンの法則そのものを指すと思う。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

リーマンの第1法則
 使われるシステムは変化する。
リーマンの第2法則
 進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
 システムの進化はフィードバックプロセスによって決まる。

(引用開始)
レーマンとベラディは、大規模なオペレーティングシステムのリリースについて、継続してその変遷を研究してきた。
そこで分かったことは、モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加するということだ。
(中略)
システムプログラムの作成は、エントロピーを減らす仮定だから、本来は準安定なものである。
他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
(引用終了)

(引用開始)
ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。
(引用終了)

この文章を読んで思い出すのは、ケント・ベックがXPを生み出した経緯のことだ。
ケント・ベックは、ソフトウェア工学の授業で習った、リリース総数が増大するにつれてソフトウェアの複雑度や変更コストが増大していく経験則に対して、異議を唱えた。
時間が進むに連れて、この曲線を頭打ちにできるような開発プロセスはないのか、と。

- eXtreme Programmingの魅力を探る オブジェクト倶楽部

(引用開始)
「変化ヲ抱擁セヨ」
この呪文めいた言葉は,Kent Beck による本の副題として掲げられている. 時間を横軸に,ソフトウェアの変更にかかるコストを縦軸にプロットする.
この「時間-変更コスト」曲線は極端な右上がりになると信じられて来た(図左).
すなわち,要求分析,設計,実装,テスト,保守,と時間が進むにつれ, 変更にかかるコストが増大するというのだ.
現在までのソフトウェア開発プロセスは,この仮定上の議論が多数 だったのである.
XP はこの曲線を平坦にできるのではないか, また,そうできたとしたら,全く違った方針でプロジェクトに立ち 向かえるのではないか,という挑戦をしている(図右)
(引用終了)

こういう素朴な問題意識はすごく重要だと思う。
XPがその理想を本当に実現したのかどうか、は検証がいると思うが、そういう背景を元にアジャイル開発のプラクティスが生まれたことは、アジャイル開発が従来のソフトウェア工学と対立しがちに見える傾向を示唆しているように思える。

ちなみに、上記の第1版の「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」に、上記の「従来のソフトウェア工学が提唱しているソフトウェア複雑性へのXPの果敢な挑戦」の文章と図はあるのに、第2版の「エクストリームプログラミング」から削られていることだ。
とても残念。
この部分がXPにとって一番重要な主張なのに。

【3】コードクローンと再利用性。

(引用開始)
ソフトウェア実体の本質とは、データセットやデータ項目間の関係、アルゴリズムや機能呼び出しなどが組み合わさったコンセプトで構成されたものである。
この本質は、同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。
それにもかかわらず、非常に正確で十分に詳細なものである。
(引用終了)

コードクローンとは、同一アルゴリズムを各プログラマが別々の実装したプログラムのことだ。
上記は、ソフトウェアの複雑性が増大しがちな理由の一つは、コードクローンが大量に発生しがちである、と言う点を示唆していると思う。

ソフトウェア工学の論文を見ていると、コードクローンのメトリクス採取の記事が割と多い。
その理由は、コードクローンを減らす方がソフトウェアの複雑性が減るので、良い、という主張が隠れているのではないか。

では、なぜコードクローンは良くないのか?

(引用開始)
ソフトウェア実体は、どの2つの部分をとっても似ることがないので、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ。
似通っている部分があれば、2つの類似部分を1つにする。
この点において、ソフトウェアシステムは、重複要素(部品)が豊富なコンピュータやビルあるいは自動車などとは全く異なっている。
(引用終了)

その理由は、ソフトウェアの再利用が進まないからだ。
たとえば、自動車やパソコン、スマートフォンのような工業製品は、再利用可能な汎用部品を組み立てる手法と大量生産することを組合せることで、規模の経済を生かし、経験曲線効果を生かして、1個当りの製造コストを劇的に減らす。
しかし、この「規模の経済」「経験曲線効果」というコストメリットを享受しうる生産手法がソフトウェア開発には全くといっていいほど通用しない。

ソフトウェアを部品化して、スマートフォンみたいに部品を組み立てるように製造したい、と考えて、CORBAとかEJBのようなコンポーネント駆動開発、製品ファミリー群の製品開発手法であるソフトウェアプロダクトラインとか色々考えられたけれど、どれも実用的ではない。

ソフトウェア部品化の幻想: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

だから、多額の資金を設備投資に投入して、最新の機械で汎用部品を組合せて大量生産する生産手法がソフトウェア開発には馴染まない。
ソフトウェア開発は徹頭徹尾、経験曲線効果すらも有効でない労働集約的な生産手法に似ているように思える。

【4】ソフトウェアの本質的な複雑性とは、同調性、可変性、不可視性。

【4-1】同調性は、リーマンの言う組み込まれた(Embeded)プログラム、を連想する。

「ソフトウェア・グラフィティ」の感想: プログラマの思索

(引用開始)
支配しなければならない複雑性の多くは気まぐれによるものだ。
インターフェイスを人間の社会制度やシステムに適合させるべく、いわば是非もなくそれらによって強制されているからである。
(引用終了)

最近、業務システムとかERPに僕自身が少し興味をなくしているのは、システム化したい業務そのものが元々複雑過ぎて、それを整理しようと言うよりも、現実の業務をいかに忠実にシステム化するかに注力する案件の方が多いからだ。
元々の業務が、日本的な複雑な組織体制を元に作られていれば、複雑なのは当たり前であり、それを忠実にシステム化するなら、複雑怪奇なままだ。
日本では、ERPをBPRとして捉えるよりも、自分達の業務中心に考えすぎているために、システムも複雑怪奇になりやすいような気がしている。

【4-2】可変性は、ソフトウェア品質の移植性や保守性を連想する。

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

(引用開始)
ソフトウェア実体は、つねに変更という圧力にさらされている。
(引用終了)

XPの言う「変化を抱擁せよ」と同じ。
ソフトウェアにとって、VerUpは宿命であり、常に変化が内在している。
ソフトウェアは変化しない固体として存在し得ない。

(引用開始)
純粋な思考の産物であってきわめて融通性に富んでいるので、ソフトウェアがより簡単に変更できるということもある。
ビルも現実には変更されるものだが、だれもが了解しているように、変更コストの高さが思いつきで変更しようとする者の気をくじく働きをしている。
(引用終了)

ソフトウェアに、仕様変更という名の保守はつきものだ。
それは簡単にできるように思えるから、簡単にソフトウェアに手を入れて、潜在バクを埋め込んでしまう。
ソフトウェア品質特性のうちの保守性を連想させる。

(引用開始)
大当たりしたソフトウェアはまずたいてい、すべて変更される。
あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を越えるような新しい使い方を試してみようとする。
主として、拡張機能のために変更して欲しいという圧力は、基本機能が気に入っていて新しい使い方を考えだす利用者から出される。
(引用終了)

これは、たとえば、Redmineが当初のバグ管理の使い方から、タスク管理、そして、アジャイル開発やWF型開発、さらには、事務処理ワークフロー、ハードウェア資産管理システムへ使い道がどんどん広がっていった事例を連想させる。
本来想定しなかった使い方が一般的になってしまい、その使い方をさらに使いやすくしたり、機能改善することで、ソフトウェアの複雑性がどんどん膨張する。
あらゆるソフトウェアは機能追加という変化にさらされている。

(引用開始)
大当たりしたソフトウェアは最初に書かれた対象である機械機器の通常の寿命よりも長く使用され続ける。
要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器といった文化的マトリックスにすっかりはめこまれているのだ。
そしてそれらは絶えず変化し続けるものであり、その経kながソフトウェア製品に容赦なく変更を強制するのである。
(引用終了)

たとえば、OSやDBやミドルウェアのバージョンアップとか。
あるいは、サーバー本体のリプレースとか。
たとえば、WindowsXP廃棄対応、WindowsServerのリプレース、OracleのVerUp、RailsのVerUpとか、iOSやAndroidOSのVerUpとか、色々思い出す。
つまり、ソフトウェア品質特性の移植性を連想させる。

こういうミドルウェアやOSのVerUpに伴うプログラム変更作業は、とてもしんどいものだ、と開発者なら誰でも知っている。
こういうつまらない開発基盤のVerUp作業は、ソフトウェアの外にある外部環境の変化によって生じるものであり、避けることは出来ない。

【4-3】不可視性は、ソフトウェア設計の難しさを連想する。

(引用開始)
ソフトウェアの構造を制限したり単純化したりすることは進歩したにもかかわらず、その構造は本質的に視覚化できないままになっている。
そのため強力な概念上のツールを作る意欲を阻害している。
その欠落は1人の人間の頭の中のデザインプロセスを妨げるばかりでなく、複数の人間の間でのコミュニケーションもひどく妨害する。
(引用終了)

UMLやDOAは、ソフトウェア構造を視覚化する問題を解決しようと試みていた。
SySMLもその流れだろう。

複雑性をコントロールするための設計技法は、歴史上いくつか考えれてきた。

たとえば、Nティア設計。
つまり、レイヤ化。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

NFuji's Café: 「Beautiful Code」を読む(中)

ポインタを制する者はプログラミングを制する: プログラマの思索

MVCモデル、通信プロトコルの7層モデルもそういう考え方だろう。

他に、渡部幸三さんの観点でのDOAでは、業務・機能・データの3層構造の業務システムにおいて、業務レイヤとデータモデルのレイヤに複雑性を押しこんで、機能レイヤは複雑性をできるだけ減らす設計が良い、と提唱していた。
すなわち、機能レイヤはまさにプログラミングレベルなので、その部分の複雑性はできるだけ減らして保守性を高めようとする考え方。
つまり、複雑性というエントロピーは一定で変わらないと仮定した場合、人が携わる業務レイヤと、データモデルのレイヤに複雑性を落としこんで、複雑性をコントロールしようとするわけだ。

だが、これらの手法で、ソフトウェア本来の複雑性が本質的に解決されたのか、と問うてみると、正直分からない。

【5】一方、ソフトウェアの偶有的な複雑さは個別撃破している。

「高水準言語」は、たとえば、VBよりもRuby。
たとえば、VBはListやHashなどの基本ライブラリのAPIが非常に不足していて使いにくい。
たとえば、Rubyなら、そういう低レベルなライブラリは非常にAPIが揃っていて、VBよりも1行で書ける。
つまり、複雑性を軽減している。

「タイムシェアリング」は、たとえば、コンパイラ言語よりもインタプリタ言語、継続的ビルド管理、構成管理を指すのかな。

(引用開始)
考えていた内容をすっかりというわけではないが些細な点でどうしても忘れてしまう。
(引用終了)

この部分は、まさにソース管理、構成管理を連想させる。
たとえば、CVS、Subversion、Gitに至るまでの構成管理ツールの歴史を振り返れば、ソフトウェア開発プロセスにおけるブランチ管理、マージなどの作業の複雑性は軽減されている。

「統一されたプログラミング環境」はたとえば、VisualStudioやEclipse、IntelliJとか。

つまり、ソフトウェアを開発する作業そのものが生じる複雑性は、今までの歴史で生み出された技術によって、多少は軽減されてきた。
しかし、だからと言って、ソフトウェアの本質的な複雑性を攻略できたわけではない。
あくまでも、以前よりも大きい複雑なソフトウェアをコントロールできるようになった、というだけだ。

| | コメント (0)

2017/02/23

データフローダイアグラムではプロセスは一番最後に書く

データフローダイアグラムの書き方について、良い記事があったのでリンクしておく。
記事を読んで、まだ修行が足りないと感じたので、自分用のメモ。

【参考1】
データフローダイアグラムの書き方

(引用開始)
プロセス,データの発生源・行き先,データの保管元・保管先全てに名前がついているにもかかわらず,データの流れにだけ名前がついていないDFDを見かけることがあります.
これらはDFDの役割を果たしていません.
DFDが表現しなければならないのは,プロセス,データの発生源・行き先,データの保管元・保管先を行き来するデータなのです.
データの流れに名前をつけないのは,DFDが最も表現しなければならないものを表現していないということです.

図6.プロセス名は最後につける
(引用終了)

(引用開始)
入出力するデータからプロセスの内容の推測が困難な場合,原因はプロセスの機能分割が適切ではないことが多々あります.
プロセスは,例え名前がなくても,入出力データからその内容を容易に推測できるものでなくてはなりません.

データの流れに名前をつける際には,「~情報」や「~データ」と言う名前をつけてはいけません.
抽象的すぎ何を表わしているのかわかりません.
図6の営業所からのデータの流れの名前が「販売実績」ではなく「営業所情報」や「販売情報」だったら,何を表わしているのかわかるでしょうか.
もし,データの流れに具体的な名前がつけられないのなら,DFDの作り方に間違いがあります.再検討しましょう.
(引用終了)

【参考2】
DFD(データフローダイヤグラム)の描き方(1) | ステキな一日

(引用開始)
仕事でDFDを書く機会が多いのだが、DFDの書き方を知らない人が多いのでここにメモしておく。
自分自身が100%完璧に使いこなしているわけではないので、自分の理解している範囲での内容となる。

データフローダイヤグラム(DFD)は単独で成り立つものではありません。
データディクショナリーとミニ仕様書という三点セットで業務分析を行う際に使用します。
システムの概念だけを伝えるのであれば、DFD単体でも良いのかも知れませんが・・・。
(引用終了)

DFD(データフローダイヤグラム)の描き方(2) | ステキな一日

(引用開始)
さて、DFDの描き方です。一番初めに何を描きますか?

(1)今回の対象外となるものをすべて描き出します。
これは外部要素となるものです。それは取引先だったり、外部システムだったりします。

(2)そして外部要素への入出力を描きます。(これは対象外への最終的な入出力となります。)

(3)データフロー名は必ず書くようにしてください。
プロセス名を入れたいかも知れませんがプロセス名は無くても大丈夫です。(後で入れられるし、変わるかもしれないので)

(4)今度はデータフローをよく見ていきます。
足りないデータフローがたくさんあるはずですから、図にどんどんデータフローを足していきます。
また、データフローが変換されるところや複数に分岐するところにはプロセスも足していきます。
そうやってどんどん書き足していくと、データを保管する所も見えてきますのでデータストアも書き足していきます。
そうやって、描き替えながらユーザとどんどん対話してください。
(引用終了)

DFD(データフローダイヤグラム)の描き方(3) | ステキな一日

(引用開始)
DFDを書くうえで一番重要なのがデータフローの名前の付け方です。
データフロー名の付け方によってDFDの分かりやすさはかなり違ってきます。
ここが一番肝心かなめのところですから手を抜かないようにしてください。

プロセスに名前を付ける段階ではデータフローのすべてに名前が付いてなければいけません。
はじめにプロセスに名前を付けたいかもしれませんが、ぐっと我慢をしてください。
プロセスに最後に名前を付けるのは、データフローを正しく書くために必要です。
(中略)
プロセスに先に名前を付けてしまうと、DFDを書けてしまった気になって肝心のデータフローがおろそかになったり、分析が足らなかったりしますので、注意してください。
(中略)
エクセルの図形で描いてもいいのですが、それでは書き直しが面倒になってきて、かなり出来の悪いDFDしか書けないと思いますのであまりおすすめできません。
それよりは手書きの方がマシだし、それともVISIOでも良いです。 
個人的にいちばんおすすめなのが astah* professional というソフトウェアです。
(引用終了)

DFD(データフローダイヤグラム)の描き方(4) | ステキな一日

(引用開始)
DFDにセットで必要になるものがあります。それがデータディクショナリーとミニ仕様書です。

データディクショナリーには、データフローの内訳を記述します。
そして、ミニ仕様書にはプロセスの内容を記述します。DFD、データディクショナリー、ミニ仕様書が揃ってひと塊となります。
どれが欠けても中途半端です。
(中略)
しかしながら、これもまた、DFD、データディクショナリー、ミニ仕様書を行ったり来たりしながら、ブラッシュアップさせていくものです。
(引用終了)

DFD(データフローダイヤグラム)は業務システム設計でよく使うけれど、何故か描きにくい、と思う時が多かった。
缶アイコンのデータストアは書けるのだが、プロセスがイマイチしっくりこない時が多い。
上記の記事を読んで、プロセスを最初に書いてしまうので、それに引きずられて、本来のモデルが描けなくなっているのではないか、と気づいた。

「プロセスの名前は一番最後に書く」。
つまり、外部要素やデータフローをじっくり書き込んで、漏れを無くし、整合性を取った後で、最後にプロセスの名前を書けばよい。
DOAでは、データが主であり、プロセスは従の立場だから。
プロセスは最後に名前付けすることで、データの入出力やタイミングに集中して分析できるようになる。

これから気をつけようと思う。

| | コメント (0)

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)

より以前の記事一覧