サイトの参照条件。 練習する

技術的な課題である記事へのコメントの中で、サイトは参照用語のテンプレートについて、そして実際には、記事で説明されている原則に従ってコンパイルされた作業指示書の例について話しました。 そこで、テンプレートとTK自体の両方を表示することを約束しました。

私は約束を守り、この記事ではTKの執筆を紹介しようとします。 この記事を読む前に、サイトの参照条件を読むことを強くお勧めします 。 ここでは、ToRがまったくこのように見える理由については説明しませんが、上記の記事の原則に従って参照用語を作成するプロセスを簡単に説明します。



参照構造の用語は次のとおりです。

1.一般的な言葉
2.運用目的
3.機能
4.用語と定義
5.データ型
6.機能特性
7.ページ
8.信頼性の要件
9.ホスティング要件
10.コンテンツの充填
11.配送と受け入れ

これらのセクションについては、TKの例で説明します。

記事のいくつかのポイントを省略、簡略化、または模式的に表示することを予約します。 これは、記事を無関係な詳細で混乱させず、理解を複雑にしないために必要です。

突然、Webサイトの技術仕様を作成するシステムを開発していることがわかりました。 そして、この機会を利用して、このシステムを使用してTKを作成するプロセスを説明します。 それはazalo.netと呼ばれます 。

azalo.netについて少し。 システムでは、用語と定義からサイトの論理的に完成した機能部分全体の説明（コンポーネント）（「ニュース」、「レビュー」など）まで空白を使用して参照用語の記述を簡素化できます。また、TKおよびサイトレイアウトエディターの典型的なテキストを記述するテンプレートエンジンも提供します。 この記事では、主にTK自体に焦点を合わせて、最も重要なポイントのみを対象に、azalo.netでの作業を最小限に説明しようとします。 TKフラグメントとサイトレイアウトを含むすべてのスクリーンショットは、azalo.netのスクリーンショットです。

この記事はいくつかのステップに分かれています。 各ステップの終わりに、渡されたステップの後にある形式で、参照条件へのリンクが与えられます。

TKテキストでは、テキストの横にマークがあります。



前の手順と比較して変更された部分をマークするか、それらに注意を払う価値があるかをテキストで示します。

TKを作成するための例として使用されるサイトについて。 これは実際のサイトであり、サイトが作成された実際のやや使いやすいTKです。 なぜ顧客がそのようなサイトを望んでいるのか、別のサイトは望んでいないのかという質問には、答えられません。 彼らが言うように、このサイトは私のサイトではないので、 TKの発表を投稿したところです。

---

それで、顧客は私たちのところに来て、彼のキャンプサイト用のサイトが欲しいと言います。 連絡後、サイトには次の情報が含まれていることが明らかになります。キャンプサイトに関する一般情報、キャンプサイトの場所を示す地図、価格、写真、レビュー、オンライン予約とフィードバックの可能性。

問題の分析に進みます。

ステップ1.サイトの初期レイアウト。

将来のサイトの計画の概要を説明します。



このスキームでは、「サイトには、キャンプサイトに関する一般情報、キャンプサイトの場所を示す地図、価格、写真、レビュー、オンライン予約とフィードバックの可能性」という言葉を繰り返します。

メインページにはキャンプサイトに関する一般情報が含まれ、残りはボックスページの名前から明らかです。 管理領域はまだ興味の対象ではなく、「管理パネルへのログイン」ボックスで表されます。

新しいプロジェクトを作成し、この図をazalo.netでスケッチしたので、すでに少しのTKを作成しました。 TKの空白を作成しました。図の各ボックス（ページ）はアイテムに対応し、TKの他のすべての部分の場所を用意しました。

スキームをお客様に見せて説明し、すべてがそこにあるかどうかを確認し、理解を確認します。 正しく移動しながら。

作業指示書 、 サイトレイアウトへのリンク。

ステップ2.導入部、ホスティングと信頼性の要件、配信条件と受け入れ。

将来のサイトの詳細は頭の中で熟していますが、参照条件の最初と最後のセクションに記入します。これらのセクションは、TKの残りの部分と大まかに関連しています。 これらは、TKのセクション1〜3、8〜10です。

一般規定

