注: ドキュメントの内容の一部とシステムのスクリーンショットを表示します。完全なビデオ、コード、記事、インストールおよびデバッグ環境が必要な場合は、アップの所有者にプライベート メッセージを送信してください。
4.1 システム設計の原則
システム設計の原則には次の点が含まれます。
(1) 実用性の原則 システムの普及促進を実現するには、システムが実用的であることが前提となる。ページの美しさからユーザーのログインに至るまで、ユーザーが Bistro システムを使用して優れたエクスペリエンスを得ることができるようにし、ユーザーのニーズと実用性を満たすために Bistro システムの機能を使用することを保証します。
情報システムがオンライン化に成功し、最終的に承認を通過する場合、実用性はその承認のための重要な前提条件です。実用性の原則は、このシステムの設計の最初から十分に理解されていたため、実用性の原則はシステム設計中に厳密に遵守されました。システム設計プロセス。
(2) セキュリティ原則: システムは業務に利便性をもたらしますが、システムを設計する際にはセキュリティ、プライバシーなどの問題を考慮する必要があります。特に、アカウントセキュリティ、情報セキュリティ、侵入防止セキュリティなどの強化に関しては、安全なプログラムを使用することで、ユーザーはより安心して使用できるようになり、ユーザー情報の漏洩によるユーザーエクスペリエンスの低下を回避できます。
(3) 操作性の原則：ユーザーがより良い操作体験を得るために、システム設計では操作性を優先する必要があります。システム設計は、ユーザーが複雑な問題をより便利かつ効率的に解決できるようにすることが主な目的であるため、操作手順が多く、難易度が高いと、システムの本来の価値が失われてしまいます。問題を完了するために複数のステップに分割すべきではありません。最も一般的なワンクリックで完了するように設計できます。操作が簡単なプログラムがあって初めて、より多くのユーザーがそのプログラムを使用できるようになります。ユーザーが後で起動できなくなるのではなく、プログラムに入ります。
4.2 システム要件の分析
本システムは、居酒屋経営の管理を支援するとともに、利用者による居酒屋管理システムの管理、または管理者による居酒屋管理システム等の情報の管理を支援するために開発されたものであるため、このシステムも同様のことを行う必要があり、居酒屋管理システムまたは利用者が行うことができる。居酒屋経営などの情報を閲覧すると同時に、居酒屋管理システムは国民情報や個人情報を変更することができ、システムにはユーザーの居酒屋経営状況の閲覧などの管理者機能を操作するための管理者ロールも必要です。
4.3 システムの動作原理
このシステムの動作原理図を図 4-1 に示します。
4.4 システム機能の動作プロセス
4.4.1 ログインシーケンス図
このモジュールの基本的な機能はログインです。ユーザーと管理者がシステムに入る前に、「ログイン」を選択し、指定されたデータを書き留めてログインを完了します。図 4-2 に示すユーザー ログイン シーケンス図。
4.4.2 パーソナルセンターモジュール
このモジュールの基本的な機能はユーザーの情報を保存することであり、ユーザーはボタンをクリックして個人情報を入力します。パーソナルセンターのタイミング図を図 4-3 に示します。
4.6 システムデータベースの設計
データベースの設計は、居酒屋システム内のすべての情報が保存される場所ですが、それは抽象的な記述であり、目に見えないため、ユーザーのデータが失われないことを保証するために、データベースの構築が重要です。同時に、このデータベースに追加、削除、変更、クエリなどの機能を追加する必要があるため、この居酒屋データベースを設計する前に、居酒屋のユーザー情報管理と管理者情報の管理、ワインの輸入、およびワインの輸入など、必要な計画作業を実行しました。ワインの保管場所、およびワインの販売に関する情報を保管する必要があります。
居酒屋データベースを設計する際、ユーザーのセキュリティを確保する必要があります。ユーザーの情報は共有されないため、情報を混在させることはできません。ユーザーに権限を割り当てる必要があり、自由にアクセスすることはできません。その他の目的故障や事故を避けるために、ユーザーの情報をバックアップする必要があります。また、データ損失後のデータの回復を容易にするために、居酒屋システムの情報もバックアップする必要があります。エンティティ E-R グラフ モデルを使用して、エンティティ、属性、関係、その他の部分から構成されます。 居酒屋システムに必要な機能の分析に基づいて、次のエンティティと E-R 図の接続を導き出しました。ユーザーエンティティ図。図 4-8 を参照してください。
4.6.2 数据库物理设计
データベース物理設計論理設計の後、エンティティ情報を取得し、データベース図を通じてエンティティ情報を提示しました。また、常に検討しています。テーブル構造の設計は、後のセキュリティ問題に影響を与え、システム パフォーマンスの最適化にも一定の影響を与えるためです。
表 4-1 ユーザーテーブル
| 分野 |
タイプ |
フィールドの説明 |
述べる |
| ID |
内部 |
主キー |
自己増加 |
| ユーザー名 |
バーチャー(50) |
ユーザー名 |
空ではない |
| 合格 |
バーチャー(30) |
パスワード |
空ではない |
| セックス |
バーチャー(30) |
性別 |
デフォルトは1です |
| 追加時間 |
日付 |
時間を追加する |
システム時刻に従う |
| 年 |
シャア |
年 |
|
| 電話番号 |
バーチャー(50) |
電話 |
表 4-2 構成表
| 分野 |
タイプ |
フィールドの説明 |
述べる |
| ID |
内部 |
主キー |
自己増加 |
| 名前 |
バーチャー(50) |
名前 |
空ではない |
| 価値 |
バーチャー(30) |
パラメータ値 |
表 4-3 ビストロテーブル
| 分野 |
タイプ |
フィールドの説明 |
述べる |
| ID |
内部 |
主キー |
自己増加 |
| アッドタイム |
日付 |
時間を追加する |
空ではない |
| 名前 |
バーチャー(30) |
名前 |
空ではない |
| 写真 |
バーチャー(30) |
写真 |
|
| 番号 |
バーチャー(30) |
シリアルナンバー |
空ではない |
| 分類 |
シャア |
カテゴリー |
空ではない |
表 4-4 トークンテーブル
| 分野 |
タイプ |
フィールドの説明 |
述べる |
| ID |
ビギント |
主キー |
自己増加 |
| ユーザーID |
ビギント |
ユーザーID |
空ではない |
| ユーザー名 |
varchar(100) |
ユーザー名 |
空ではない |
| テーブル名 |
varchar(100) |
テーブル名 |
|
| 役割 |
varchar(100) |
役割 |
空ではない |
| トークン |
varchar(100) |
パスワード |
空ではない |
| 追加時間 |
タイムスタンプ |
時間を追加する |
空ではない |
| 有効期限切れ |
タイムスタンプ |
有効期限 |
空ではない |
表 4-5 管理者テーブル
| 分野 |
タイプ |
フィールドの説明 |
述べる |
| ID |
ビギント |
主キー |
自己増加 |
| ユーザー名 |
varchar(100) |
名前 |
空ではない |
| パスワード |
varchar(100) |
パスワード |
|
| 役割 |
varchar(100) |
役割 |
空ではない |
| 追加時間 |
タイムスタンプ |
時間を追加する |
空ではない |
5.2 ホームページインターフェースモジュール
ユーザーがコンピュータ上で居酒屋システムを使用する場合、アカウントとパスワードを入力してシステムにログインすると、ホームページに直接アクセスできます。ホームページのインターフェイスは、図 5-5 に示されています。
5.3 ワイン詳細情報モジュール
ユーザーが売れ筋ワインをクリックすると、売れ筋ワインの詳細情報インターフェイスが表示されます。このインターフェイスでは、ワインがさまざまな種類に分類されます。インターフェイスは図 5-8 に示すとおりです。
6.1 テストの目的
システムテストは、居酒屋管理システムの設計完了後に不可欠なステップであり、システム設計完了後、顧客が会計時にホットドリンクを選択する、ショッピングカートの情報を検索するなど、居酒屋システムには多くの問題が発生する可能性があります。選択した製品と一致しない、またはログインしたときにアカウント情報が自分のものではないことが判明したため、居酒屋システムのシステム機能をテストする必要があります。このアプリケーションはユーザーに高いレベルのエクスペリエンスを提供します。
6.2 テスト計画
システムの各モジュールの機能をテストします。管理者アカウントにログインし、ユーザーのリクエストを処理し、ユーザーのアカウントにログインし、曲リクエストとホットドリンクモジュールを通じてリクエストを開始し、システムがユーザーに正しい応答を与えることができるかどうかを確認し、ユーザーを通じて個人情報を変更します。 、データベースのバックグラウンドが同期的に変更されているかどうかを確認します。
6.3 テストケース
システムのテストケースは代表的なものであり、機能が正しく利用されているかどうかをテストケースで表現できるか検証できる必要があり、居酒屋のテストケースをテストした後は、具体的な結果を十分に記述して、その結果をわかりやすく説明する必要があります。テスト結果
居酒屋システムへの情報追加のテスト結果を表 6-1 に示します。
表6-1 システムユーザー情報追加テスト結果表
| シリアルナンバー |
試験方法 |
期待される結果 |
実績 |
| 1. システム プロンプト要件を満たすユーザー情報を入力し、[保存] をクリックします。 |
正常に追加されました。そして、追加されたユーザー情報をユーザー表示インターフェイスに表示します。 |
合格 |
|
| 2. システム プロンプト要件を満たさないユーザー情報を入力し、[保存] をクリックします。 |
システム プロンプト要件を満たさない情報は追加に失敗し、ユーザーには追加に失敗するプロンプトが表示されます。 |
合格 |
|
| 3. システム プロンプト要件を満たすユーザー情報を入力し、[リセット] をクリックします。 |
エントリー情報がリセットされます。 |
合格 |
ユーザー表示インターフェイスに入り、削除する情報の右側にある削除ボタンをクリックします。システムのプロンプトに従って、与えられたプロンプトに基づいて主観的に独自の選択を行い、削除ボタンとオフボタンをクリックする必要があります。ユーザーの削除のテストが完了しました。上記の操作の結果を表 6-2 に示します。
表6-2 システム削除情報テスト結果表
| シリアルナンバー |
テスト手順 |
期待される結果 |
実績 |
| 1 |
削除するユーザー情報の右側にある削除ボタンをクリックして削除を確定します。 |
正常に削除されました。ユーザー表示インターフェイスには、削除されたユーザー情報は含まれません。 |
合格 |
| 2 |
削除するユーザー情報の右側にある削除ボタンをクリックして削除を終了します。 |
削除確認画面が消え、ユーザー情報は削除されません。 |
合格 |
ユーザー情報のテストケースを変更するには、テスターは管理者アカウントにログインし、ユーザー管理のユーザー表示機能をクリックすると、ユーザー表示インターフェイスが表示されます。このインターフェイスに入ると、ボタンが表示されます。ボタンはユーザー情報で、管理システム上の一部の情報の変更アクションの右側に変更用のマークがあります。これらの操作を完了すると、次の結果が得られます。
目 录