Re: Modeling User/Accounts


mySpamB8@xxxxxxxxx wrote:
mySpamB8@xxxxxxxxx wrote:
H. S. Lahman wrote:
Responding to MySpamB8...

I have a system with the following concepts:
*Programs (As in social service programs)
*Program Contacts (people who are associated with programs)
*Application Users (most users are Program Contacts, but some users are
system admins who aren't associated with a program)

All the above is fairly easily modeled, I think. However, I hit a snag
with the following spec:
*Application Users need an email address (for password retrieval
purposes).

I think you have already answered the question. B-) All Application
Users have email addresses, including those not associated with
Programs. So the email address is an attribute of Application User, not
Program Contact. IOW,

[ApplicationUser]
+ emailAddress
... <common properties>
A
| R1
+-----------+--------------+
| |
[ProgramContact] [SysAdmin]
... <contact properties> ... <admin properties>
| *
|
| R2
|
| related to
| 1
[Program]
... <program properties>

Darn, I see one more snag, and that is that some contacts are not even
application users at all. With your help, and remembering about
interfaces (which my target language, CFML, actually doesn't have), I
have come up with the following:

[EmailHaving]
<<interface>>
+ emailAddress
... <common properties>
A
: R1
............:...............
: :
[Contact] [SysAdmin]
<<interface>> <<interface>>
... <contact properties> ... <admin properties>
A A A
: : :
: R2 : R3 : R4
: : :
[ConferenceContact] [Program Contact]
| |
| R5 | R6
| |
[Conference] [Program]
... <contact properties> ...<program properties>

Does this seem sane?

Also, I'm not sure whether to keep my class diagram generic (including
interfaces) or to acknowledge the lack of interfaces in my Class
Diagram. Thoughts?

Whoops, I have a confusing naming error, as well as an omission, here
is the correction:

[EmailHaving]
<<interface>>
+ emailAddress
... <common properties>
A
: R1
............:...............
: :
[Contact] [ApplicationUser]
<<interface>> <<interface>>
... <contact properties> ... <admin properties>
A A A
: : :
: R2 : R3 : R4
: : :
[ConferenceContact] [Program Contact]
| |
| R5 | R6
| |
[Conference] [Program]
... <contact properties> ...<program properties>


Also to correct the omission: there is a Sys Admin Class that would
only implement the ApplicationUser interface, and not the Contact
interface.

Arghh, I guess interfaces don't have properties, so I'm pretty confused
again...

.

Relevant Pages

  • Re: Modeling User/Accounts
    ... <common properties> ... interfaces, I ... is the correction: ...
    (comp.object)
  • Re: Modeling User/Accounts
    ... <common properties> ... Darn, I see one more snag, and that is that some contacts are not even ... interfaces, I ...
    (comp.object)