Re: Modeling User/Accounts

Responding to MySpamB8...

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:

<snip original diagram>

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?

UML supports a separate Interface model element (i.e., the "lollipop" box), but it is rarely used. A Class defines responsibilities that are externally accessible. Those usually map directly to interfaces at the 3GL level.

One usually only needs the Interface model element when one wants to limit the access some objects have (i.e., to not expose all the responsibilities to certain other objects) AND that is important to the problem solution (as opposed to making the 3GL code more maintainable).

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>

I thought you said originally that the SysAdmin people (having admin properties) were unrelated to Programs. Also, ConferenceContact seems to be a new feature. So I think the first task is get get the requirements straight. B-)

The name EmailHaving makes me nervous. I think you were originally describing two sorts of people: those involved with administration and those involved with programs. (Now perhaps a third type involved with conferences.) Anyway, I would bet there is a more descriptive term for the set of human beings that can be subdivided into SysAdmin and other subset categories.

So I think the second thing to do is decide what flavors of people are relevant and how they are categorized, presumably by the way they map into programs, admin, and conferences. Assign them meaningful names that are based on the relevant problem semantics. Then you can determine what properties they need.

[Also note that the notion of 'contact information' can be separated from the notion of 'person' (e.g., think: card in a Rolodex). That might be desirable if some category of persons may be conditionally related to programs. So one only needs the contact information in those situations where the relationship is actually instantiated. IOW, a ContactInfo object might be an associative object on the relationship or it could be a separate object that is dynamically related to certain persons depending on context. My point is that separating the notion of 'contact information' may allow you to avoid the multiple inheritance implied in R3/R4. Multiple inheritance is one of those things that one tries to avoid whenever possible.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Relational model versus object model
    ... Today almost all OOPL IDEs provide integrated class libraries. ... Note that OO classes with no behavior responsibilities are fairly ... >> paradigm as manifested by a relational DBMS. ... implement interfaces for inclusion polymorphism. ...
    (comp.object)
  • Re: object system...
    ... IMO we need another OOPL about as much as a revival of smallpox. ... interfaces can implement slots as well as methods; ... In OOA/D accessing knowledge responsibilities is quite different than accessing behavior responsibilities. ... I think existing relationship navigation and interfaces work just fine in supporting peer-to-peer collaboration whether delegation is used or not. ...
    (comp.object)
  • Re: From requirement to entity model
    ... > I'm facing for the first time the conceptual design of a new web ... OO construction is driven by the problem space. ... abstract those characteristics as knowledge and behavior responsibilities. ... IOW, exactly what do our ...
    (comp.object)
  • Re: DUnit TestCase wizard is useless
    ... > abstraction between design and implementation. ... You use interfaces to ... > responsibilities and implementations around as needed until you have ...
    (borland.public.delphi.non-technical)
  • Re: OT: Following is the timeline not widely discussed in the news:
    ... responsibilities across the board, and about equal levels of "I take responsibility for anything I might have done wrong." ... IOW, everyone's offering apologies and mea culpas and we'll see who follows them up with meaningful action. ...
    (rec.crafts.textiles.needlework)