Sunder, Markus thank you so much for the feedback. Here&#39;s what I think<br><br>- About the cardinality, I don&#39;t use it too much in class diagram but I will include cardinality in the diagram to make it clear<br>- 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.<br>

- 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.<br>

<br>I think mosts of your suggestions make perfect sense, I&#39;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 think?<br>



<br><br clear="all">/***************************************<br>* Don&#39;t Worry.......Be Linux!!!!<br>* Cristian Gómez Alvarez           <br>* Ingeniero en Sistemas y Computación<br>* Universidad de Caldas   <br>* Comunidad de Software Libre Manizales<br>



* IEEE/WIE Student Member<br>* Linux User #463617                <br>* Mi Blog: <a href="http://cristianpark.sehablalinux.com/" target="_blank">http://cristianpark.sehablalinux.com/</a><br>****************************************/<br>



<br><br><div class="gmail_quote">2009/8/23 Sander van Grieken <span dir="ltr">&lt;<a href="mailto:sander@3v8.net" target="_blank">sander@3v8.net</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



<div>On Sunday 23 August 2009 09:36:44 Cristian Gómez wrote:<br>
&gt; Hi all, I were following this thread and I think that the most remarkable<br>
&gt; post is this one from Martin who resumes the most important things that we<br>
&gt; want to have in the showroom page.<br>
&gt;<br>
&gt; I made this Classes diagram [1] in DIA to make the basis for the<br>
&gt; development of the site. It&#39;s really basic but I think that it&#39;s a start<br>
&gt; point.<br>
<br>
</div>I&#39;m missing the cardinality and direction in the relations. Second, you should add a<br>
Release class (one-to-many) to distinguish versions of applications. Also abstract the<br>
File class to a Resource class (You can then subclass File from Resource to specialize),<br>
this allows you flexibility in the resource type (which could be a screenshot, like you<br>
modeled, but also for example a howto, FAQ, homepage whatever).<br>
<br>
Application has no &#39;belongs to&#39; relationship to Distribution. Instead, Distribution has a<br>
&#39;provides&#39; relationship to Application. The Application attribute &#39;multiplatform&#39; is<br>
useless. &#39;provedOn&#39;, &#39;notWorkingOn&#39;, &#39;distribution&#39; are all one-to-many associations and<br>
should be modeled in the diagram. &#39;author&#39; should be a list or even an association, not a<br>
string.<br>
<br>
popularity is a derived attribute (pun intended)<br>
<br>
grtz,<br>
<font color="#888888">Sander<br>
</font><div><div></div><div><br>
<br>
_______________________________________________<br>
Openmoko community mailing list<br>
<a href="mailto:community@lists.openmoko.org" target="_blank">community@lists.openmoko.org</a><br>
<a href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank">http://lists.openmoko.org/mailman/listinfo/community</a><br>
</div></div></blockquote></div><br>