Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

TransMaster in Class Diagram

 
Murat Balkan
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
Should I include a POJO for interaction with the TransMaster in the class diagram? Or should it be represented in the component diagram?
Thanks,
Murat
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Murat Balkan:
Should I include a POJO for interaction with the TransMaster in the class diagram? Or should it be represented in the component diagram?
Thanks,

What are your pros and contras?
 
Murat Balkan
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thomas,
Thanks for your reply but I did not understand what you asked.
Thanks,
Murat
 
Newman Huang
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i think meaning 'profits' and 'constrains'.
 
Ricardo Ferreira
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Murat Balkan:
Hi all,
Should I include a POJO for interaction with the TransMaster in the class diagram? Or should it be represented in the component diagram?
Thanks,
Murat


The TransMaster represents the API that the application must use to validate and process the customer's credit card.

You could look for this API as an service the your travel application is going to consume. The service term used here represents the operational functions that some system access of another system (subsystem).

So, give that the TransMaster is just one subsystem and will provides some kind of service to your application, you should design some kind of piece of interaction between the systems.

This means that you can design a class or DTO to identify the parameters that must be passed from your travel application to transmaster core API.

For example, if you incept that the transmaster must require two parameters of processing (The customer credit card number, and the ammount to debit), you could plan some design like this:

[has] [ref]
Customer -----------> CreditCard ------------> [CreditCardType]
-------- ---------- --------------
Name, Age number, expireDate creditCardName
birthDay


[TransMasterMessage]
--------------------
creditCard [ref to CreditCard]
double ammount

The 'TransMasterMessage' could represents the parameters data that must be passed to the TransMaster subsystem, and some controller object will pick up the object to assembly a parameters passing to the API. The method could be something like this:

public class TransMasterInterfaceBO {

// The stub object could be injected by a IoC framework ...
private TransMasterStub tms;

public boolean processRequest(TransMasterMessage tmm, double ammount) {
// extract the valuable paramaters from the object ...
String creditCardNumber = tmm.getCreditCard().getNumber();
double _ammount = ammount;
//
tms.processCreditCard(creditCardNumber, _ammount);
}

}

Well, that's are my souths!
 
Murat Balkan
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ricardo,
Thanks for your clear explanation. I understand that I should add this class to my diagram but as this class represents an access point to an external service it should not be in dependency with the other classes, so must be represented as a seperate entity in the class diagram. Am I right?
Thanks,
Murat
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Murat,

From Merriam-Webster OnLine at http://www.m-w.com

pro - an argument or evidence in affirmation <an appraisal of the pros and cons>
con - an argument or evidence in opposition

Regards,
Dan
[ June 26, 2006: Message edited by: Dan Drillich ]
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First sorry @Murat Balkan for answering so late - it has been a long day.
Then thanks @Jan Drillich for explaining the terms pros and cons. Acc. to dict.leo.org another synonym
- for "pro" could be "advantage" or "benefit", and
- for "con" could be "disadvantage" or "drawback".

Originally posted by Murat Balkan:
I understand that I should add this class to my diagram but as this class represents an access point to an external service it should not be in dependency with the other classes, so must be represented as a seperate entity in the class diagram. Am I right?

I agree that this access point should not depend on any other classes and therefor should be a separate class - or better interface - in the class diagram. This interface then can be implemented by one DAO for the new web interface and by another DAO for the old line API in case it is still needed as a fallback solution (keep in mind the millions for the campaign and that the web API is still just a promise!).

Thomas
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic