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
