Hi David, Dan and All, Thanks a lot for your help in shaping up the domain model. I think David's model covers most aspects of the domain I plan to cover.
@David, One entity I'm not clear about is "ContactedParty". What is the reason that this is abstracted out from EmailContact? Also I assume the CriteriaReputation class is as same as Reputation class in my diagram? Thanks again for all your help. Regards, Dileepa On Sun, Apr 6, 2014 at 3:03 PM, David Tildesley <[email protected]> wrote: > Hi Dan, Dileepa, > > Yes - sorry should have read all the trails and also had a brain fade on > the uml violation thing as well. > Unfortunately this is proving really hard to do by email (as I suspected > it would be). > > I've drawn a domain model based on what I think I understand and attached > to the Jira (1) as an image. > > [1] https://issues.apache.org/jira/browse/ISIS-736 > > > On Saturday, 5 April 2014 9:24 PM, Dan Haywood < > [email protected]> wrote: > > 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. > > >> > > >> > > >> > > >> > > >> > > >> > > > > > >
