UMLクラス図を使用してユーザー管理をモデル化する方法は？
私とチームがヘルスケアシステムを構築する必要がある学校のプロジェクトがあります。これは、次のようなさまざまなモジュールで構成されています。
医師向けモジュール：これにより、医師は患者の医療記録にアクセスし、患者に指示を送信し、彼の議題を参照できます...
患者向けのモジュール：患者は医師との面談、緊急事態の通知、または指標（血糖値、体重、血圧）の送信を行うことができます。システムによって世話をしなければならない患者の3つのタイプがあります：危険な妊娠の女性、糖尿病患者、およびアルツハイマーに苦しんでいる人々。後者は、家族や医療スタッフからの支援を受けています。
輸送用モジュール：患者が緊急事態を通知した場所に救急車を動かして派遣する。
UMLクラス図（実際にはプロジェクトのデュードキュメント）を介してソリューションをモデル化しようとしたときに、3つの問題/ジレンマに遭遇しました。
- 患者をモデル化するには？
私たちの最初の考えは、次のように他のクラスを継承するserクラスを作成することでした：
。
しかし、これでは、たとえば患者が妊娠して糖尿病になることはできません。面倒です。
インターネットで検索したところ、役割ベースのアクセス制御について知りましたが、アカウントの管理と権限を目的としたものであり、さまざまな役割（糖尿病患者と妊娠中の患者）のようなビジネス関連のものではないと考えたため、詳細には触れませんでした。例）。
最終的にPathologyクラスを作成し、各患者の病理のリストを追加することに同意しました。 これは優れた設計原則に違反していますか？これを行うための標準的またはより良い方法はありますか？
アシスタントでも同様の問題が発生します。彼は患者の家族または医療スタッフのメンバーになることができるので、私たちは彼をAssistantserのクラスまたはMedicalAssistantのいずれかに分類します。MedicalStaffの下のクラス。しかし、これは患者の病理と同じ問題だと思います。
- アシスタントをモデル化する方法は？
再びアシスタントと一緒に、彼はアルツハイマーに苦しむ患者を支援するためにここにいます：彼は彼のために医者の予約をし、彼があまりにも離れて歩き回った場合は通知されます（ソリューションにはGPSを装備したウェアラブルブレスレットが含まれています）。クラスAssistantおよびPatientがメソッドMakeAppointment（Doctor、Date）を実装しているため、これにより冗長性の問題が発生しました。 。これにより、2つの可能性が生まれました。
-このメソッドは代わりにDoctorクラスにあるべきですか？
-メソッドを含むIAppointementインターフェースが必要ですか？
私は個人的に、メソッドをDoctorクラスに移動する必要があると思います（おそらくこれは、基本的なOOPことでもあります）。
- MVCを表す方法は？
このシステムをサポートするWebサイトとモバイルアプリを作成します。私たちは、ASP.NETを使用してそれを手に入れ、MVCデザインパターンについて知ることを考えました。少しドキュメントを書いた後（主にTom Butlerの「MVC In PHPシリーズ」と「Martin FowlerのGUIアーキテクチャ（両方ともWebサイトにあります）」から）、 ControllerレイヤーとViewレイヤーは、次のようなクラス図で表す必要があります。
。
同様の質問をするstackoverflowのこの投稿を見つけました：
MVCのUMLクラス図を作成する方法
モデル（ビジネス関連クラス）のみを表現する必要があると述べています。しかしそれは一般的なルールですか？ControllerクラスとViewクラスを表す必要がありますか？それはシーケンス図にどのように変換されますか？
投稿が長すぎて質問が非常に不均一であるのが残念です。あなたが私たちに与えるかもしれないどんな助け、助言または発言も前もって感謝します。
1。患者をモデル化する方法は？
Account、User、およびユーザーのさまざまな派生物を使用した設計は、すでに良いスタートです。
Patientは、実際には特別な種類のUserである可能性があります。ただし、PatientはではないaDiabetic、AlzheimerまたはPregnant。彼/彼女はDiabetesやAlzheimerのような病状、またはPregnantのような病状を持っています。彼/彼女は同時にいくつかの病状を持っているかもしれません。したがって、Patientと1つ以上のPathologiesを関連付けることを強くお勧めします。したがって、継承に対する合成の原理を使用します。
一人でこのオリエンテーションに来たので、私はあなたが一人が良い方法であることを確認できます。
アシスタントのモデル化方法
アシスタントは、少なくともビジネス上の意味で、Patientのproxyです。彼は彼自身のために約束をしません：彼は患者に代わって約束をします。他の患者は自分で予約をするかもしれません。
したがって、予約の方法は、Doctor（より正確には、医師のスケジュール）によって提供される必要があります。しかし、これはAssistantにMakeAppointment()を含めることにも反対しません。これにより、関連するDoctorに呼び出しが転送されます。
ちなみに、患者にはスケジュールもあります。原則として、同じ患者に対して2つの予約を同時に行うことはできません。これにより、さらなるアプローチが可能になります。MakeAppointmentを "Transaction Script" としてよく見ることができます。これは、特定の時間に医師と患者のスケジュールが空いているかどうかをチェックします。予約を医師のスケジュールで予約してから、患者のスケジュールで予約します。
3。 MVCの表現方法
実際、UMLダイアグラムの目的によって異なります。
ドメインモデル の場合、 ドメインオブジェクト （たとえば、Patients、Doctors、Users）のみが含まれ、コントローラーまたはビューが含まれていないため、モデルが増えるだけです。理解しにくいです。
ただし、実装モデルの場合は、コントローラーやビューなど、ソフトウェアの構築に必要なクラスを表示できます。
ロールモデルの詳細
ロールモデルに戻ると、Pathologyについて説明した問題は他のロールにも存在します。たとえば、ドクターが足を骨折した場合、ドクターも患者になる可能性があります。
したがって、1人のユーザーが複数の役割を持つことができます。これは同様に構成設計を必要とします：UserはIDを持ち、各ユーザーはいくつかの役割を持つことができます。次に、どの属性が一般的でユーザーに属しているか、およびどの属性が役割に固有であるかを考える必要があります。