ssm 私立歯科医院ケース管理システム卒業プロジェクトの設計と実装 - ソース コード 071128

目次

まとめ

1はじめに

1.1システム開発のプロジェクト背景

1.2システム開発の目的

1.3論文構成と章の配置

2私立歯科医院の症例管理システム分析 

2.1実現可能性の分析

2.2システムフロー解析

2.2.1データ追加処理

2.2.2データ変更プロセス_

2.2.3データ削除プロセス_

2.3システム機能の分析

2.3.1機能分析

2.3.2非機能分析

2.4システムのユースケース分析

2.5この章の概要

3私立歯科医院における症例管理の全体設計

3.1システムアーキテクチャ設計

3.2システム機能モジュールの設計

3.2.1全体的な機能モジュール設計

3.2.2ユーザーモジュールの設計

3.2.3コメント管理モジュールの設計

3.2.4部門情報管理モジュールの設計

3.2.5登録情報管理モジュールの設計

3.3データベース設計

3.3.1データベースの概念構造設計

3.3.2データベースの論理構造設計

3.4この章の概要

4民間歯科医院における症例管理の詳細設計と導入 

4.1ユーザー機能モジュール

4.1.1フロントページのインターフェース

4.1.2ユーザー登録インターフェース

4.1.3ユーザーログインインターフェース22

4.1.4掲示板インターフェース

4.1.5歯科情報インターフェース

4.1.6部門詳細インターフェース

4.3管理者機能モジュール

4.3.1サイト管理インターフェイス

4.3.2ユーザー管理インターフェース

4.3.3歯科情報インターフェース

4.3.4追加の管理インターフェイス

5システムテスト31

5.1システムテストの目的31

5.2システムテストケース31

5.3システムテスト結果32

結論33

参考文献34

ありがとう  

まとめ

情報化社会においては、ターゲットを絞った情報入手経路が求められますが、基本的には経路の拡大が人々の目指す方向であり、視点の偏りにより、得られる情報の種類が異なることが多くなり、それもまた問題です。克服するのが最も難しいテクノロジーのトピックです。個人歯科医院におけるケースマネジメントなどの課題に着目し、個人歯科医院におけるケースマネジメントに関する調査・分析を行い、問題解決に向けた個人歯科医院におけるケースマネジメントの開発・設計を行います。

個人歯科医院の症例管理の主な機能モジュールには、ユーザー管理、部門センター、予約情報、登録情報、課金情報、症例情報、メッセージ情報、薬剤管理、記録の追加、販売記録が含まれており、オブジェクト指向開発モデルを採用しています。ソフトウェア開発. 開発とハードウェアのインストールは実際の使用のニーズに十分に応えることができ、それに対応するソフトウェアのインストールとプログラムのコーディング作業が改善されました. MySQL がバックグラウンド データの主記憶装置として使用され、SSM フレームワーク、JAVA テクノロジー、 Ajax技術は業務に活用されており、システムのコーディングと開発によりシステムのあらゆる機能を実現しています。この報告書はまず研究の背景、機能、意義を分析し、研究作業の合理性の基礎を築きます。個人歯科医院における症例管理のニーズと技術的問題を分析し、システムの必要性と技術的実現可能性を証明した後、設計システムで使用する必要がある技術ソフトウェアと設計思想の基本を紹介し、最終的に実現しました私立歯科クリニックの症例管理と展開の実行に使用されます。

キーワード:SSMテクノロジー、MYSQL、私立歯科医院の症例管理

概要

情報化社会においては、対象を絞った情報アクセスが求められていますが、アクセスの拡大は基本的に人々の努力の方向です。視点のズレにより、人は異なる種類の情報を取得することが多くなりますが、これはテクノロジーが克服するのが最も難しい課題でもあります。個人歯科医院における症例管理の問題を目指して,本論文は個人歯科医院における症例管理を研究,分析し,次に問題を解決するための個人歯科医院における症例管理を開発,設計する。

個人歯科医院における症例管理の主な機能モジュールには、ユーザー管理、部門センター、予約情報、登録情報、課金情報、症例情報、メッセージ情報、薬剤管理、記録の追加、記録の販売が含まれます。ソフトウェア開発とハードウェア構築にはオブジェクト指向開発モードが採用されており、実際の使用ニーズを十分に満たし、対応するソフトウェア構築とプログラムコーディングを改善できます。MySQL はバックグラウンドデータの主記憶装置として使用され、SSM フレームワーク、業務システムのコーディング・開発にはJava技術とAjax技術が使用され、システムのすべての機能が実現されます。この報告書はまず、研究作業の合理性の基礎を築く研究の背景、機能、意義を分析します。本稿では、私立歯科医院における症例管理のさまざまなニーズと技術的問題を分析し、システムの必要性と技術的実現可能性を証明し、その後、システムの設計に必要な技術的ソフトウェアと設計思想について基本的に紹介します。最後に、症例管理と民間歯科医院の展開を実現します。

キーワード: SSM テクノロジー; MYSQL;民間歯科医院における症例管理

1はじめに

病院情報システム(HIS)は、私立歯科医院の近代化のための重要な基本プロジェクトであり、私立歯科医院の症例管理レベル、医療レベル、業務運営効率およびサービス品質を向上させるために必要な手段です。診療所の情報利用ニーズに応えるため、個人の歯科医院における患者の医療情報、財務会計分析情報、予約情報などのデータを収集、保存、処理、抽出、通信するためにコンピュータおよびネットワーク通信機器を使用するコンピュータアプリケーションソフトウェアを指します。すべての許可されたユーザー システム。

