[ALL] New showroom for Openmoko apps

Markus Törnqvist mjt at nysv.org
Mon Aug 24 09:25:37 CEST 2009

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 


>popularity is a derived attribute (pun intended)

And user karma is not explained and studdlyCaps look like stupidCraps.


More information about the community mailing list