中小規模のケータリング企業のワークフローの詳細な調査に基づいて、ケータリング企業の作業効率を制限するさまざまな要因を分析した結果、効率に影響を与える主な要因は、レシピの手動登録が一般的に使用されている現象であることがわかりました。このシステムは、ケータリング企業 顧客オーダー、シェフケータリング、レジ管理、システム設定の4大機能を実現し、ケータリング会社における顧客オーダーの遅さ、ウェイター登録のわかりやすさ、シェフのケータリング不在、レシピ更新のタイミングの遅さ、直感的でない、混乱するメンバー管理の問題を解決現象。
キーワード: レストランのオーダー、オブジェクト指向開発手法、C#
目次
要約 I
第 1 章 はじめに 1
1.1 実践的背景と理論的背景 1
1.2 研究の目的と意義 2
1.2.1 目的 2
1.2.2 意義 3
第 2 章 システム要件の分析 4
1. はじめに 4
1.1 執筆の目的 4
1.2 プロジェクトの背景 4
2 . 用語の定義 5
3. 参考資料 5
4. 現在のケータリング企業のワークフロー 5
5. 提案システムのワークフロー 6
6. 製品の機能 7
7. ソフトウェア要件の説明 7
8. システムユースケース図 8
9. ソフトウェアインターフェース 9
第 3 章 システム設計 10
1. システム配置図設計 10
2. データベース設計 11
2.1 命名規則 11
2.2 セキュリティ設計11
2.3 概念設計 11
2.4 物理設計 13
2.5 機能設計 15
3. システムモジュール設計 16
4. システムアーキテクチャ設計 17
5. クライアントシステムディレクトリ構造 17
6. システムクラス図設計 18
7. メインモジュール設計 22
7.1 ログインモジュール設計 22
7.2 オーダーモジュール設計 24
第 4 章 システム実装 27
1: システムコーディング仕様 27
1.1: 型の名前付け 27
1.2、メソッドと属性の名前付け 28
1.3、変数と定数 28
1.4、ラベル 29
1.5、名前空間 29
1.6、注記 30
2: モジュール関数の実現 30
2.1 ログインモジュールの実現 30
2.2 メイン注文モジュールのコード 31
2.3 レジモジュールのコード実装 33
2.4 ケータリングモジュールのコード実装 35
2.5 システム管理モジュールの実装 35
第 5 章 システムテスト 37
1 はじめに 37
1.1 執筆の目的 37
1.2 プロジェクトの背景 37
1.3 システムの紹介 37
1.4 用語と略語 38
1.5 参考文献 38
2 テストの概要 38
2.1 テスト ケースの設計 38
2.2 テスト環境と構成 38
2.3 テスト方法 (およびツール) 39
3 テスト結果と欠陥分析 39
3.1 テストの実行と記録 39
結論 45
文献 46
感謝 49
第 1 章 はじめに
1.1 実践的な背景と理論的背景
1.1.1 実践的な背景
中国の外食市場における 30 年以上の改革、開放、発展を経て、我が国は外食産業の大きな発展期を迎えていると言えます。市場の潜在力は巨大であり、その見通しは非常に有望です。中国料理協会が発表した「2009年外食産業発展報告」によると、経済が大打撃を受けた2009年でも、社会全体の外食産業の小売売上高は1兆7,998億元に達し、前年比で増加した。 16.8%。このうち、月間小売売上高は1,300億元を超え、成長率は14.4～21.6％で安定した。あらゆる消費支出の中で、交通費、通信費に次いで伸び率が高い。そしてケータリング市場は2012年も成長を続け、売上高は2兆元に達すると予想されている。
同時に、我が国のケータリング産業の発展の質と内包も大きな変化を遂げました。業界の事業分野と市場空間は拡大し続け、ビジネスレベルと企業管理レベルは向上し続け、ビジネス形態はますます多様化し、投資主体と消費者の需要の多様化の特徴はより顕著になり、その数は増加しています。店舗数と人材チームは拡大を続け、ケータリング市場はより繁栄し、消費の個別化と専門化の傾向は明らかであり、健康的な栄養の追求とチェーン規模の発展がテーマとなっています。集団化、ブランド化、工業化、国際化の発展のペースは加速しており、近代化に対応するプロセスは常に進歩しています。
近年、中国の外食産業の発展は力強い急速な成長を維持していますが、同時に外食産業に共通する問題も見えてきました。外食企業の発展は常に自己探求、自己運営、自己蓄積、自己改善の状態にあり、低利益、重負荷、少額サポート、困難な発展の特徴が顕著です。ケータリング企業は、製品の標準化技術と設備の開発、チェーン管理システムの確立、専門人材の育成、資本投資の吸収、理論的指導と情報交換などの条件が非常に不十分であり、技術開発には困難があります。流通チャネルと開発資金の困難、コミュニケーションと協力の困難、業界プラットフォームと基本サポートの弱さなどの根深い要因によって制約され、企業の発展に大きな影響を与えます。
1.2 研究の目的と意義
1.2.1 目的
「食文化」が高度に発達した我が国において、ケータリング産業は間違いなく最大の伝統産業となっている。しかし、長い歴史と規模を誇るこの業界は、情報化が最も遅れ、最も進んでいない業界の一つでもあります。これまでのところ、ほとんどのケータリング企業の運営形態は依然として「紙とペン、マネージャーが大声で叫び、従業員が逃げる」という状況に留まり、会計業務は依然としてペンかそろばんに基づいています。 、または最良の場合、加算、減算、乗算、除算の計算機は依然として人間の脳の計算に基づいており、これは膨大な作業負荷であるだけでなく、非常に間違いが発生しやすいものでもあります。筆者は以前、非常に繁盛している屋台を見たことがありますが、ウェイターが屋外テーブルとロビーバーとキッチンの間を慌ただしく出入りし、マネージャーが電卓を手に大汗をかきながらいる光景は壮観でした。このような日々の反復的で単調な労働の意味は言うに及ばず、消費量の計算ミスだけでも引き起こされる顧客との軋轢や諍いは枚挙にいとまがない。
実際、人類の文明は電子情報の時代に入り、反復的で単調なプログラム可能なタスクのほとんどはすでにコンピューターによって完了できます。複雑かつ膨大なコンピューティング タスクに直面すると、コンピューターの効率と精度は人間の脳の及ばないものになります。伝統産業であるケータリング産業も、他の多くの伝統産業と同様に、情報変革を導入する可能性があります。
ケータリング業界の情報化変革の内容としては、主に、従来の紙とペンによる注文から電子注文への変更、従来の手作業による計算、統計、管理をコンピュータによる計算、統計、管理に置き換えること、現代の電子技術や無線技術に置き換えることが挙げられます。 、コンピューター技術とネットワーク技術がケータリング業界に導入され、一部の手動作業が置き換えられ、ケータリング企業の業務効率が向上し、ケータリング企業の管理レベルが向上し、ケータリング企業の運営がより標準化され、科学的かつ効率的になります。
ケータリング企業の情報化変革において、ワイヤレス受発注（発注）システムはその中核コンテンツとなっており、ケータリング企業が情報化変革を実行する唯一の方法でもあります。
そこで本論文の目的は、ケータリング企業の情報化変革と無線技術の活用により、従来の紙とペンに代わる電子注文（受発注）業務を実現し、長距離への即時情報伝達を実現することである。もちろん、ワイヤレス注文（受発注）システムは料理を注文するだけでなく、サポートするケータリング管理ソフトウェアを通じて強力な統計機能と管理機能を実現できるため、ケータリング企業は真の情報化を実現できます。
1.2.2 意義
情報化は、ケータリング企業の等級と管理レベルを効果的に向上させ、科学的な管理、科学的な意思決定、効率的な運営を実現し、コストを削減する唯一の方法です。従来の手動注文に代わるワイヤレス注文（発注）システムの使用、および従来の手動統計と広範な管理に代わるケータリング管理ソフトウェアの使用は、情報化の中核的な内容です。
ケータリング会社が導入する無線受発注（オーダー）システム一式のコストは約1万元（構成による）で、ウェイターの1年間の給与に相当するが、もたらされる利便性と管理レベルの向上は比類のないものだ。ワイヤレス受発注（受発注）システムによってもたらされる業務効率の大幅な向上と人件費の削減は、投資コストをはるかに上回っており、ケータリング企業の情報化に最適な選択肢といえる。
第 2 章 システム要件分析
2.1 はじめに
2.1.1 執筆の目的
この文書は、レストラン注文システムのプロジェクト要件仕様書であり、レストラン注文システムを簡単にレビューし、現在のビジネス プロセスを分析し、このタイプの管理の基本的な特徴を要約しています。システム全体の機能、すべての要件を可能な限り完全に要約および抽出します。この文書は、プロジェクト開発者、設計者、システム実装者にとって非常に重要な指針となります。
2.1.2 プロジェクトの背景
中国は、5,000 年の食文化と巨大なケータリング市場を持つ世界的に有名な美食国であり、人々の生活水準やライフスタイルの変化に伴い、ケータリング産業は中国の「しかし、 , ケータリング業界は大きな発展のチャンスに直面しているだけでなく、前例のない課題や試練にも直面していることにも留意すべきです。
ケータリング業界の継続的な発展に伴い、運営と管理も徐々に電子化の方向に進んでおり、ケータリング業界の内部事務はコンピュータ情報システムを通じて管理され、運営がよりシンプルかつ効率的になっています。財務に焦点を当て、現場オペレーターの労働集約度を軽減し、ビジネス担当者のシフト時間を節約し、財務監査管理を強化します。注文・決済・統計レポートなどの多彩な機能を提供し、フロントで注文データを直接印刷できる独立したキッチンを提供する。ケータリング業務では、従来の紙製造プロセスでは、情報エンターテインメントとサービスのセキュリティの観点から現代の顧客の要件を満たすことができません。このシステムを使用することで、レストランのマネージャーはビジネスやエンターテイメントを便利に管理できるようになり、各店舗のコスト管理と売上が大幅に向上します。
回転率が高いということは、食べて帰る人が多いことを意味し、回転率が低いということは、同じ客が長時間テーブルを利用しているか、テーブル席が空であることを意味します。
2.3 ケータリング企業の現在のワークフロー
現在、中小規模のケータリング企業は最も手作業による記帳方法を採用しており、その業務プロセスは図 2.1 に示されています。
図 2.1 手動業務プロセス分析の導入
フローチャート: 顧客はレストランに到着し、案内係に席に案内された後、レシピを手に取り、注文した料理を登録します。ケータリングスタッフは、ロビーのウェイターが提出したレシピに基づいて、ゲストのためにドリンク、ドリンク、デザートなどの料理をすべて調理し、シェフが素早くおいしい料理を調理します。ロビーのウェイターが提供するレシピに従って、最初に冷まして、次に熱いという順序で配達スタッフと仲良くなり、指定されたテーブルに配達します。客が食べ終わったら、ウェイターや客がレジに行って精算手続きをするが、客が会員カードを持っていれば、レジはそれに見合った割引をするはずだが、必然的にレシピの争奪戦が起きて、間違った料理が提供されることもある皿の取り忘れ、皿の取り忘れ、皿の出し忘れ、計算ミスなどは、少なくとも顧客の不満、最悪の場合は紛争の原因となるため、上記のような事態が発生しないように新たな業務形態を導入する必要がある。
2.5で提案するシステムのワークフローは、
従来のケータリング企業の手作業によるさまざまなデメリットを踏まえ、コンピュータを用いて情報を管理する新たなシステム、レストランオーダリングシステムが誕生した。図 2.2 に示すように
図 2.2 自動発注システム
2.6 システムの機能モジュール
提案システムの業務フローチャートに基づき、新システムの機能モジュール図を分析すると、2.3 に示すようになる。
図 2.3 機能モジュール図
上記の機能モジュール図と組み合わせると、システム要件は次のように説明されます。
2.7 ソフトウェア要件分析
1. ユーザーログイン
システムは、ユーザー名とパスワード、役割検証機能を提供し、異なる役割に応じて異なるサブシステムを開く必要があります。
2. 顧客は食べ物を注文します。
顧客はさまざまなサービスカテゴリ（スペシャルオファー、冷たい料理、温かい料理、スープ、ワイン、飲み物）に応じて異なる料理と量を選択します。システムはさまざまな料理に応じて合計価格を計算し、顧客が管理するのに便利です。合計金額 システムへの入力ミスがあった場合の削除機能を提供します。
３．ケータリング管理
シェフは、最新のケータリング情報に基づいて時系列に料理を構成し、完了後に決済管理サブシステムに提出します
。決済管理
テーブル番号に応じてシステムが自動計算し、会員カードシステムがカード番号と会員本人確認を自動認証すると、それに応じた割引額と実際の支払額を計算します。
5. システム管理
レシピ画像のアップロード、レシピ価格の変更、ユーザー登録、ユーザー削除、会員登録、会員管理、顧客メッセージ閲覧、顧客満足度統計などの機能を明確に設計しており、具体的なユースケースは以下の通りです。ログインの使用例は図 2.4、注文の使用例は図 2.5、ケータリングの使用例は図 2.6、チェックアウトの使用例は図 2.7、および注文の使用例は図 2.8 に示します。管理のユースケース
図 2.4 ログインの使用例
図 2.5 注文の使用例
図 2.6 ケータリングの使用例
図2.7 決済のユースケース
図 2.8 システム設定の使用例
2.9 ソフトウェア インターフェイス
Windows オペレーティング システムによって提供されるさまざまな API [10];
第 3 章 システム設計
3.1 システム配置図の設計
システム配置図とは、システムの物理構造とソフトウェア構造の空間的配置を指します。 、この構造はクライアントとサーバーの構造に基づいています。その理由は、このシステムのアプリケーションシナリオが中小規模のレストランやレストランであり、現在プロジェクトの第1フェーズではWebサービスが提供されていないためです。したがって、C/S 構造を採用することは科学的かつ合理的です。具体的な構造を図 3.1 に示します。 図 3.1
システム配置図
上図のサーバーはシステム全体の動作の基礎であり、SqlServer2005 サーバーを使用してすべてのクライアントのデータ送信と保存を担当し、ネットワーク送信には WiFi ( 802.11 を
Win7として
端末)インストールする必要があります。 データベース ログイン アカウント ダイニング2: データベース db_ Dining の所有者ユーザーを作成します。 ダイニング3: アカウント マッピングを構成します。 ダイニング-ダイニング3.2. 3 概念設計システムの要件を分析した結果、図 3.2-3.8 に示すようにシステムには次のエンティティがあることがわかり、それらの関係は図 3.9 に示されます。
図 3.2 ユーザーエンティティ - 属性
図 3.3 意見エンティティ - 属性
図 3.4 メンバーシップ エンティティ - 属性
図 3.5 食事リストのエンティティ属性
図 3.6 食事リストの詳細エンティティ属性
図 3.7 レシピエンティティ - 属性
図 3.8 エンティティ関係図
3.2.4 物理設計
物理設計はデータベース エンティティを物理的に実現するもので、以下の図は概念設計の各エンティティに対応します。
1: T_CAIPU テーブル (図 3.9 を参照)
図 3.9 レシピ表
2: T_CanMingXi (図 3.10 に示す)
図 3.10 食事リスト
3: T_CanDan、図 3.11 に示す
図 3.11 食事表
4: T_Member (図 3.12 に示す)
図 3.12 メンバー テーブル
5: T_User (図 3.13 に示す)
図 3.13 ユーザー テーブル
6: T_YiJian、図 3.14 に示す
図 3.14 オピニオン表
3.2.5 関数設計
1: F_CaiJinEById (図 3.15 参照)
図 3.15 価格計算関数
2: F_CaiMingById (図 3.16 を参照)
図 3.16 料理名検索関数
3: F_MemberLeavlByID (図 3.17 に示す)
図 3.17 メンバー レベル関数
4: F_MemberNameByID (図 3.18 を参照)
図 3.18 メンバ名機能
3.3 システムモジュールの設計
システム要件の分析に基づいて、以下の 8 つのモジュールの合計 8 つのモジュールを設計します [11]。3.3.1 システムログインモジュール
このモジュールでは、主にユーザー ID の検証と役割のチェックを実現し、異なるユーザー ID に従って異なるサブシステムにログインします。
3.3.2 システム注文モジュール
このモジュールはシステムのメインモジュールです. このモジュールでは主に料理と飲み物を注文する機能が実装されています. 食べ物の分類に応じて, インターフェースは特別メニュー, 冷たい料理, 温かい料理に分かれています. 、スープ、ドリンク、ドリンク用の別のエリアと食べ物を注文するためのエリア。
3.3.3 システムのケータリングモジュール
このモジュールは主にシェフやドリンクケータリング業者を対象としており、その機能は食事の時間順に従って注文リストを表示することであり、シェフは詳細リストに従ってさまざまな料理やその他の項目を設定します。メニューの。各食事の注文が完了すると、システムはそれをレジエリアに提出します。
3.3.4 システムレジモジュール
このモジュールは主にレジ担当者向けであり、その機能は、食事の準備後にメニューを表示し、顧客が食事後にテーブル番号と会員カードを提示することであり、システムは割引額と割引額を自動的に計算します。実際の支払い金額: 支払いの受領後、システムはデータベースを自動的に更新します。
3.3.5 システム管理モジュール
主に管理者・管理者向けのモジュールであり、メンバー管理、レシピ管理、ユーザー管理の機能を実現します 3.3.4
システムアーキテクチャ設計
本システムは、/server- という一般的な C/S 構造を採用しています。サイド構造、クライアントは .Net FrameWork プラットフォームに基づくアプリケーション プログラム、サーバーは Sql Server 2005 に基づくデータベース ストレージ アプリケーション システム、プログラミング言語としてオブジェクト指向開発言語 C# [13] が使用されます。 Visual Studio 2010 開発ツールおよび一般的なソフトウェア開発モデルとしてのウォーターフォール モデル [14]
3.5 クライアント システムのディレクトリ構造
クライアント ディレクトリ構造は、ファイル管理と将来の二次開発を容易にするために、異なるモジュールに従って異なるファイル ディレクトリを作成します。スクリーンショットは 3.19 に示されています。
図 3.19 システム ディレクトリ
ディレクトリ構造の説明: 1: DianCan: 顧客注文モジュール 2: PeiCan: ケータリング モジュール 3: JieZhang: レジおよびチェックアウト モジュール 4: 管理: システム管理モジュール 5: 画像: システム画像 3.6 に従ったシステム クラス図の設計の
システムエンティティに
、詳細については以下の図 3.20 に示すように、合計 6 つのクラスが設計されています。
図 3.20 システムクラス構造図
詳細な説明は以下のとおりです。
1. T_CaiPu レシピ クラス、このクラスの属性とメソッド構造を 3.21 に示します。
図 3.21 レシピ クラス
T_CaiPu クラスはシステム内のレシピ エンティティを記述するために使用され、その属性には id (レシピ番号)、c_name (レシピ名)、c_Price (料理の価格)、c_type (カテゴリ)、c_image (写真)、 is_Tejia( 特別オファーかどうか)、isEnable (有効かどうか)
2. T_User ユーザー クラス、属性、およびメソッドを図 3.22 に示します。
図 3.22 ユーザー クラス
T_user クラスはシステム ユーザー エンティティを記述するために使用され、その属性には id (レコード番号)、userName (ユーザー名)、userPwd (ユーザー パスワード)、userRole (ユーザー ロール)、isEnable (有効かどうか) 3 が含まれます
。 .T_YiJian (Opinion クラス): このクラスのプロパティとメソッドを図 3.23 に示します。
図 3.23 意見クラス
T_YiJian は顧客の意見を記述するために使用されるエンティティであり、その属性には id (意見番号)、HJ_YJ (環境意見)、FW_YJ (サービス意見)、FC_YJ (食事意見)、KH_LY (顧客メッセージ) が含まれます 4
。 (メンバクラス): このクラスのプロパティとメソッドを図 3.24に示します。
図 3.24 会員クラス
T_Member クラスは顧客レベルの実体を記述するために使用され、その属性には id (会員番号)、member_Name (会員名)、type_id (会員レベル番号)、isEnable (有効にするかどうか) が含まれます。
class ): このクラスのプロパティとメソッドを図 3.25 に示します。
図 3.25 食事クラス
T_CanDan は顧客メニューを記述するためのエンティティクラスであり、その属性には id (メニュー番号)、desk_HM (テーブル番号)、xf_je (消費量)、member_id (会員番号)、isJieZhang (チェックアウトの有無) が含まれます。 、xf_date (消費日)、state (ケータリング状況)
6. T_Can_MingXi (食事リストの詳細) クラス: このクラスの属性とメソッドを図 3.26 に示します。
図 3.26 メニュー詳細クラス
T_Can_MingXi はメニュー詳細を記述するためのエンティティであり、その属性には id (レコード番号)、can_id (メニュー番号)、cai_id (レシピ番号)、cai_SL (人数)、cai_JE (各タイプ) が含まれます。 3.7.1 ログインモジュールの設計
3.7 メインモジュールの設計ユーザー名とパスワードが有効かどうかを検証し、有効であればロール番号の値 (1: ウェイターロール 2: シェフロール 3:レジ係ロール 4: 管理者ロール)、ロールに応じて異なるウィンドウが開きます。このモジュールの前提条件は、正しいサーバー アドレスを設定し、サーバーが起動状態にあることです。入出力データは表 3.27 データ データに示されています。出力タイプ データタイプ 制約ユーザー名 入力文字列タイプは 4 ～ 10 桁の文字で構成されますパスワード入力文字列タイプは 4 ～ 6 桁の数字で構成されます
表3.27 ログインモジュールの入出力データ
具体的な実装コードは以下の通り:
//ユーザー名
string un = this.txt_UserName.Text.Trim();
//パスワード
string pwd = this.txt_UserPwd.Text.Trim() ;
//ユーザー名、パスワードが空かどうかを判定
if (address == "" || un == "" || pwd == "")
MessageBox.Show("ユーザー名、パスワード、アドレスを空にすることはできません");
else
{ // ユーザー名が文字であり、長さが 4 ～ 10 桁であるかどうかを判断しますif (!Regex.IsMatch(un, "[a-zA-Z]{4,10}")) { MessageBox.Show("Not文字または長さが不十分です"); return; } else if (!Regex.IsMatch(un, "[0-9]{4,6}")) { MessageBox.Show("4 の数字を入力してください-6 桁"); return ; } dc = Program.GetDc(address); // データベース内の最新の更新を返します// dc = Program.ChangeDc(dc.T_user); IQueryable<T_user> t_user = dc.T_user. Where (u => u.userName == un && u.userPwd == pwd); if (t_user!=null&&t_user.Count()==1) { this.Hide();
if (t_user.First().userRole == 1)
{//注文ウィンドウを開く
MainMenu mm = new MainMenu();
mm.Show();
}
else if (t_user.First().userRole == 4)
{ //マネージャーを開くManage.FrmManage frmManage = new Manage.FrmManage(); frmManage.Show(); } else if (t_user.First().userRole == 2) { //シェフ ウィンドウを開くPeiCan.FrmZuoCai frmZuoCai = new PeiCan .FrmZuoCai(); frmZuoCai.Show(); } else if (t_user.First().userRole ==3) { //決済ウィンドウを開くJiezhang.FrmJieZhang frm_JieZhang = new Jiezhang.FrmJieZhang(); frm_JieZhang.Show() ; } } else MessageBox.Show("ログインに失敗しました");
3.7.2 注文モジュールの設計
注文モジュールはシステムの重要なモジュールです. 主に顧客メニューの作成と注文した料理の保存を実現します. このモジュールの実現アイデアは、まず今日のスペシャル、冷たい料理を体系的に表示することです、温かい料理、スープを分類別にクラス、飲み物、飲み物、ゲストはニーズに応じてテーブルを登録し、料理とポイントを選択します（デフォルトは1）、システムが自動的に合計金額を計算します、間違ったゲストがいる場合は、削除できます特定の種類の料理を選択し、最後に「送信」をクリックしてデータベースに保存します。このモジュールを実装するための前提条件は、ユーザーがウェイターとしてシステムにログインし、対応する料理情報と一定数のテーブルがデータベースに存在することです。本モジュールの入出力データを表 3.28 に示します
データ データの出力型 データ型の制約 料理
名 出力文字列型の長さ 50 未満
価格 出力文字列型長 50 未満
ピクチャ出力 バイナリ型
テーブル番号 入力文字列型長 未満50
料理名 入力番号 人数
入力番号
表3.28 オーダリングモジュールの入出力データ 具体的な
実装コード：
///
/// システム表示メニュー
///
///
///
private void MainMenu_Load(object sender, EventArgs e)
{ dc = Program.dc; cur_z = new Cursor("images/icons/z.cur"); cur_y = new Cursor("images/icons/you1.cur"); tj_list = new List();
lc_list = new List();
rc_list = new List();
t_list = new List();
js_list = new List();
yl_list = new List();
LoadImage(-1, true);
//デフォルトで特別価格を表示
if( tj_list.Count!=0)
this.panelEx4.Style.BackgroundImage = tj_list[tj_index];
//テーブル番号をロード
LoadDesk();
}
///
/// レシピを変更します
///
///
// /
private void dgv_CanMingXi_CellContentClick(object sender, DataGridViewCellEventArgs e)
{ if (dgv_CanMingXi.Columns[e.ColumnIndex].Name == “del”) { //レシピ ID を取得cai_id = this.dgv_CanMingXi.Rows[e.RowIndex].Cells [“caiid "].Value.ToString();
var mx = canDan.T_Can_MingXi.ElementAt(e.RowIndex);
canDan.xf_je -= mx.cai_JE;
canDan.T_Can_MingXi.RemoveAt(e.RowIndex);
//コントロールを再バインド
this.lbl_HJ.Text = "total:" + canDan .xf_je + "元";
BindingList<T_Can_MingXi> canList = new BindingList<T_Can_MingXi>(canDan.T_Can_MingXi.ToList());
this.dgv_CanMingXi.DataSource = canList;
}
}
第4章 システム実装
4.1 システムコーディング仕様
システムコーディング実装は、現在普及しているオブジェクト指向プログラミング言語C#を採用しており、将来のシステム拡張やテスト保守を考慮してマイクロソフト社が統一的に公開しているC#コーディング仕様に準拠しています。 : 4.1
. 1 型の命名
1. クラス名、Class で宣言されたクラスは、クラスの役割を反映するために名詞または名詞句を使用して命名する必要があります。例: クラス インジケータ クラスが属性 (Attribute) の場合は Attribute で終了、クラスが例外 (Exception) の場合は Exception で終了: クラス ColorSetException クラス CauseExceptionAttribute クラスが 1 つのオブジェクト インスタンス (グローバル オブジェクト) のみを必要とする場合、Application など）は、Class ScreenClass Class SystemClass など、Class で終わる必要があります。クラスが他のクラスの基底クラスとしてのみ使用される場合は、状況に応じて Base:MustInherit Class IndicatorBase で終了します。定義されたクラスがフォームの場合は、名前の後にサフィックス Form を追加する必要があります。 Web フォームの場合、サフィックスを追加する必要があります。 Page: Class PrintForm : Inherits Form '* Windows Forms Class StartPage : Inherits Page '* Web Forms
2. 列挙型と構造体: 名詞または名詞句に基づいて名前を付ける必要もあります。次のような列挙または構造の特性を反映することが最善です。 Enum ColorButtons ' 複数の数字で終わり、これが列挙であることを示します。 CustomerInfoRecord ' ' Record で終わり、これが構造であることを示します。
3. 委任タイプ: 一般的な委任タイプは、委任タイプ インスタンスの機能を反映するために、アクションを説明する名詞に基づいて名前が付けられます。Delegate Sub DataSeeker (ByVal SeekString As String)、イベント処理に使用される委任タイプは、次のように EventHandler で終わる必要があります。 : Delegate Sub DataChangedEventHandler (ByVal Sender As Object, ByVal e As DataChangedEventArgs)
4. インターフェイス: 他のタイプとは異なり、インターフェイスを実装するクラスが持つ機能を強調するために、インターフェイスには接頭辞 I を付け、形容詞で名前を付ける必要があります。 インターフェイス ISortable 5.
モジュール: モジュールはタイプではありません。その名前は名詞に基づいて命名する必要があり、接尾辞 Module:Module SharedFunctionsModule を追加する必要があります。上記すべてのルールの共通の特徴は、名前を構成する各単語が大文字で始まる必要があることです。完全に大文字または小文字の名前は禁止されています。
4.1.2 メソッドと属性の命名
1. メソッド: 関数であってもサブルーチンであっても、メソッドは動詞または動詞句にちなんで命名する必要があります。関数とサブルーチンを区別する必要はなく、戻り値の型を指定する必要もありません。Sub Open(ByVal CommandString As String)、Function SetCopyNumber(ByVal CopyNumber As Integer)、パラメータは ByVal または ByRef を示す必要があり、プログラムは長くなりますが、これは非常に必要です。特別な事情がない場合はByValを使用します。パラメータの命名方法については、以下の「変数の命名方法」を参照してください。オーバーロードする必要があるメソッドの場合、オーバーロードは通常は記述されず、オーバーロードされたメソッドは必要に応じて記述されます。
2. 属性：フィールド（Field）は原則として公開できず、フィールドの値にアクセスするには属性を使用するのが一般的です。プロパティには、簡潔で明確な名詞が付けられます。Property Concentration As Single、Property Customer As CustomerTypes
3. イベント: イベントは、イベント処理のコンテキストでのみ使用できる特別なプロパティです。命名規則は通常、動詞または動詞の分詞であり、時制はイベントが発生する時刻を示します。 Event Click As ClickEventHandler、Event ColorChanged As ColorChangedEventHangler 4.1.3 変数と定数 定数は、意味を示す名詞に基づいて名前が付けられ
ます
。定数のタイプを区別せず、通常は定数のタイプを区別しません。Const DefaultConcentration As Single = 0.01、要件が厳しいコードでは、定数は c_DefaultConcentration のように c_ で始まりますが、これを使用しないことをお勧めします。タイピングの難しさ。通常の型の変数には意味のある名前を付けることができますが、A、x1 などの略語や意味のない名前は許可されません。良い例を以下に示します: Dim Index As Integer Dim NextMonthExpenditure As Decimal Dim CustomerName As String
Cannot
If
the
nameは長すぎるため、次の例のようにできるだけ簡潔にする必要があります。
Dim Variable UsedToStoreSystemInformation As String '* 間違っている、複雑すぎる
Dim SystemInformation As String '* 正しく、単純かつ明確
Dim sysInfo As String '* 間違っている、単純すぎる
特殊なケースでは、1 文字の変数が考慮されます。
Dim g As Graphic
コントロールの場合、変数の後にクラス名を直接追加してコントロールのタイプを指定する必要があります。
Friend WithEvents NextPageButton As Button '* button
Friend WithEvents ColorChoicerPanel As Panel '* パネル
Friend WithEvents CardFileOpenDialog As FileOpenDialog '* ファイルを開くダイアログ
お待ちください。特定の型の変数のプレフィックスを指定する必要はありません。後ろに型を書き込むだけです。次のコードを比較してみてください: btnCancel.Text
= "&Cancel"
CancelButton.Text = " &Cancel"
明らかに後者は、変数の型がボタンであることを読者に理解させることができます。
4.1.4 ラベル
ラベルは、Goto ジャンプに使用されるコード識別ですが、Goto は推奨されていないため、ラベルの使用は比較的厳密です。ラベルはすべて大文字にする必要があり、中間のスペースはアンダースコア _ に置き換え、_ で始める必要があります。例: _A_LABEL_EXAMPLE: ラベルは、他のコード要素と完全に区別するためにこの方法で定義されます。
4.1.5 名前空間
通常、プロジェクトは名前空間を使用します。通常、名前空間ステートメントを使用する必要はありませんが、プロジェクト オプションの「ルート名前空間」で指定されます。ルート名前空間を使用すると、コードがより整理され、簡単になります。これは利点がたくさんある VB です。ネームスペースの構文は次のとおりです: 会社名. 製品名 [. コンポーネント名の複数形]
例: Namespace Ninputer.VirtualScreen
名前空間 Ninputer.CardEditor.CustomeControls
名前空間にランダムに名前を付けるのは決して良い考えではなく、上記の規則に従う必要があります。
4.1.6 コメント コメント
には多くのルールがありますが、ここではそのうちの 1 つを紹介します。 通常のコメントは「, 別個」で始まり、一時的に使用されていないコードをコメントするためにのみ使用されます
'これは一般的なコメントです
'* このコードはデバッグ後に追加されます正しい
'If UseHighSpeed(g) = True then ...
これにより、コード コメント ツールを使用してコードの使用を制御することが容易になります。
4.2 モジュール機能の実現
4.2.1 ログインモジュールは
ログイン機能を実現します. ユーザーが入力したユーザー名とパスワードに従って, データベース内の情報と比較されます. 検証が成功すると, 要求に従って異なるサブシステムに入ります.システムの役割はポジションに基づいており、ウェイター、シェフ、レジ係、マネージャーの 4 つの固定役割に分割され、各役割には異なる権限と機能があります。システム実装のスクリーンショットを 4.1 および 4.2 に示します。
図 4.1 ユーザー名とパスワードが空であることを確認するスクリーンショット
図 4.2 検証パスワードの数字のスクリーンショット
4.2.2 注文モジュールの主なコード
注文モジュール コードの考え方は、まず顧客がメニューを参照してさまざまな食品を選択し、システムが最初にその食品をショッピング カートに入れるというものです。カート内の食品は削除され、同じ種類の食品を繰り返し注文することはできません ショッピングカート内の食品の合計金額は、システムが自動的に計算し、顧客に送信します確認後のデータベース システムのスクリーンショットを 4.3 ～ 4.6 に示します。
図 4.3 空のテーブルのクエリ
図 4.4 温かい料理のスクリーンショット
図 4.5 ドリンクのスクリーンショット
図 4.6 メニューのスクリーンショット
4.2.3 レジモジュールのコード実装
レジモジュールの実装のアイデアは、会員番号システムに従って割引額と実際の支払い額を自動的に計算することです。具体的なコードは以下の通りです。
double yh=0;
//会員番号取得
Mid = this.txt_Member_id.Text.Trim();
if (xf_je == null || xf_je == "")
{ MessageBox.Show("メニューを選択してください"); } else if ( mid== "") { MessageBox.Show("会員番号を入力してください"); } else { //会員情報を確認if (dc.T_Member.Count(m => m.id.ToString() = = mid) == 0) { MessageBox.Show("そのようなメンバーはいません"); } else { //メンバー情報を表示this.lbl_Member_Info.Text = "メンバー情報:" + dc.F_MemberNameByID(Convert.ToInt32(mid)) + ":" + dc.F_MemberLeavlNameByID(Convert.ToInt32(mid)) +
"–" + dc.F_MemberLeavlByID(Convert.ToInt32(mid)) + "Level";
//割引を計算
yh= Convert.ToInt32(xf_je) * (10 - dc.F_MemberLeavlByID(Convert.ToInt32(mid)).Value) * 0.1d;
this.txt_YH.Text = String.Format(“{0:C2}”,yh);
//実際の支払額を計算
this.txt_SF.Text = String.Format(“{0:C2}”, Convert .ToDouble(xf_je) - yh);
isMember = true;//メンバーです
}
}
システム実装のスクリーンショットは 4.7 に示されています。
図 4.7 顧客チェックアウトのスクリーンショット
4.2.4 ケータリング モジュール コードの実現
ケータリング モジュール機能の実現のアイデアは、主に最新のメニューとメニューの詳細な内容を表示し、最新のメニューを時間内に更新することです
。システム管理モジュール システム
管理モジュールは、図 4.8-4.10 に示すように、主にレシピ、ユーザー、テーブル、メッセージ、メンバーの追加、編集、削除、クエリの機能を実現します。
図 4.8 システム管理のスクリーンショット
図 4.9 レシピ編集のスクリーンショット
図 4.10 テーブル管理のスクリーンショット
第 5 章 システムテスト
5.1 テストの目的
科学的手法によってシステム内の欠陥をできるだけ多く見つけること。主に、システム機能が要件仕様書に規定されている機能要件および肺機能要件に適合しているかどうか、システム機能が適切であるかどうかをテストします。システムが異常データを捕捉し、データを正しく出力するかどうか。
5.2 テスト方法
このテストケース設計では主にブラックボックステスト [15] の手法を採用しており、機能モジュールや統合テストで使用される具体的な手法としては、同値クラス分割 [16]、境界値分割、直交分解、因果関係図分析、誤差などが挙げられる。推測【17】。回帰テスト[18]は、ビジネスプロセスに応じたシステムテストに使用されます。
5.3 テスト環境
1. サーバーアドレス: 172.16.1.4
2. オペレーティングシステム: Windows VISTA
3. CPU: Intel® Pentium®4 CPU 3.00HZ
4. ハードディスク空き容量: 160GB
5. データベース: Microsoft SQL Server 2005
6. テスト対象: FengShaDuMIS.exe
5.4 テスト結果
多くのブラック ボックス テストを行った結果、システムは機能と性能の面で設計要件を満たしました。以下はテスト後のシステムのスクリーンショットです。
1. ログインモジュールのテスト状況を図5.1に示します。
図 5.1 ログインテストのスクリーンショット
2. モジュールの発注状況を図 5.2 および 5.3 に示します。
図 5.2 食事を注文するためのメイン インターフェイスのスクリーンショット
図 5.3 オーダー テスト
3 のスクリーンショット。ケータリング モジュールのテスト状況を図 5.4 に示します。
図 5.4 シェフのケータリング テストのスクリーンショット
4. レジモジュール テストを図 5.5 に示します。
図 5.5 Cashier モジュール テストのスクリーンショット
5. システム管理モジュール テスト 図 5.6-5.8
図5.6 レシピ管理テストチャート
図 5.7 メンバーシップ管理テストの図
図 5.8 ユーザー管理テストのスクリーンショット
6. メッセージ管理テスト 図 5.9—5.10
図 5.9 顧客メッセージ テストのスクリーンショット
図 5.10 メッセージ統計のスクリーンショット
結論
この記事では、ウォーターフォール モデル開発プロセスの原理から開始し、ケータリング システムのワークフロー分析に基づいて、C#4.0 + DotNet Bar7 によって実現されるレストラン注文システムのワークフロー モデルについて説明し、確立します。 0+Ling+Sql Server 2005 レストランの注文情報管理システムを開発し、ブラック ボックス テスト原理を使用したシステムの単体テストと統合テストでそれを示しました。このシステムは、(1)顧客の注文 (2)シェフのケータリング (3)レジ管理 (4)システム設定 を実現します。このシステムの問題点は、主にレシピのタイムリーな更新に現れており、管理者が営業期間中にレシピの価格を適時に調整すると、顧客は注文時に価格の更新が間に合わないという状況に遭遇します。キャッシュカード決済に対応していないなどの問題点も十分にあり、今後のシステム改善の方向性である。
文献
[1] Gan Huarong、『ケータリング管理と実践』、北京、国際ビジネス経済大学出版局、2009 年、109-120 ページ [2] Miao Fengjun、LAN テクノロジーとネットワーク工学、北京、
清華大学出版局、2010 年、150 -151 ページ
[3] Li Dajun、POS システム アプリケーション、北京、清華大学出版局、2004 年、10 ～ 13 ページ [4]
Wu Renjie、Web プログラミング、北京、中国鉄道出版局、2009 年、5 ～ 6 ページ
[5] Xu Shiliang、Ge Bing、『コンピュータ ソフトウェア テクノロジーの基礎』、北京、清華大学出版局、2010 年、25 ～ 31 ページ [6]
Peng Aihua、Liu Hui、Wang Shenglin、Windows 7 の詳細な説明、北京、人民郵政通信出版局発行、2010、2-3 ページ
[7] Qian Shao、Li Huijian、Li Jizhe、C# WinForm 実践開発コース、北京、水利・水力出版、2010 年、15-18 ページ [8] Jiang Hanyang、Li Yuejun
、 Pang Ya Juan、『SQL Server 2005 データベース管理および開発チュートリアル』、北京、人民郵政通信社、1 ～ 8 ページ [ 9] Grady
Booch、Ivar Jacobson、James、Rumbaugh、『統一モデリング言語ユーザー ガイド』[M]、Addison -Wesley、1998 156
[10] Petzold、Windows Programming、北京、清華大学出版局、2010 年、245-256
[11] Bertand Meyer、オブジェクト指向ソフトウェア構築 [M]、プレンティス ホール、1998 年、5 ページ
[12] Jim Arlow、Ila Neustadt、UML と統一プロセス: 実践的なオブジェクト指向分析と設計 [M]、Addison Wesley、2002、95 ページ [13] Wang Xiaoke、Lu Shuang、C# の入門から習得まで、北京
、清華大学出版局、2008 年、3 ～ 4 ページ
[14] Lu Huien、ソフトウェア エンジニアリング、北京、人民郵政通信新聞社、2007 年、9 ～ 10 ページ
[15] Sun Yong、現代ソフトウェア工学、北京、北京ホープ電子Publishing Society、2002 年、111 ページ
[16] Deng Liangsong、Liu Haiyan、Lu Lina、ソフトウェア エンジニアリング、西安、西安大学出版局、2004 年、56-57 ページ [17] Zhou Su、Wang Wen、ソフトウェア エンジニアリング
コース、北京、サイエンス プレス、2002 年、74 ～ 75 ページ
[18] Wang Shaofeng、オブジェクト指向テクノロジ UML コース、北京、清華大学出版局、2004 年、23 ～ 50 ページ
謝辞
時間が経つのはあっという間に過ぎ、プロフェッショナルクラスは終了しましたが、全体として、プロジェクトはテーマの選択から最終的な完成まで多くの経験をしました。私はそこから多くの恩恵を受け、いくつかの成果を達成しましたが、自分自身の欠点も発見しました。
1. やみくもに新しいアイデアを求めるのではなく、使い慣れた開発言語や技術を選ぶことが重要 プロジェクトのテーマをもらったとき、すぐに思い浮かぶ開発言語はマイクロソフトのオブジェクト指向C#言語ですが、Javaも新世代の言語です。オブジェクト指向開発言語を採用しましたが、UIデザインや効率性などに若干の欠点があり、レノボのレストランオーダーシステムの適用範囲が社内LAN内に限定されていたため、最終的にC#開発言語を選択しました。 .NET 開発プラットフォームの効率。
2. システムモデルの作成は、チームワークやコミュニケーションを強化し、システム開発効率を向上させる有効な手段です。初めてシステム開発の仕事を受けた時は、何から始めればいいのか、何をすればいいのか分からず、インターネットからソフトウェアをダウンロードするにしても、どうやって開発すれば良いのか分かりませんでした。 『オブジェクト指向技術とUML』を読んで、分析・研究した結果、ウォーターフォールモデル、反復増分モデル、スパイラルモデルのそれぞれの特徴を組み合わせて、ソフトウェアモデルを作成するのが最も直接的で理解しやすく、簡単だと思います。ソフトウェア開発手法を実行することは、さまざまな要件に基づいているためです。ビジネス ルールに精通していない場合、これが開発者や顧客とコミュニケーションをとるための最も簡単で効果的な方法であることを理解しています。また、この手法の正しさは事実によって証明されています。 . レストラン注文システムは 2 週間足らずで 1.0 バージョンが完成しました。
3. 日々のサマリーは、問題を発見し、進捗を管理するための重要な手段です 詳細な開発計画が策定されていても、その実行過程では、日々のサマリーを通じて休暇や技術的障害など、予想外の事態も発生します。まとめると、問題の核心がわかります。理解の問題であれば、理解を深め、技術の問題であれば、先生に相談したり、インターネットで情報を確認したりして、完成です。慎重な計画と進捗状況のタイムリーな調整は切り離せません。
4. 新しいテクノロジーが必ずしも最良であるとは限りません。成熟した安定したテクノロジーが第一の選択肢です。フレームワークを決定する前に、インターネット上で多くの関連テクノロジも検索しました。ほとんどの ORM フレームワークでは、設定ファイルと新しいコンポーネントのインストールが必要です。これらの新しいテクノロジには確かに利点がありますが、結局のところ、私にとっては新たな挑戦でした。 , 私も新しい技術を学ぼうとして、プロジェクトに新しい技術を適用しようとしましたが、後になって、学習時間が長くなり、消化吸収して習熟レベルに達するのが難しいことが分かりました。選択を比較検討した結果、 Microsoft の開発ツールを選択しましたが、ORM ツール Ling to Sql を使用すると、テスト後のコーディング効率が大幅に向上しました。
このプロジェクトを通じて、私の経験は豊かになり、個人的なプログラミング能力やコミュニケーション能力はある程度向上しましたが、自分自身に足りない部分も多く感じています。主な理由としては、(1)当該業界におけるプロジェクト開発経験が不足しているため、需要抽出が不完全であり、ビジネスロジックが不正確であるため、今後さらにプロジェクト開発経験を蓄積する必要がある。(2) 必要なマネジメント経験と効果的なコミュニケーション手段の不足 プロジェクト開発の初期段階では、理解不足によりプロジェクトが先延ばしになりましたが、その後、私は自制心を強化し、タイムリーに学生とコミュニケーションや連絡を取るようにしました。徐々に進捗が進み、ついにプロジェクトが完成しました。(3) インターフェイスアートはプロジェクトの開発プロセスで最も重要な作業ですが、私には理工系のバックグラウンドに必要な芸術的細胞と美的感覚が欠けているため、インターフェイスのカラーマッチングやレイアウトがプロのレベルに達することができず、これまでは合計 インターフェイスのデザインが満足のいくものではないと感じているため、今後のプロジェクト開発プロセスでは、プロのアーティストにデザインを依頼することが最善であり、それが最善の選択であるはずです。
最後に、特に技術的な問題が発生したとき、多大なご協力をいただいた孫飛賢先生に心から感謝します。孫先生は、いつでも辛抱強く私を助けてくださいました。プロジェクトと卒業論文のデザインは完了したと確信しており、これからもよろしくお願いします。孫先生に心から感謝します。 先生は「先生、よく頑張ったね」と言われました。