ここでは、キャンプサイト用のサイトを作成していることと、オブジェクトについて知っていることを示します。

Forest HillsキャンプサイトのWebサイトを作成する必要があります。 キャンプ場は黒海にあり、低い山々に囲まれ、一対の丘の上にあります。 16の家と3つのカテゴリの部屋があります。 家には2部屋と4部屋があります。 チケットが発行されると、クライアントは部屋のタイプを示しますが、特定の家は、空き場所に基づいてマネージャーによって決定されます。

azalo.netサービスでは、このピースは次のようになります。



今、私たちは多かれ少なかれ、どのホステルのためにサイトが作られるかを想像しています。

運用目的

「サイトの運用条件 ：運用目的」の記事に記載されているように、これはお金を受け取る前の1つのステップです。 観光客が来て、写真を見て、レビューを読んで、これらの場所を訪れてチケットを購入したいという欲求を明るくするために、ウェブサイトが必要です。 お金に戻ります（バウチャー購入）：

このサイトの運用目的は、キャンプサイトに関する情報を提供し、新しい顧客を引き付けることです。

機能目的

どういう意味で「運用目的」を提供しますか：

サイトは、キャンプサイトに関する一般情報を提供する必要があります。 写真を表示する機能。 サイトには目的地への行き方の地図が必要です。 部屋予約フォーム; レビューを残す機会を持つゲストのレビュー（ゲストブック）

ここでは、データ、機能、およびページに関連するすべてをスキップし、サイトの入力に関する項目に進みます。 不足しているポイントについては、予約に関するセクションで詳しく検討します。

サイトコンテンツ

私たちの契約には充填は含まれていません。
なぜなら 私はすでにこの状況をアザロで説明しましたが、このケースのテキストを準備しました。 このような空白はセクションの右側にあり、それぞれの横に「Add to TK」ボタンがあります。 「最小充填」ボタンを押すと、テキストがドキュメントに追加されます。少し修正して先に進みます。

請負業者は、サイトの最小コンテンツを満たす義務があります。これにより、顧客はサイトの使用を開始できます。 請負業者は、このTKに記載されている商品のカテゴリを作成し、スーパーユーザーを作成する必要があります。 「ギャラリー」やテキストページのコンテンツなどのセクションに記入することは、請負業者の義務ではありません。

ホスティング要件

少しのPHPホスティングが必要です。 なぜなら サイトの作成には常に同じフレームワークを使用しているため、サイト間で同じ特性を持つホスティングが必要です。 当然、ホスティングの要件を説明する空白があり、作業ステートメントに空白を追加するだけです。

最小の適切な構成：

• 少なくとも330 MBのディスククォータでのホスティング
• PHP5でホストし、インストールされたApache Rewriteモジュール
• InnoDBモジュールを備えたMySQLデータベースバージョン5以降
• 登録され、正しく構成されたドメインの存在

なぜ330MBですか？ 彼はプログラマーに明言し、彼らはこのプロジェクトに330人が必要だと言った。

信頼性要件

もちろん、ここにはサイトに脆弱性を含めるべきではないことを書くことができますが、実践が示すように、これは非現実的です。 一方、サイトを保護するための措置を講じないことも悪いことです。 したがって、ここでは、サイトが「ふるい」であってはならないという事実について、いくぶんあいまいな表現を挿入します。

このサイトは、クロスサイトスクリプティング（XSS）、SQLインジェクション、CSRF脆弱性などの主要な種類の攻撃に対する基本的な保護を提供する必要があります。

しかし、これだけでは、誰もバックアップをキャンセルしませんでした。

ソフトウェアの1つのコピーを外部メディアに保存することをお勧めします。 ホスティング会社がそのようなサービスを提供していない場合は、データベースファイルを外部メディアに定期的にコピーすることもお勧めします。

配送と受け入れの条件

顧客に7日間の受付期間があることを予約します。この間に、サイトを通常の稼働状態にし、見つかったバグを修正するためにさらに30日間必要です。 その後、私たちの仕事は明確な良心をもって行われたと考えます。

サイトは正常に表示され、機能するはずです。

このサイトは、次のブラウザーで正しく表示および機能するはずです。

