救援物資の管理・配送体制
まとめ
科学技術の急速な発展は人々の日常生活に大きな変化をもたらし、電子情報技術の急速な発展により、さまざまな分野における電子情報技術の応用レベルが普及し、応用されています。情報化時代の到来は抗しがたいファッショントレンドとなり、人類の発展の歴史は新たな時代を迎えています。実際の運用では、ソフトウェアの運用ルールや開発手順を適用し、SSMフレームワークを用いて救援物資管理・配布システムを構築します。
この設計は主に、人間化、高効率、利便性の利点を統合した救助物資管理および配布システムを実現し、従業員管理、救助物資管理、救助物資保管管理、保管管理、配送管理、救助物資在庫管理を完了します。ベンダー管理、部門管理、ブラックリスト管理、その他の機能モジュール。システムはブラウザを介してサーバーと通信し、データのやり取りと変更を実現します。科学的な管理手法と便利なサービスにより、作業効率を向上させ、データ保管のミスや漏れを削減します。救助・救援物資の管理および配布システムは、MVC モデルに基づく SSM テクノロジーを使用して開発され、Eclipse 2017 CI 10 コンパイラーで記述され、データは主に Microsoft の MySQL リレーショナル データベースをデータ記憶媒体として使用し、フロントと連携します。 -end HTML+CSS技術 システム開発を完了します。
キーワード: 救助物資の管理と配布、リレーショナルデータベース、データストレージ
救援物資の管理・配布体制
概要
科学技術の急速な発展は人々の日常生活に大きな変化をもたらしました。電子情報技術の急速な発展により、電子情報技術の応用レベルはさまざまな分野に普及し、応用されています。情報化時代の到来は抗しがたいファッショントレンドとなり、人類の発展の歴史は新たな時代を迎えています。実際の応用では、ソフトウェアの作業ルールと開発手順が適用され、SSM フレームワークを使用して救助物資の管理および配布システムが構築されます。
この設計は主に、人間化、高効率、利便性の利点を統合した救助物資管理および配布システムを実現し、従業員管理、救助物資管理、物資倉庫管理、アウトバウンド管理、配送管理、物資在庫管理、メーカー管理、部門管理、ブラックリスト管理など。システムはブラウザを介してサーバーと通信し、データのやり取りと変更を実現します。科学的な管理と便利なサービスにより、作業効率を向上させ、データ保存のエラーや漏れを削減します。救援物資管理および配布システムは、MVC モードに基づく SSM テクノロジーを使用して開発され、eclipse 2017 CI 10 コンパイラーによって記述されています。データ的には、
キーワード：救援物資の管理と配布。リレーショナルデータベース。データが保存される
人類の歴史の発展とともに、人類社会は数千年の歴史を経験しており、この数千年の間、さまざまな要因の影響により、さまざまな社会的緊急事態が発生し続け、滅亡するまでの循環的な発展過程です。いわゆる公共的緊急事態には、さまざまな自然災害や疾病紛争などの自然発生的なものと、国家混乱や民族紛争などの人為的なものと、さまざまな種類が含まれます。特に、西側諸国における産業革命の勃発により、社会産業技術の急速な発展に伴い、交通事故、技術事故、環境事故、医療事故、テロ攻撃などの公共緊急事態が増加しています。社会がどのように発展しても、緊急事態は避けられず、人々は緊急事態に対する意識を高め、緊急事態に備える必要があります。
現在、我が国の近代化推進は新たな段階に入り、政策改革と経済発展は敏感な時期にあり、この敏感期において、国、社会、国民の公共の安全に影響を与える要因は徐々に増大しており、その影響は大きくなっています。さまざまな緊急事態への公的イベントが時々発生します。我が国の緊急事態の管理・調整能力、緊急対応能力、事象処理効率を向上させるために、高度な情報技術とアプリケーションシステムをどのように活用するか、現在の救援物資管理システムに存在する問題点の分析に基づき、コンセプトと組み合わせることで、管理システムの構造とシステム開発の基本原理と方法、高速な計算速度、大容量の記憶情報容量、強力な論理的問題処理を備えたコンピュータの使用、B/S構造を使用した強力な機能の利点、救援物資の基本情報、救援物資の入退場情報、救援物資の在庫情報、メーカーなどの管理ニーズを把握します。情報の照会や変更といった管理ニーズを起点に、関連性が高く基本的な応用機能が比較的充実しており、本システムを通じて救援物資の管理・配布の情報化・ネットワーク化を実現し、管理の効率化を目指します。そして救援物資の配布。
米国、ドイツなどの一部の西側先進国では、災害救援に由来する災害救援物流システムが急速に発展しており、その発展スピードは企業物流と基本的に同じである。災害支援物流においても、商流分離、第三者物流、スルー型倉庫、サプライチェーンマネジメントなどの先進的な物流概念を活用し、災害支援物流システムを強固なものとしています。タイムリーかつ迅速な救助活動を展開し、さまざまな救援物資を被災地に迅速に送り、緊急事態によって引き起こされる被害を効果的に軽減します。数十年にわたる研究と構築を経て、既存の対外援助物資輸送システムはリアルタイムで段階的に管理され、災害の実際の状況に応じて的を絞った救援活動を実施できるように発展しており、この管理方法により、国内への救援物資の供給の遅れも発生しません。最も大きな被害を受けた地域が、やみくもに軽度災害地域に救援物資を提供するのではなく、災害救援物資の供給を確保することを基本として、救援物資の恩恵を最大化するという目標は達成された。
公的緊急事態をより適切に防止し、対応するために、米国は長年の研究と努力を経て、非常に完全な国家災害緊急計画を策定しました。地震、ハリケーン、火山噴火などの大規模な自然災害が国内で発生する限り、洪水や津波など、政府は緊急事態に対処するために非常事態に入り、被災地で救助活動を実施するための緊急計画を開始する。すべての災害救援と対応事務は「連邦政府」の全責任の下にある。緊急事態管理庁」。また、米国は情報技術が非常に進んでいることから、防災・救援活動には高度なハイテク情報技術が活用され、事前に複数回の防災・模擬訓練が実施されることとなる。 。各都市には治安組織制度が設けられており、災害のない時は警察と連携して市の治安を共同管理し、大規模災害が発生すると直ちに緊急災害救助体制に移行します。廃棄局は災害後の処理を担当します。災害発生後、最も重要な業務は緊急救援物資の輸送・配布であり、そのため連邦緊急事態管理庁には特別物流管理部隊が設置され、通常の災害を担当するのが主な任務である。災害別の緊急支援物資の需要予測、緊急支援物資の輸送・配給ルートの計画などの管理業務。災害発生時、物流管理部門は迅速に非常事態に移行し、災害情報や被災地のニーズに応じて災害救援物資の配布・配布を行うことができます。
私の国は地理的な理由から、世界で最も自然災害が多い国の一つであり、自然災害の種類が多いだけでなく、頻度も多く、基本的に毎年発生しています。私の国で一般的な自然災害には、干ばつ、洪水、台風、地震、雪害、土砂崩れ、森林火災などが含まれます。これらの自然災害には、地域的、季節的、段階的、共生的、半減期など、多くの注目すべき特徴があります。国と地域、そして国民の生命と財産に極めて重大な損失をもたらしました。
我が国では、州都の約 74%、県レベル以上の都市の 62% が地理的に地震の危険性が高い地域に位置しており、これらの被災地では我が国の工業と農業の 75% 以上が拠点となっています。大都市の 70% 以上が分散しており、人口の 50% 以上が居住しています。近年、気候変動等の影響により自然災害が多発し、我が国の被災地や死傷者は増加傾向にあり、国民経済の急速な発展に伴い、工業生産や農業生産の規模も拡大を続けています。都市人口は増加を続けており、これらの要因は極めて重要であり、自然災害による損失は大幅に増加しました。この課題の背景と意義を分析すると、救援物資の管理・配布体制の構築が非常に必要であることが分かります。
-
- この記事の構成
最初の章は序文であり、この記事の始まりであり、このトピックの研究背景と研究の重要性についてのテキストの説明がいくつかあります。
第 2 章では、マテリアル管理および配布システムで使用される開発テクニックとツールについて説明します。
3 章はシステム分析部分で、システム全体の要件の説明、機能面からのシステム要件の分析、システムが実現可能かどうかの非機能分析が含まれます。
第 4 章は、この記事の重要な部分であるシステム設計部分であり、システム アーキテクチャの詳細な設計といくつかの主要な機能モジュールの設計の説明を提供します。
第 5 章はシステムの具体的な実現であり、システムの各モジュールの具体的な実現を紹介します。
第 6 章では、前の章に基づいてシステムをテストし、実行します。
最後に、システムを真剣に総括し、将来への新たな展望を持ちます。
システムのフロントエンド部分は B/S モデルを使用して MVVM モデルに基づいて開発され、バックエンド部分は Java ssm フレームワークに基づいて開発されます。
フロントエンド部分: フロントエンド フレームワークには、人気のあるプログレッシブ JavaScript フレームワーク Vue.js が採用されています。Vue-Router と Vuex を使用して動的ルーティングとグローバル状態管理を実現し、Ajax を使用してフロントエンドとバックエンドの通信を実現し、Element UI コンポーネント ライブラリを使用してページを迅速にプロトタイプ化し、プロジェクトのフロントエンドはグリッドを通じて応答性を実現しますPC、タブレット、モバイルなどに適応できるレイアウト。さまざまな画面サイズに最適なレイアウト表示。
バックエンド部分: 開発フレームワークとして ssm を使用し、MyBatis、Redis、およびその他の関連テクノロジーを同時に統合します。
SSM は SpringMVVM+Spring+MySQL であり、これら 3 つのフレームワークにはそれぞれ独自の利点があるため、これらを組み合わせることで強力なスパークを生み出すことができます。設計者は手間をかけずに Web アプリケーション プログラムを作成でき、階層が明確で、アップグレードや更新の操作が通常の使用に影響を与えず、複数の使用が可能であるという特徴もあります。この複合フレームワークは、完全な構造、強力な機能、優れた構造を持つシステムを形成します。SpringMVVM が各プレートを分離し、Spring が開発をより柔軟かつ便利にし、開発者がオブジェクトを直接操作できるようにし、各レベルで作業内容を分割し、各レベルを実現します。分離すると、コードがより柔軟で合理化されます。このフレームワークにより、プログラマーは開発期間中の全体の破壊につながる個別のミスを回避することができ、また、開発後の段階での顧客からの製品に対する新たな要求にも対応することができます。
2.3 MySQL データベース
科学技術の進歩は、日常生活に多くの利便性をもたらしました。教室のプロジェクターには仮想イメージング技術が使用され、デジタルカメラには光電検出技術が使用されています。たとえば、スーパーマーケットの倉庫に出入りする商品の記録には情報倉庫が必要です。この情報倉庫はデータベースであり、今回のスーパーマーケットの商品管理システムにもこの技術のサポートが必要です。
MySQL ソフトウェアを使用する理由は、複数のユーザーがアクセスできること、およびその中にアーカイブなどが存在するためです。データを分類してからテーブルに分けて格納するという特殊な操作により、データ管理システム自体の速度が向上し、データベースを柔軟に利用できるようになります。MySQL のコードは公開されており、他の人がそれを 2 回コンパイルしてアップグレードすることができます。この機能により、ユーザーのコストを削減し、適切なソフトウェアと組み合わせて優れた Web サイト システムを構築できます。欠点もありますが、あらゆる面でユーザーの主流のアプリケーションオブジェクトです。
2.4 B/S構造
B/S (ブラウザ/サーバー) は、以前のアーキテクチャよりも便利なアーキテクチャです。Web サーバーを使用してデータの転送と交換を完了します。クライアントとしてブラウザをダウンロードするだけで、作業は「スリム化」効果を実現し、ソフトウェアのノンストップインストールの問題を考慮する必要はありません。
2.5 B/S システムの動作原理:
B/S アーキテクチャは、ブラウザ要求とサーバー応答の動作モードを採用しています。
ユーザーはブラウザを介して、インターネット上の Web サーバーによって生成されるテキスト、データ、画像、アニメーション、ビデオ オン デマンド、サウンドなどの情報にアクセスできます。
また、各 Web サーバーはさまざまな方法でデータベース サーバーに接続でき、実際には大量のデータがデータベース サーバーに保存されます。
Webサーバーからプログラムをダウンロードしてローカルで実行します。ダウンロード プロセス中にデータベースに関連する命令が発生すると、Web サーバーはその命令をデータベース サーバーに渡して解釈および実行し、Web サーバーに返します。 Web サーバーはそれをユーザーに返します。この構造では、多数のネットワークが接続されて巨大なネットワーク、つまりグローバルネットワークが形成されます。各企業は、この構造に基づいて独自のインターネットを構築できます。
B/Sモードでは、ユーザーはブラウザを通じてネットワーク上に分散した多数のサーバーへのアクセスを要求し、ブラウザの要求はサーバーで処理され、その処理結果と対応する情報がブラウザに返されます。すべて Web サーバーによって完了します。フレーム構造とオペレーティング システムに組み込まれたブラウザにより、この構造は今日のソフトウェア アプリケーションの主流の構造モードになりました。
システムを開発するには、実現可能性を分析し、時間とリソースの制約を考慮する必要があり、これによりシステム開発のリスクを軽減できます。同時に、分析後は人的資源を合理的に使用できるだけでなく、さまざまなリソースの消費も節約できます。テクノロジー、経済、社会の3つの側面を紹介します。
-
-
- 技術的実現可能性分析
-
いわゆる技術的実現可能性とは、初期段階で計画した機能を限られた時間内で満たせるかどうかを指します。開発・設計で解決できない問題が発生するかどうか。完成したプロジェクトがうまく適用できるか、不足点はないか、後のメンテナンスに大きな困難がないか。システムを評価した結果、既存のテクノロジーで目標を達成できることが判明しました。JSP技術による動的なページの実現、依存性の低い設計パターンの組み込み、柔軟なデータベース、安定したサーバーにより、システム全体の運用効率が大幅に向上します。技術レベルで目標を達成することはナンセンスではないことがわかります。
プロジェクトで使用されるツールのほとんどは現在一般的なオープンソースで無料であるため、開発の初期段階ではプロジェクトに使用される資金が大幅に削減され、ソフトウェアの開発は開発期間中の資金の影響を受けません。プロジェクトの立ち上げ時期にあるため、経済的にはまだ実現可能です。ユーザーのニーズを満たすために、最小限のコストを使用するようにしてください。人件費や設備費に充てるための資金を節約します。ペーパーレス化と高効率化の道はますます進んでいきます。
この機能を実現するためのシステムの操作は非常に簡単で、一般的なコンピュータの一般的な構成で動作し、コンピュータの基本的な使用常識を大まかに理解していればスムーズに使用することができます。コンピュータはインターネットに接続する機能を備えており、システムに正常にアクセスすることができ、オペレータに特別な能力は必要なく、業務プロセスを理解し、専門知識に基づいて正しく動作するだけで利用できるため、スーパーマーケットの商品は管理システムが実現可能です。
システムの開発・設計の前に、機能の事前構想を立て、管理システムがどのようなセクションで構成され、各セクションがどのような機能を持っているのか、全体の設計がユーザーのニーズを満たしているのかを把握し、詳細な分析と要約を行う必要があります。開発されたシステムの機能を統合して、完全なシステムを設計し、実装します。ユーザーと開発者のコミュニケーションを分析し、理解を深め、システムを最大限に機能させる。
従業員のユースケース図を以下に示します。
図 3-1 従業員のユースケース図
管理者のユースケース図を以下に示します。
図 3-2 管理者の使用例図
ユースケースの説明は、ユースケース図の各機能モジュールの最もよく理解された要件の説明をテキストで記述したもので、ユースケースの説明は次のとおりです。
表 3-1 ログインの説明
| 説明項目 |
説明する |
| ユースケース名 |
ログイン |
| ユースケースの説明 |
ユーザーが正しいユーザー名とパスワードを入力した場合にのみ、システムにログインし、その後の操作を続行できます。 |
| 参加者 |
ユーザー |
| 前提条件 |
ユーザーが URL を正しく入力した場合 |
| 事後条件 |
ユーザーがログインし、メイン インターフェイスに正常にジャンプします。 |
| メインイベントの流れ |
ユーザーは対応するユーザー名とパスワードを入力します ユーザー名が存在しない場合は、登録する必要があります パスワードまたはユーザー名が間違っているとログインに失敗します 入力したユーザー名とパスワードが正しい場合は、プラットフォームのメインインターフェイスに入ります |
| 異常なイベントの流れ |
e1. ネットワーク異常 e2. データベース接続例外 |
表 3-2 従業員管理の説明
| 説明項目 |
説明する |
| ユースケース名 |
スタッフのオペレーション |
| ユースケースの説明 |
管理者がバックグラウンド管理に正しくログインしていることを条件に、従業員を管理します |
| 参加者 |
管理者 |
| 前提条件 |
管理者は正常にログインし、バックグラウンドのメイン インターフェイスにジャンプします。 |
| 事後条件 |
操作成功 |
| メインイベントの流れ |
管理者は従業員管理ページにジャンプして従業員の詳細を照会します。 管理者は従業員情報を削除できます |
| 異常なイベントの流れ |
e1. 500 エラーを報告する e2. データベース接続例外 |
表 3-3 材料管理の説明
| 説明項目 |
説明する |
| ユースケース名 |
マテリアルハンドリング |
| ユースケースの説明 |
管理者がバックグラウンド管理に正しくログインしていることを条件として、素材モジュールを管理することができます。 |
| 参加者 |
管理者 |
| 前提条件 |
管理者は正常にログインしました |
| 事後条件 |
操作成功 |
| メインイベントの流れ |
(1) 管理者は素材管理ページに入り、素材情報を問い合わせます (2) 管理者は素材の追加・削除・編集が可能 (3) 管理者が素材を追加し、追加が成功すると問い合わせページにジャンプします |
| 異常なイベントの流れ |
e1. 500 エラーを報告する e2. データベース接続例外 |
表 3-4 材料分類管理の説明
| 説明項目 |
説明する |
| ユースケース名 |
材料分類操作 |
| ユースケースの説明 |
管理者がバックグラウンド管理に正しくログインしていることを条件として、素材分類モジュールが管理します。 |
| 参加者 |
管理者 |
| 前提条件 |
管理者は正常にログインしました |
| 事後条件 |
操作成功 |
| メインイベントの流れ |
(1) 管理者は素材分類管理ページに入り、素材分類内容の情報を照会します。 (2) 管理者は素材分類を削除できます |
| 異常なイベントの流れ |
e1. 500 エラーを報告する e2. データベース接続例外 |
表3-5 入库管理描述
| 描述项 |
说明 |
| 用例名称 |
仓库操作 |
| 用例描述 |
管理员正确登录后台管理的条件下，对入库模块进行管理 |
| 参与者 |
管理员 |
| 前置条件 |
管理员成功登录 |
| 后置条件 |
操作成功 |
| 主事件流 |
（1）管理员进入入库管理页面，查询物资的信息 （2）管理员可以对入库进行增删除和编辑仓库操作 （3）管理员新增入库，添加成功跳转到查询页面 |
| 异常事件流 |
e1.报500错误 e2.数据库连接异常 |
表3-6 员工检测管理描述
| 描述项 |
说明 |
| 用例名称 |
员工检测操作 |
| 用例描述 |
管理员正确登录后台管理的条件下，员工检测模块进行管理 |
| 参与者 |
管理员 |
| 前置条件 |
管理员成功登录 |
| 后置条件 |
操作成功 |
| 主事件流 |
（1）管理员进入员工检测管理页面，查询员工检测内容的信息 （2）管理员可以对员工检测进行删除操作 |
| 异常事件流 |
e1.报500错误 e2.数据库连接异常 |
救援物资管理与分配系统在对需求做解析后，整个系统主要分为两个部分：管理员和员工，每个模块下的分支功能不一样。对功能做出如下说明：
员工模块：
账号登录认证。
管理个人资料信息，修改可修改的信息项。
物资种类，员工可以对物资进行分类，输入具体物资的具体信息（包括物资名称、物质种类、厂商信息、物质编号等）。
物资仓库，同时查看历史物资的记录。
员工检测，员工能看见自己的检测信息（包括体温、身体状况、健康码等）。
物资分类，同时查看分类信息的记录。
管理员模块：
维护员工信息，审核员工的账号，可以冻结员工的登录权限，或者删除员工账号。
物资入库管理，并可以销毁某个物资，更新物资数据，模糊搜索物资数据等。
厂商管理，并可以销毁某个厂商，更新厂商数据，模糊搜索厂商数据等。
系统维护管理数据。
系统非功能需求有非常多，比如性能需求、可承载最大用户数、稳定性、易用性需求等。本系统分析时考虑到易用性需求，因为系统是给人使用的，所以必须充分从用户的角度出发，考虑用户体验，使系统易理解易上手易操作。
一层数据流程图包括了登录、用户功能和检索维护等模块，在登录模块使用到的数据存储有用户账户文档，用户功能模块需要的存储是用户各功能模块数据文档，检索维护是使用以上这些数据文档通过关键词进行检索。
系统的一层数据流图如下图所示。
图3-2系统数据流图（一层）
二层数据流程是对一层数据流层图中填写登录信息、用户功能的细化。即：填写登录信息细化为填制信息、后台审核，用户功能细化为物资仓库、物资分类信息、物资派送、员工检测等操作。
系统的二层数据流图如下图所示。
图3-4系统数据流图（二层）
目前B/S体系的系统主要的数据访问方式是：通过浏览器页面用户可以进入系统，系统可以自动对用户向服务器发送的请求进行处理，处理请求是在系统后台中进行的，用户在浏览器页面上进行相应操作，就能够看到服务端传递的处理结果。超市商品管理系统主要分为视图-模型-控制三层架构设计。在视图层中，主要是操作在服务器端向用户端反馈并显示的数据，在模型层中，主要处理相关的业务逻辑、数据整合等，最后的控制层它介于视图和模型之间，主要是调整两层之间的关系，最终落实数据的传递。
系统架构图如下图所示。
图4-1系统架构图
系统设计的目的是分析系统包括的所有功能结构，为开发人员设计开发和实现系统做好准备工作。经过前期的需求调查、分析和整理之后，确定的总体需求主要包括多个模块，分别是：员工管理、物资仓库管理、物资分类管理、入库管理、厂商管理、系统维护管理、派送管理、员工检测管理。系统整体角色分为两个部分，一是员工、二是管理。权限分布也是很明显，员工是在除去浏览信息之外还具有查询和管理自己账户信息、物资信息录入、仓库信息、物资分类、物资库存查询、物资派送等权限；管理员是最高权限拥有者。
系统功能结构图如下图所示。
图4-2系统功能结构图
用户管理模块
该模块是为所有用户登录设计的，如员工登录后只能进行自己的普通功能操作(如个人信息修改），管理员和超级管理员登录后有不同的权限，管理员不能超越权限。超级管理员能对整个系统的数据进行管理，主要是用户的登录权限以及用户登录后在系统里的操作权限。
物资仓库模块
员工和物资仓库存在录入信息关系，关系为一对多，根据物资编号来将物资数据传入到仓库信息数据中，操作人为员工，然后生成物资列表，员工查看个人输入物资列表，可以进行数据销毁。
物资种类模块
操作人来录入物资种类数据，点击物资种类录入按钮，依次填写要录入的种类数据，点击提交按钮，将数据提交至数据库，然后刷新物资种类数据页面，每条数据右边有删除和编辑按钮，来完成相应的删除和更新功能。
用户维护模块
操作人来录入用户数据，点击用户录入按钮，依次填写要录入的用户数据，点击提交按钮，将数据提交至数据库，然后刷新用户数据页面，每条数据右边有删除和编辑按钮，来完成相应的删除和更新功能。
员工检测模块
管理员点击员工检测管理菜单，点击公告添加子菜单，添加检测数据，填写检测情况、内容，提交成功后，员工检测数据页面刷新，新数据成功载入页面。
1.出错信息类型
出错信息类型包括：
A 未输入必填项；
B 应输入合法字符或数字却输入非法字符或数字；
C 对空数据表进行更改或删除操作；
D 向要求唯一值的关键字段添加重复值。
2.出错处理对策
对于错误A，系统要求用户输入非空值。
对于错误B，系统要求用户输入合法字符。
对于错误C，系统提示数据表无记录可更改或删除。
对于错误D，系统要求用户输入非重复值。
救援物资管理与分配系统是个现代化的高度集成的综合信息系统，系统主要服务对象为用户，最大化在页面中提供多的信息，因此在系统维护上，数据量较大，整体的维护设计如下：
（1）代码的维护：部署在云服务器上或本地服务器，通过SVN或FTP保持版本更新迭代。
（2）功能增加：功能升级在必要的前提下。
（3）数据维护：根据安全性等需求，定期对数据库进行人工备份。
对于一个要开发的系统来说，E-R图可以让别人能更快更轻松的了解此系统的事务及它们之间的关系。根据系统分析阶段所得出的结论确定了在超市商品管理系统中存在着多个实体分别是用员工、管理员、物资、仓库、厂商、物资库存、物资派送。
系统总体ER图如下图所示。
图4-4系统总体ER图
管理员（管理员id、用户名、密码、权限）
员工（员工id、账号、密码、姓名、性别、地区、手机、Email、照片）
通知数据（通知id、标题、类别、首页图片、点击率、发布人）
物资分类（物资id、编号、名称、类别、数量、厂商、创建时间）
物资仓库（物资仓库id、物资编号、物资名称、物资种类、仓库数量、厂商信息）
物资派送（物资派送id、物资编号、物资名称、物资数量、派送人员）
数据库逻辑结构就是将E-R图在数据库中用具体的字段进行描述。用字段和数据类型描述来使对象特征实体化，最后形成具有一定逻辑关系的数据库表结构。超市商品管理系统所需要的部分数据结构表如下表所示。
vendor_management表:
| 名称 |
类型 |
长度 |
不是null |
主键 |
注释 |
| vendor_management_id |
int |
11 |
是 |
是 |
厂商管理ID |
| manufacturer_name |
varchar |
64 |
否 |
否 |
厂商名称 |
| manufacturer_address |
varchar |
64 |
否 |
否 |
厂商地址 |
| contact_number |
varchar |
16 |
否 |
否 |
联系电话 |
| vendor_details |
text |
0 |
否 |
否 |
厂商详情 |
| provision_of_materials |
text |
0 |
否 |
否 |
提供物资 |
| examine_state |
varchar |
16 |
是 |
否 |
审核状态 |
| recommend |
int |
11 |
是 |
否 |
智能推荐 |
| create_time |
datetime |
0 |
是 |
否 |
创建时间 |
| update_time |
timestamp |
0 |
是 |
否 |
更新时间 |
material_warehousing表:
| 名称 |
类型 |
长度 |
不是null |
主键 |
注释 |
| material_warehousing_id |
int |
11 |
是 |
是 |
物资入库ID |
| warehousing_date |
date |
0 |
否 |
否 |
入库日期 |
| material_name |
varchar |
64 |
否 |
否 |
物资名称 |
| material_type |
varchar |
64 |
否 |
否 |
物资种类 |
| warehouser |
int |
11 |
否 |
否 |
入库人 |
| manufacturer |
varchar |
64 |
否 |
否 |
厂商 |
| storage_location |
varchar |
64 |
否 |
否 |
存放位置 |
| receipt_quantity |
int |
11 |
否 |
否 |
入库数量 |
| examine_state |
varchar |
16 |
是 |
否 |
审核状态 |
| recommend |
int |
11 |
是 |
否 |
智能推荐 |
| create_time |
datetime |
0 |
是 |
否 |
创建时间 |
| update_time |
timestamp |
0 |
是 |
否 |
更新时间 |
material_warehouse表:
| 名称 |
类型 |
长度 |
不是null |
主键 |
注释 |
| material_warehouse_id |
int |
11 |
是 |
是 |
物资仓库ID |
| material_name |
varchar |
64 |
否 |
否 |
物资名称 |
| item_no |
varchar |
64 |
否 |
否 |
物资编号 |
| material_type |
varchar |
64 |
否 |
否 |
物资种类 |
| material_picture |
varchar |
255 |
否 |
否 |
物资图片 |
| storage_location |
varchar |
64 |
否 |
否 |
存放位置 |
| manufacturer |
varchar |
64 |
否 |
否 |
厂商 |
| stock |
int |
11 |
否 |
否 |
库存 |
| examine_state |
varchar |
16 |
是 |
否 |
审核状态 |
| recommend |
int |
11 |
是 |
否 |
智能推荐 |
| create_time |
datetime |
0 |
是 |
否 |
创建时间 |
| update_time |
timestamp |
0 |
是 |
否 |
更新时间 |
material_delivery表:
| 名称 |
类型 |
长度 |
不是null |
主键 |
注释 |
| material_delivery_id |
int |
11 |
是 |
是 |
物资派送ID |
| material_name |
varchar |
64 |
否 |
否 |
物资名称 |
| material_type |
varchar |
64 |
否 |
否 |
物资种类 |
| delivery_quantity |
int |
11 |
否 |
否 |
派送数量 |
| material_flow_direction |
varchar |
64 |
否 |
否 |
物资流向 |
| sender |
int |
11 |
否 |
否 |
派送人 |
| manufacturer |
varchar |
64 |
否 |
否 |
厂商 |
| delivery_date |
date |
0 |
否 |
否 |
派送日期 |
| examine_state |
varchar |
16 |
是 |
否 |
审核状态 |
| recommend |
int |
11 |
是 |
否 |
智能推荐 |
| create_time |
datetime |
0 |
是 |
否 |
创建时间 |
| update_time |
timestamp |
0 |
是 |
否 |
更新时间 |
department_management表:
| 名称 |
类型 |
长度 |
不是null |
主键 |
注释 |
| department_management_id |
int |
11 |
是 |
是 |
部门管理ID |
| department_name |
varchar |
64 |
否 |
否 |
部门名称 |
| department_number |
varchar |
64 |
否 |
否 |
部门编号 |
| department_information |
text |
0 |
否 |
否 |
部门信息 |
| number_of_departments |
varchar |
64 |
否 |
否 |
部门人数 |
| department_location |
varchar |
64 |
否 |
否 |
部门位置 |
| examine_state |
varchar |
16 |
是 |
否 |
审核状态 |
| recommend |
int |
11 |
是 |
否 |
智能推荐 |
| create_time |
datetime |
0 |
是 |
否 |
创建时间 |
| update_time |
timestamp |
0 |
是 |
否 |
更新时间 |
employee_testing表：
| 名称 |
类型 |
长度 |
不是null |
主键 |
注释 |
| employee_testing_id |
int |
11 |
是 |
是 |
员工检测ID |
| temperature |
varchar |
64 |
否 |
否 |
体温 |
| health_code |
varchar |
255 |
否 |
否 |
健康码 |
| staff |
int |
11 |
否 |
否 |
员工 |
| physical_condition |
varchar |
64 |
否 |
否 |
身体状况 |
| remarks |
varchar |
64 |
否 |
否 |
备注 |
| examine_state |
varchar |
16 |
是 |
否 |
审核状态 |
| recommend |
int |
11 |
是 |
否 |
智能推荐 |
| create_time |
datetime |
0 |
是 |
否 |
创建时间 |
| update_time |
timestamp |
0 |
是 |
否 |
更新时间 |
系统的登录窗口是用户的入口，用户只有在登录成功后才可以进入访问。通过在登录提交表单，后台处理判断是否为合法用户，进行页面跳转，进入系统中去。
登录合法性判断过程：用户输入账号和密码后，系统首先确定输入输入数据合法性，然后在login.jsp页面发送登录请求，调用src下的mainctrl类的dopost方法来验证。
用户登录模块的IPO如下所示：
输入：用户名和密码。
处理：
1）检测用户输入的账号、密码是否正确及在数据库已对应存在。
2）从数据库中提取记录，并储存在本地的session中（timeout默认=30min）。
3）根据用户名，将其显示在系统首页上。
输出：是否成功的信息。
登录流程图如下所示。
图5-1登录流程图
系统登录界面如下所示。
图5-2系统登录界面
登录模块的关键代码如下：
/**
* 登录
* @param data
* @param httpServletRequest
* @return
*/
@PostMapping("login")
public Map<String, Object> login(@RequestBody Map<String, String> data, HttpServletRequest httpServletRequest) {
log.info("[执行登录接口]");
String username = data.get("username");
String email = data.get("email");
String phone = data.get("phone");
String password = data.get("password");
List resultList = null;
QueryWrapper wrapper = new QueryWrapper<User>();
Map<String, String> map = new HashMap<>();
if(username != null && "".equals(username) == false){
map.put("username", username);
resultList = service.selectBaseList(service.select(map, new HashMap<>()));
}
else if(email != null && "".equals(email) == false){
map.put("email", email);
resultList = service.selectBaseList(service.select(map, new HashMap<>()));
}
else if(phone != null && "".equals(phone) == false){
map.put("phone", phone);
resultList = service.selectBaseList(service.select(map, new HashMap<>()));
}else{
return error(30000, "账号或密码不能为空");
}
if (resultList == null || password == null) {
return error(30000, "账号或密码不能为空");
}
//判断是否有这个用户
if (resultList.size()<=0){
return error(30000,"用户不存在");
}
User byUsername = (User) resultList.get(0);
Map<String, String> groupMap = new HashMap<>();
groupMap.put("name",byUsername.getUserGroup());
List groupList = userGroupService.selectBaseList(userGroupService.select(groupMap, new HashMap<>()));
if (groupList.size()<1){
return error(30000,"用户组不存在");
}
UserGroup userGroup = (UserGroup) groupList.get(0);
//查询用户审核状态
if (!StringUtils.isEmpty(userGroup.getSourceTable())){
String res = service.selectExamineState(userGroup.getSourceTable(),byUsername.getUserId());
if (res==null){
return error(30000,"用户不存在");
}
if (!res.equals("已通过")){
return error(30000,"该用户审核未通过");
}
}
//查询用户状态
if (byUsername.getState()!=1){
return error(30000,"用户非可用状态，不能登录");
}
String md5password = service.encryption(password);
if (byUsername.getPassword().equals(md5password)) {
// 存储Token到数据库
AccessToken accessToken = new AccessToken();
accessToken.setToken(UUID.randomUUID().toString().replaceAll("-", ""));
accessToken.setUser_id(byUsername.getUserId());
tokenService.save(accessToken);
// 返回用户信息
JSONObject user = JSONObject.parseObject(JSONObject.toJSONString(byUsername));
user.put("token", accessToken.getToken());
JSONObject ret = new JSONObject();
ret.put("obj",user);
return success(ret);
} else {
return error(30000, "账号或密码不正确");
}
}
public String select(Map<String,String> query,Map<String,String> config){
StringBuffer sql = new StringBuffer("select ");
sql.append(config.get(FindConfig.FIELD) == null || "".equals(config.get(FindConfig.FIELD)) ? "*" : config.get(FindConfig.FIELD)).append(" ");
sql.append("from ").append("`").append(table).append("`").append(toWhereSql(query, "0".equals(config.get(FindConfig.LIKE))));
if (config.get(FindConfig.GROUP_BY) != null && !"".equals(config.get(FindConfig.GROUP_BY))){
sql.append("group by ").append(config.get(FindConfig.GROUP_BY)).append(" ");
}
if (config.get(FindConfig.ORDER_BY) != null && !"".equals(config.get(FindConfig.ORDER_BY))){
sql.append("order by ").append(config.get(FindConfig.ORDER_BY)).append(" ");
}
if (config.get(FindConfig.PAGE) != null && !"".equals(config.get(FindConfig.PAGE))){
int page = config.get(FindConfig.PAGE) != null && !"".equals(config.get(FindConfig.PAGE)) ? Integer.parseInt(config.get(FindConfig.PAGE)) : 1;
int limit = config.get(FindConfig.SIZE) != null && !"".equals(config.get(FindConfig.SIZE)) ? Integer.parseInt(config.get(FindConfig.SIZE)) : 10;
sql.append(" limit ").append( (page-1)*limit ).append(" , ").append(limit);
}
log.info("[{}] - 查询操作，sql: {}",table,sql);
return sql.toString();
}
public List selectBaseList(String select) {
List<Map<String,Object>> mapList = baseMapper.selectBaseList(select);
List<E> list = new ArrayList<>();
for (Map<String,Object> map:mapList) {
list.add(JSON.parseObject(JSON.toJSONString(map),eClass));
}
return list;
}
系统呈现出一种简洁大方的首页：界面简约、鳞次栉比，用户能轻车熟路的使用。出于对系统使用群体广泛的顾虑，应有良好性能的后台。
如下图所示为系统的首页界面。
图5-3系统首页界面
入库的物资过程中，首先使用getmap(id,"xinxi")，通过商品ID得到商品数据，将商品数据赋值给入库的物资，调用CommDAO的insert方法将领取数据插入订单表中，最后查看个人历史物资入库记录，可以销毁历史领取数据。
物资入库流程图如下所示。
图5-4物资入库流程图
物资仓库界面如图所示。
图5-5物资仓库界面
物资派送过程中，首先使用getmap(id,"xinxi")，通过商品ID得到物资数据，将数据赋值给物资派送，调用CommDAO的insert方法将移库数据插入退货表中，最后查看个人历史物资派送记录，可以销毁历史退货数据。
物资派送流程图如下所示。
图5-6物资派送流程图
物资派送界面如图所示。
图5-7物资派送界面
物资派送界面关键代码如下：
@RequestMapping("/get_list")
public Map<String, Object> getList(HttpServletRequest request) {
Map<String, Object> map = service.selectToPage(service.readQuery(request), service.readConfig(request));
return success(map);
员工在yhzhgl查看员工信息，先使用sql语句查询出所有员工表的数据，然后调用PageManager.getPages(url,4,sql, request )，返回一个ArrayList的对象，在for循环里，使用jsp得到每个ArrayList对象的数据，在jsp页面中解析ArrayList对象，得到其各个键值对的值。
员工管理界面如下图所示。
图5-8员工管理界面
用户点击登录填写账号信息登录后，会切换内容为“某某用户欢迎您”和历史订单，并给出注销链接。当用户登录成功后会将个人信息保存在session作用域中，点击自己的用户名时，会跳转到个人详细信息页面，由后台通过Freemarker取出session作用域中的用户信息进行动态渲染，例如，邮箱、电话号码、用户名等等。同时页面上会显示修改个人信息和修改密码的按钮，这时用户可以修改自己的登录密码以保障账号的安全性，防止被人窃取账号，通过UserController.java的updatePassword()实现，同时也可以根据自己的个人信息是否变动做出相应的修改，通过updateUserInfo()实现。
密码修改流程图如下所示。
图5-9密码修改流程图
添加员工检测信息时，输入必填字段后，表现层的ShangpinController接受传过来的员工检测信息参数，再调用ShangpinController类的addShangpin方法，经过ShangpinService业务层到ShangpinMapper持久层的处理，完成对整个添加员工检测信息的操作。addShangpin方法也和用户管理中的addUser方法类似，同时做添加和修改工作。
修改员工检测信息时，选择需要修改的员工检测进行修改，调用ShangpinController控制器的editShangpin方法，拿到该员工检测原本的信息并显示到页面，管理员再对需要修改的员工检测信息字段进行修改，完成后调用addShangpin方法，调用业务层的updateByKey方法，更新数据库的员工检测信息表的数据。
员工检测流程图如下所示。
图5-10员工检测流程图
员工检测管理界面如下图所示。
图5-11员工检测界面
员工检测界面关键代码如下：
@RequestMapping("/get_obj")
public Map<String, Object> obj(HttpServletRequest request) {
List resultList = service.selectBaseList(service.select(service.readQuery(request), service.readConfig(request)));
if (resultList.size() > 0) {
JSONObject jsonObject = new JSONObject();
jsonObject.put("obj",resultList.get(0));
return success(jsonObject);
} else {
return success(null);
}
}
选择需要删除的用户信息进行删除，把主键的uId传到CangkuController控制器，再调用控制器的deleteCangku方法，数据经过CangkuService业务层解析和处理，请求CangkuMapper持久层调用deleteByPrimaryKey方法操作数据库将仓库数据从数据库中删除。
查找用户时，输入需要查找的用户名，调用getData方法获取所有数据并且进行分页，把获取到的所有数据显示到视图上，这时候只需要用脚本方法便能快速查找，不涉及对数据库操作。
用户管理流程图如下所示。
图5-12用户管理流程图
用户选择物资添加派送记录，用户在shangpinxinxi_list查看物资，点击派送，跳转至rukuxinxi_add.jsp，添加派送记录则将添加的派送记录数据封装在HashMap中，然后调用CommDAO的insert方法将派送记录内容插入派送记录表中。
物资派送管理流程图如下所示。
图5-14物资派送管理流程图
图5-15物资派送管理界面
物资派送管理界面关键代码如下：
@RequestMapping("/get_list")
public Map<String, Object> getList(HttpServletRequest request) {
Map<String, Object> map = service.selectToPage(service.readQuery(request), service.readConfig(request));
return success(map);
本系统单独编写一个Pager类用于分页技术的实现，在该类中确定每一个页面显示记录的总数pageSize，同时定义总记录数totalSize、当前页currentPage和总页数totalPage这几个属性，声明一个带两个参数的构造函数，获取数据库记录的时候传入记录总数给pageSize，通过记录总数和pageSize这两个变量计算出总页数，在查询数据的时候需要通过Pager类的pageSize设置每次取出数据的最大记录数和设置起始取出记录的位置。该类中还定义了几个boolean类型的变量，用于判断是否有上一页、下一页、最后一页等等，在jsp页面显示数据的时候通过标签显示记录是否有上一页或者下一页。
在对该系统进行完详细设计和编码之后，就要对救援物资管理与分配系统的程序进行测试，检测程序是否运行无误，反复进行测试和修改，使之最后成为完整的软件，满足用户的需求，实现预期的功能。
在软件的测试过程中，通常测试人员需要针对不同的功能模块设计多种测试用例。通过测试用例能够及时发现代码业务逻辑上是否与真实的业务逻辑相对应，及时发现代码上或逻辑上的缺陷，以此来来完善系统，提高软件产品的质量，使软件具有良好的用户体验。
登录测试用例表如下所示。
表6-1登录测试用例
| 测试性能 |
用户或操作员登录系统 |
||
| 用例目的 |
测试用户或操作员登录系统时功能是否正常 |
||
| 前提条件 |
进入用户登录页面或操作员登录页面 |
||
| 输入条件 |
预期输出 |
实际情况 |
|
| 各项信息不予填写，直接点击登陆按钮 |
不允许登录，提示填写账号相关信息 |
一致 |
|
| 填写错误的登录名或密码后点击登录系统 |
提示用户名或密码错误，要求重新填写进行登录 |
一致 |
|
| 填写与验证码信息不一致的信息 |
系统显示出提示信息，表明验证码错误，要求重新填写 |
一致 |
|
物资入库测试用例表如下所示。
表6-2物资入库测试用例
| 测试性能 |
用户进行物资入库的操作 |
||
| 用例目的 |
测试用户进行物资入库操作时，该功能是否正常 |
||
| 前提条件 |
用户进入物资详情页，该物资能够被入库 |
||
| 输入条件 |
预期输出 |
实际情况 |
|
| 对着某物资点击“入库”按钮 |
界面跳转至领取界面 |
一致 |
|
| 在领取界面，输入必填项，点击“提交”按钮 |
提示“入库成功”，并返回上一级界面 |
一致 |
|
| 在领取界面，填写领取表单的时候未输入完整，点击“提交”按钮 |
提示“入库失败” |
一致 |
|
物资仓库管理测试用例表如下所示。
表6-3物资仓库管理测试用例
| 测试性能 |
用户进行物资仓库的操作 |
||
| 用例目的 |
测试用户进行物资仓库操作时，该功能是否正常 |
||
| 前提条件 |
用户进入物资详情页，该物资能够被移库 |
||
| 输入条件 |
预期输出 |
实际情况 |
|
| 对着某物资点击“仓库”按钮 |
界面跳转至仓库界面 |
一致 |
|
| 在物资界面，输入必填项，点击“仓库”按钮 |
提示“成功”，并返回上一级界面 |
一致 |
|
| 在物资界面，填写物资表单的时候未输入完整，点击“仓库”按钮 |
提示“失败” |
一致 |
|
物资仓库管理测试用例表如下所示。
表6-4物资派送测试用例
| 测试性能 |
物资相关信息管理功能 |
||
| 用例目的 |
测试系统操作者对物资相关信息进行管理的功能是否正常 |
||
| 前提条件 |
登录系统进入相关管理页面 |
||
| 输入条件 |
预期输出 |
实际情况 |
|
| 进入物资派送界面，点击“派送”按钮，填写所有必填项，点击提交 |
提示“派送成功”，并返回查询界面 |
一致 |
|
| 进入物资派送界面，点击“派送”按钮，未填写一个或者多个必填项，点击提交 |
提示“派送失败”，请填写必填项 |
一致 |
|
| 进入物资派送界面，选择要修改的一条数据，点击该条数据后面的“修改”按钮 |
节目跳转至修改界面 |
一致 |
|
| 在修改界面，修改可修改项后，点击“提交”按钮 |
提示“修改成功”，并返回查询界面 |
一致 |
|
| 进入物资派送界面，点击某条数据后面的删除按钮 |
提示“是否要删除该数据”，如果用户点击“确定”按钮，则成功删除该条数据，并提示“删除成功”，之后返回查询界面 |
一致 |
|
经过对此系统的测试，得出该系统足以满足用户日常需求，在功能项目和操作等方面也能满足操作员对于其他用户的管理。但是，还有很多功能有待添加，这个系统仅能满足大部分的需求，还需要对此系统功能进一步的完善，这样使用起来才能更加的完美。
通过救援物资管理与分配系统的开发，本人巩固了之前学过的知识，如今将平时所学到的知识融合在设计中，在设计过程中，做了很多的准备，首先，在数据库系统的设计过程中，尤其是在数据库的工作原理、工作特点，对其深刻的讨论，与此同时，对于小型站点来说，最好服务器的选择，其次，利用所学的知识点分析所做的系统，并在此基础上设计。
目前本系统已经上线，正在试运行阶段，用户反馈良好，基本完成用户所需，试运行过程中没有出现阻断性问题，有一些不足和小问题也及时予以修正，系统上线后，为了保证数据的安全性，对系统进行了备份操作，系统备份是每两个月备份一次，数据库备份为每周备份一次，系统部署在租赁的云平台服务器中。
本次系统上线成功后，得到了用户的高度认可，但是在功能上和性能上还需做进一步的研究处理，使其有更高的性能和更好的用户体验。
系统在以后的升级过程中，需要解决一系列用户所提出的问题，例如打印过程中如何避免浏览器的兼容性问题，大量用户访问时，如何保持较高的响应速度，在系统今后的升级过程中将着重解决这些安全性问题。
参考文献
[1]Shan Li,Peng Xiao,Wei Zhou,Yun Liang,Shiao-Wei Kuo,Tao Chen.Bioinspired Nanostructured Superwetting Thin-Films in a Self-supported form Enabled “Miniature Umbrella” for Weather Monitoring and Water Rescue[J].Nano-Micro Letters,2022,14(02):180-195.
[2]段容谷,庄媛媛,张克勇,吴云霞.突发公共卫生事件下多阶段应急救援物资配置研究[J].中国安全生产科学技术,2021,17(12):142-148.
[3]张毅.考虑需求缺口的应急物资分配机理及运作模式[J].中国流通经济,2021,35(09):32-42.
[4]安聪琢,王玖河.突发性公共卫生事件下横纵结合应急物资配送模式[J].科学技术与工程,2021,21(23):10029-10036.
[5]黄辉,梁星,李梦想,张娟.应急物资联合配送决策研究[J].运筹与管理,2021,30(06):48-54.
[6]叶芷吟. 基于需求分析的大型灾害属地应急物资分配研究[D].北京交通大学,2021.
[7]肖姜. 基于深度学习的跨海大桥灾害救援研究[D].扬州大学,2021.
[8]乐磊,陆倩,杨梦蝶.基于NET平台的应急医疗救援物资管理系统模块化构建[J].现代医院,2021,21(03):417-419+423.
[9]曹策俊,高学鸿.基于数学规划的救援物资分配优化模型及其求解算法综述[J].计算机应用,2020,40(08):2398-2409.
[10]王妍妍,孙佰清.模糊信息下多种类应急物资多周期分配优化模型[J].中国管理科学,2020,28(03):40-51.
[11]左文泽. 基于情景分析的城市应急救援调度研究[D].哈尔滨工业大学,2019.
[12] Zheng Qiangcheng. SSM に基づく緊急資源管理システムの設計と実装 [D]. 華中師範大学、2019.
[13] Zhang Jie、Xie Yonggang、Li Xuelong. 危機管理システムに関する研究 [J]. Land Bridge Vision, 2018(09):75-77+80.
[14] Sun Xiaoye. 地震緊急救助資材管理システムの設計と実装 [D]. 北京理工大学、2018.
[15] イン・プミン、オンラインでの子供たちの救出 [J]、北京レビュー、2018、59(24): 30-31。
[16] Li Zijian、Zhu Xiaolong、Qiao Zhengfu、Che Jibo、Cao Ping、Wang Youjin. RFID 技術に基づく「3 つの防御」医療救助および戦闘準備物品管理システムの開発と応用 [J]. 医療および健康機器、 2018, 35 (09):38-40.
ありがとう
設計が完了すると、大学生活は終わりを迎えます。大学生活は私にとって最も大切にしている時間であり、大学生活で多くのことを学び、成長することができ、そのすべての思い出が私の心に刻まれています。一緒に学び成長してきた生徒たち、成長過程を教えてくれた先生方のおかげで、御社に心より感謝いたします。
まずは先生に感謝したいと思いますが、デザインの完成には先生の一連のご指導があってこそです。卒業制作の際には、先生が的確なアドバイスをたくさんして下さり、先生の丁寧な仕事姿勢のおかげで、私のデザインが無事に完成することができました。
最後に、大学生活中に私にたくさんの知識を教えていただき、問題に遭遇したときの対処法や解決法を教えてくださった先生方に感謝いたします。ご支援とご協力に感謝いたします。
いいね+お気に入り+フォロー→プライベートメッセージでソースコードとデータベースを受け取ります