実践的オブジェクト指向分析入門40

　この記事は、実践的オブジェクト指向分析入門39の続きです。前回は、機能モデルの構築の解説を終えました。
　オブジェクト指向方法論OMTにおけるオブジェクト指向分析はこれで終わりです。あとは、オブジェクトモデルの構築、動的モデルの構築、機能モデルの構築を必要なだけ繰り返すだけです。1度で完璧に分析を出来る人間は存在しません。オブジェクト指向分析を何回か繰り返す事が大事です。
　また、作業の順序は必ずしも同じ順序でする必要はありません。同じプロジェクトは存在せず、教科書通りに物事が進む事もあり得ません。臨機応変に対処する姿勢が大切なのです。
　この一連の記事では、オブジェクト指向方法論OMTに限定し、時代に合わせてUMLを使用する方向で、オブジェクト指向法分析を解説しました。しかしながら、オブジェクト指向分析は他の方法論にもあります。
　さらに実務では、現場の状況やプロジェクトの性質をよく考慮し、複数の方法論を組み合わし、最適なオブジェク指向分析を実施します。開発方法論は大事ですが、あくまでも方法論は思考ツールなのです。
　実践的オブジェクト指向分析入門が少しでも参考になれば幸いです。終わり。

実践的オブジェクト指向分析入門39

　この記事は、実践的オブジェクト指向分析入門38の続きです。前回から引き続き、機能モデルの構築で行う作業について具体的に書きます。
　オブジェクト間の制約が識別したあとは、機能モデルの構築の最終段階である最適化基準の指定を行います。最適化基準の指定では、システムの機能要件の基準値を決定します。システムには、1時間で処理できるトランザクションの数、セキュリティの強固さ、レスポンスの早さなど色々な機能要件があります。従って、これらの機能要件をはっきりさせるために、基準値を定める事は非常に重要です。
　しかしながら、機能要件の基準値を決定は困難です。そこで、機能モデルの構築作業で現状のシステムを分析し、新システムのために具体的な値を測定します。そして、測定結果を元に、ユーザーが求める基準値を割り出します。ただし、数値化できない人間の感覚的なものは依然として残りますし、システムの後工程で変更される可能性が高いのを忘れてはなりません。
　何でも数値化する事を目標とするのではなく、柔軟な態度でユーザーの要望を引き出し、開発作業の基準を割り出すために最適化基準の指定を行います。

実践的オブジェクト指向分析入門38

　この記事は実践的オブジェクト指向分析入門37です。前回から引き続き、機能モデルの構築で行う作業について具体的に書きます。
　入力値と出力値が判明したら、オブジェクトの制約について考えます。どの様な機能も前提となる条件があります。現時点で注目する制約は事前条件・事後条件・不変表明です。他にも制約は考えられますが、余程複雑な機能でない限り、ひとまずこの3つの条件を考えましょう。
　事前条件とは、処理をする前に満たさねばならない条件です。例えば、「振り込み処理は、投入する金額が1円以上なければならない。」などです。事後条件はその反対に、処理後に満たさねばならない条件です。残りの不変表明は、オブジェクトが常に満たすべき条件です。例えば、「社員の勤務年数は、年齢を超えてはならない。」などです。
　制約はシーケンス図に追加します。制約の書き方はいくつか考えられますが、私がお勧めする方法を書きます。不変表明をオブジェクトの上に書いておきます。そうする事により、オブジェクトの性質が分かりやすくなります。事前条件と事後条件については、[ 金額 > 0 ]の様にメッセージ名に括弧をつけて書くか、制約をつける方法があります。メッセージに制約を書く方法は、処理の流れが変わる時に使用します。制約をノートなどで書く方法は、処理の流れに注目しない時に使用します。
　シーケンス図に書く時に注意する事は、「重要な制約のみを記述するように注意する」です。シーケンス図は細かい制約を書くのには向いていませんし、過剰な分析は害となります。もし、分析において必要ならば、アクティビティ図を別に書くとよいでしょう。その時は、関係する図がある事をメモに書きましょう。続く...