• Chrome 13
• Firefox 4
• Safari 5
• オペラ11
• Internet Explorer 8および9

もちろん、欠点を見つけることもできます。「正しく表示する」とはどういう意味ですか？ ピクセルごとのデザイン、またはウェブサイトを注文した場合、何を理解しますか？ 私たちは質問を聞いていないふりをして先に進みます。

プログラムの受理は、プログラムの試運転期間後に行われます。 サイトが7暦日にわたって正しく着実に稼働している場合、試用期間は完了したと見なされます。 請負業者は、（プログラムの機能の構成を変更することなく）技術仕様とのすべての欠陥と矛盾を排除するために、運用期間の開始から1か月以内にソフトウェア製品に同行することを約束します

さて、ステップ2の後、次の参照用語があります 。 前の手順のサイトレイアウトは変更されていません。

参照条件のテキストでは、作成された説明に青いバーが付いています。

騎士の動き

個人的には、技術的なタスク全体を完全かつ即座に書くことは、非常に難しいタスクです。 タスクを小さなサブタスクに分割しようとしています。 焦点を合わせて決定するのが簡単であり、これらのソリューションを再利用できます。

azalo.netでTKに取り組んでいる間、「コンポーネント」を使用します。 コンポーネントは、原則として異なるプロジェクトで使用できるサイトの論理的に完成した部分です。 たとえば、ニュース、ブログなど。 サイトのプログラマにとっては、プラグイン「ニュース」、プラグイン「ブログ」などに似ています。

たとえば、以下はそのようなコンポーネントの図です。 これはゲストブックです。 ゲストブックに関連するもののみが含まれ、それ以上は含まれません。 ご想像のとおり、このコンポーネントはゲストブックが必要なさまざまなプロジェクトで使用できます。



コンポーネントの技術的なタスクはサイト全体とほぼ同じですが、いくつかの例外があります。
TKコンポーネントには、サイト全体でTKが持つ次の記述ブロックがありません。

• 一般規定
• 運用目的
• 機能目的
• サイトコンテンツ
• 信頼性要件
• 配送と受け入れの条件

ただし、コンポーネントとサイトには、次のようなアイテムがあります。

• 用語と定義
• 機能特性
• ホスティング要件

このようなコンポーネントはメインプロジェクトに接続でき、コンポーネントからの参照条件のすべての部分がメインの技術タスクにマージされます。 利用規約、ページ間など

そのようなコンポーネントの構成を以下に示します。 コンポーネントとして、私は「予約」を最も特徴的なコンポーネントとして選択しました。 このようなコンポーネントのTKの構築は、基本的にサイト全体や他のコンポーネントの構築と変わりません。 つまり 実際、ミニTKの構築を継続します。これには、完全なタスクを構築するためのすべてのキーポイントが示されます。 このような操作により、重要な部分をすべて表示することができ、記事を巨大なテキストに変えることはできません。

私たちのサイトにもいくつかのコンポーネントがありますが、それらは「予約」よりもはるかに単純であり、同じ原則に従って作成されているため、それらについては説明しませんが、他の作品のために以前に作成され、単にプロジェクトに接続するだけです仕事の終わりに。

したがって、追加のステップ3、4、および5は「予約」コンポーネントに関連しています。

ステップ3.機能の説明。 データとリスト

セクション6「機能特性」では、サイトの作業（部分）を直接説明します。 なぜなら サイトのすべてのページ（コンポーネント）とすべてのエンティティについてさらに詳しく説明します。ここでは、作業の一般原則、または特定のページにリンクできない機能のいずれかを取り上げます。

お客様から、予約は次のとおりであるとの連絡を受けました。
特定の数の部屋があります。 部屋は異なるタイプ（より安く、より便利で便利）で、2または4部屋の家で、必ずしも同じタイプではありません。 クライアントは、リラックスしたい期間、部屋のタイプ、部屋の数を選択して、リクエストを行うことができます。 アプリケーションをチェックする必要があります。このため、マネージャーがクライアントに連絡し、クライアントが注文を確認すると、番号が予約されます。 さらに、クライアントからの支払いはしばらくの間予想され、支払いがN日後に到着しない場合、マネージャーは予約を削除します。 支払いが到着した場合、予約は支払い済みとしてマークされます。