1.1システム開発のプロジェクト背景

 コンピュータ産業の急速な発展に伴い、電子コンピュータは情報管理、ワードプロセッサ、設計支援、教育支援、および人々の日常生活に広く使用されています。歯科医院管理システムは、主に各病院の外来管理における一連の関連業務を管理することを目的としており、このシステムの構築により歯科医院の管理がより標準化・体系化され、問い合わせ方法もより便利になりました。同時に、このシステムはオブジェクト指向開発手法を採用しており、構造化パラダイムにおけるソフトウェアの再利用率の低さやソフトウェア製品のメンテナンスの困難さの問題をさらに解決します。

近年、受診する患者数が徐々に増加しており、手書きのデータでは膨大なデータを扱うことができなくなってきました。情報化時代の効率化に適応するためには、歯科医院管理システムの業務をコンピュータで実現するシステムの誕生が必要です。これに基づいて設計された歯科医院管理システムを使用して医院を管理し、管理プロセス全体が効率的かつ正確に最短時間で完了できるようにします。

上記の理解に基づいて、関連情報とデータを収集し、関連文献と技術パラメータを参照し、ユーザーのニーズを調査し、最近採用された手動記録方法は管理の対象が多岐にわたり、データの保存が容易ではないことを確認します。何万もの情報と書類の山は管理者にとって負担であり、大量の文書化が必要です。ただし、このプロセスに合わせて設計された一部の診療所管理システム ソフトウェアは、ソフトウェアの再利用の程度が低く、ソフトウェア製品の保守が容易ではありません。上記の理由から、歯科医院の経営にはデータを管理するためのオブジェクト指向設計ソフトウェアが急務となっています。

現代の経営におけるコンピュータ技術の応用により、リーダーやマネージャーにとってコンピュータは現代のテクノロジーを適用するための重要なツールとなっています。コンピュータを利用した外来管理活動により、管理者の情報収集および処理能力が大幅に向上し、管理者によるタイムリーな意思決定に役立ちます。コンピュータシステムは、管理プロセスの変更に応じて元のデータと資料を処理および保存することができ、管理担当者が特定の問題を解決するために情報と資料が必要な場合、いつでも検索して問い合わせることができ、全体の動的な状況を把握できます。歯科医院管理システムを導入し、ダイナミックな管理を行うことで、歯科医院の経営を効率的に処理し、歯科医院経営の自動化を実現し、効率化を実現します。

1.2 システム開発の目的

歯科医院管理システムの開発目的は、歯科医院管理システムのモードをマニュアル記録から情報管理へ、プロセス指向開発ソフトウェアからオブジェクト指向開発ソフトウェアへ変更し、外来経営者やソフトウェア保守スタッフの利便性を提供することです。ユーザーの実態を調査し、詳細な需要分析を行い、既存の管理モデルを改善し、新しいオブジェクト指向管理システムを開発することで、システム開発の考え方を理解し、システム開発のプロセスと手法を習得します。外来情報システムの継続的な改善に伴い、病院経営は情報管理への依存度がますます高まっています。そこで、歯科医院の業務実態を重視したシステム開発を行い、さまざまな歯科医院のニーズに迅速に対応できるようにしていきます。

歯科医院管理システム実現の実際的な意義:経営医院のスタッフ数の削減、管理スタッフがいつでも閲覧・閲覧でき、より直観的であること、手作業による給与記録のやり方が変わったこと従来と異なり、コンピュータ入力がより速く、より便利になり、外来管理システムの電子化が実現しました。

個人歯科医院症例のデジタル構築の活発な発展に伴い、個人歯科医院症例のデジタル化の概念は大規模な個人歯科医院症例に広く受け入れられていますが、現在直面している主な問題は、デジタル個人歯科医院症例をどのように構築するかです。したがって、現時点では、我が国におけるデジタル私立歯科医院症例の構築は、医療のデジタル化、つまりデジタル管理の開発と私立歯科医院症例における医療活動に関連するさまざまな情報の総合的利用に焦点を当てなければなりません。診断・治療業務や医療行為のデジタル化を実現し、システムの自動化とオープン化を確保し、将来の地域医療への展開に向けた基盤を構築します。これに対応して、医療情報システムはデジタル歯科医院症例構築のシステム基盤であるため、純粋な医療活動のための各種医療情報システムとその統合研究にも研究の焦点が向けられることになる。医療のデジタル化を中心とした個人歯科医院のデジタル化事例の全体プランニングを、各種医療情報システムの有機的統合により実現します。新世代の医療情報システムは、「デジタル歯科医院症例」の構築において決定的な役割を果たすと言えます。

1.3 論文構成と章の配置

論文は抽象的な謝辞と参考文献を除いて階層的に構成され、本文では Web サイトの要件も分析し、一般的な設計と実装された機能を説明し、最後にいくつかの試運転記録をリストします。次のように:

第1章;序章。第 1 章では、主に対象研究の背景、システム開発の現状、本論文の研究内容と主な業務を紹介します。

第 2 章: システム要件の分析。第 2 章では、主にシステムの利用者と機能の側面から需要分析を行います。

第 3 章: システム設計。第 3 章では主にシステムフレーム、システム機能モジュール、データベースの機能設計を進めます。

第 4 章: システムの実現。第 4 章では主にシステムフレームワークの構築とシステムインターフェースの実現について紹介します。

第 5 章: システムのテスト。第 5 章では主にシステムのいくつかのインターフェイスをテストし、主要な機能をテストします。

第 6 章: 概要。

2 私立歯科医院における症例管理の分析

システム分析はプロジェクト開発の前提条件であり、システム分析を通じてシステムの主要ユーザーの基本的なニーズを十分に理解することができ、これがプロジェクト開発の理由でもあります。さらに、システム開発に関しては、通常、技術的実現可能性、経済的実現可能性などを含めた実現可能性分析が行われます。実現可能性分析は、プロジェクト全体の観点からの分析でもあります。次に、プロジェクトの特定のニーズを分析します。分析の手段は通常、ユーザーのユース ケース図を通じて実現されます。以下に詳しくご紹介します。

2.1実現可能性の分析

(1) 経済性:

プロジェクトで使用されるツールのほとんどは現在一般的なオープンソースで無料であるため、開発の初期段階ではプロジェクトに使用される資金が大幅に削減され、ソフトウェアの開発は開発期間中の資金の影響を受けません。プロジェクトの立ち上げ時期にあるため、経済的にはまだ実現可能です。ユーザーのニーズを満たすために、最小限のコストを使用するようにしてください。人件費や設備費に充てるための資金を節約します。ペーパーレス化と高効率化の道はますます進んでいきます。

したがって、経済的存続可能性については何の疑問もありません。

(2) 運用可能性:

このプロジェクトの設計では、このモードでの Web サイトのいくつかの開発事例を参照し、その操作インターフェイスを分析し、多くの事例を組み合わせて、基本的なコンピューターの知識を持つ人がこのプロジェクトを操作できるように、人間中心の操作と簡素化された操作を強調しています。

したがって操作性には問題ありません。

(3) 技術的な実現可能性:

技術的実現可能性とは、フレームワークの構築の実現可能性、より優れた技術が登場した場合のシステム技術のアップグレードの受け入れ可能性、および開発時間とコストの比率を指します。

既存の Java テクノロジーは、あらゆる電子商取引システムの構築に対応できます。この個人歯科医院の症例管理を開発するとき、私は Java + MYSQL を使用してプログラム全体を実行しました。

結論から言えば、技術的な実現可能性には問題はない。

(4) 法的実現可能性:

開発者の観点から見ると、Java と MYSQL はオープンソースであり、オンラインで無料であり、知的財産権に関して法的な紛争は発生しません。

ユーザー利用の観点からは、システム上で密輸品が販売されない限り、システム上で条約が締結され、違法な支払いは排除されます。

要約すると、法的な実現可能性に疑問はありません。

2.2 システムフロー解析

ビジネス プロセスは、特定の記号や線を使用して、ユーザーによるシステムの使用プロセスを示すものです。システム分析を実行する際、ビジネス プロセスは、開発者がビジネスをより深く理解し、エラーを発見し、システムを改善するのに役立ちます。

2.2.1 データ追加処理

ユーザーがシステムに正常にログインした、データを追加する操作が実現できます。追加するデータの数はシステムによって生成される特定の数であり、ユーザーが任意に入力することはできません。その数以外は、ユーザーが自由に入力できます。その他の追加情報をご自身で入力し、入力された情報がシステムによって検証され、正当であることが確認されます。合格はデータの追加が成功したことを示します。逆は、追加が成功しませんでした。図 2-1 は、データの追加が成功したことを示します。データを追加しています。

 

図 2-1 データ追加のフローチャート

2.2.2 データ変更プロセス

図 2-2に示すように、データ変更のプロセスは、上で説明したデータ追加のプロセスと同様です

 

図 2-2 データ変更のフローチャート

2.2.3 データ削除プロセス

システム内に不要なデータが存在する場合管理担当者はこれらのデータを削除することもできます (図2-3にデータ削除のフローチャートを示します)。

 

図 2-3 データ削除のフローチャート

2.3 システム機能の分析

2.3.1 機能分析

個人歯科医院の症例管理の役割に応じて、一般ユーザー管理モジュール、医師ユーザー管理モジュール、管理者管理モジュールの 3 つの部分に分けました。

ユーザー管理モジュール:

(1) ユーザー登録とログイン:ユーザーは個人歯科医院症例管理に会員登録しログインし、個人情報やパスワード変更などの個人情報の追加、削除、変更、確認を行います。

(3) 掲示板: ホームページのナビゲーション バーに「掲示板ニュース」のメニューが表示され、クリックして入力すると、バックグラウンドですべての管理者によって公開された掲示板情報が表示されます。

(4)歯科情報: ホームページのナビゲーションバーにメニューという情報歯科

(5)部門センター: ホームページのナビゲーション バーに「部門情報」のメニューが表示されます。クリックして入力すると、バックグラウンドですべての管理者によって公開された部門情報が表示されます。部門について知りたい場合は、「いいね!」+ブックマーク+登録+予約+コメントをしてください

(6) 私のお気に入り: 「私の」では、「私のお気に入り」情報を表示および管理でき、お気に入りを表示したり、お気に入り情報を削除したりすることもできます。

(6) マイアカウント: ユーザーが右上隅の「マイ」ボタンをクリックすると、サブメニューが表示されます。「マイアカウント」をクリックして、システムにログインするための個人情報とパスワードを設定します。

(7) パーソナル センター: ユーザーが右上隅の「マイ」ボタンをクリックすると、情報管理の対応する背景に入ります。

管理者管理モジュール:

(1) ログイン: 管理者のアカウントはデータテーブルに直接設定および生成され、登録は必要ありません。

(2) サイト管理: 「サイト管理」メニューをクリックすると、カルーセル マップ + 掲示板の 2 つのサブメニューが表示され、これら 2 つのモジュールの追加、削除、変更、確認ができます。

(3) ユーザー管理: 「ユーザー管理」メニューをクリックすると、管理者 + 医師ユーザー + 一般ユーザーの3 つの、これら3 つの

(4) コンテンツ管理: 「コンテンツ管理」メニューをクリックすると、歯科情報 + 歯科情報分類の2 つのサブメニューが表示されます。これにより、ユーザーがフロントデスクで提出した歯科情報を管理することができます。フロントデスクでの歯科情報の表示時間 機密情報の追加、削除、変更、照会。

(5) 詳細管理: 「詳細」メニューをクリックすると、 9 つの部門センター + 予約情報 + 登録情報 + 請求情報 + 症例情報 + メッセージ情報 + 薬剤管理 + レコードの追加 + 販売記録が表示さます9 つのモジュールを追加、削除、変更、確認できるメニュー

(6) モール管理:個人歯科医院の症例管理において、ユーザーから提出された全診療科、部門分類、オーダー情報を一括管理。

