Re: Modeling User/Accounts

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?

Thanks again,
Jamie

.

Relevant Pages