Q: When I say that class X is a "composition" of class Y and class Z, is this because X has properties that are defined AS _TYPE_ Y and Z?
A: When you say X is a composition class Y and class Z, all you are saying is that X has dependencies on Y and Z to get information. Saying "X has property that are defined as type of Y and Z" is spelling out an inheritence relationship rather than a collaborative one. Q: My logic to place the Contact class and the Address class as composing elements of the Account class is simply because the Contact class have defined properties OF TYPE Contact and Address. Is this correct? A: It's a good first start in trying to extract keep things low coupled. My opinion of that first UML diagram you have is that i think you are keeping things a little too uncoupled. There is this GRASP design principle "Information Expert" that states if an object is rightly knowledegable about retaining or producing information for the other objects in the system. In this case, I would combine your Contact and Address as one and called it something like "ContactInfo". By Information Expert, the ContactInfo object would be the expert for data pertaining to all things Contact information. How this makes sense to me is that you can turn to your domain model or look at the real world and really use your imagination of how some of the information changes. Using the Address obj as you have it for example, if my street, city, or state changes, then it's highly likely that in the Contact obj, I will have to change my phone number. Q: If this is not an appropriate place to ask this sort of question... A: http://www.objectsbydesign.com/ Good luck with into UML and OOA/D, -mL http://knowledge.lapasa.net P.S. Craig Larman's book, Applying UML and Patterns, is currently my programmer's bible. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of js Sent: Monday, June 19, 2006 8:13 PM To: Flashcoders mailing list Subject: [Flashcoders] UML + Actionscript I have been trying to learn the basics of UML for the past couple days or so by assembling a class diagram for a hypothetical Contact Manager--although it may not stay hypothetical if I can learn this properly ;). Unfortunately I am experiencing a bit of confusion in regards to properly communicating class hierarchy between associated / aggregated classes. Here is the (very simple) diagram that I made thus-far: http://www.aerosdesign.com/jsorensen/store/uml/uml_diag_a.jpg Basically, I have three classes -- the Account class being a composition of the Contact and Address classes. (I think) Here is my question: When I say that class X is a "composition" of class Y and class Z, is this because X has properties that are defined AS _TYPE_ Y and Z? My logic to place the Contact class and the Address class as composing elements of the Account class is simply because the Contact class have defined properties OF TYPE Contact and Address. Is this correct? If this is the case, I will be glad to hear that I am doing things correctly. However, a new source of confusion then emerges for me; say, for instance that I wanted to have an Array of contacts for any given account as opposed to just one. I then replace accContact:Contact with accContacts:Array. Here is the updated diagram: http://www.aerosdesign.com/jsorensen/store/uml/uml_diag_b.jpg The relationship between the Contact class and the Account class is no longer explicit--but I still want to convey that the accContacts array will be populated with instances of "Contact". How do I now communicate this relationship? Would this be an "association" now? See this diagram if you are confused: http://www.aerosdesign.com/jsorensen/store/uml/uml_diag_comment.jpg A sincere thank you to anyone who took the time to read and attempt to understand my post; I apologize if this is slightly outside the scope of normal list discussion. If this is not an appropriate place to ask this sort of question, I would be very happy to hear about an active UML mailing list or equivalent alternative. :) Thanks for any assistance, Joseph _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
