web-dev-qa-db-ja.com

ユーザーログイン用のUMLクラス図

以下の図は、Webサイトへのユーザーログインを説明するUMLクラス図を作成するための最初の試みです。

rubbishlogindesign

私はそれが貧弱なデザインで欠陥がたくさんあると確信していますが、このような簡単なログインをどのように設計するかを皆さんから学びたいと思っています。私は、デザインパターンの使用と、使用するパターン、デザインでのパターンの実装方法、およびその理由に特に関心があります。

アドバイス、批判、コメント、提案は本当にありがたいです。前もって感謝します。

design-patternsoopclass-designuml
18
Anthony

これがこの機能を実装する方法です

Class Diagram

ご覧のとおり、多くのアプリケーションがあります（ここでは、Webサイトのように動作します）。

あなたのマッピングに示されているように、モデレーター、Webマスター、およびメンバーは、ロールとして優れています。新しい「役割」を追加する必要があるかどうかはどうなりますか。たぶん、モデルをすべて変更する必要があります。

各UserApplication（UserWebsite）には、開始日と終了日があります。そして、各アプリケーションには独自の役割があります。銀行のウェブサイトにはマネージャーの役​​割が必要です。健康保険会社のウェブサイトにはエージェントの役割などが必要です...

[〜＃〜]更新[〜＃〜]

ログイン/ユーザー（部分/全体）の構成関係を理解し​​ています。先に進む前に、これを参照してください answer 構成と集計について。

しかし、私が理解していないのは、UserApplicationクラスとApplicationクラスの目的です。

アプリケーションをあなたのウェブサイトと考えてください。私は多くのモジュールを持っている大きな健康保険会社で働いています（各モジュール（アプリケーション）は独自のウェブサイトを持っています）。ただし、一部のユーザーは、すべてではなく、各モジュールを使用できます。 UserApplicationを定義する理由を説明します。

このログインプロセスでの役割の役割

無し。 UserApplicationに役割を与えるだけです。私は次の役割を定義する財務モジュールを使用できます：マネージャー、顧客、その他。マネージャーの役​​割を果たすことができます。ただし、金融モジュールを使用するために、一時ユーザー（startDateおよびendDate）をCustomerとして割り当てることができます。

Application financialModule = new Application();

financialModule.addRole(new Role("Manager"));
financialModule.addRole(new Role("Customer"));
financialModule.addRole(new Role("Other"));

User arthur = new User(new Login("#####", "#####"));
arthur.setFirstName("Arthur");
arthur.setLastName("Ronald");
arthur.setEnabled(true);

UserApplication financialModuleUser = new UserApplication(new Period(new Date(), null));
financialModuleUser.setUser(arthur);
financialModuleUser.addRole(financialModule.getRoleByDescription("Manager"));

financialModule.addUserApplication(financialModuleUser);

あなたのウェブサイトは次のようになります

Website myWebsite = new Website();
myWebsite.addRole(new Role("Member"));
myWebsite.addRole(new Role("WebMaster"));
myWebsite.addRole(new Role("Moderator"));

User you = new User(new Login("#####", "#####"));
you.setFirstName("FirstName");
you.setLastName("LastName");
you.setEnabled(true);

UserApplication myWebsiteUser = new UserApplication(new Period(new Date(), null));
myWebsiteUser.setUser(you);
myWebsiteUser.addRole(myWebsite.getRoleByDescription("WebMaster"));

myWebsite.addUserApplication(myWebsiteUser);

ご覧のとおり、Webマスター、モデレーター、およびメンバーは、Webサイトによって定義された単なるロールです。他には何もありません。

UMLとORMに関する優れたリソースは、Java Persistence with Hibernate bookです。

23
Arthur Ronald

私はあなたのユースケースの説明を調べました、それは間違っています、それは次のことができます：

Use Case: Login The System
Scope: Your Project Name.
Primary Actor: User
StakeHolders and Interests:
User: want to sign-in the system without any mistake or error.
Preconditions: User should be the system user
Success Guarantee: User entered the system
Main Success Scenario:
1.  User enters login page.
2.  System builds login page. Fields such as username and password  are observed on the screen.
3.  Users enters required informations.
4.  Users sends information with a view to entering the system.
5.  System approves information, open the session of user and returns message ”Login process is successfull”.
Alternate flows:
      3a.User does not enter all required field.
              1.System wait that user enter so-called required field.
       4a.The information of user such as username or password is wrong
              1.System send message ”Your send wrong user parameters.”

ユースケースを書いた後、このようにSSDを描画します。

alt text

このような前述のSSDの相互作用図.ORM（Hibernate、LinqToSql、EntityFrameworkなど）を使用すると想定したため、データにアクセスするときにファサードパターンは必要ありません。） alt text

そしておい、あなたは1つのユースケースから他のユーザーを決定しないでください。ラーマン氏は、そのグループはユースケースであり、実装のために1つのグループを選択したと述べています。このユースケースグループは、バージョン1のクラスを反映しているため、1つのユースケースでは多くのクラスを取得できません。 Larmansの本を読んで、これらのプレゼンテーションをご覧ください http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm

クラスに責任を割り当てる場合、実装はとても簡単になります。多分あなたは読書が好きではないかもしれませんが、時には私たちはいくつかの本を読むべきです。多くの大学では、この本をオブジェクト指向の分析と設計に使用しています。

7
ibrahimyilmaz

優れたデザインを作成するためにGrasp Designパターンを使用することをお勧めします。この分野によれば、最初に、誰がこの操作を行う責任があるかを考える必要があります。まとめると、GofパターンのルートがGraspであることがわかります。あなたの設計では、申し訳ありませんが、ユースケースが十分に定義されていないと申し訳ありません。このクラス図は、ユースケースの概念を反映しているため、ドメインモデルである必要があります。いわゆるユースケースについてシステムシーケンスと相互作用図を作成する前に、クラス図を作成することに反対しました。ドメインモデルの通常のメンバー、Webマスターおよびモデレーターはuserであり、user account。ちなみに、クラスの結合を増やすので、すべきでない限り継承を行わないでください。そのため、すぐにリファクタリングを行うことはできません。 http://en.wikipedia.org/wiki/GRASP_（Object_Oriented_Design）

alt text

http://www.Amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691

3
ibrahimyilmaz

変更する場所が2つあります。

1）データベースはクラスではないため、クラス図に表示しないでください。これはおそらくUser_accountの実際のものです（私はそれがDB内のテーブルであることを理解しています）

2）3つのクラスが1つのスーパークラス（WebMaster、モデレーター、RegularMemberからユーザー）から継承されている場合も、下に描いたように表示されます。

                 1     uses>   1..*
          User <>--------------->UserAccount
           /|\
            |
            |
     _______|________
     |      |       |
     |      |       |
   Mod     WebM   RegularM
2
Roman