実践的オブジェクト指向分析入門37

　この記事は、実践的オブジェクト指向分析入門36の続きです。前回は、機能モデルの構築について解説しました。今回は、機能モデルの構築で行う作業について具体的に書きます。
　私が所持しているオブジェクト指向方法論OMTについての解説本は古く、DFD（データフロー図）の作成が手順として書かれています。しかしながら、現状ではお勧めできない方法なので、実際に私がしているOMTの応用について書きます。
　最初にするべき作業は、現状のシステムの機能的な側面をユースケースとシーケンス図に書く事です。分析対象となるビジネスプロセスを選び、そのプロセスの概要をユースケースに書きます。そして、シーケース図に大まかな流れを書きます。ユースケースとシーケンス図はどちらを先に書いてもOKです。大まかな流れを把握したら、入力値と出力値に注目します。
　システムを機能として捉えると、様々な値がやり取りされているのが分かります。この値（オブジェクト）に注目すると、よりシステムの機能面を把握する事が出来ます。分かり難いと思いますので例を挙げます。
　例として商品の販売プロセスを考えます。お客様オブジェクトは、何らかの情報を元に店に来店します。そして、商品を選びレジで清算します。このプロセスは、お客様オブジェクトとレジオブジェクトとの間で、様々な情報（値）がやり取りされているのが分かります。また、お客様オブジェクトへ販売会社オブジェクトからの情報（値）が渡されているのが分かります。
　これらのプロセス内で発生する値（オブジェクト）に注目し、ユースケースとシーケンス図で書くと、システムをより詳細に分析出来ます。言いかえれば、機能モデルの構築とはやり取りされる情報の分析だと言えます。続く．．．

実践的オブジェクト指向分析入門36

　この記事は実践的オブジェクト指向分析入門35の続きです。前回は、重要な動的振る舞いを持つオブジェクトの分析について書きました。今回は、機能モデルの構築について解説します。
　ユースケース、アクティビティ図、ステートチャートを書き終えたら動的モデルの構築は終了です。各図と静的モデルの整合性をチェックした後、オブジェクト指向分析（OMT）の最終段階である機能モデルの構築を行います。
　機能モデルは、計算順序や条件判断などといったオブジェクト内部の構造を無視し、値がどのように計算されるのかを分析する作業です。これから、この様な分析がなぜ必要なのかを説明します。
　オブジェクトモデルの構築では、オブジェクトの静的な構造が分析できました。次に動的モデルの構築で、オブジェクトがどのように振舞うのか（事象）が分析できました。この2つの作業を通じて、システムを構成する要素が分かりました。しかし、足りないものがあります。それは、「システムが何をするのか」という機能的な視点です。これを可能にするのが機能モデルの構築です。
　機能モデルの構築では、誰がではなく生成される値に着目し、システムが提供する機能を分析します。ただし、値と言っても単純な数値や文字とは限らず、値もまたオブジェクトである点に注意して下さい。オブジェクト指向分析では、値を実装レベルのものではなく、抽象的な情報として値を捉えなくてはなりません。そうする事により、柔軟なシステム設計と実装が可能となります。続く・・・ 　

実践的オブジェクト指向分析入門35