また、予約の際、クライアントは1つの家で部屋を借りたいことを示すことができるはずです。

休日の価格は、部屋のタイプと期間によって異なります。 夏には1つの価格、冬にはもう1つの価格。

予約システムは、ユーザーが興味を持っている期間の座席の空き状況を把握し、予約要求を行う機会をユーザーに提供する必要があります。

キャンプ場には同じタイプの家がたくさんあると思われます。 家の部屋は、標準や豪華などの少数のカテゴリに分けられます。

予約時に、ユーザーは希望する部屋のタイプを示しますが、自分が望む番号は示しません。 ゲストが収容される特定の数は、マネージャーによって決定されます。

予約アプリケーションには3つの状態があります。

• 未確認
• 確認済み
• 予約済み

ユーザーがアプリケーションを作成すると、自動的に未確認になります。 マネージャーがクライアントに連絡して注文を確認すると、マネージャーは注文のステータスを「確認済み」に変更し、特定の家の特定の番号にアプリケーションを関連付けます。 支払いを受け取った後、マネージャーはアプリケーションのステータスを「予約済み」に変更します。

未確認のアプリケーションには、「アプリケーション確認期間」フィールドで定義された有効期間があります。 予約ステータスが「未確認」ステータスから変更されていない場合、アプリケーションの確認期限に達すると、アプリケーションは自動的に削除されます。

部屋の価格は、部屋のカテゴリ（標準、豪華など）と季節（たとえば、夏に高く、冬に安くなる）によって異なります。

予約を行うとき、ユーザーが1つの家のすべての部屋を予約することを希望することを示すために、ユーザーがチェックマークを使用できるようにする必要があります。 ただし、このチェックマークは単なる願いであり、マネージャーに通知するのに役立ちます。番号による第三国定住の最終決定は、状況に応じてマネージャーが行います。

すべての機能特性による。

エンティティ分析。

お客様の話から、次のことが明らかになります。

• 自宅で
• 家の部屋
• 部屋の種類（カテゴリ）（シンプル、快適、...）
• 期間（真夏）
• 季節と部屋に依存する価格
• アーマー

これらのエンティティについては、「データタイプ」の参照用語の5番目のセクションで説明する必要があります。

数

番号から始めましょう。 番号は家の中の部屋であり、属性からは、名前の意味での「番号」、番号、識別子、例えば「番号205」とカテゴリがあります。

ハウス

概して、これは単なる数字の集合体です。 つまり 彼には数字があります。それだけです。 写真も、階数も、位置座標もありません。 おそらく、タイプの名前は「Breeze」または「Sun」または単に「House 2」です。 部屋の番号（トートロジーについては申し訳ありませんが、そうでなければ新しい用語が必要ですが、私はしたくないでしょう）が家を一意に定義する場合、たとえば、「205」という番号は家2、部屋5を意味し、家はそのような名前を必要としません。 部屋の名前からすべてが明らかです。 顧客との会話から、家の名前がわかり、数字の数字は「念のために」テキスト行にする必要があることがわかりました。

家と部屋は、1対多の関係で接続されたエンティティです。1つの家には複数の番号があります。



「数値」タイプの「数値」変数は、そのままで、1対多の関係の存在を強調します。

ある段階で変数があるが、その意味をまだ知らない、または理解していない場合、そのタイプを「未定義」としてマークできます。 タイプ「Number」がまだ作成されておらず、データタイプのリストにまだない場合にも役立ちます。

カテゴリー

名前だけがあります。 顧客は、サイトのカテゴリは「Lux」、「Junior Suite」、「Standard」の順序で行く必要があると言っていました。 直感から、管理パネルでカテゴリの順序を設定する機能を追加する必要があることがわかります。 これは、変数「Order」の構造の説明に追加することで示されます。

期間

需要に応じて異なる価格で期間を定義するエンティティ。 例えば、需要が最大の夏には価格が高くなり、需要が低い冬には顧客を刺激するために価格が下がります。 期間には開始と終了が必要ですが、各期間に「開始」と「終了」の2つの日付を入力する場合、期間の終了が常に次の開始と一致するようにする必要があります。すでに終了しており、夏はまだ始まっていないか、逆に期間が重なっています。

