[ALL] New showroom for Openmoko apps

Cristian Gómez cristianpark at gmail.com
Mon Aug 24 18:00:13 CEST 2009

Sunder, Markus thank you so much for the feedback. Here's what I think

- About the cardinality, I don't use it too much in class diagram but I will
include cardinality in the diagram to make it clear
- I have doubts about the versions of a application. I think that versions
(Release class as you point) have many in common attributes with the
Application itself (each version can have different author(s), downloadURL,
installation instructions, etc). Maybe in the Application class we only need
to store the app name, description and in the versions, the authors,
downloadURL, etc.
- User karma is like popularity for application, I think that we may
implement a way to say thanks to developers/maintainers by given them karma
points. Same way as we will have a Top 10 applications, we should have Top
10 contributors IMHO.

I think mosts of your suggestions make perfect sense, I'll update the
diagram as soon as I can. But reading your comments I think that maybe we
should make a DB diagram instead to make things clearly from the DB
perspective and then we should update the Classes diagram, what do you

* Don't Worry.......Be Linux!!!!
* Cristian Gómez Alvarez
* Ingeniero en Sistemas y Computación
* Universidad de Caldas
* Comunidad de Software Libre Manizales
* IEEE/WIE Student Member
* Linux User #463617
* Mi Blog: http://cristianpark.sehablalinux.com/

2009/8/23 Sander van Grieken <sander at 3v8.net>

> On Sunday 23 August 2009 09:36:44 Cristian Gómez wrote:
> > Hi all, I were following this thread and I think that the most remarkable
> > post is this one from Martin who resumes the most important things that
> we
> > want to have in the showroom page.
> >
> > I made this Classes diagram [1] in DIA to make the basis for the
> > development of the site. It's really basic but I think that it's a start
> > point.
> 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).
> Application has no 'belongs to' relationship to Distribution. Instead,
> Distribution has a
> 'provides' relationship to Application. 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.
> popularity is a derived attribute (pun intended)
> grtz,
> Sander
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20090824/835e1d95/attachment.htm 

More information about the community mailing list