　この記事は実践的オブジェクト指向分析入門34の続きです。前回は、事象の発見で注意するべき事柄や要素を書きました。今回は、重要な動的振る舞いを持つオブジェクトの分析について書きます。
　今までの作業で、必要なオブジェクトとプロセスの全体像が分かりました。次にするべき作業は、重要な動的振る舞いを持つオブジェクトの分析です。
　オブジェクト指向分析を行うと、動的な振る舞いを持つ重要なオブジェクトが見つかります。例えばユーザーオブジェクトは、システムに対して動的で複雑な振る舞いをします。動的振る舞いを持つ重要なオブジェクトは、システムを理解する上で重要な情報をもたらします。特別に分析する必要があります。
　UML内で動的な振る舞いを持つオブジェクトを、分析するのに向いた図はステートチャート図です。ステートチャート図を用いると、対象となるオブジェクトの状態と事象の関係が分かります。
　ユースケースとアクティビティ図でシステムを分析すると、一つのオブジェクトがどの様に振る舞うのかが分かりづらくなります。この事態を放置しておくと、分析に漏れが生じます。そこで、複数のユースケースに登場する重要なオブジェクトを、ステートチャート図を用いて分析するのです。
　ここで、重要なオブジェクトという点に注意して下さい。オブジェクト指向分析初心者は、全てのオブジェクトのステートチャート図を書いてしまいます。しかし、動的振る舞いを持つ重要なオブジェクト以外に、神経をすり減らすのは得策だとは言えません。
　過剰な分析をすると、重要でない些細な部分に注意が向き、システムの本質や全体像を捉えられなくなります。システムの本質と全体像をとらえ、重要なものに意識を集中させるのが正しい分析です。

実践的オブジェクト指向分析入門34

　この記事は実践的オブジェクト指向分析入門33の続きです。前回は、動的モデルの構築の最初に行うべき作業である「事象の発見」について解説しました。今回は、事象の発見で注意するべき事柄や要素を書きます。
　事象の発見において重要な要素の内の1つがインタフェースです。ここでいうインタフェースとは、既存システムの画面や帳票などを含む広義の意味で使用しています。
　interfaceという英単語は、2つの物体や空間の面の境界面・接触面を表し、システムや組織体が接して交信・交流する共通領域や、境界領域間を結ぶ手段も表しています。この意味をオブジェクト指向分析に当てはめて考えると、部門間や組織間でやり取りするデータおよび手段を分析する事になります。
　システム構築でよくある失敗の内の一つが、他部門・関連会社・顧客の接点を考慮しない事です。例えば、販売管理システムを受注した際に販売管理だけを考えてしまうと、会計データの扱いが疎かになり使えないシステムになります。
　また、今日のビジネスは顧客との関係が重要視されています。システムを導入するお客様が提供している商品やサービスを買う消費者の事まで考えないと、役に立たないシステムの烙印を押されてしまいます。すなわち、オブジェクト指向分析は広い意味のシステムのインタフェースが大事なのです。
　それとは別の問題で、企業が持つデータとオブジェクトを分析するために、帳票や既存システムのインタフェースを分析する事も大切な作業です。システム分析は基本的にビジネスプロセスを対象としますが、それだけでは見落としが生じます。何故ならば、日本は特に暗黙の了解や慣習が多いからです。それが原因で、ビジネスプロセスからは見えにくいオブジェクトがよくあります。
　オブジェクト指向分析では、事象とオブジェクトの見落としがないように多面的な分析をしましょう。

実践的オブジェクト指向分析入門33

　この記事は実践的オブジェクト指向分析入門32の続きです。前回は、要求定義と動的モデルの関係について解説しました。今回は、動的モデルの構築の最初に行うべき作業である「事象の発見」について解説します。
　OMTでは動的モデルを、「システムおよびその中のオブジェクトの時間に依存した振る舞いを表す。」と定義しています。そして、動的モデルは事象の発見から始めるとされています。これから、現代に即した事象を発見する方法を解説します。
　事象の発見は様々な方法が考えられますが、ユースケース図とアクティビティ図を書くとよいでしょう。ユースケース図とアクティビティ図のどちらを先に書くかについては状況次第です。分析対象が複雑な場合はユースケース図を先に書き、全体像が明らかならばアクティビティ図を先に書きます。とはいえ、実務では両方同時に書く場合が多いので、順番については意識しない方がよいでしょう。
　ユースケース図については今まで解説してきたので省略し、アクティビティ図を書く際の注意事項について述べます。
　オブジェクト指向分析の段階で書くアクティビティ図は、ビジネスプロセスの流れです。誤解されやすいのですが、アクティビティ図はプログラムのロジックだけを対象とした図ではありません。実装段階で書くのであれば、実際にプログラミングした方が早いです。
　アクティビティ図はそういった目的ではなく、抽象度が高いビジネスプロセスを書くのに適しています。何故ならば、並列処理をサポートしており、抽象度が高い事象も表現できるのでビジネスプロセスを可視化しやすいからです。実際の業務は並列して行われる事が多く、並列処理を表現できる事は重要な要素です。
　ただし、並列処理に関する記述には表現力が不足しているので注意が必要です。並列処理を考える時、詳細な情報が欲しくなりますが、アクティビティ図は並列処理に関する詳細な情報を書くのには向いていません。アクティビティ図は抽象的に考えるのに使用します。
　アクティビティ図が書き終わったら次の作業をします。続く...