2つの値が常に一致するようにする必要がある場合は、1つの値を捨てることが最善です。とにかく新しいものは追加されません。 したがって、期間の開始点のみがあり、1つの期間の終了点は次の期間の開始点になります。

価格

価格（エンティティ）には価格（属性）があり、一方では部屋のカテゴリに依存し、他方では期間に依存します。 このことから、価格はすべてのカテゴリとその年のすべての期間を結ぶ結合テーブルであり、価格はこれらのリンクにあると結論付けることができます。

アーマー

おそらく最も広範な構造。 アーマーには次のものが必要です。

• アクションの開始と終了（日付）
• 希望の部屋のカテゴリ（カテゴリ）
• 部屋数（整数）
• 顧客名、電話番号、電子メール（行）
• 「1つの家のすべての部屋」（論理的）を望む
• 注-予約時にクライアントが残したテキスト（テキスト）
• アプリケーションの状態（整数）
• 申請確認期限（日付）
• コメント-サイト管理者によるメモ（テキスト）
• 番号-アプリケーションに含まれる番号のリスト（番号のリスト）

リスト

少なくとも管理者パネルでは、価格を除き、上記のすべてのエンティティのリストが必要になります。価格は個別の会話になります。 私たちの場合、リストはシンプルで、飾り気がなく、特別な説明は必要ありません。

この時点で、データ構造を使用した参照条件のセクションは十分に補充されました。

ステップ4.コンポーネントの構造とページの説明

「予約」コンポーネントのToRでは、「ページ」のセクション7は空白のままでした。 アウトライン構造をスケッチすることで、必要なページを簡単に想像できます。

予約の公開側は小さく、価格のページと予約といくつかの子会社のページが含まれます。

管理パネルでは、前述のエンティティを編集するためのセクションをいくつか作成する必要があります。

このような「ディレクトリ」の編集は、エンティティのすべての要素のリスト、既存のエンティティの編集への切り替え、新しいエンティティの作成、および既存のエンティティの削除の典型的な外観を持っています。 T.O. エンティティごとに3つのページが必要です。要素を削除する機能を備えたリスト、エントリを作成および編集するためのページです。

上記のように、価格用に別のページを作成し、スキップしますが、別のトライアルが必要になります。

変更されたスキーム：


ここに技術的なタスクがあります 。これはページとサイトレイアウトを説明するための空のセクションでこれまで補充されました。

ステップ5.ページの説明

サイトページのテキストを書く準備

Bookingコンポーネントに必要なページとデータは既に決定しています。

次に、ページのテキストの説明をさらに簡素化するトリッキーな移動を行います。

前のステップで説明したデータをページに接続します。 これを行うには、構造またはリストを適切なページにプルアンドドロップします。 たとえば、管理ページ「期間の作成」で「期間」をドロップし、次のアクションでこのページに新しい期間を作成できることを示します。



このアクションにより、ページ記述の作成の準備に加えて、TKの「ギャップ」に気付くことができます。 たとえば、データで満たされていない「ボックス」が表示された場合、これは少なくとも奇妙です。 データが関連付けられていないページはどのようなものですか？ または、ページがあるかもしれませんが、そのデータを説明するのを忘れていませんか？

ここで、回路全体にデータと関連する操作を入力します。少し後で、非常に役立ちます。

ページの説明

すべてのページを説明するための最後のステップ、つまり TOR「ページ」の7番目のセクションに入力します。 このステップはかなり大きいですが、作業を簡素化する手段があります。

原則として、各サイトには、他のすべてが展開する「ハイライト」のようなものがあります。 顧客が自分のサイトについて話すとき、彼はこの特定のハイライトに最も注意を払い、請負業者はそれぞれこのハイライトに最も取り組んでいます。 原則として、このハイライトは怠ではなく、それについて考え、ToRで記述し、コードに実装することは興味深いです。

「ハイライト」が完了すると、実行者の魂は作業が完了したと感じ、残りのルーチンは些細なことです。 主なものは背後にあります。

このサイトのハイライトは予約です。 詳細な説明は3ページに値します。

• 予約、顧客ページ
• 注文のマップ（管理者）
• アプリケーションの編集（管理者）

