住所録アプリケーションの設計

• どんな動作をする(操作を受け付ける)の？
• データ項目はなに？
• 内部構造はどうなる？
• どんな技術で実現するの？

住所録アプリケーションの要件

設計するにしても、「どんなことが必要とされるのか」を決めないと取り掛かりにくいです。
ということで、進捗重視であまり深い検討はしませんが、決めてみましょう。

業務要件（機能要件）

• 住所録は、住所データを多数保持する。
  　当たり前ですね。ただ、住所データって何？
  　ここでは、都道府県、市区町村、番地号、建物、部屋にしましょう。
  　え。グローバル？国？ネットの世界にすむ妖精はどうするんだ？
  　まあ、それは「住所」を抽象化しておけばあとで拡張できそうではありますね。
  
• 住所録は、住所データを追加する機能がある。
  
• 住所録は、住所データを修正する機能がある。
  　引っ越ししたときとかでしょうかね。
  
• 住所録は、住所データを削除する機能がある。
  　お別れはさみしいですが、そういう時もありますね。
  
• 住所録は、住所データを名前の一部から住所データを検索する機能がある。
  　　一般的な住所録は、名前から住所を検索しますよね。
  
• 住所録は、住所データを一覧する機能がある。
  　　検索結果を一覧表示できると見やすいです。
  　　とりあえず名前の昇順でソートすることにしましょう。
  
• 住所録は、よく使う住所データを一覧する機能がある。
  　　起動時に、よく使う住所の一覧が出てるといい感じですよね。
  
• 住所録は、住所データに関連したメモを扱うことができる。
  　　最寄駅とか、便利情報があるといいですね。
  

非機能要件

• 住所録は、ユーザーにストレスのない反応速度を実現する。
  　ほんとはもっと厳密に定義しないといけませんが。
  
• ネットワークが切れているときも、「よく使う」住所は確認できる。
  
• ネットワークが切れているときも、「よく使う」住所は変更できる。
  
• ネットワークが切れているときも、新しい住所は追加できる。
  
• （ネットワークが切れているときは、削除はできない）
  

住所録アプリケーションのデータ項目の設計

操作や機能から先に考えるか、どんなデータを扱うかを主眼に考えるかで、設計のアプローチを分類する手法があります。
扱うデータを主眼に考えるのはDOAと言います。
誰ですかテクモの乳揺れ格闘ゲームを思い浮かべた人は。あのXtreme Beach VolleyballをプレイするためだけにXBOX買った友人(私じゃないよ！)もいます。何もかも懐かしい。
えーと、暴走はこのくらいにして、この場合のDOAはデッドオアアライブではなくてデータ志向アプローチということです。
業務システムの設計では、比較的「堅い」手法として知られています。
この企画では、そんなに頑張ってDOAするつもりはないんですが、業務アプリ開発において判りやすい手法としてちょっとだけやってみます。

ここで住所録で扱うデータを考えます。
(実際に、要件から、ユーザに使われるかどうか、が問題です)

• 氏名
• 住所　─　都道府県、市区町村、番地号、建物、部屋
• メモ

ところで、氏名を姓と名に分ける必要はあるでしょうか。あるいは、住所をこのように分ける必要はあるでしょうか。
これは、どう使われるかどうかが肝心です。

たとえば、姓と名で別々にソートするとか、家族単位を管理するので姓を認識したいとか、そういう要件があるなら氏名を分ける理由になります。
グローバルになると、姓名の表示順が違ったりする(そして親しみを持たせるために名のみを表示するとか)あったりします。
が、今回の要件には含まれていないのでとりあえず繋げてます。