実践的オブジェクト指向分析入門32

　この記事は、実践的オブジェクト指向分析入門31の続きです。前回は動的モデル構築の導入部分について書きました。今回は要求定義と動的モデルの関係について解説します。
　前回の記事を読めば、ユースケース図とユーザーストーリーが重視されている事に気付くと思います。ユースケース図とユーザーストーリーを重視している理由は、システム開発に於いて要求定義は非常に重要だからです。要求定義が正しく行われていなければ、そのシステムは初めから失敗していると言っても過言ではありません。たとえ開発側が満足しても、ユーザーが求めるものを提供できないシステムは存在価値がありません。厳しい表現ですが、これは揺るぎない真実です。
　オブジェクトモデルとはどちらかというと机上の話しでしたが、動的モデルの構築はより現実の話しに近くなります。動的モデル構築の段階になると、より一層気を引き締めなくてはなりません。
　オブジェクトモデル構築の際に作るユースケースは、正常処理もしくは正常時の業務の流れが必然的に多くなります。何故ならば、分析初期の段階で全体像を把握する必要があるからです。分析の目的は現実を抽象化する事なので、細かい所から入るのではなく、全体像を把握せねばなりません。そうしなければ、分析が際限なく続く羽目になります。また、最初から忙しいユーザーに細かい事を根ほり葉ほり聞くと悪い印象を与え、以後のシステム開発に悪影響を及ぼします。例外などの詳細な事例に関するユースケース図は、動的モデル構築の段階で作ります。
　具体的には、システムの動的側面を表す図を作成しつつ、ユーザーに少しずつヒヤリングし、ユースケース図を並行して作成していく事になります。

実践的オブジェクト指向分析入門31

　この記事は実践的オブジェクト指向分析入門30の続きです。前回で静的なオブジェクトモデルの構築についての解説を終えました。今回は動的モデルの構築について解説します。
　システムは静的なものではなく動的で複雑なものです。従って、静的な側面に目を向け、オブジェクトを発見したり、オブジェクトをまとめたりする作業だけではオブジェクト指向分析だと呼べません。システムの動的な面について分析する必要があります。
　最初に行う作業はユースケースの記述です。ユーザーがシステムを使って何をするのか、そしてユーザーがシステムに対して何を求めるのかを理解しなくては、ユーザーが望むシステムを構築できません。ユーザーが望むシステムをつくるために、ユーザーシナリオを通じてシステムの動的な面を把握する糸口にします。
　ここで、オブジェクトモデルの構築をする時に、ユースケース図にユーザーストーリーの記述をするべきだと解説した事を思い出して下さい。システムの静的な側面と動的な側面は表裏一体です。静的な分析図と動的な図を結びつける図が必要となります。それがユースケース図なのです。おそらく、大半のユーザーストーリーは記述済みだと思います。
　オブジェクトモデルの構築をする際に記述したユースケース図を見て、足りないシナリオがあれば書きます。その結果、足りないオブジェクトがあれば、オブジェクトモデルに新しいクラスを追加します。この作業は意外と忘れやすいので注意しましょう。定期的に、静的なオブジェクトモデルと動的モデルが矛盾していないかチェックします。