Webサイトの設計 - 検討中

なんか、デファクトスタンダードなくね?
という事でUMLを使ってWebサイトを設計する場合で、かつ人員に渡す工程に反映出来るレベルまで落として考えて見る。
ただしサーバなどは省く。

リスト

  1. ユースケースユースケース仕様(文書)の作成
  2. ページリストの作成
  3. ユースケースごとにアクティビティでナビゲーションフローを作成
  4. 必要に応じてサイトマップの作成(形式は自由に)

以後はプログラムの設計に。
プログラム方面の設計もどっかで考えるかも。
特にPHPのようなファイル単位のものは考えないといけない気がする。Servletはやりやすいんだがな。

補足

ただ、トップページからhelp, about, what's newと大量にあるページごとに、「View About」「Maintain About」などとユースケースを乱立すると可読性を落とす上大変なのだが、ここは上手く書くしかないのかなと。
迷ったのはここを「ユースケース」「ファンクション」「ページ」の三分類にするべきか、「ユースケース」「ページ」の二分類にするべきかというところで、今もどっちがいいか迷っている。シンプルに設計するなら修正がしやすい後者であるべきだと思うんだよな。
こんな感じ。

  1. ユースケースユースケース仕様(文書)の作成
  2. ファンクションリストとファンクション仕様(文書)の作成。ここでファンクションごとのページも作成
  3. ページリストの作成
  4. ユースケースまたはファンクションごとにアクティビティでナビゲーションフローを作成
  5. 必要に応じてサイトマップの作成(形式は自由に)

ページはファンクションに属し、ファンクションはユースケースに属すツリー構造。これならユースケースの可読性が落ちる事はないし、設計の変更時はファンクションから作り直せるので、全体を把握するための可読性の高いユースケース、細部を見るためのファンクションという役割分担も出来る。
でもこの場合UML以外の代物が混入するので、UMLという枠組みの中では出来ないんだよな。「うちはこういうやり方でやってますよ」という話になってしまう。
よって、とりあえずユースケースを煩雑にする方を起案とした。

こうした理由

とりあえずユースケースをサイトの基盤とすることが目的。
で、後はナビゲーションフローをアクティビティで書きましょね、サイトマップはおまけ程度に作りましょうね、と方針を決めるのも目的。

でも

なんかいまいち。
ベトナム人SEのQuoc氏には、私が面接等で非常に忙しいため考えながらやってもらっているが、もう少し煮詰めた方がいい気もする。
結構今まで客先要望に合わせて適当にやってきたが(多いのはフローチャート系のサイトマップかな)、Web系をメインと公言する以上デファクトスタンダードがあろうがなかろうが、自社内標準設計手法は確立しなければなるまい。


まあ、もうちょい考えよう。