2.3.2 非機能分析

私立歯科医院における症例管理のセキュリティ、信頼性、パフォーマンス、スケーラビリティなど、私立歯科医院における症例管理の非機能要件。具体的には、次の表 3-1 で表すことができます。

3-1私立歯科医院における症例管理の非機能要件表

安全性

主に民間の歯科医院に症例管理データベースを導入することを指し、データベースの利用やパスワードの設定などは規定に従う必要があります。

信頼性

信頼性とは、個人歯科医院の症例管理がユーザーの指示に従って操作できることを意味し、テスト後の信頼性は90%以上です。

パフォーマンス

個人歯科医院の症例管理が市場を占有するにはパフォーマンスが必須条件であり、最高のパフォーマンスが最高です。

スケーラビリティ

たとえば、データベースは、システムの非機能要件を確実に満たすために、インターフェイスの使用などの複数の属性を予約します。

使いやすさ

利用者は個人歯科医院の症例管理ページに表示される内容に従うだけで済みます。

保守性

個人歯科医院における症例管理開発の保守性は非常に重要ですが、テスト後は保守性に問題はありません

2.4システムのユースケース分析

2.3 の機能の分析を通じて、この私立歯科医院における症例管理のユースケース図が得られます。

図 2-3 は、ユーザーの役割の例を示しています。

 

図 2-3 私立歯科医院におけるケース管理ユーザーの役割のユースケース図

管理者はウェブ上でバックグラウンド管理を行い、個人歯科医院全体の症例管理におけるすべてのデータ情報を維持します。医師ユーザーの役割の例を図 2-4 に示します。

                                           

 

図 2-4 私立歯科医院の症例管理における医師ユーザーの役割のユースケース図

管理者はウェブ上でバックグラウンド管理を行い、個人歯科医院全体の症例管理におけるすべてのデータ情報を維持します。図 2-5 は、管理者の役割の例を示しています。

 

図2-5 私立歯科診療所のケース管理管理者の役割のユースケース図

2.5 この章の概要

本章では主に、個人歯科医院症例管理の実現可能性分析、プロセス分析、機能要件分析、システムユースケース分析を通じて、個人歯科医院全体の症例管理において実現すべき機能を決定します。また、民間の歯科診療所における症例管理のためのコード実装とテストの標準も提供します。

3 私立歯科医院における症例管理の全体設計

この章では主に、個人歯科医院の症例管理の機能モジュール設計とデータベースシステム設計について説明します。

3.1システムアーキテクチャ設計

この個人歯科医院の症例管理は、アーキテクチャからプレゼンテーション層(UI)、ビジネスロジック層(BLL)、データ層(DL)の3層に分かれています。

                                      

 

図 3-1 私立歯科医院における症例管理システムのアーキテクチャ設計図

 

プレゼンテーション層 (UI): UI 層とも呼ばれ、主にこの私立歯科医院におけるケース管理の UI インタラクション機能を完成させます。優れた UI は、ユーザーのユーザー エクスペリエンスを向上させ、この層でケース管理を使用する際のユーザーの快適さを向上させることができます。プライベート歯科医院。UI インターフェイスの設計は、良好な互換性を実現するために、私立歯科医院の症例管理のさまざまなバージョンやさまざまなサイズの解像度にも適応する必要があります。UI インタラクション機能の要件は合理的であり、ユーザーはインタラクティブ操作を実行するときに一貫したインタラクション結果を取得する必要があります。これには、プレゼンテーション層とビジネス ロジック層の間の適切な接続が必要です。

ビジネス ロジック層 (BLL): 主に、この個人歯科医院における症例管理のデータ処理機能を完成させます。ユーザーがプレゼンテーション層から送信したデータは処理されてビジネスロジック層を介してデータ層に渡され、システムがデータ層から読み出したデータは処理されてビジネスロジック層を介してプレゼンテーション層に渡されます。

データ層(DL):この個人歯科医院の症例管理データはサーバー側のmysqlデータベースに置かれているため、サービス層に属する部分はビジネスロジック層に直接統合できるため、データ層のデータベースは、主にこの個人歯科診療所における症例管理のためのデータ保管および管理機能を完了します。

3.2システム機能モジュールの設計

3.2.1 全体的な機能モジュール設計

前章では、主にシステムの機能要件と非機能要件を分析し、要件に従ってこの個人歯科医院の症例管理におけるユースケースを分析しました。次に、この個人歯科医院の構造、主な機能、症例管理のデータベースの設計を開始します。私立歯科医院の症例管理は、前章の要件分析に基づいて得られ、その全体的な設計モジュール図を図 3-2 に示します。

 

図 3-2 私立歯科医院における症例管理の機能モジュール図

3.2.2ユーザーモジュールの設計

バックグラウンドマネージャーは、フロントデスクに登録されているユーザーの追加、削除、変更、確認を行うことができ、ユーザーモジュールの構成図は以下のとおりです。

 

図 3-3 メンバーユーザーモジュールの構成図

3.2.3コメント管理モジュールの設計

私立歯科医院の症例管理はコミュニケーションのためのオープン プラットフォームであり、会員ユーザーはプラットフォーム上でコミュニケーションをとることができ、ユーザー間の交流を増やすことができます。しかし同時に、メッセージの内容をより適切に規制し、管理者に不適切なコメントを削除する機能を与えるためには、メッセージ管理モジュールを設計する必要があり、具体的な構造図は次のとおりです。

 

図 3-4 メッセージモジュールの構成図

3.2.4部門情報管理モジュールの設計

個人歯科医院の症例管理には多くの部門情報を保存する必要があり、そのモジュール機能構造、具体的な構造図は次のとおりです。

 

図 3-5 部門モジュール構成図

3.2.5 登録情報管理モジュールの設計

