Hi David, I think you've raised one or two points I did already (eg "Entity" as a name), which Dileepa already addressed in the latest iteration; the most recent is [1]. But I really appreciate you taking the time to help develop Dileepa's model here; great points being raised.
Hi Dileepa, Not sure if David or I mentioned it already, but the "description", "thing", "role" and "moment-interval" archetypes are from the Coad modelling in color approach [2,3] that David and I have both (independently) used in the past, and which I've described in my previous books. Could be worthwhile adding these archetypes to the model, make it more expressive. Cheers Dan [1] http://yuml.me/17514278 [2] http://en.wikipedia.org/wiki/UML_colors [3] http://www.step-10.com/SoftwareDesign/ModellingInColour/ On 4 April 2014 22:33, David Tildesley <[email protected]> wrote: > 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 < > [email protected]> wrote: > > Hi All, > > > On Fri, Apr 4, 2014 at 11:11 PM, Dan Haywood > <[email protected]>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 <[email protected] > >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 <[email protected] > > > >> escribió: > >> > >> Hi Oscar and all, > >> > >> On Thu, Apr 3, 2014 at 1:52 PM, GESCONSULTOR - Óscar Bou < > >> [email protected]> 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 < > [email protected]> > >>> 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 < > >>> [email protected] > >>> > >>> 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 < > >>> [email protected] > >>> > >>> wrote: > >>> > >>> > >>> On 2 April 2014 08:09, Dileepa Jayakody <[email protected]> > >>> 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. > >> > >> > >> > >> > >> > >> > > >
