Hi Dileepa, Whenever I see a 1:1 relationship between two object/classes I am thinking that they should be collapsed together unless there is some future reason you might want to keep them separate. i.e. Reputation - Context. ReputationObject, ComputationalAlgorithm appears to have no meaning or place on the domain model except perhaps as concrete implementation via plugin point. Entity (as with object) as a name is just wrong - you should regard it as if it were a reserved word and come up with a proper domain specific name. Your compositions on Entity break the uml semantics - it would have to be an aggregation relationship to be shared.
Maybe we can improve the model by you telling us what object is the highest business value in the domain. I'm thinking you have a moment-interval archetype called "Reputation" that is point in time and it has behaviour that is effectively "calculateReputation". It may have some MI-details (as composition) that participate in the calculation. I'm thinking Criteria is actually a "description" archetype which has a plugin point (strategy pattern) for the computation algorithm. UserInbox looks like a "thing" archetype and it looks like you have chosen to collapse the user (Party) onto that - which may be fine if all you want to know about the user is say an identifier and name so that you can locate the logged in principal's UserInbox. If it were an email client app domain then Email would be a moment-interval and EmailContact a party archetype. Maybe it is true in this domain as well. David. On Saturday, 5 April 2014 8:56 AM, Dileepa Jayakody <dileepajayak...@gmail.com> wrote: Hi All, On Fri, Apr 4, 2014 at 11:11 PM, Dan Haywood <d...@haywood-associates.co.uk>wrote: > I think I like Oscar's a bit more, also. > > Qn: Why is there a 1:1 relationship between Reputation and ReputationValue? > > ReputationValue entity encapsulates the result of the reputation analysis process. It can simply be a value type (a reputation score). And I think each Reputation object should have a corresponding reputation value, that's why I added it as a 1:1 relationship. Any ideas for a better model? > > > > > 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? >> >> I agree with you on the cyclic model being bit strange. I also adjusted the association between ReputationValue and Criteria entitys as [ReputationValue]0..*-1>[Criteria] so that now ReputationValue has a uni-direction association to the criteria used for the computation. See : http://yuml.me/17514278 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. >> >> >> >> >> >> >