私立歯科医院における症例管理の最も重要な機能の 1 つは予約を行うことであり、そのモジュール機能構造、具体的な構造図は次のとおりです。

 

図 3-5 登録情報モジュールの構成図

3.3 データベース設計

データベースの設計は、一般に要件分析、概念モデル設計、データベーステーブル構築の 3 つの主要なプロセスから構成されます。要件分析については前章で説明しましたが、概念モデル設計は概念モデルと論理構造設計の 2 つの部分に分かれます。

3.3.1データベースの概念的な構造設計

以下は、個人歯科医院全体の症例管理における主要なデータベース テーブルの ER エンティティ関係図です。

図 3-6 私立歯科医院の症例管理の一般的な ER 関係図

 

個人歯科医院の症例管理データベースの一般的な ER 関係図によると、個人歯科医院の症例管理には多くの ER 図が必要であると結論付けることができます。主なデータベースの ER モデル図をいくつか示します。

 

図 3-7 医師ユーザー ER 関係図

 

図3-8 予約情報のER関係図

 

図 3-9 事例情報の ER 関係図

 

図 3-10 メッセージ ER 関係図

3.3.2 データベースの論理構造設計

前セクションの個人歯科医院の症例管理における全体的な ER 関係図から、多くのデータ テーブルを作成する必要があると結論付けることができます。ここでは主に、いくつかの主要なデータベース テーブル構造設計をリストします。

sales_record テーブル:

名前

タイプ

長さ

nullではない

主キー

ノート

sales_record_id

整数

11

はい

はい

販売記録ID

薬剤名

可変長文字

64

いいえ

いいえ

薬剤名

薬剤の種類

可変長文字

64

いいえ

いいえ

薬の種類

用法と用量

可変長文字

64

いいえ

いいえ

投与量

販売済みドクター

整数

11

いいえ

いいえ

医者を売る

販売日

日にち

0

いいえ

いいえ

発売日

販売数量_

整数

11

いいえ

いいえ

販売数量

お勧め

整数

11

はい

いいえ

インテリジェントな推奨事項

作成時間

日付時刻

0

はい

いいえ

作成時間

更新時間

タイムスタンプ

0

はい

いいえ

更新時間

予約情報表:

名前

タイプ

長さ

nullではない

主キー

ノート

予約情報id

整数

11

はい

はい

予約情報ID

部署名

可変長文字

64

いいえ

いいえ

部署名

部門の種類

可変長文字

64

いいえ

いいえ

部門の種類

部門_医師

整数

11

いいえ

いいえ

科医師

勤務時間

可変長文字

64

いいえ

いいえ

労働時間

患者ユーザー

整数

11

いいえ

いいえ

患者ユーザー

ユーザー名

可変長文字

64

いいえ

いいえ

ユーザー名

ユーザーの性別

可変長文字

64

いいえ

いいえ

ユーザーの性別

ユーザー年齢

可変長文字

64

いいえ

いいえ

ユーザーの年齢

ユーザーアドレス

可変長文字

64

いいえ

いいえ

ユーザーアドレス

予約時間

日付時刻

0

いいえ

いいえ

予定

予定数

可変長文字

64

いいえ

いいえ

予約数

ユーザープロフィール

文章

0

いいえ

いいえ

疾患プロフィール

お勧め

整数

11

はい

いいえ

インテリジェントな推奨事項

作成時間

日付時刻

0

はい

いいえ

作成時間

更新時間

タイムスタンプ

0

はい

いいえ

更新時間

登録情報表:

名前

タイプ

長さ

nullではない

主キー

ノート

登録情報id

整数

11

はい

はい

登録情報ID

部署名

可変長文字

64

いいえ

いいえ

部署名

部門の種類

可変長文字

64

いいえ

いいえ

部門の種類

部門_医師

整数

11

いいえ

いいえ

科医師

勤務時間

可変長文字

64

いいえ

いいえ

労働時間

患者ユーザー

整数

11

いいえ

いいえ

患者ユーザー

ユーザー名

可変長文字

64

いいえ

いいえ

ユーザー名

ユーザーの性別

可変長文字

64

いいえ

いいえ

ユーザーの性別

ユーザー年齢

可変長文字

64

いいえ

いいえ

ユーザーの年齢

ユーザーアドレス

可変長文字

64

いいえ

いいえ

ユーザーアドレス

登録日

日にち

0

いいえ

いいえ

登録日

登録者数_人

可変長文字

64

いいえ

いいえ

登録番号

ユーザープロフィール

文章

0

いいえ

いいえ

疾患プロフィール

お勧め

整数

11

はい

いいえ

インテリジェントな推奨事項

作成時間

日付時刻

0

はい

いいえ

作成時間

更新時間

タイムスタンプ

0

はい

いいえ

更新時間

ordinary_users表:

名前

タイプ

長さ

nullではない

主キー

ノート

普通のユーザーID

整数

11

はい

はい

共通ユーザーID

ユーザー番号

可変長文字

64

はい

いいえ

ユーザーID

ユーザー名

可変長文字

64

いいえ

いいえ

ユーザー名

ユーザーの性別

可変長文字

64

いいえ

いいえ

ユーザーの性別

ユーザー年齢

可変長文字

64

いいえ

いいえ

ユーザーの年齢

検査状態

可変長文字

16

はい

いいえ

承認状況

お勧め

整数

11

はい

いいえ

インテリジェントな推奨事項

ユーザーID

整数

11

はい

いいえ

ユーザーID

作成時間

日付時刻

0

はい

いいえ

作成時間

更新時間

タイムスタンプ

0

はい

いいえ

更新時間

メッセージ情報表:

名前

タイプ

長さ

nullではない

主キー

ノート

メッセージ情報ID

整数

11

はい

はい

メッセージID

部署名

可変長文字

64

いいえ

いいえ

部署名

部門の種類

可変長文字

64

いいえ

いいえ

部門の種類

部門_医師

整数

11

いいえ