ページの説明を作成する必要がある場合、最初にページをスケッチします。これは、微妙な点を理解して確認し、その後でテキストの説明を行うのに役立ちます。 そこで、まず、「注文の地図」ページのサムネイル。

_{スケッチについて。 スケッチを作成するには、 鉛筆プロジェクトを使用します。 これがその種の最高のプログラムであるとは言いませんが、それは起こりました。 さらにすべてのスケッチは、その助けを借りて作成されました。 ちょっとしたコツ：コンポーネントを作成するときは、常にコンポーネントとともにソーススケッチファイルを保存します。 したがって、次のサイトを作成するとき、新しいプロジェクトの複雑さを考慮してスケッチを再描画することは難しくありません。}



そして今、テキストの説明：



パレートの原則によれば、キーページレーズンは結果の80％を決定しますが、20％の労力が必要です。 次に、結果の20％と作業の80％を見つけます：ルーチンページ。

たとえば、部屋のカテゴリと期間のリストを含むいくつかの定期的な管理ページ：





これらのページは常に類似しています：エンティティのリスト、新規作成、古い削除、編集、ページネーターなど。 そして、それらを何らかの形で説明することは、非常に刺激的ではありませんが、必要です それらは一般的に類似しているという事実にもかかわらず、詳細が異なります。 そして、そのようなページでは、顧客から多くのウィッシュリストを入手できます。 ページハイライトの場合、顧客のウィッシュリストにある要望を満たす準備ができている場合、 それは本当に重要で必要です。二次ページのウィッシュリストは最も刺激と拒絶を引き起こします。

そしてここで勇敢な航空が私たちの助けになります。データを記述し、それらを図のボックスにリンクするために行われた作業です。 このようなバインディングの後、記述生成が利用可能になります。 たとえば、カテゴリ番号のあるページには、次のオプションがあります。



緑色の枠は、このページに関連付けられたデータに基づいて置換された単語を示しています。

出産とケースの承認のために生成されたテキストを手動で編集することから逃れることはできません（現時点では、この方向で作業が進行しています）。ナビゲートできます。

独自のテキストを書くことができることに注意してください。 テキストの場合、対応する値に置き換えられる変数が利用可能です。



前述の価格設定ページはまだあります。

価格を編集する別の方法があります。 価格は期間に関連付けられています。 したがって、期間を編集するページに、編集の可能性があるさまざまなカテゴリのこの期間の価格のリストを表示することができます。



ただし、この場合、部屋の新しいカテゴリを追加するときは、すべての期間を経て新しい価格を追加する必要があります。そして、これは、いくらかの価格を忘れなければならないという事実に満ちています。

カテゴリー編集ページでエディターを作成すると、同様の問題が発生します。期間を追加する場合、すべてのカテゴリーを調べて価格を指定する必要があります。

許容されるオプションは、列が期間、行がカテゴリ、セルが価格の表を作成することです。このシナリオでは、価格を示すのを忘れることは困難です。なぜなら、それらはすべて見えています：



そして説明：

価格表が表示されるページ。
表では、行は数字のカテゴリであり、列は期間です。表のセルには、価格を変更できる入力フィールドが含まれています。

入力したデータが間違っているか、必須フィールドが空の場合、価格をデータベースに保存しないでください。
この場合、以前に入力したデータを保存し、誤って入力されたフィールドを表示して、同じページへの移行を実行する必要があります。

この時点で、参照コンポーネントのすぐに使用できる「予約」用語と、すべてのページのサムネイルを含む図があります。

強調表示されたページは、青いバーと価格編集ページ、灰色のバーが付いた通常のページで強調表示されます。ページの説明の横の写真はクリック可能です。

ステップ6.その他

フクロウの残りの部分を描きます。残りはほとんどありません。画像ギャラリー、フィードバックフォーム、顧客レビュー、ロケーションマップ。

上記のすべてについて、過去のプロジェクトのコンポーネントがあり、それらをプロジェクトにドッキングするだけです。

そして、ここで我々の仕事の結果である：参照の最終条件及び回路は、サイトを取得します。

---

レビューや質問、私が見逃す可能性のある「暗い」場所に喜んでいます。すべての質問に答えようとします。