SSMホテル資産管理システムの設計
まとめ
ホテル資産管理システムの主な機能モジュールには、倉庫情報、資産タイプ、購入申請、倉庫購入、借入申請、返品情報、修理情報、メンテナンス完了、スクラップ申請、スクラップ確認が含まれます。ソフトウェア開発とハードウェアのインストールにはオブジェクト指向開発モデルが採用されており、実際の使用ニーズを十分に満たし、対応するソフトウェアのインストールとプログラムのコーディング作業を向上させます。バックグラウンド データの主なストレージ ユニットとして Mysql が使用されます。SSM フレームワーク、業務システムのコーディングや開発にはJSP技術、Ajax技術が利用されており、本システムのすべての機能が実現されています。この報告書では、まず研究の背景、役割、意義を分析し、研究作業の合理性の基礎を築きます。ホテル資産管理システムのさまざまなニーズと技術的問題を分析し、システムの必要性と技術的実現可能性を証明し、その後、設計システムで使用する必要がある技術ソフトウェアと設計アイデアの基本を紹介し、最終的に実装します。ホテル資産管理システムと導入運用で使用されます。
キーワード: ホテル資産管理、SSM フレームワーク、Mysql データベース
抽象的な
ホテル資産管理システムの主な機能モジュールには、倉庫情報、資産タイプ、調達申請、調達倉庫保管、借入申請、返品情報、修理情報、メンテナンス完了、スクラップ申請、スクラップ確認が含まれます。ソフトウェア開発とハードウェアのインストールにオブジェクト指向開発モデルを採用すると、実際の使用ニーズを効果的に満たし、対応するソフトウェアのインストールとプログラムのコーディング作業を改善し、バックエンド データのメイン ストレージ ユニットとして MySQL を採用し、SSM フレームワーク、JSP テクノロジー、業務システムのコーディングと開発のためのAjax技術により、システムのすべての機能を実現します。この報告書では、まず研究の背景、役割、意義を分析し、研究作業の合理性の基礎を築きます。ホテル資産管理システムのさまざまな要件と技術的問題を分析し、システムの必要性と技術的実現可能性を証明し、システム設計に必要な技術的なソフトウェアと設計思想についての基本的な紹介を行います。最後に、ホテル資産管理システムを導入し、導入・運用します。
キーワード：ホテルアセットマネジメント、ホテルアセットマネジメント SSM フレームワーク。MySQLデータベース
目次
第1章; 序章
1.1 研究の背景と意義
近年、社会の発展に伴い各地からの観光客が増加し、ホテルの数も増加しており、ホテルの資産管理における情報量も飛躍的に増加し続けています。そのため、従来のホテルの資産管理方法では、問題が増え、人員が浪費され、効率が低下するなど、ますます問題が顕在化しています。現在、ホテルではホテルスタッフが膨大な情報をより早く、より便利に、より正確に管理できるようにするためのさまざまなシステムが急務となっています。
インターネット技術が普及した今日、人々の生活はコンピューターと切り離すことができず、仕事、勉強、さらには買い物にもコンピューターを使用しています。たとえば、海外出張や旅行に行くとき、人々は通常、自分のニーズに応じて事前にオンラインで部屋を予約することを選択し、部屋を見つける時間を大幅に節約します。大規模ホテルの場合、ホテルシステムを利用して資産情報を管理することが特に重要です。
1.2 開発状況
1. 国内の研究状況：
我が国のホテル業界は、管理を強化し、サービスレベルを向上させるためにコンピューター管理システムを長年使用してきました。私の国のホテルにおける IT の発展段階は、主にコンピュータ システムの使用によって特徴付けられていますが、実際、電話通信システムはプログラム制御の交換技術の出現により質的に飛躍しました。コンピュータの普及と応用に伴い、コンピュータ技術の継続的な発展により、ホテルの資産管理システムも新しい時代を迎え、より完璧になる傾向にあります。ホテル資産管理システムにより、ホテルの人件費が節約されます。
2. 海外研究の現状：
外国のホテル産業は中国よりも何年も早く発展し、長年の開発探査を通じてホテルの機能開発はより包括的かつ多様化しました。最初の建安の宿泊施設から現在のレジャー、エンターテイメント、ビジネス旅行まで、ホテルはより複雑な機能とより完全な機能の方向に発展しています。これらのホテルの総合的な発展に伴い、ホテルの管理要件も増大しており、コンピュータの急速な発達を背景に、ホテルをより便利に管理するために、ホテル資産管理システムのソフトウェアが開発され、人員が大幅に削減されました。また、物質的および財政的資源により、ホテルの運営がより標準化され、サービス水準が向上します。
第2章 関連技術の紹介
2.1 開発技術説明
このシステムのフロントエンド部分は B/S モードを使用した MVVM モデルに基づいて開発され、バックエンド部分は Java の ssm フレームワークに基づいて開発されています。
フロントエンド部分: フロントエンド フレームワークは、人気のあるプログレッシブ JavaScript フレームワーク Vue.js を使用します。Vue-Router と Vuex を使用して動的ルーティングとグローバル状態管理を実現し、Ajax を使用してフロントエンドとバックエンドの通信を実現し、Element UI コンポーネント ライブラリを使用してページのプロトタイプを迅速に作成し、プロジェクト フロントエンドを使用してグリッド レイアウトによる応答性を実現します。 PC、タブレット、携帯電話などに適応できます。さまざまな画面サイズに最適なレイアウト表示。
バックエンド部分: ssm を開発フレームワークとして使用し、MyBatis、Redis、およびその他の関連テクノロジーを統合します。
2.2 MVVMパターンの概要
MVVMはModel-View-ViewModelの略称です。これは本質的に MVC の改良版です。MVVM はビューの状態と動作を抽象化し、ビュー UI とビジネス ロジックを分離できるようにします。もちろん、ViewModel はこれらのことをすでに行っており、モデルのデータを取り出して、コンテンツを表示する必要があるためにビューに含まれるビジネス ロジックの処理に役立ちます。Microsoft の WPF は、Silverlight、オーディオ、ビデオ、3D、アニメーションなどの新しい技術エクスペリエンスをもたらし、その結果、ソフトウェア UI レイヤーがより詳細でカスタマイズ可能になります。同時に、技術レベルでは、WPF はバインディング、依存関係プロパティ、ルーテッド イベント、コマンド、DataTemplate、ControlTemplate などの新機能ももたらします。MVVM (Model-View-ViewModel) フレームワークの起源は、 MVP (Model-View-Presenter)パターンと WPF を組み合わせたアプリケーション手法から進化した新しいアーキテクチャフレームワークです。これは、オリジナルの MVP フレームワークに基づいており、ますます複雑になる顧客ニーズの変化に対応するために WPF の新機能が組み込まれています。
2.3 SSM フレームワーク
SSM (Spring+SpringMVC+MyBatis) フレームワーク セットは、2 つのオープン ソース フレームワーク Spring と MyBatis によって統合されています (SpringMVC は Spring の一部です)。比較的単純なデータ ソースを使用する Web プロジェクトのフレームワークとしてよく使用されます。
2.4.1スプリング
Spring は、プロジェクト全体で Bean を組み立てる大きな工場のようなもので、構成ファイルで、特定のパラメーターの使用を指定して、エンティティ クラスのコンストラクター メソッドを呼び出し、オブジェクトをインスタンス化できます。プロジェクトにおける接着剤とも言えます。
Spring の核となるアイデアは IoC (Inversion of Control) です。これは、プログラマがオブジェクトを明示的に「新規」にする必要がなくなり、Spring フレームワークにすべてを任せることを意味します。
2.4.2 SpringMVC
SpringMVC は、プロジェクト内のユーザー リクエストをインターセプトします。そのコア サーブレットである DispatcherServlet は、仲介またはフロント デスクの役割を引き受け、HandlerMapping を通じてユーザー リクエストをコントローラーに照合します。コントローラーは、リクエストに応じて実行される特定の操作です。SpringMVC は、SSH フレームワークの Struts に相当します。
2.4.3 マイボット
Mybatis は jdbc のカプセル化であり、データベースの基礎となる操作を透過的にします。mybatis の操作は sqlSessionFactory インスタンスを中心に行われます。Mybatis は、構成ファイルを通じて各エンティティ クラスの Mapper ファイルに関連付けられており、Mapper ファイルには、各クラスに必要な SQL ステートメントのデータベースへのマッピングが設定されています。データベースと対話するたびに、sqlSessionFactory を通じて sqlSession を取得し、sql コマンドを実行します。
ページがコントローラーにリクエストを送信し、コントローラーがビジネス層の処理ロジックを呼び出し、ロジック層がリクエストを永続層に送信し、永続層がデータベースと対話して、結果をビジネス層に返します。処理ロジックをコントローラーに送信し、コントローラーはビューを呼び出してデータを表示します。
2.4 MySQL データベース
Mysql は度重なるアップデートを経て機能的に非常に豊富かつ完成度が高く、バージョン 4 からバージョン 5 まで比較的大規模なアップデートが行われ、実際の商用利用においても良好な実用化実績をあげています。Mysql の最新バージョンは情報の圧縮と暗号化をサポートしており、情報セキュリティのニーズをより適切に満たすことができます。同時に、システムの複数回のアップデートを経て、データベース自体のミラーリング機能も大幅に強化され、動作のスムーズさと使いやすさが大幅に向上し、ドライバーの使用と作成がより効率的になり、もっと早く。最大の変更点は空間情報の表示の最適化で、これによりアプリケーション マップ上のラベル付けと座標の計算が容易になります。強力なバックアップ機能で安心してご利用いただけるとともに、サポートされているOffice機能により、ユーザー自身でのインストールや利用もサポートします。情報の表示形式も大幅に刷新され、よく使用される2つの表示エリアが追加され、表とテキストが分類されたインフォメーションエリアと、よりすっきりとした具体的なインターフェース表示が追加されました。2つ目は機器の情報制御であり、機器情報エリアに情報を表示したり、複数の情報を同時に比較したりすることができ、ユーザーの実際の使用に大きな利便性をもたらします[7][8]。
この記事で設計したホテル資産管理システムの実際の導入プロセスにおいて、最終的に Mysql データベースを選択した主な理由は、企業のアプリケーション システムのアプリケーションおよび開発プロセスで頻繁にデータベース操作が多数発生するためです。データのセキュリティ要件も非常に高いです。これらの要因を踏まえ、ホテル資産管理システムのバックエンドデータの保存には、最終的にセキュリティ要素が比較的高い Mysql が選択されました [9][10]。
第 3 章 システム分析
3.1 実現可能性の分析
技術面では、システムの主要な枠組みの構築には現在主流のSSMフレームワークを使用し、フロントページのデザインや美観調整にはjqueryとajaxを使用しており、上記の技術は全て私が体系的に研究したものです。コース設計で実践されており、開発をより便利かつ体系的に行うことができます。技術的な観点から見ると、このシステムは完全に実現可能です。
実用性の観点から、この設計の主なタスクは、倉庫情報、資産タイプ、購入申請、倉庫購入、借入申請、返品情報、修理情報、修理完了、スクラップ申請、およびスクラップ確認の機能モジュールをホテルに実装することです。資産管理システム等を時代の発展に合わせて整備していきます。ユーザーの視点から、システム運用コストや人的リソースも考慮し、インターネット上の便利な手段を活用して、より体系的で使いやすく、より実践的な業務プロセスを実現するオンラインビジネスを実現します。
本プロジェクトで設計したホテル資産管理システムは、経済性の観点から、ホテル資産情報をより包括的に管理・取得することを主目的とした、直接活用可能な情報ソフトウェアです。システムの主なコストは、主にその後の使用状況データの保守管理更新に集中します。したがって、このソフトウェアを開発することは経済的に実行可能です。
3.2 機能要件の分析
ホテル資産管理システムの機能は主に従業員ユーザー、倉庫管理者、メンテナンス担当者、バイヤー、財務担当者、管理者の6つの役割に分かれています。
システムにログインすると、倉庫情報の閲覧、借入の申し込み、借入の確認、資産の返却、修理の申し込みなどを行うことができます。
倉庫管理者は、システムにログインすると、倉庫情報の管理、購入申請書や購入情報の表示、従業員の借入申請書や返品情報の確認、倉庫内の資産の廃棄申請を行うことができます。
保守担当者はシステムにログインして倉庫情報を表示したり、倉庫内の資産を借りたり返却したり、従業員が提出した保守情報を表示したりできます。
購入者がシステムにログインすると、まず倉庫情報を表示し、購入申請を提出し、購入倉庫作業を実行できます。
財務担当者はシステムにログインして倉庫情報を表示し、購入者が提出した購入申請を確認できます。
管理者はログイン後、システムモジュールやシステム情報を保守・管理します。
従業員のユースケース図を以下に示します。
図 3-1 従業員のユースケース図
倉庫マネージャーのユースケース図を以下に示します。
図 3-2 倉庫マネージャーの使用例図
保守員のユースケース図を以下に示します。
図 3-3 保守員のユースケース図
バイヤーのユースケース図を以下に示します。
図 3-4 購入者のユースケース図
トレジャラーのユースケース図を以下に示します。
図 3-5 財務担当者のユースケース図
3.2.1 ユーザー機能
アカウントの登録: ユーザーは個人情報を入力し、携帯電話番号を確認します。
ログイン: アカウントとパスワードに基づいてログインします。
個人情報の管理：ユーザーは、個人情報の変更により、いつでも登録情報を変更することができます。
倉庫情報：ユーザーは必要に応じて倉庫の資産情報を閲覧でき、倉庫情報の追加、削除、変更、確認は倉庫管理者が行います。
購入要求書: 資産の購入要求書は購入者によって提出され、財務担当者が閲覧および検討できます。
調達と倉庫保管: 倉庫管理者は、購入した資産を倉庫保管用に登録します。
借入申込：従業員による資産の借入申込と保守員による資産の借入申込に分かれており、倉庫管理者が申込書を審査します。
借入確認: 倉庫担当者は、従業員や保守担当者が閲覧できる借入確認情報を公開します。
返却情報: このモジュールは、従業員による借用資産の返却と、保守担当者による借用資産の返却にも分かれており、倉庫管理者によって確認されます。
廃棄申請：従業員は放棄された資産の廃棄を申請するものとします。
スクラップの確認: スクラップの確認は倉庫管理者によって確認されます。
修理情報: 従業員が修理情報を提出し、保守担当者が特定の情報を参照して保守を手配できます。
メンテナンス完了: メンテナンスが完了すると、保守担当者からメンテナンス完了情報が公開されます。
3.2.2 管理者機能
パスワードの変更: 管理者は、システムのセキュリティを確保するために、いつでもシステムに入るログイン パスワードを変更できます。
倉庫情報等の維持管理
ユーザー管理: 従業員、メンテナンス担当者、バイヤー、倉庫管理者、財務担当者を管理します。
調達要求管理: 資産調達情報を維持および管理します。
資産種類管理：資産情報を分類して管理します。
調達入庫管理：調達を経た資産の入庫情報を管理します。
借入・返却情報管理：従業員や保守要員の資産の借入・返却情報を管理します。
修理情報管理：修理情報を閲覧・管理できます。
3.3 非機能要件の分析
まず、システム機能ソフトウェアが具体的な設計プロセスにおいて、さまざまなユーザーの基本的な機能ニーズをより適切に満たすことができるかどうかが主な考慮事項であり、ユーザーのニーズをよりよく満たすことができない場合、このシステムの存在価値はありません。ソフトウェアシステムの非機能分析は、システムを対象としたパフォーマンス分析、システムを対象としたセキュリティ分析、システムを対象とした完全性分析の7つの側面から実行されます。 1 つはシステムを対象とした保守性分析、1 つはシステムを対象としたスケーラビリティ分析、もう 1 つはビジネスに適応するパフォーマンス分析です。ホテル資産管理システムの 7 つのパフォーマンス側面 (パフォーマンス、セキュリティ、拡張性、完全性) を包括的に比較および分析した結果、対応する非機能要件の分析が必要であることがわかりました。
3.4 セキュリティ要件の分析
3.4.1 システムのセキュリティ
セキュリティはあらゆるシステムにとって非常に重要です。セキュリティがしっかりしたシステムであれば、企業情報やユーザー情報の盗難を防ぐことができます。システムのセキュリティを向上させることは、ユーザーだけでなく企業にも責任があります。特にホテルの資産管理システムの場合、システム全体を保護するための優れたセキュリティが必要です。
システムにはユーザーの権限制御があり、システムのセキュリティを確保するためにさまざまな役割に基づいてユーザーの権限を制限します。
3.4.2 データのセキュリティ
データベース内のデータは外部から入力されるものですが、そのデータが入力されると、様々な理由により、入力されたデータは無効なデータやダーティなデータになります。したがって、入力データが規制に準拠していることを確認する方法が、データベース システム、特にマルチユーザー リレーショナル データベース システムの主な関心事になっています。
したがって、データベースに書き込むときは、データの整合性、正確性、一貫性を確保する必要があります。
3.5 データプロセス分析
システムのデータ フローを分析した後、システムのユーザーは、システム ユーザー (従業員、保守担当者、バイヤー、倉庫管理者、財務担当者) と管理者の 2 つのカテゴリに分類されます。このシステムは主にインターフェース情報の送信、ログイン情報の検証、登録情報の受信、およびユーザーの各種操作への応答を処理します。
システムのトップレベルのデータ フロー図を次の図に示します。
図 3-2 最上位のデータ フロー図
ユーザーの身元を判断するには、ログイン データに基づいて判断し、対応する機能インターフェイスにジャンプします。システム内のユーザーはデータを操作でき、データベース センターはシステムから送信された有効なデータ ストリームを受信して、データ SQL ステートメントに対して対応する操作を実行できます。
システムの基礎となるデータ フロー図を次の図に示します。
図 3-3 基礎となるデータ フロー図
システムはフロントエンドとバックエンドの 2 つの部分に分かれており、各操作の後にシステムは操作結果を返します。フロントエンドとバックエンド間のデータ接続は主にデータベースを介して行われます。これは、データベース上でそれぞれ異なる操作が実行されることを意味します。
第4章 システム設計
4.1 システムアーキテクチャ設計
ホテル資産管理システムのアーキテクチャ設計は、主にWeb層、ビジネス層、モデル層の3層に分かれています。Web レイヤーにはビュー レイヤーとコントローラー レイヤーも含まれ、モデル レイヤーにはメタデータ拡張レイヤーとデータ アクセス レイヤーが含まれます。
システムアーキテクチャを次の図に示します。
図 4-1 システムアーキテクチャ
4.2 システム全体の設計
ホテル資産管理システムは一般にユーザーモジュールと管理者モジュールに分かれています。2 つのモジュールは独立して存在しているように見えますが、アクセスするデータベースは同じです。管理者は最高の権限を持つ者であり、具体的な機能としては、倉庫情報、資産種類、購入申込、倉庫購入、借入申込、返品情報、修理情報、修理完了、スクラップ申請、スクラップ確認などが挙げられます。
まとめると、システム機能図は次の図に示されます。
図 4-2 システム機能図
4.3 システム機能設計
ログイン モジュール: ログイン モジュールはシステムへの入り口であり、すべてのユーザーがシステムにアクセスする前にログインする必要があります。ログインするには、ユーザー名とパスワードを入力する必要があります。複数回ログインを試行する場合は、確認コードを入力する必要があります。ログインする際には、一般ユーザーか管理者ログインかなど、ユーザーの役割を選択する必要があります。ログインに成功すると、データベースを通じてユーザーの権限が取得され、ユーザーのホームページにジャンプします。
倉庫情報データモジュール：倉庫情報データ閲覧、倉庫情報データ取得、倉庫情報データ保守の3つのモジュールに分かれており、倉庫管理者は倉庫情報データの保守、新規倉庫情報データの公開、既存倉庫の更新を行う権限を有します。 . 情報データ等
購入申請モジュール: 購入申請は購入申請の追加と変更に分かれています。購入要求は購入者によって変更、追加、削除され、購入要求のレビューは財務担当者によって実行されます。
借入申込モジュール：借入申込は借入追加、変更、審査に分かれます。借用情報の修正・追加・削除は従業員や保守員が行い、借用情報の見直しは倉庫管理者が確認・確認します。
スクラップ申請モジュール: スクラップ申請はスクラップ追加、修正、レビューに分かれています。スクラップ情報は従業員によって変更、追加、削除され、倉庫管理者、財務責任者、保守担当者によってレビューおよび確認されます。
メンテナンス情報モジュール：メンテナンス情報は追加、変更、見直しに分かれています。修理情報は従業員から提出され、修理内容は保守員が確認します。
4.4 データベース設計
4.4.1 データ要件の分析
これまでの分析から、データベース内で最も重要なものは、倉庫情報、購入申込情報、借入申込情報、同時購入入庫情報と返品情報、およびスクラップ申請とスクラップ確認であることがわかります。分析により、次のデータの説明を取得できます。
プラットフォーム ユーザー: ユーザー名、パスワード、名前、性別、住所、電子メール、連絡先情報、その他のデータ項目を含むさまざまなユーザー情報を記録するために使用されます。
管理者: 管理者のログイン情報を記録します。ユーザー名、パスワード、権限、その他のデータ項目が含まれます。
倉庫: 倉庫に保管されているコンテンツ。資産番号、資産名、仕様モデル、資産タイプ、在庫数量、単価、メーカー、その他のデータ項目が含まれます。
購買要求: さまざまな購買要求情報を格納します。発注番号、資産番号、資産名、仕様モデル、資産タイプ、メーカー、購入日、購入単価、購入数量、購入金額などのデータ項目が含まれます。
借用申込書：借用申込情報を格納します。借入注文番号、資産番号、資産名称、資産種類、仕様型式、単価、メーカー、借入日、借入数量、物件価格、借入理由等のデータ項目が含まれます。
修理情報: 修理情報を保存します。修理番号、資産番号、資産名、資産タイプ、仕様モデル、単価、修理理由、保守担当者、保守日、保守情報、保守費用などのデータ項目が含まれます。
スクラップアプリケーション: スクラップアプリケーション情報を保存します。スクラップ注文番号、資産番号、資産名、資産タイプ、仕様モデル、単価、スクラップ日、その他のデータ項目が含まれます。
4.4.2 データベースの概念設計
先ほどのデータフローチャートに従い、システムの機能モジュール設計と組み合わせて、システムに適合する各情報エンティティを設計します。
システムER図を以下に示します。
図 4-3 システム ER 図
4.4.3 データベーステーブルの設計
ホテル資産管理システムは、倉庫情報テーブル、購入申込書、購入倉庫テーブル、借入申込書、返却情報テーブル、修理情報テーブル、スクラップ申請入札、メンテナンス情報テーブルのデータテーブルを有する。
データ テーブルが多数あるため、次の表に示すように、システムの主要なデータ テーブルのみを示します。
テーブル access_token (ログインアクセス期間)
| シリアルナンバー |
名前 |
データの種類 |
長さ |
小数位 |
Null値を許可する |
主キー |
デフォルト値 |
説明する |
| 1 |
トークンID |
整数 |
10 |
0 |
N |
Y |
一時的なアクセスバッジID |
|
| 2 |
トークン |
可変長文字 |
64 |
0 |
Y |
N |
一時的なアクセスバッジ |
|
| 3 |
情報 |
文章 |
65535 |
0 |
Y |
N |
||
| 4 |
最大値 |
整数 |
10 |
0 |
N |
N |
2 |
最大寿命: デフォルト 2 時間 |
| 5 |
作成時間 |
タイムスタンプ |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
作成時間: |
| 6 |
更新時間 |
タイムスタンプ |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
更新時間: |
| 7 |
ユーザーID |
整数 |
10 |
0 |
N |
N |
0 |
ユーザーID： |
テーブルborring_application_employee (借用アプリケーション(従業員))
| シリアルナンバー |
名前 |
データの種類 |
長さ |
小数位 |
Null値を許可する |
主キー |
デフォルト値 |
説明する |
| 1 |
借用アプリケーション従業員 ID |
整数 |
10 |
0 |
N |
Y |
借入申請（社員）ID |
|
| 2 |
借用注文番号 |
可変長文字 |
64 |
0 |
Y |
N |
借用追跡番号 |
|
| 3 |
資産番号 |
可変長文字 |
64 |
0 |
Y |
N |
資産番号 |
|
| 4 |
資産名 |
可変長文字 |
64 |
0 |
Y |
N |
アセット名 |
|
| 5 |
仕様とモデル |
可変長文字 |
64 |
0 |
Y |
N |
仕様と型式 |
|
| 6 |
資産の種類 |
可変長文字 |
64 |
0 |
Y |
N |
資産の種類 |
|
| 7 |
単一の値 |
整数 |
10 |
0 |
Y |
N |
0 |
単位値 |
| 8 |
メーカー |
可変長文字 |
64 |
0 |
Y |
N |
メーカー |
|
| 9 |
倉庫管理人 |
整数 |
10 |
0 |
Y |
N |
0 |
倉庫番 |
| 10 |
従業員_ユーザー |
整数 |
10 |
0 |
Y |
N |
0 |
従業員ユーザー |
| 11 |
財務担当役員 |
整数 |
10 |
0 |
Y |
N |
0 |
会計担当 |
| 12 |
借用日 |
日付 |
10 |
0 |
Y |
N |
借りた日 |
|
| 13 |
借入数量 |
整数 |
10 |
0 |
Y |
N |
0 |
借入量 |
| 14 |
アイテムの値 |
可変長文字 |
64 |
0 |
Y |
N |
アイテムの値 |
|
| 15 |
借入の理由 |
文章 |
65535 |
0 |
Y |
N |
借入理由 |
|
| 16 |
検査状態 |
可変長文字 |
16 |
0 |
N |
N |
未レビュー |
承認状況 |
| 17 |
検査_返信 |
可変長文字 |
16 |
0 |
Y |
N |
モデレート返信 |
|
| 18 |
推薦する |
整数 |
10 |
0 |
N |
N |
0 |
インテリジェントな推奨事項 |
| 19 |
作成時間 |
日付時刻 |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
作成時間 |
| 20 |
更新時間 |
タイムスタンプ |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
更新時間 |
テーブルborring_confirmation_employee (借入確認(従業員))
| シリアルナンバー |
名前 |
データの種類 |
長さ |
小数位 |
Null値を許可する |
主キー |
デフォルト値 |
説明する |
| 1 |
借入確認従業員ID |
整数 |
10 |
0 |
N |
Y |
借用確認（従業員）ID |
|
| 2 |
借用注文番号 |
可変長文字 |
64 |
0 |
N |
N |
借用追跡番号 |
|
| 3 |
資産番号 |
可変長文字 |
64 |
0 |
Y |
N |
資産番号 |
|
| 4 |
資産名 |
可変長文字 |
64 |
0 |
Y |
N |
アセット名 |
|
| 5 |
仕様とモデル |
可変長文字 |
64 |
0 |
Y |
N |
仕様と型式 |
|
| 6 |
資産の種類 |
可変長文字 |
64 |
0 |
Y |
N |
資産の種類 |
|
| 7 |
単一の値 |
整数 |
10 |
0 |
Y |
N |
0 |
単位値 |
| 8 |
メーカー |
可変長文字 |
64 |
0 |
Y |
N |
メーカー |
|
| 9 |
倉庫管理人 |
整数 |
10 |
0 |
Y |
N |
0 |
倉庫番 |
| 10 |
従業員_ユーザー |
整数 |
10 |
0 |
Y |
N |
0 |
従業員ユーザー |
| 11 |
財務担当役員 |
整数 |
10 |
0 |
Y |
N |
0 |
会計担当 |
| 12 |
借用日 |
日付 |
10 |
0 |
Y |
N |
借りた日 |
|
| 13 |
借入数量 |
整数 |
10 |
0 |
Y |
N |
0 |
借入量 |
| 14 |
アイテムの値 |
可変長文字 |
64 |
0 |
Y |
N |
アイテムの値 |
|
| 15 |
登録数 |
可変長文字 |
64 |
0 |
Y |
N |
登録数 |
|
| 16 |
推薦する |
整数 |
10 |
0 |
N |
N |
0 |
インテリジェントな推奨事項 |
| 17 |
作成時間 |
日付時刻 |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
作成時間 |
| 18 |
更新時間 |
タイムスタンプ |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
更新時間 |
テーブル buy_receipt (購買倉庫)
| シリアルナンバー |
名前 |
データの種類 |
長さ |
小数位 |
Null値を許可する |
主キー |
デフォルト値 |
説明する |
| 1 |
購入レシートID |
整数 |
10 |
0 |
N |
Y |
倉庫IDを購入する |
|
| 2 |
発注番号 |
可変長文字 |
64 |
0 |
N |
N |
注文書番号 |
|
| 3 |
資産番号 |
可変長文字 |
64 |
0 |
Y |
N |
資産番号 |
|
| 4 |
資産名 |
可変長文字 |
64 |
0 |
Y |
N |
アセット名 |
|
| 5 |
仕様とモデル |
可変長文字 |
64 |
0 |
Y |
N |
仕様と型式 |
|
| 6 |
資産の種類 |
可変長文字 |
64 |
0 |
Y |
N |
資産の種類 |
|
| 7 |
メーカー |
可変長文字 |
64 |
0 |
Y |
N |
メーカー |
|
| 8 |
倉庫管理人 |
整数 |
10 |
0 |
Y |
N |
0 |
倉庫番 |
| 9 |
買い手 |
整数 |
10 |
0 |
Y |
N |
0 |
買い手 |
| 10 |
財務担当役員 |
整数 |
10 |
0 |
Y |
N |
0 |
会計担当 |
| 11 |
購入日 |
日付 |
10 |
0 |
Y |
N |
購入日 |
|
| 12 |
購入単価 |
整数 |
10 |
0 |
Y |
N |
0 |
購入価格 |
| 13 |
購入数量 |
整数 |
10 |
0 |
Y |
N |
0 |
購入数量 |
| 14 |
購入金額 |
可変長文字 |
64 |
0 |
Y |
N |
購入金額 |
|
| 15 |
推薦する |
整数 |
10 |
0 |
N |
N |
0 |
インテリジェントな推奨事項 |
| 16 |
作成時間 |
日付時刻 |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
作成時間 |
| 17 |
更新時間 |
タイムスタンプ |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
更新時間 |
テーブル Purchase_request (購入リクエスト)
| シリアルナンバー |
名前 |
データの種類 |
長さ |
小数位 |
Null値を許可する |
主キー |
デフォルト値 |
説明する |
| 1 |
購入リクエストID |
整数 |
10 |
0 |
N |
Y |
購入申請ID |
|
| 2 |
発注番号 |
可変長文字 |
64 |
0 |
Y |
N |
注文書番号 |
|
| 3 |
資産番号 |
可変長文字 |
64 |
0 |
Y |
N |
資産番号 |
|
| 4 |
資産名 |
可変長文字 |
64 |
0 |
Y |
N |
アセット名 |
|
| 5 |
仕様とモデル |
可変長文字 |
64 |
0 |
Y |
N |
仕様と型式 |
|
| 6 |
資産の種類 |
可変長文字 |
64 |
0 |
Y |
N |
資産の種類 |
|
| 7 |
メーカー |
可変長文字 |
64 |
0 |
Y |
N |
メーカー |
|
| 8 |
倉庫管理人 |
整数 |
10 |
0 |
Y |
N |
0 |
倉庫番 |
| 9 |
買い手 |
整数 |
10 |
0 |
Y |
N |
0 |
買い手 |
| 10 |
財務担当役員 |
整数 |
10 |
0 |
Y |
N |
0 |
会計担当 |
| 11 |
購入日 |
日付 |
10 |
0 |
Y |
N |
購入日 |
|
| 12 |
購入単価 |
整数 |
10 |
0 |
Y |
N |
0 |
購入価格 |
| 13 |
購入数量 |
整数 |
10 |
0 |
Y |
N |
0 |
購入数量 |
| 14 |
購入金額 |
可変長文字 |
64 |
0 |
Y |
N |
購入金額 |
|
| 15 |
検査状態 |
可変長文字 |
16 |
0 |
N |
N |
未レビュー |
承認状況 |
| 16 |
検査_返信 |
可変長文字 |
16 |
0 |
Y |
N |
モデレート返信 |
|
| 17 |
推薦する |
整数 |
10 |
0 |
N |
N |
0 |
インテリジェントな推奨事項 |
| 18 |
作成時間 |
日付時刻 |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
作成時間 |
| 19 |
更新時間 |
タイムスタンプ |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
更新時間 |
テーブルrepair_completed (修復完了)
| シリアルナンバー |
名前 |
データの種類 |
長さ |
小数位 |
Null値を許可する |
主キー |
デフォルト値 |
説明する |
| 1 |
修理完了_id |
整数 |
10 |
0 |
N |
Y |
完全な修理ID |
|
| 2 |
修理番号 |
可変長文字 |
64 |
0 |
N |
N |
修理番号 |
|
| 3 |
資産番号 |
可変長文字 |
64 |
0 |
Y |
N |
資産番号 |
|
| 4 |
資産名 |
可変長文字 |
64 |
0 |
Y |
N |
アセット名 |
|
| 5 |
仕様とモデル |
可変長文字 |
64 |
0 |
Y |
N |
仕様と型式 |
|
| 6 |
資産の種類 |
可変長文字 |
64 |
0 |
Y |
N |
資産の種類 |
|
| 7 |
単一の値 |
整数 |
10 |
0 |
Y |
N |
0 |
単位値 |
| 8 |
倉庫管理人 |
整数 |
10 |
0 |
Y |
N |
0 |
倉庫番 |
| 9 |
メーカー |
可変長文字 |
64 |
0 |
Y |
N |
メーカー |
|
| 10 |
従業員_ユーザー |
整数 |
10 |
0 |
Y |
N |
0 |
従業員ユーザー |
| 11 |
保守担当者 |
整数 |
10 |
0 |
Y |
N |
0 |
メンテナンスマン |
| 12 |
修理の理由 |
文章 |
65535 |
0 |
Y |
N |
修理報告の理由 |
|
| 13 |
財務担当役員 |
整数 |
10 |
0 |
Y |
N |
0 |
会計担当 |
| 14 |
修理日 |
日付 |
10 |
0 |
Y |
N |
修理日 |
|
| 15 |
維持費 |
整数 |
10 |
0 |
Y |
N |
0 |
修理料金 |
| 16 |
メンテナンス情報 |
長文 |
2147483647 |
0 |
Y |
N |
メンテナンス情報 |
|
| 17 |
推薦する |
整数 |
10 |
0 |
N |
N |
0 |
インテリジェントな推奨事項 |
| 18 |
作成時間 |
日付時刻 |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
作成時間 |
| 19 |
更新時間 |
タイムスタンプ |
19 |
0 |
N |
N |
CURRENT_TIMESTAMP |
更新時間 |
第5章 システムの導入
5.1 データベースアクセス層の実装
システムは jdbc と Mysql を介して接続されています。新しい jdbc.properties ファイルを作成して、データベースへの接続に必要なドライバーとパラメーターを入力します。
jdbc.driverClass=com.Mysql.jdbc.Driver
jdbc.url=jdbc:Mysql://localhost:3306/tsi
jdbc.ユーザー名=ルート
jdbc.パスワード=123
最初のパラメータは MySQL データベース ドライバを表し、2 番目のパラメータは接続するデータベースを表し、3 番目と 4 番目のパラメータはデータベース接続名とパスワードを表します。
バックエンドとデータベースへのアクセスは、主に HQL ステートメントを通じてクエリされます。クエリ ステートメント内のテーブル名は、テーブルのエンティティ クラス名です。* は、集計関数での使用に適している場合を除き、そのようなクエリ ステートメントで使用することはできません。
5.2 ログインモジュールの実装
これは主に、ログイン前のログイン インターフェイスとログイン後のユーザー機能インターフェイスの 2 つの部分で構成されます。ログイン インターフェイスでは、ユーザーはユーザー名とパスワードを入力する必要があります。ユーザー名またはパスワードのいずれかが空の場合は、「ユーザー名とパスワードを空にすることはできません」というプロンプトが表示されます。ユーザー名とパスワードを取得したら、データベースで検索し、ユーザー名が存在し、対応するパスワードが正しければログイン成功、そうでなければログイン失敗となります。ログインに失敗すると、プロンプトが表示され、テキスト ボックスでフォーカスが停止します。ログインに成功すると、セッションのグローバル変数 username がそのユーザー名に設定されます。ログインに成功したら、メンバー機能モジュールに入ります。このモジュールには、主に基本的なメンバー情報の変更、リリースされたルーム情報の管理、情報のリリース、および終了の機能が含まれます。終了機能は、グローバル変数 username の値をクリアし、ホームページに戻ることです。
ログインのフローチャートを以下に示します。
図 5-1 ログインのフローチャート
ユーザーのログイン インターフェイスを次の図に示します。
図 5-2 ユーザーのログイン インターフェイス
ユーザーログイン用のキーコードは以下のとおりです。
/**
* ログイン
* @paramデータ
* @param httpServletRequest
* @戻る
*/
@PostMapping("ログイン")
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 用户资料修改模块的实现
用户登录/注册成功之后可以修改自己的基本信息。修改页面的表单中每一个input的name值都要与实体类中的参数相匹配，在用户点击修改页面的时候，如果改后用户名与数据库里面重复了，页面会提示该用户名已经存在了，否则通过Id来查询用户，并将用户的信息修改为表单提交的数据。
5.4 仓库信息管理模块的实现
如果仓库信息需要修改，管理员可以通过查询资产的基本信息来查询，查询资产信息是通过ajax技术来进行查询的，需要资产编号、资产名称等参数然后在返回到该页面中,可以选中要修改或删除的那条信息，如果选中了超过一条数据，页面会挑一个窗口提醒只能选择一条数，如果没有选中数据会挑一个窗口题型必须选择一条数据。当选择确认修改的时候，后台会根据传过来的id到数据库查询，并将结果返回到修改页面中，可以在修改页面中修改刚刚选中的信息当点击确认的时候from表单会将修改的数据提交到后台并保存到数据库中，就是说如果提交的数据数据库中存在就修改，否则就保存。
仓库信息添加界面如下图所示。
图5-3仓库信息添加界面
仓库信息管理界面如下图所示。
图5-4仓库信息管理界面
仓库信息发布的关键代码如下。
@PostMapping("/add")
@Transactional
public Map<String, Object> add(HttpServletRequest request) throws IOException {
service.insert(service.readBody(request.getReader()));
return success(1);
}
@Transactional
public Map<String, Object> addMap(Map<String,Object> map){
service.insert(map);
return success(1);
}
5.5 借用申请模块的实现
借用申请功能需要考虑高并发，防止出现资产重复借用、资产状态显示出错等情况，特对资产这一共享数据增加锁机制。在乐观锁、悲观锁以及线程锁中，综合考虑性能效率和错误的可接受性选择了乐观锁机制。乐观锁的实现方式是使用版本标识来确定读到的数据与提交时的数据是否一致，提交后修改版本标识，不一致时可以采取丢弃和再次尝试的策略。在数据库资产表（对应资产实体）设计中增加了version字段，每次数据提交时（更改资产状态）会判断version是否匹配，若不匹配停止本次提交，若匹配则提交成功并增加version的值。
借用申请功能整体流程：用户浏览资产信息时，同时会显示资产的状态，系统会在其显示详细信息的页面时便会判断资产的状态，若资产状态为可借用，则会显示借用的链接按钮。在用户点击借用按钮时，会先通过拦截器判断用户是否登录，若未登录，会跳转至登录页面，提示用户先登录，若为登录用户就会跳转至填写借用信息的页面，填写好借用信息之后，点击提交按钮，借用成功之后返回提示信息，告知用户借用成功。
资产借用流程图如下图所示。
图5-5资产借用流程图
资产借用界面如下图所示。
图5-6资产借用界面
借用管理界面如下图所示。
图5-7借用管理界面
资产借用关键代码如下。
@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);
}
}
5.6归还信息模块的实现
归还信息功能整体流程：用户进行资产归还操作时，点击归还申请后按照提示进行归还申请提交。在用户点击归还申请提交时，会先通过拦截器判断用户是否登录，若未登录，会跳转至登录页面，提示用户先登录，若为登录用户就会跳转至填写归还申请的页面，填写好归还信息之后，点击提交按钮。
归还信息流程图如下图所示。
图5-8归还信息流程图
归还信息界面如下图所示。
图5-9归还信息界面
归还信息添加关键代码如下。
@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);
}
5.7 报修信息管理模块的实现
此页面的关键是编写报修信息，包括报修信息编号，资产名称，资产编号等。单击提交按钮以完成信息的添加。如果未写入完整的报修信息，例如，如果未写入资产编号，系统将给出相应的错误提示，并且无法成功输入。数据以概念的形式以onsubmit =“return checkForm（）”的形式写入以进行检查，checkForm（）函数是一种用于写入数据的不同类型的校对方法，是不是为空也是经过form表单中的οnsubmit=”return checkForm()来检查。
管理员点击左侧菜单“报修信息管理”，页面跳转到报修信息管理外观，调用后台查询所有报修信息。
报修信息管理流程图如下图所示。
图5-10报修信息管理流程图
报修信息添加界面如下图所示。
图5-11报修信息添加界面
报修信息管理界面如下图所示。
图5-12报修信息管理界面
报修信息发布的关键代码如下。
@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);
}
5.8报废申请管理模块的实现
根据需求，需要对资产进行报废。新增报废申请时，点击报废链接按钮时，请求到达后台，还会先查询资产状态再次做出判定能否进行报废添加。填写好报废申请信息后，数据提交到后台会对数据库中相应的记录做出修改。
报废申请管理流程图如下图所示。
图5-13报废申请管理流程图
报废申请添加页面设计效果如下图所示。
图5-14报废申请添加界面
报废申请管理页面效果如下图所示。
图5-15报废申请管理界面
报废申请发布的关键代码如下。
public Map<String, Object> success(Object o) {
Map<String, Object> map = new HashMap<>();
if (o == null) {
map.put("result", null);
return map;
}
if (o instanceof List) {
if (((List) o).size() == 1) {
o = ((List) o).get(0);
map.put("result", o);
}else {
String jsonString = JSONObject.toJSONString(o);
JSONArray objects = service.covertArray(JSONObject.parseArray(jsonString));
map.put("result", objects);
}
} else if (o instanceof Integer || o instanceof String) {
map.put("result", o);
} else {
String jsonString = JSONObject.toJSONString(o);
JSONObject jsonObject = JSONObject.parseObject(jsonString);
JSONObject j = service.covertObject(jsonObject);
map.put("result", j);
}
return map;
}
第6章 系统测试
6.1 测试目的
对任何系统而言，测试都是必不可少的环节，测试可以发现系统存在的很多问题，所有的软件上线之前，都应该进行充足的测试之后才能保证上线后不会Bug频发，或者是功能不满足需求等问题的发生。下面分别从单元测试，功能测试和用例测试来对系统进行测试以保证系统的稳定性和可靠性。
6.2 功能测试
下表是系统登录功能测试用例，检测了用户名和密码的不同的输入情况，观察系统的响应情况。得出该功能达到了设计目标。
表6-1 系统登录功能测试用例
| 功能描述 |
用于系统登录 |
|
| 测试目的 |
检测登录时的合法性检查 |
|
| 测试数据以及操作 |
预期结果 |
实际结果 |
| 输入的用户名和密码带有非法字符 |
提示用户名或者密码错误 |
与预期结果一致 |
| 输入的用户名或者密码为空 |
提示用户名或者密码错误 |
与预期结果一致 |
| 输入的用户名和密码不存在 |
提示用户名或者密码错误 |
与预期结果一致 |
| 输入正确的用户名和密码 |
登录成功 |
与预期结果一致 |
下表是注册功能测试用例，检测了各种数据的输入情况，观察系统的响应情况。得出该功能达到了设计目标。
表6-2 注册功能测试用例
| 功能描述 |
用于用户注册 |
|
| 测试目的 |
检测用户注册时的合法性检查 |
|
| 测试数据以及操作 |
预期结果 |
实际结果 |
| 输入的手机号不合法 |
提示请输入正确的手机号码 |
与预期结果一致 |
| 输入的字段为空 |
提示必填项不能为空 |
与预期结果一致 |
| 输入的密码少于6位 |
提示密码必须为6-12位 |
与预期结果一致 |
| 输入的密码大于12位 |
提示密码必须为6-12位 |
与预期结果一致 |
下表是资产管理功能的测试用例，检测了资产管理中对资产信息的增加，删除，修改，查询操作是否成功运行。观察系统的响应情况，得出该功能也达到了设计目标，系统运行正确。
前置条件；用户登录系统。
表6-3 资产管理的测试用例
| 功能描述 |
用于资产管理 |
|
| 测试目的 |
检测资产管理时的各种操作的运行情况 |
|
| 测试数据以及操作 |
预期结果 |
实际结果 |
| 点击添加资产，必填项合法输入，点击保存 |
提示添加成功 |
与预期结果一致 |
| 点击添加资产，必填项输入不合法，点击保存 |
提示必填项不能为空 |
与预期结果一致 |
| 点击修改资产，必填项修改为空，点击保存 |
提示必填项不能为空 |
与预期结果一致 |
| 点击修改资产，必填项输入不合法，点击保存 |
提示必填项不能为空 |
与预期结果一致 |
| 点击删除资产，选择资产删除 |
提示删除成功 |
与预期结果一致 |
| 点击搜索资产，输入存在的资产名 |
查找出资产 |
与预期结果一致 |
| 点击搜索资产，输入不存在的资产名 |
不显示资产 |
与预期结果一致 |
下表是借用申请管理功能的测试用例，检测了借用申请管理中借用申请单的操作是否成功运行。观察系统的响应情况，得出该功能也达到了设计目标，系统运行正确。
前置条件；用户登录系统。
表6-4 借用申请管理的测试用例
| 功能描述 |
用于借用申请管理 |
|
| 测试目的 |
检测借用申请管理时各种操作的情况 |
|
| 测试数据以及操作 |
预期结果 |
实际结果 |
| 未填写资产信息，点击提交 |
提示请填写资产信息 |
与预期结果一致 |
| 未输入数量，点击提交 |
提示请输入数量 |
与预期结果一致 |
| 未输入借用原因，点击提交 |
提示请输入借用原因 |
与预期结果一致 |
6.3 性能测试
使用阿里云PTS（Performance Testing Service）性能测试服务对线上系统进行压力测试。线上服务器环境为：1核心CPU，1G内存，1Mbps公网带宽，Centos7.0操作系统。
压测过程中使用了2台并发机器，每台机器20个用户并发，对系统主页，登录，数据查询和数据维护等模块进行并发访问，测试结果是有40个用户并发时，数据管理相关页面的响应时间甚至达到了7s，通过查看服务器出网流量发现已经达到1381kb/s，可以看出服务器的带宽已经达到峰值，如果系统使用5Mbps的带宽，系统的响应时间和TPS将会大大增加。在整个测试的过程中，CPU的使用率占用仅8%，也提现出带宽瓶颈对系统的影响非常严重。
第7章 总结与展望
随着计算机互联网技术的迅猛发展，各行各业都已经实现采用计算机相关技术对日益放大的数据进行管理。该课题是酒店资产管理为核心展开的。酒店资产管理系统的开发是以Java编程语言作为基础，在Myeclipse平台上完成编码工作，系统整体为B/S架构，数据库系统使用Mysql。文中详细分析了酒店资产管理系统的研究背景、研究目的和意义、开发工具和相关技术以及系统需求、系统详细设计和系统测试等等一系列内容。系统实现了酒店资产管理系统所需的一些基本功能，并通过测试对这些实现的功能进行了完善，进而提高了系统整体的实用性。整个系统的开发过程中大量使用了Java相关的知识以及前端开发使用的html和javascript等，同时涉及到了很多开源框架和组件，例如后台系统中运用的MVC架构、Freemarker模板引擎等，前端运用的UI框架等。
系统投入运行时，各功能均运行正常。系统的每个界面的操作符合常规逻辑，对使用者来说操作简单，界面友好。整个系统的各个功能设计合理，体现了人性化。
但是由于自己在系统开发过程中对一些用到的相关知识和技术掌握不够牢固，再加上自身开发经验欠缺，因此系统在有些方面的功能还不够完善，考虑的不够全面，因此整个系统还有待日后逐步完善。
参考文献
[1]张浩.SSM框架在Web应用开发中的设计与实现研究[J].电脑知识与技术,2023,19(08):52-54.
[2]吴昊.信息化时代下通信企业固定资产管理系统设计探讨[J].经济师,2023(03):50-51.
[3]张晓娜.固定资产管理系统在企业资产管理中的应用研究[J].老字号品牌营销,2023(04):136-138.
[4]郭志英.基于Web的酒店管理系统的设计与实现[J].长江信息通信,2022,35(12):120-123.
[5]宋式斌,袁启龙. 基于物联网技术的信息化资产管理系统建设探索[C]//中国计算机用户协会网络应用分会.中国计算机用户协会网络应用分会2022年第二十六届网络新技术与应用年会论文集.中国计算机用户协会网络应用分会2022年第二十六届网络新技术与应用年会论文集,2022:366-370.
[6]赵静.基于SSM+VUE框架的企业合规管理系统[J].数字通信世界,2022(11):17-19.
[7]于盛洋.智慧酒店管理系统设计与实现——基于RFID模块[J].产业科技创新,2022,4(02):37-40.
[8]岳颖颖.基于Web酒店管理系统设计分析[J].电子技术与软件工程,2021(17):196-197.
[9]朱云杰.翼云居酒店管理系统前置服务设计[J].电子元器件与信息技术,2021,5(06):182-185.
[10]王磊. 基于J2EE平台酒店资产管理系统设计与实现[D].电子科技大学,2019.
[11]梁新月,张伟.基于物联网的酒店固定资产管理系统研究[J].物联网技术,2019,2(12):63-64+68.
致谢
本次设计历时3个月。在这个毕业设计中，它离不开指导教师的指导，使事情基本顺利。指导老师无论是在毕业设计历经中，还是在论文做完中都给了了我特别大的助益。另1个方面，教师认真负责的工作姿态，谨慎的教学精神厚重的理论水准都使我获益匪浅。他勤恳谨慎的教学育人学习姿态也给我留下了特别特别深的感觉。我从老师那里学到了很多东西。在理论和实践中，我的技能得到了特别大的提高。在此，特向教师表示由衷的感激。
经过对该毕业设计的全部研究和开发，我的系统研发经历了从需求分析到实现详细功能，再到最终测试和维护的特殊进展。让我对系统研发有了更深层次的认识。如今我的动手本领单独处理疑惑的本领也获取到了特别大的演练学习增多，这是这次毕业设计最好的收获。
最后，在整个系统开发过程中，我周围的同学和朋友给了我很多意见，所以我很快就确认了系统的商业思想。在次，我由衷的向他们表示感激。