いいえ

科医師

メッセージユーザー

整数

11

いいえ

いいえ

メッセージユーザー

message_time

日付時刻

0

いいえ

いいえ

メッセージ時間

メッセージの内容

文章

0

いいえ

いいえ

メッセージ内容

お勧め

整数

11

はい

いいえ

インテリジェントな推奨事項

作成時間

日付時刻

0

はい

いいえ

作成時間

更新時間

タイムスタンプ

0

はい

いいえ

更新時間

medical_record_information表:

名称

类型

长度

不是null

主键

注释

medical_record_information_id

int

11

病历信息ID

department_name

varchar

64

科室名称

department_type

varchar

64

科室类型

department_doctor

int

11

科室医生

patient_user

int

11

患者用户

user_name

varchar

64

用户姓名

user_gender

varchar

64

用户性别

user_age

varchar

64

用户年龄

add_time

date

0

添加时间

medical_records

text

0

就诊病历

recommend

int

11

智能推荐

create_time

datetime

0

创建时间

update_time

timestamp

0

更新时间

doctor_user表:

名称

类型

长度

不是null

主键

注释

doctor_user_id

int

11

医生用户ID

doctor_job_number

varchar

64

医生工号

name_of_doctor

varchar

64

医生姓名

doctor_gender

varchar

64

医生性别

doctor_age

varchar

64

医生年龄

length_of_medical_service

varchar

64

从医时长

doctor_certificate

varchar

255

医生证件

examine_state

varchar

16

审核状态

recommend

int

11

智能推荐

user_id

int

11

用户ID

create_time

datetime

0

创建时间

update_time

timestamp

0

更新时间

department_center表:

名称

类型

长度

不是null

主键

注释

department_center_id

int

11

科室中心ID

department_name

varchar

64

科室名称

department_type

varchar

64

科室类型

department_doctor

int

11

科室医生

on_duty_time

varchar

64

在岗时间

number_of_reservations

int

11

可就诊数

doctor_picture

varchar

255

医生图片

doctor_profile

longtext

0

医生简介

hits

int

11

点击数

praise_len

int

11

点赞数

recommend

int

11

智能推荐

create_time

datetime

0

创建时间

update_time

timestamp

0

更新时间

charging_information表:

名称

类型

长度

不是null

主键

注释

charging_information_id

int

11

收费信息ID

department_doctor

int

11

科室医生

patient_user

int

11

患者用户

charge

int

11

收取费用

charge_date

date

0

收费日期

charging_content

text

0

收费内容

pay_state

varchar

16

支付状态

pay_type

varchar

16

支付类型

recommend

int

11

智能推荐

create_time

datetime

0

创建时间

update_time

timestamp

0

更新时间

drug_administration表:

名称

类型

长度

不是null

主键

注释

drug_administration_id

int

11

药品管理ID

drug_name

varchar

64

药品名称

drug_type

varchar

64

药品类型

quantity_of_drugs

int

11

药品数量

usage_and_dosage

varchar

64

用法用量

drug_picture

varchar

255

药品图片

drug_details

text

0

药品详情

recommend

int

11

智能推荐

create_time

datetime

0

创建时间

update_time

timestamp

0

更新时间

3.4本章小结

整个私人牙科诊所病例管理的需求分析主要对系统总体架构以及功能模块的设计,通过建立E-R模型和数据库逻辑系统设计完成了数据库系统设计。

4 私人牙科诊所病例管理详细设计与实现

私人牙科诊所病例管理的详细设计与实现主要是根据前面的私人牙科诊所病例管理的需求分析和私人牙科诊所病例管理的总体设计来设计页面并实现业务逻辑。主要从私人牙科诊所病例管理界面实现、业务逻辑实现这两部分进行介绍。

4.1用户功能模块

4.1.1 前台首页界面

当进入私人牙科诊所病例管理的时候,首先映入眼帘的是系统的导航栏,下面是轮播图以及系统内容,其主界面展示如下图4-1所示。

 

图4-1 前台首页界面图

4.1.2 用户注册界面

不是私人牙科诊所病例管理中正式会员的是可以在线进行注册的,如果你没有本私人牙科诊所病例管理的账号的话,添加“注册”,当填写上自己的账号+密码+确认密码+昵称+邮箱+手机号等后再点击“注册”按钮后将会先验证输入的有没有空数据,再次验证密码和确认密码是否是一样的,最后验证输入的账户名和数据库表中已经注册的账户名是否重复,只有都验证没问题后即可会员注册成功。其用用户注册界面展示如下图4-2所示。

 

图4-2 前台用户注册界面图

注册逻辑关键代码如下所示。

/**

     * 注册

     * @return

     */

    @PostMapping("register")

    public Map<String, Object> signUp(HttpServletRequest request) throws IOException {

        // 查询用户

        Map<String, String> query = new HashMap<>();

        Map<String,Object> map = service.readBody(request.getReader());

        query.put("username",String.valueOf(map.get("username")));

        List list = service.selectBaseList(service.select(query, new HashMap<>()));

        if (list.size()>0){

            return error(30000, "用户已存在");

        }

        map.put("password",service.encryption(String.valueOf(map.get("password"))));

        service.insert(map);

        return success(1);

}

    public Map<String,Object> readBody(BufferedReader reader){

        BufferedReader br = null;

        StringBuilder sb = new StringBuilder("");

        try{

            br = reader;

            String str;

            while ((str = br.readLine()) != null){

                sb.append(str);

            }

            br.close();

            String json = sb.toString();

            return JSONObject.parseObject(json, Map.class);

        }catch (IOException e){

            e.printStackTrace();

        }finally{

            if (null != br){

                try{

                    br.close();

                }catch (IOException e){

                    e.printStackTrace();

                }

            }

        }

        return null;

    }

    public void insert(Map<String,Object> body){

        E entity = JSON.parseObject(JSON.toJSONString(body),eClass);

        baseMapper.insert(entity);

        log.info("[{}] - 插入操作:{}",entity);

}

