On Mon, Aug 24, 2009 at 01:07:07AM +0200, Sander van Grieken wrote: >On Sunday 23 August 2009 09:36:44 Cristian Gómez wrote:
First off, thanks to Cristian for making this, clearly it has been a good starting point for us, because there have been suggestions for improvement! :) >I'm missing the cardinality and direction in the relations. Second, you >should add a Release class (one-to-many) to distinguish versions of >applications. Also abstract the File class to a Resource class (You can then >subclass File from Resource to specialize), this allows you flexibility in >the resource type (which could be a screenshot, like you modeled, but also >for example a howto, FAQ, homepage whatever). The directions are IMO quite clear anyway, but I have to agree with the Release table. Also distribution needs to drop author, authorEmail, installationInstructions and downloadURL and most of the other stuff. Author stuff can be in a distribution_maintainers table, which would glue distributions and users together. lastReleaseDate and stuff would come from the Release table. >Application has no 'belongs to' relationship to Distribution. Instead, >Distribution has a 'provides' relationship to Application. This is UML arrowtech? that the arrows are wrong? (I actually wrote in a job application that I know "Whiteboard UML" because it's just easier to draw lines and arrows and explain only where it's not self-evident ;) >The Application >attribute 'multiplatform' is useless. 'provedOn', 'notWorkingOn', >'distribution' are all one-to-many associations and should be modeled in the >diagram. 'author' should be a list or even an association, not a >string. Amen. >popularity is a derived attribute (pun intended) And user karma is not explained and studdlyCaps look like stupidCraps. -- mjt _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community