静的ページ間のリンクと、動的ビューコンポーネント(htmlフォーム、JSP、Ajaxなど)がサーバー側コンポーネント(サーブレット、Strutsアクションなど)とどのように相互作用するかを考慮して、Webアプリケーションのフローを文書化するためにアーティファクト/ダイアグラムが使用するもの?UML図を使用しますか?
4 に答える
ConallenのエッセイModelingWebApplication DesignwithUMLのバリエーションを使用してUMLクラス図を使用しました。このエッセイは、ネット上でさまざまな形に進化し、 Building-Web-Applications-UML-2ndという本にさえなっていることがわかります。
私たちが使用したアプローチの2セントツアー:
Conallenの論文に続いて、サーバー側のコード(JavaサーブレットやJSPなど)をクライアント側のHTML / javascript / AJAXと区別できるように、Webページまたはページの一部を表す新しいUMLエンティティ(ステレオタイプ)を定義しました。生成されたもの。例:
- [ウェブページ]
- [ナビゲーションバー]
- [ページコンテンツ]
- [ヘッダ]
- [フッター]
次のような新しい関連付けがありました。
- [ビルド]-サーバー側のコードを、生成されたWebページまたはページフラグメントに関連付けます
- [apparent-link]-サイトマップ図のクライアントページ間で使用
- [リンク]-URLリンク、つまりGETリクエスト
- [送信]-サーバーへのフォームポストバック、つまりPOSTリクエスト
- [client-redirect]-クライアント側のリダイレクト
- [サーバーリダイレクト]-当たり前
最後に、次のようないくつかの新しい図(ほとんどはクラス図の特殊化)。
- [サイトマップ]->クラス図のように-ユーザーの観点から[Webページ]間の静的な関係([apparent-link])を示します
- [ページ生成]->クラス図のように-特定のWebページの表示に静的に関連するクラスを示します:どのコードがそれを生成し、どのコードが投稿の送信を処理するか
- [page-composition]-クラス図のように-与えられた[web-page]を構成するものを示します
- [シーケンス図]-その他の唯一の変更点は、シーケンス図にクライアント側のエンティティをアクターとして含めることができるようになったことです。
良いニュース:
- ダイアグラムを適切に見せるために必要なRationalRoseアイコン拡張機能が見つかりました。
悪いニュース:
- このアプローチは大変な作業でした。サーバー側のクラスに加えてクライアント側のエンティティをモデル化していたため、モデル化するエンティティの数が2倍になりました。
私が話していることの写真については、コナレンの論文の1つを読んでください。しかし、私が言ったように、彼のアプローチに厳密には従いませんでした。必要な部分だけを取りました。お役に立てれば。
アプリケーション開発には37signalsアプローチを採用することをお勧めします。
各ページには目的が必要です。最初にその目的に焦点を合わせ、その周りの他のすべてを設計します。
プロセス:
- シャーピーと紙で主要部分をスケッチします
- リストアイテム
- 早い段階で詳細を無視します(邪魔になるだけです)
- できるだけ早く本物の何かを作成します(つまり、アプリケーションがどのように流れるかを示すために他のページに移動するリンクを含むいくつかのhtmlファイルを作成します
- サイトのフローが設定されたら、設計コンポーネントを追加してプログラミングを開始します
既存のプログラミングを回避するアプリを設計するよりも、すでに設計および検討されているものにプログラミングを追加する方がはるかに簡単です(ほとんどの場合、最初に見逃されていた設計/フローの問題に適応するようにコードを書き直す必要があります)。
以前は、Webアプリのページナビゲーションを文書化するためにUML状態図を使用していました。
アクティビティ図の一部としてのユースケースは、私の同僚の一部によって使用されていますが、これは、静的な高レベルのナビゲーションの概要に適している可能性があります。
Cucumber with Webratで使用されるBDDシナリオ形式に似たカスタムDSLを開発しようとしています。このようなシナリオには、インタラクションとWebページモデルを作成するのに十分な情報が含まれています。