4.1.3 用户登录界面

私人牙科诊所病例管理中的前台上注册后的会员是可以通过自己的账户名和密码进行登录的,当会员输入完整的自己的账户名和密码信息并点击“登录”按钮后,将会首先验证输入的有没有空数据,再次验证输入的账户名+密码和数据库中当前保存的用户信息是否一致,只有在一致后将会登录成功并自动跳转到私人牙科诊所病例管理的首页中;否则将会提示相应错误信息,用户登录界面如下图4-3所示。

 

图4-3用户登录界面图

登录系统主要代码如下。

/**

     * 登录

     * @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;

}

4.1.4公告栏界面

当点击导航栏上的“公告栏”的时候,就会进入对应的界面查看公告信息,公告栏界面如下图4-5所示。

 

图4-4公告栏界面图

4.1.5 牙科资讯界面

用户在点击导航栏上面的牙科资讯后,就可以搜索查看牙科资讯信息,用户根据自己的喜好可以进行查询、评论,牙科资讯界面如下图4-5所示。

 

图4-5牙科资讯界面图

4.1.6 科室详情界面

当访客点击了任意科室后将会进入该科室的详情界面,可以了解到该科室的科室名称、科室类型、科室医生、在岗时间、可就诊数等,同时可以对该科室进行留言购+收藏+点赞+挂号+预约+评论,科室详情展示页面如图4-6所示。

 

图4-6 科室详情界面图

4.2管理员功能模块

4.2.1 站点管理界面

私人牙科诊所病例管理中的管理人员在“站点管理”这一菜单中是可以对前台显示的轮播图以及公告栏进行管控。界面如下图4-7所示。

 

图4-7站点管理界面图

站点管理关键代码如下所示。

@RequestMapping(value = "/del")

    @Transactional

    public Map<String, Object> del(HttpServletRequest request) {

        service.delete(service.readQuery(request), service.readConfig(request));

        return success(1);

}

4.2.2 用户管理界面

私人牙科诊所病例管理中的管理人员是可以对前台注册的用户、医生用户进行管理的,也可以对管理员进行管控。界面如下图4-8所示。

 

图4-8用户管理界面图

用户管理关键代码如下所示。

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;

}

4.2.3 牙科资讯界面

私人牙科诊所病例管理中管理人员是可以对私人牙科诊所病例管理内的牙科资讯信息进行维护和管理的。牙科资讯界面如下图4-9所示。

 

图4-9牙科资讯界面图          

4.2.4 更多管理界面

私人牙科诊所病例管理中的管理人员在“更多管理”这一菜单下是可以对私人牙科诊所病例管理内的科室信息、挂号信息、预约信息、留言信息、药品管理、收费信息、售出记录、添加记录、病例信息进行管控的,其管理界面如下图4-10所示。

 

图4-11更多管理界面图               

5系统测试

5.1系统测试的目的

系统开发到了最后一个阶段那就是系统测试,系统测试对软件的开发其实是非常有必要的。因为没什么系统一经开发出来就可能会尽善尽美,再厉害的系统开发工程师也会在系统开发的时候出现纰漏,系统测试能够较好的改正一些bug,为后期系统的维护性提供很好的支持。通过系统测试,开发人员也可以建立自己对系统的信心,为后期的系统版本的跟新提供支持。

5.2 系统测试用例

系统测试包括:用户登录功能测试、科室展示功能测试、科室添加、科室搜索、密码修改功能测试,如表5-1、5-2、5-3、5-4、5-5所示:

用户登录功能测试:

表5-1 用户登录功能测试表

用例名称

用户登录系统

目的

测试用户通过正确的用户名和密码可否登录功能

前提

未登录的情况下

测试流程

1) 进入登录页面

2) 输入正确的用户名和密码

预期结果

用户名和密码正确的时候,跳转到登录成功界面,反之则显示错误信息,提示重新输入

实际结果

实际结果与预期结果一致

科室查看功能测试:

表5-2 科室查看功能测试表

用例名称

科室查看

目的

测试科室查看功能

前提

用户登录

测试流程

点击科室列表

预期结果

可以查看到所有科室信息

实际结果

实际结果与预期结果一致

管理员添加科室界面测试:

表5-3 管理员添加科室界面测试表

用例名称

科室发布测试用例

目的

测试科室发布功能

前提

员工用户正常登录情况下

测试流程

1)员工点击科室信息管理就,然后点击添加后并填写信息。

2)点击进行提交。

预期结果

提交以后,页面首页会显示新的科室信息 

实际结果

实际结果与预期结果一致

科室搜索功能测试:

表5-4科室搜索功能测试表

用例名称

科室搜索测试

目的

测试科室搜索功能

前提

测试流程

1)在搜索框填入搜索关键字。

2)点击搜索按钮。

预期结果

页面显示包含有搜索关键字的科室

实际结果

实际结果与预期结果一致

密码修改功能测试:

表5-5 密码修改功能测试表

用例名称

密码修改测试用例

目的

测试管理员密码修改功能

前提

管理员用户正常登录情况下

测试流程

1)管理员密码修改并完成填写。

2)点击进行提交。

预期结果

使用新的密码可以登录

实际结果

实际结果与预期结果一致

5.3 系统测试结果

通过编写私人牙科诊所病例管理的测试用例,已经检测完毕用户登录模块、科室查看模块、科室添加模块、科室搜索模块、密码修改功能测试,通过这5大模块为私人牙科诊所病例管理的后期推广运营提供了强力的技术支撑。

结论

至此,私人牙科诊所病例管理已经结束,在开发前做了许多的准备,在本系统的设计和开发过程中阅览和学习了许多文献资料,从中我也收获了很多宝贵的方法和设计思路,对系统的开发也起到了很重要的作用,系统的开发技术选用的都是自己比较熟悉的,比如Web、Java技术、MYSQL,这些技术都是在以前的学习中学到了,其中许多的设计思路和方法都是在以前不断地学习中摸索出来的经验,其实对于我们来说工作量还是比较大的,但是正是由于之前的积累与准备,才能顺利的完成这个项目,由此看来,积累经验跟做好准备是十分重要的事情。

当然在该系统的设计与实现的过程中也离不开老师以及同学们的帮助,正是因为他们的指导与帮助,我才能够成功的在预期内完成了这个系统。同时在这个过程当中我也收获了很多东西,此系统也有需要改进的地方,但是由于专业知识的浅薄,并不能做到十分完美,希望以后有机会可以让其真正的投入到使用之中。

参考文献

[1]陈燕帆,官文兵. 一种关于mysql数据库的本地用户访问审计方法[P]. 广东省:CN114328455A,2022-04-12.

[2]王春丽.基于SSM框架的会议管理信息系统设计与实现[J].电脑编程技巧与维护,2022(03):83-85.DOI:10.16184/j.cnki.comprg.2022.03.016.

[3]戴靓婕.MySQL数据库在自动测试系统中的应用研究[J].长江信息通信,2022,35(03):162-164.

[4]王常珏,段尧清,朱泽.基于SSM的政府数据治理联盟链框架构建[J/OL].情报科学:1-18[2022-04-21].http://kns.cnki.net/kcms/detail/22.1264.g2.20220309.1213.002.html

[5]吴明阳,王森琛.基于SSM框架整合的客户服务系统设计和实现[J].新型工业化,2022,12(02):12-15.DOI:10.19335/j.cnki.2095-6649.2022.02.005.

[6]张文慧,王国田,陈永,温禾,袁涛,艾显威.基于SSM框架城市水体治理工程案例信息系统设计与实现[J].软件,2022,43(02):83-88+92.

[7]李双,郭晨晨,李佳虎,张慧娥.基于SSM框架的智能驾校系统的设计与开发[J].电脑知识与技术,2022,18(03):62-63+65.DOI:10.14004/j.cnki.ckt.2022.0150.

[8]王慧芳,孙方,陈玉,朱茜.基于SSM框架的大数据个性化推荐系统设计[J].信息与电脑(理论版),2022,34(02):90-92.

[9]郭静.基于SSM框架的高校新生预报到系统的设计与实现[J].电子技术与软件工程,2022(02):232-235.

[10]徐旭,李明明,夏辉,陈曦,王天宇,肖硕,雍旭.基于SSM框架的互联网+多元监管下构建医疗设备质量控制管理服务平台研究[J].中国医学装备,2021,18(12):106-110.

[11]张洁,张圆梦.基于改进F-AHP的牙科诊所选址合理性研究[J].经营与管理,2022(01):78-84.DOI:10.16517/j.cnki.cn12-1034/f.2022.01.006.

[12]师晨昊,宋谊深,师悦祺,张馨月. 一种用于牙科诊所的电脑管理系统[P]. 河北省:CN213122754U,2021-05-04.

[13]吴晓旭.经济背景下牙科诊所信息系统的分析与设计[J].营销界,2020(35):182-184.

[14]Khan Mahnoor,Soltau Rhea,Sea Juehwan,Sofjan Amelia K. 2078. Patterns, Indications, and Appropriateness of Antibiotics Prescribed at a Private Dental Practice[J]. Open Forum Infectious Diseases,2019,6(Supplement2).

[15]Nikolaus Palmer,Henry Clover. A Pilot Study to Investigate Antibiotic Prescribing in Private Dental Practice in the UK[J]. Primary Dental Journal,2019,8(1).

[16]Jean Gillian,Holden Alexander C L,Tennant Marc,Kruger Estie. Infection Control Standards in Private Dental Practice - The Role of Accreditation.[J]. Journal of law and medicine,2018,25(4).

[17]肖睿,程宁,田崇峰,金志雄,杜毅. MySQL数据库应用技术及实战[M].人民邮电出版社:, 201801.177.

[18]罗蓓蕾. K公司在中国私立牙科诊所的营销策略研究[D].上海交通大学,2017.DOI:10.27307/d.cnki.gsjtu.2017.001276.

致  谢

逝者如斯夫,不舍昼夜。转眼间,大学生会员活便已经接近尾声,人面对着离别与结束,总是充满着不舍与茫然,我亦如此,仍记得那年秋天,我迫不及待的提前一天到了学校,面对学校巍峨的大门,我心里充满了期待:这里,就是我新生活的起点吗?那天,阳光明媚,学校的欢迎仪式很热烈,我面对着一个个对着我微笑的同学,仿佛一缕缕阳光透过胸口照进了我心里,同时,在那天我认识可爱的室友,我们携手共同度过了这难忘的两年。如今,我望着这篇论文的致谢,不禁又要问自己:现在,我们就要说再见了吗?

感慨莫名,不知所言。遥想当初刚来学校的时候,心里总是想着工科学校会过于板正,会缺乏一些柔情,当时心里甚至有一点点排斥,但是随着我对学校的慢慢认识与了解,我才认识到了她的美丽,她的柔情,并且慢慢的喜欢上了这个校园,但是时间太快了,快到我还没有好好体会她的美丽便要离开了,但是她带给我的回忆,永远不会离开我,也许真正离开那天我的眼里会满含泪水,我不是因为难过,我只是想将她的样子映在我的泪水里,刻在我的心里。最后,感谢我的老师们,是你们教授了我们知识与做人的道理;感谢我的室友们,是你们陪伴了我如此之久;感谢每位关心与支持我的人。

少年,追风赶月莫停留,平荒尽处是春山。

点赞+收藏+关注 → 私信领取本源代码、数据库

おすすめ

転載: blog.csdn.net/weixin_61498557/article/details/131515745
おすすめ