TransMaster in Class Diagram

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

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?

Thomas,
Thanks for your reply but I did not understand what you asked.
Thanks,
Murat

i think meaning 'profits' and 'constrains'.

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!

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

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 ]

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