では住所はどうでしょうか。
都道府県別にソートするとか検索するとかあれば、これは分ける必要がありますし、「都道府県」を正確に入力する必要があります。島根県を嶋根県と打ったりしては困るわけです。
そのため、都道府県をルールか台帳(マスタ)で用意して、それと整合性のチェックが必要になります。
今回はどうでしょうか。要らないですね要件にそういうのないですから。(住所のチェックもないし）
実際の仕事では、ここで、もしこの機能がいるんじゃない？と思ったら、「ないけどいーんですか」とか確認してあげてください。
上流工程での忘れものは、できるだけ早く見つけたほうが、修正に流す血は少なくて済みます。

今回は別に要件変更ないので

• 氏名　（単純に文字列）
• 住所　（単純に文字列）
• メモ 　（単純に文字列）

それにしてもこれは単純でどうにもソソらない。
そんな動機で要件変更は普通しないんですが、メモには文字列じゃなくて画像とか動画とか扱えるようにしたいですよね。
せっかくSilverlightなんだし。でも動画とかいってもソースデータがないですが。
今はこれ（全部文字列）で行きますが、様子をみて要件にマルチメディア対応を追加することを検討しましょう。
マッシュアップでなんとかなりますかねえ。

あと、もうひとつ、要件がありましたね。「よく使う住所データを一覧する機能がある」。正直やめればよかった。
よく使う、の定義どうしましょう。「過去に表示させた１０件、最近見た順」とかにしましょうか。
あるいは、見た回数を管理して、回数多い順、というのもアリですね。
そのほかいろいろ指標的なデータを組み合わせて違和感ない「よく使う」を実現する…のが王道ですが、この企画ではさくっと「過去表示させた１０件、最近見た順」でいきましょう。
あ。もちろん本当のお仕事では、こういった言葉の定義は要件定義の時にはっきり決めます。
そうすると、表示させた日時がデータに必要ですよね。
このほか、住所録でよくあるのは「最近データ追加した人」「最近情報変更した人」とかで、それぞれそれらを実現するための項目がデータに必要になりますが、今回は要件から抜けてますので特に考えません。

すると、結局

• 氏名　（単純に文字列）
• 住所　（単純に文字列）
• メモ 　（単純に文字列あとで拡張考えよう）
• 参照日時（年月日時分秒）

なんで「その１」かというと、今日はここで終了だからです。時間切れでした。

まっさきにここから始めるアプローチもありますね。
それはさておき、操作と画面は密接に絡み合っていますし、このよしあしが作業する人の生産性を決定づけたりするので、本来ならば慎重に検討し、そして結果として大胆なイノベーションが求められる分野です。
ユースケース分析などからはじめてしっかり練りこんだほうが、いいものができます。
今回はなんちゃって設計なので、おおむね、以下のことだけ考えます。

とりあえずユースケース図:

とりあえずシーケンス図:

とりあえず画面遷移図:

さっさと実装したいのは山々ですが、もうしばらく設計が続きます。

さて、画面遷移図みたら、やりたいことの割りに複雑で超ダサい、という感じだったので、ちょっと見直しましょう。
設計変更です。
確定のときに、いちいち確定画面を出すんじゃなくて、一気に一覧画面に戻るというのはどうでしょうか。
一覧画面の一部に「〜〜を変更しました」とか「〜〜を削除しました」とか出てれば、あえて確定画面を表示させる必要はなさそうな気がします。
そういう風に画面遷移を作り直して見ましょう。

とりあえず画面遷移図その２:

さて、この画面遷移図に従って、シーケンス図を書き直してみました。

とりあえずシーケンス図:

起動	検索→詳細
検索→変更	検索→削除
追加	終了

とりあえずユースケース図:

データ項目の設計の見直し（考慮漏れを発見）

画面遷移を直してる最中に気がついたんですが、PID（パーソナルID)というか、個人識別子がないですね。うっかりうっかり。
なんとなく個人識別は名前で考えていたんですが、結婚して姓が変わるケースもありますよね。
変更画面で、何を変更する？と考えていたときに、名前も変更するだろうと気がつきまして、おわ、それじゃ個人識別するの名前じゃだめじゃないかと。
ということでPIDを導入します。
ちょっと型が微妙なんですが、実装言語側で便利な型があるかもしれないんでここではあんまり縛らないでおきます。
最大件数が決まってるときは、その件数が識別できるサイズの数値だったりしますが…。

• PID　（単純に文字列？数字？データのなかでプライマリキー扱いとなる。一意の値であればよい）
• 氏名　（単純に文字列）
• 住所　（単純に文字列）
• メモ 　（単純に文字列あとで拡張考えよう）
• 参照日時（年月日時分秒）

以下次回…。
あと、構造の設計やって画面（やっとBlendが動く）に行く感じです。
先長いなー。まあ業務アプリの水流だとじれったいですな。
ああ早く実装したい。でも、もうちょっと設計。