I think I like Oscar's a bit more, also. Qn: Why is there a 1:1 relationship between Reputation and ReputationValue?
On 4 April 2014 17:08, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote: > Hi Dileepa. > > Not sure about this, but seems a little "strange" the "cycle" on your > model between the Context, Criteria and Reputation entities. > > Perhaps the Context is a more generic entity than Criteria, and it's the > Criteria what should have a relationship with a Context, and also with > Reputation? > > Something like this: > > http://yuml.me/3aa65a6f > > HTH, > > Oscar > > > > El 04/04/2014, a las 17:56, Dileepa Jayakody <dileepajayak...@gmail.com> > escribió: > > Hi Oscar and all, > > On Thu, Apr 3, 2014 at 1:52 PM, GESCONSULTOR - Óscar Bou < > o....@gesconsultor.com> wrote: > >> Hi Deleepa, >> >> Seeing at your last diagram, shouldn't the Criteria be related with (is >> specific to) a Context? If so, a relationship would also be needed. >> > > Yes, I agree. The criteria to calculate reputation depends on the context. > Therefore there should be a relationship > [Context]1-1..*>[Criteria]. > I have modified the diagram like this : http://yuml.me/26953ad7 > >> >> Perhaps the Computation Algorithm could also be specific for one or more >> Contexts. In that case, a relationship is also needed. >> > > I think, now that Context has a relationship with Criteria, the > relationship between the ComputationAlgo and Context could be derived > through the Criteria entity. > >> >> Also, perhaps the relationship between Reputation and Criteria is >> redundant, as it can be obtained through the ReputationValue. It could be >> modeled as a derived relationship in Isis. >> >> Yes, Thanks for pointing out. Removed this relationship between > Reputation and Criteria > >> HTH, >> >> Oscar >> >> >> >> El 03/04/2014, a las 09:59, Dileepa Jayakody <dileepajayak...@gmail.com> >> escribió: >> >> >> Hi Dan and all, >> >> I modified the diagram and the latest is : http://yuml.me/75c87f26 >> >> >> On Thu, Apr 3, 2014 at 12:50 PM, Dileepa Jayakody < >> dileepajayak...@gmail.com >> >> wrote: >> >> >> Thanks Dan, >> >> I will modify the diagram with proper notations and reply with >> explanations.. >> >> >> On Thu, Apr 3, 2014 at 12:31 PM, Dan Haywood < >> d...@haywood-associates.co.uk >> >> wrote: >> >> >> On 2 April 2014 08:09, Dileepa Jayakody <dileepajayak...@gmail.com> >> wrote: >> >> Hi All, >> >> After doing some background reading on Reputation object modeling [1], >> >> >> >> (good to hear) >> >> >> I >> have extended my class diagram to describe the reputation analysis >> >> model in >> >> my application : http://yuml.me/c97453ec >> >> >> There are some discrepancies between this diagram and the description >> below... >> >> >> >> An entity >> >> >> >> Not sure if having an entity called "entity" is a particularly good idea; >> could get confusing... >> >> >> has a reputation >> >> >> >> The diagram shows the "entity" entity as having many reputations. >> >> An entity can have different reputations in different contexts. As an >> >> example entity might have a good reputation for email context but bad >> reputation for marketing context. >> Hence, [Reputation]1-1[Context] and [<<Entity>>]1-0..*[Reputation] >> >> >> >> >> which describes it's value. EmailContact, Email >> are the 2 entity objects in my application. >> >> >> The diagram shows EmailContact and Email as having (an association with) >> an >> "entity", rather than being (implementing) entity. But I think the latter >> is probably what you want; Entity is an interface and EmailContact and >> Email implement them. >> >> Yep, I wanted to show the inheritance relationship. Sorry for the mistake >> >> with notation. I have modified this in the latest diagram. >> >> >> >> >> Reputation is an interface implemented by ReputationObject class. >> >> >> The diagram doesn't show this, it shows an association. >> >> In yuml.me, think that is shown using RepuationObject -^ Reputation >> >> Also, ReputationObject isn't a particular great name. Why have Reputation >> as an interface at all; as I understand it there's likely only one impl. >> >> >> I agree. I removed ReputationObject and added Reputation as an entity in >> the diagram. >> >> >> >> >> >> Reputation has a particular context/domain in which it isearned >> >> (eCommerce, >> >> films, technical forums etc ), >> >> >> >> Reputation *->1 Context >> >> >> in this case the context is email >> communication. The reputation's value is represented by the >> >> ReputationValue >> >> object which is calculated based on a certain criteria (In my case the >> criteria are People associated with the email, topic and actions in the >> email). Criteria defines the required parameters and the >> ComputationAlgorithm to be used to calculate reputation value. >> >> >> >> The reputation value is calculated by the particular >> >> ComputationAlgorithm >> >> using the parameters given by the criteria. This is where the >> implementation specific stuff comes in for calculation. Mahout >> recommendation algorithms, Drools rules are implementations of such >> ComputationAlgorithms. >> >> >> From an implementation standpoint, my first pass would be to implement >> ComputationAlgorithm as an enum. That way it can be polymorphically >> dispatched to. >> >> Overall, I like the way that the domain is getting richer. But I do still >> worry pragmatically about where these entities are all to be persisted, >> and >> how to they are sync'ed. Perhaps you could extend the diagram and use >> stereotypes to indicate for each entity whether its native persistence is >> in Isis, or Mahout, or gmail, or somewhere else. >> >> >> Yes, I will design the persistence model and we can discuss over that. >> >> >> Could also indicate if types are entities or value types. >> >> HTH >> Dan >> >> >> [1] Adrian Paschke, Rehab Alnemr, Christoph Meinel, The Rule Responder >> Distributed Reputation Management System for the Semantic Web >> >> >> >> >> Thanks, >> >> Dileepa >> >> >> >> Óscar Bou Bou >> Responsable de Producto >> Auditor Jefe de Certificación ISO 27001 en BSI >> CISA, CRISC, APMG ISO 20000, ITIL-F >> >> 902 900 231 / 620 267 520 >> http://www.twitter.com/oscarbou >> >> http://es.linkedin.com/in/oscarbou >> >> http://www.GesConsultor.com <http://www.gesconsultor.com/> >> >> >> >> Este mensaje y los ficheros anexos son confidenciales. Los mismos >> contienen información reservada que no puede ser difundida. Si usted ha >> recibido este correo por error, tenga la amabilidad de eliminarlo de su >> sistema y avisar al remitente mediante reenvío a su dirección electrónica; >> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. >> Su dirección de correo electrónico junto a sus datos personales constan >> en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la >> de mantener el contacto con Ud. Si quiere saber de qué información >> disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo >> enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a >> la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, >> 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 >> (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o >> sus archivos adjuntos no contengan virus informáticos, y en caso que los >> tuvieran eliminarlos. >> > > > *Óscar Bou Bou* > Responsable de Producto > Auditor Jefe de Certificación ISO 27001 en BSI > CISA, CRISC, APMG ISO 20000, ITIL-F > > 902 900 231 / 620 267 520 > http://www.twitter.com/oscarbou > > http://es.linkedin.com/in/oscarbou > > http://www.GesConsultor.com <http://www.gesconsultor.com/> > > > > Este mensaje y los ficheros anexos son confidenciales. Los mismos > contienen información reservada que no puede ser difundida. Si usted ha > recibido este correo por error, tenga la amabilidad de eliminarlo de su > sistema y avisar al remitente mediante reenvío a su dirección electrónica; > no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. > Su dirección de correo electrónico junto a sus datos personales constan en > un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de > mantener el contacto con Ud. Si quiere saber de qué información disponemos > de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un > escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente > dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - > 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). > Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos > adjuntos no contengan virus informáticos, y en caso que los tuvieran > eliminarlos. > > > > > >
