Model Driven Architecture without Automation

785 views

Published on

This is an old presentation, but still interesting. An example of using models as primary artifacts for communication during a development effort, even without code generation.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
785
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Model Driven Architecture without Automation

  1. 1. A Real-World Example of MDA without Automation Copyright © 2004 InteliData Ed Seidewitz 26 August 2004
  2. 2. Agenda • Background • Model-driven architecture • Case study • Conclusions 2 Copyright © 2004 InteliData
  3. 3. Background • Consumer bill payment • InteliWorks architecture • InteliWorks development 3 Copyright © 2004 InteliData
  4. 4. Background: Consumer bill payment CCoonnssuummeerr CCoommppuutteerr Consumer Computer I nt ernet WWeebb BBaannkkiinngg// BBiillll PPaayy UUII Web Banking/ Bill Pay UI BBiillll PPaayymmeenntt WWaarreehhoouussee Bill Payment Warehouse Bank-owned syst ems FFuunnddiinngg SSyysstteemm Funding System Bat ch files RReemmiittttaannccee PPrroovviiddeerr Remit tance Provider (Bank syst em / ACH / …) MMMeeerrrccchhhaaannntttsss 4 Copyright © 2004 InteliData
  5. 5. Background: InteliWorks architecture PPPrrreeessseeennntttaaatttiiiooonnn TTTiiieeerrr CCoonnssuummeerr FFrroonntt EEnndd Consumer Front End CCSSRR// AAddmmiinn FFrroonntt EEnnddss CSR/ Admin Front Ends AAAppppppllliiicccaaatttiiiooonnn TTTiiieeerrr GGaatteewwaayy SSeerrvviicceess Gateway Services DDDaaatttaaa TTTiiieeerrr AAddaapptteerr DDaattaa Adapter Data CCoonnssuummeerr SSeerrvviicceess Consumer Services CCoonnssuummeerr DDaattaa Consumer Data FFFiiinnnaaannnccciiiaaalll WWWaaarrreeehhhooouuussseee Event not ificat ion BBaacckk--EEnndd DDaattaa Back-End Data Web Services RRMMII RReeqquueessttss RReessppoonnsseess 5 Copyright © 2004 InteliData
  6. 6. Background: InteliWorks development • InteliWorks project initiated late in 2000. • Iterative development approach with each (overlapping) increment taking 3-4 months (currently working on Increment 18). • Significant modeling introduced in stages starting early in 2001. – Architectural modeling – Logical data modeling – Physical Java class modeling (no longer done) – Use case modeling • Complete model-driven approach established by mid 2003. 6 Copyright © 2004 InteliData
  7. 7. Model-driven architecture • What is it? • What is a platform? • CIM, PIM, PSM and all that… • Transformations • Why “manual transformation”? 7 Copyright © 2004 InteliData
  8. 8. MDA: What is it? From the MDA Guide Version 1.0.1 (omg/2003-06-01) “The Model-Driven Architecture starts with the well-known and long established idea of separating the specification of the operation of a system from the details of the way that system uses the capabilities of its platform.” 8 Copyright © 2004 InteliData
  9. 9. MDA: What is a platform? From the MDA Guide Version 1.0.1 (omg/2003-06-01) “A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns, which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented.” 9 Copyright © 2004 InteliData
  10. 10. MDA: CIM, PIM, PSM and all that… From the MDA Guide Version 1.0.1 (omg/2003-06-01) • “A computation independent model is a view of a system” that “focuses on the on the environment of the system, and the requirements for the system.” • “A platform independent model is a view of a system” that “focuses on the operation of a system while hiding the details necessary for a particular platform.” • “A platform specific model is a view of a system” that “combines the platform independent viewpoint with an additional focus on the detail of the use of a specific platform by a system.” 10 Copyright © 2004 InteliData
  11. 11. MDA: Transformations • “The platform independent model is transformed to be a model specific to a particular platform.” • “Four different transformation approaches… illustrate the range of possibilities:” – manual transformation – transforming a PIM that is prepared using a profile – transformation using patterns and markings – automatic transformation 11 Copyright © 2004 InteliData
  12. 12. Case study • Overview • Architecture • Data 12 Copyright © 2004 InteliData
  13. 13. Case study: Overview Consumer: Payment - View Payments Consumer Consumer: Payment - Cancel <<extend>> <<include>> <<extend>> Consumer: Payment - Create (without Bill) <<extend>> Consumer: Payment - View Activity <<extend>> <<include>> Consumer: Payment - Modify Consumer: Payment - Validate <<include>> <<include>> Consumer: Payment - Route Requirements Model CIM (use case and activity diagrams) <<Interface>> PaymentFeExtended addPaymentNoteExtended() completePaymentExtended() failPaymentExtended() getPaymentsExtended() pendPaymentExtended() resubmitPaymentExtended() reversePaymentExtended() PaymentService <<Interface>> PaymentFe addPayment() cancelPayment() getPayments() getPaymentActivity() updatePayment() handlePayeeChange() OperationalDirectory <<Interface>> Payment SchedulingEvent (from Scheduler) (from Operati onal Direct ory Service) PaymentRead <<Interface>> PaymentUtility prepare() getRouting() checkForDuplicate() <<Interface>> PaymentEvent processPayments() Notification (f rom eMessenger) Implementation platform • J2EE (WebLogic app server) • Relational DB (Oracle DBMS) • Web services (Apache Axis) hand modeled traces FinancialTransactionCommon (from Financial Transaction Servi ce) PayeeUtility AccountUtility FinancialTransactionRead FinancialTransactionWrite FinancialTransactionUtility (f rom Financial Transacti on Service) FinancialTransaction (from Financial Transaction Servi ce) PIM Dependency Model (class diagrams) hand modeled hand modeled : Consumer : ConsumerFrontEnd : XmlConnector : PaymentService : FinancialTransac tionService Sequence Diagram: InteliWork s Consumer: Payment Realizations / Consumer: Payment - Enter 2.1.1. addPayment( ) 2.1.1.2. payment Sequence Diagram: InteliWorks Consumer: Financ ial Transaction Realizations / Consumer: Financial Transaction - Add Sequence Diagram: InteliWorks Consumer: Payment Realizations / Consumer: Payment - View Payments 1. Create payment 1.1. Enter payment 2.1. addPaymentRq 2.1. 2. addPaymentRs 1.2. Display confirmation 2. Ok 3. Close view 3.1. View payments 2.1.1.1. addFinancialTransaction( ) 2.1. 1.1.1. financialTransaction Architectural Realizations (sequence diagrams) FinancialTransactionBase CreationData DisplayStatus FinancialTransactionConsumerData +creationData 1 +displayStatus 11 1 FinancialTransactionData FinancialTransaction FinancialTransactionExtended 0..1 * +note Note <<enumeration>> FinancialTransactionTypeCode PAYMENT FUNDS_TRANSFER CurrencyAmount 0..1 1 +specification FinancialTransactionSpecification +transactionType +amount 1 00....11 1 ProcessingData +processingData 11 1 0..1 1 +status ProcessingStatus +status +previousStep 1 0..1 ProcessingStep 0..1 * {ordered} Logical Data Model (class diagrams) hand modeled hand coded hand coded xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx PSM Interface Code (EJB) xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx generated generated Web Services Code (WSDL/SOAP) xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx Value Object Code (Java) PIM/PSM xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx Schema Definition (Torque XML) generated engineered xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx reverse xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx Schema Code (SQL) PAYMENTS AUDIT_ID : NUMBER(9, 0) ACT ION_CODE : NUMBER(9, 0) FI_TRANSACTION_SEQ_ID : NUMBER(9, 0) PAYEE_SEQ_ID : NUMBER(9, 0) BILL_SEQ_ID : NUMBER(9, 0) PROVIDER_SEQ_ID : NUMBER(9, 0) PAYEE_NAME : VARCHAR2(255) PAYEE_PHONE_NUMBER : VARCHAR2(32) NAME_ON_ACCOUNT : VARCHAR2(255) BILLING_ACCOUNT : VARCHAR2(255) PAYMENT_DESTINATION_TYPE : NUMBER(9, 0) ADDRESS1 : VARCHAR2(64) ADDRESS2 : VARCHAR2(64) ADDRESS3 : VARCHAR2(64) ADDRESS4 : VARCHAR2(64) CITY : VARCHAR2(32) STATE_PROV : VARCHAR2(32) POSTAL_CODE : VARCHAR2(11) COUNTRY_CODE : CHAR(3) ACT _PAYEE_NAME : VARCHAR2(255) REMITTANCE_METHOD : NUMBER(9, 0) ACT _PAYEE_PHONE_NUMBER : VARCHAR2(32) ACT _NAME_ON_ACCOUNT : VARCHAR2(255) ACT _BILLING_ACCOUNT : VARCHAR2(255) ACT _PAYMENT _DESTINAT ION_TYPE : NUMBER(9, 0) ACT _ADDRESS1 : VARCHAR2(64) ACT _ADDRESS2 : VARCHAR2(64) ACT _ADDRESS3 : VARCHAR2(64) ACT _ADDRESS4 : VARCHAR2(64) ACT _CITY : VARCHAR2(32) ACT _STATE_PROV : VARCHAR2(32) ACT _POSTAL_CODE : VARCHAR2(11) ACT _COUNTRY_CODE : CHAR(3) CHECK_NUMBER : VARCHAR2(40) ACT _REMIT TANCE_METHOD : NUMBER(9, 0) SERVICE_CENTER_SEQ_ID : NUMBER(9, 0) MERCHANT _SEQ_ID : NUMBER(9, 0) DEFAULT_ROUT ING_REASON : NUMBER(9, 0) DAYS_TO_PROCESS : NUMBER(9, 0) AUDIT_VERSION : NUMBER(9, 0) AUDIT_GENERATION : NUMBER(9, 0) AUDIT_DATE : DATE FINANCIAL_TRANSACTIONS AUDIT _ID : NUMBER(9, 0) ACTION_CODE : NUMBER(9, 0) FI_TRANSACTION_SEQ_ID : NUMBER(9, 0) LAST _MODIFIED_BY : NUMBER(9, 0) CONSUMER_SEQ_ID : NUMBER(9, 0) TRANSACT ION_TYPE : NUMBER(9, 0) MODEL_INSTANCE_NUMBER : NUMBER(9, 0) RECURRING_MODEL_SEQ_ID : NUMBER(9, 0) SOURCE_ACCOUNT_SEQ_ID : NUMBER(9, 0) SOURCE_ACCOUNT_TYPE_CODE : NUMBER(9, 0) SOURCE_ACCOUNT_NUMBER : VARCHAR2(32) SOURCE_ROUTING_NUMBER : VARCHAR2(9) SOURCE_ACCOUNT_HOLDER : VARCHAR2(255) REQUESTED_DATE : DATE REQUESTED_SCHEDULE_TYPE : NUMBER(9, 0) CREDIT_DATE : DATE PROCESS_DATE : DATE DISPLAY_STATUS_CODE : NUMBER(9, 0) CURRENCY_CODE : CHAR(3) AMOUNT : NUMBER(17, 2) CONSUMER_MEMO : VARCHAR2(255) DISPLAY_STATUS_MODIFIED_DATE : DATE DISPLAY_STATUS_MODIFIED_BY : NUMBER(9, 0) DISPLAY_STATUS_NOTE : VARCHAR2(255) PROCESSING_FLOW_TYPE : NUMBER(9, 0) PROCESSING_TIME : DATE RETRY_COUNT : NUMBER(9, 0) DEST INATION_PROVIDER_SEQ_ID : NUMBER(9, 0) PROCESS_STATUS_CODE : NUMBER(9, 0) AUTHORIZAT ION_PROVIDER_SEQ_ID : NUMBER(9, 0) DAYS_TO_CREDIT : NUMBER(9, 0) SOURCE_PROVIDER_SEQ_ID : NUMBER(9, 0) VALIDATE_STATUS_CODE : NUMBER(9, 0) PROCESS_STATUS_PROVIDER_SEQ_ID : NUMBER(9, 0) PROCESS_STATUS_MODIFIED_BY : NUMBER(9, 0) PROCESS_STATUS_MODIFIED_DATE : DATE PROCESS_STATUS_NOTE : VARCHAR2(255) VALIDATE_STATUS_MODIFIED_BY : NUMBER(9, 0) VALIDATE_STATUS_MODIFIED_DATE : DATE AUDIT _DATE : DATE AUDIT _VERSION : NUMBER(9, 0) VALIDATE_STATUS_NOTE : VARCHAR2(255) AUDIT _GENERATION : NUMBER(9, 0) hand coded Database Design Model (class diagram) 13 Copyright © 2004 InteliData
  14. 14. Why “manual transformation”? • Manual transformation “is not greatly different from how much good software design work has been done for years. The MDA approach adds value in two ways:” – “the explicit distinction between a platform independent model and the transformed platform specific model,” – “the record of the transformation.” • For InteliWorks… – Needed to establish effective modeling before introducing automation. – Lacked a business case for an effective team late in the product development cycle. The long-term benefits were not convincingly worth the short-term loss of productivity to introduce new tools. • The business case would likely be different for a new product development cycle. 14 Copyright © 2004 InteliData
  15. 15. Case study: Architecture • Dependency models – Payment Service dependencies • Architectural models to code – PaymentFe helper class – Add payment request value object class • Architectural models to Web services – WSDL for the Payment Service 15 Copyright © 2004 InteliData
  16. 16. Payment Service dependencies <<Interface>> PaymentFeExtended addPaymentNoteExtended() completePaymentExtended() failPaymentExtended() getPaymentsExtended() pendPaymentExtended() resubmitPaymentExtended() reversePaymentExtended() PaymentService <<Interface>> PaymentFe addPayment() cancelPayment() getPayments() getPaymentActivity() updatePayment() handlePayeeChange() OperationalDirectory <<Interface>> Payment SchedulingEvent (from Scheduler) (from Operational Directory Service) PaymentRead <<Interface>> PaymentUtility prepare() getRouting() checkForDuplicate() <<Interface>> PaymentEvent processPayments() Notification (from eMessenger) FinancialTransactionCommon (from Financial Transaction Service) PayeeUtility AccountUtility FinancialTransactionRead FinancialTransactionWrite FinancialTransactionUtility (from Financial Transaction Service) FinancialTransaction (from Financial Transaction Service) 16 Copyright © 2004 InteliData
  17. 17. PaymentFe helper class public class PaymentFeHelper { public static AddPaymentRsVO addPayment ( SessionVO session, AddPaymentRqVO request ) throws CheckedException, UncheckedException { … } public static CancelPaymentRsVO cancelPayment ( SessionVO session, CancelPaymentRqVO request ) throws CheckedException, UncheckedException { … } public static GetPaymentActivityRsVO getPaymentActivity ( SessionVO session, GetPaymentActivityRqVO request ) throws CheckedException, UncheckedException { … } public static GetPaymentsRsVO getPayments ( SessionVO session, GetPaymentsRqVO request ) throws CheckedException, UncheckedException { … } public static UpdatePaymentRsVO updatePayment ( SessionVO session, UpdatePaymentRqVO request ) throws CheckedException, UncheckedException { … } private static PaymentRequestMgr getPaymentRequestMgr () throws CheckedException, RemoteException { … } } 17 Copyright © 2004 InteliData
  18. 18. Add payment request value object class public class AddPaymentRqVO implements ValueObject { private PaymentSpecificationVO specification; public AddPaymentRqVO( ) { } public AddPaymentRqVO( PaymentSpecificationVO specification) { this.specification = specification; } public PaymentSpecificationVO getSpecification() { return this.specification; } public void setSpecification(PaymentSpecificationVO specification) { this.specification = specification; } } 18 Copyright © 2004 InteliData
  19. 19. WSDL for the Payment Service <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions …> … <wsdl:message name="addPaymentRequest"> <wsdl:part name="session" type="tns1:SessionVO"/> <wsdl:part name="request" type="tns1:AddPaymentRqVO"/> </wsdl:message> … <wsdl:portType name="PaymentService"> <wsdl:operation name="addPayment" parameterOrder="session request"> <wsdl:input message="impl:addPaymentRequest" name="addPaymentRequest"/> <wsdl:output message="impl:addPaymentResponse" name="addPaymentResponse"/> <wsdl:fault message="impl:ServiceException" name="ServiceException"/> </wsdl:operation> … </wsdl:portType> … </wsdl:definitions> 19 Copyright © 2004 InteliData
  20. 20. Case study: Data • Logical data model – Financial transaction entity model – Payment entity model • Logical model to code – Payment value object classes • Logical model to XML – Payment XML aggregate • Logical model to database schema – Payment tables 20 Copyright © 2004 InteliData
  21. 21. Financial transaction entity model FinancialTransactionBase CreationData DisplayStatus FinancialTransactionConsumerData +creationData 1 +displayStatus 11 1 FinancialTransactionData FinancialTransaction FinancialTransactionExtended 0..1 * +note Note <<enumeration>> FinancialTransactionTypeCode PAYMENT FUNDS_TRANSFER CurrencyAmount 0..1 1 +specification FinancialTransactionSpecification +transactionType +amount 1 00..11 1 ProcessingData +processingData 11 1 0..1 1 +status ProcessingStatus +status +previousStep 1 0..1 ProcessingStep 0..1 * {ordered} 21 Copyright © 2004 InteliData
  22. 22. Payment entity model FinancialTransactionConsumerData FinancialTransactionSpecification FinancialTransactionExtended PaymentExtended PaymentSpecification 0..1 1 +paymentSpecification +destination RoutedPaymentSpecification PaymentDestination 0..1 +paymentSpecification +source 0..1 00....11 0..1 0..1 +remittanceDetail 0..1 00....11 00....11 0..1 +destinationRoutingData 1 PaymentRemittanceDetail DestinationRoutingData Payment FiAccountSpecification 0..1 0..1 +actualDestination 22 Copyright © 2004 InteliData
  23. 23. Payment value object classes public abstract class FinancialTransactionBaseVO implements ValueObject { private Long financialTransactionId; private Date processDate; private Date creditDate; // Getter and setter methods … } public abstract class FinancialTransactionConsumerDataVO extends FinancialTransactionBaseVO { private CreationDataVO creationData; private DisplayStatusVO displayStatus; // Getter and setter methods … } public class PaymentVO extends FinancialTransactionConsumerDataVO { private RoutedPaymentSpecificationVO paymentSpecification; // Getter and setter methods … } 23 Copyright © 2004 InteliData
  24. 24. Payment XML aggregate <payment xsi:type="ns2:PaymentVO" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"> <financialTransactionId xsi:type="xsd:long">10006</financialTransactionId> <processDate xsi:type="xsd:dateTime">2004-06-01T04:00:00.000Z</processDate> <creditDate xsi:type="xsd:dateTime">2004-06-03T04:00:00.000Z</processDate> <creationData xsi:type="ns2:CreationDataVO"> … </creationData> <displayStatus xsi:type="ns2:DisplayStatusVO"> … </displayStatus> <paymentSpecification xsi:type="ns2:RoutedPaymentSpecificationVO"> <source xsi:type="ns2:FiAccountSpecificationVO"> … </source> <amount xsi:type="ns2:CurrencyAmountVO"> … </amount> <destination xsi:type="ns2:PaymentDestinationVO"> … </destination> <actualDestination xsi:type="ns2:PaymentDestinationVO"> … </actualDestination> <destinationRoutingData xsi:type="ns2:DestinationRoutingDataVO"> … </destinationRoutingData> … </paymentSpecification> </payment> 24 Copyright © 2004 InteliData
  25. 25. Payment tables PAYMENTS AUDIT_ID : NUMBER(9, 0) ACTION_CODE : NUMBER(9, 0) FI_TRANSACTION_SEQ_ID : NUMBER(9, 0) PAYEE_SEQ_ID : NUMBER(9, 0) BILL_SEQ_ID : NUMBER(9, 0) PROVIDER_SEQ_ID : NUMBER(9, 0) PAYEE_NAME : VARCHAR2(255) PAYEE_PHONE_NUMBER : VARCHAR2(32) NAME_ON_ACCOUNT : VARCHAR2(255) BILLING_ACCOUNT : VARCHAR2(255) PAYMENT_DESTINATION_TYPE : NUMBER(9, 0) ADDRESS1 : VARCHAR2(64) ADDRESS2 : VARCHAR2(64) ADDRESS3 : VARCHAR2(64) ADDRESS4 : VARCHAR2(64) CITY : VARCHAR2(32) STATE_PROV : VARCHAR2(32) POSTAL_CODE : VARCHAR2(11) COUNTRY_CODE : CHAR(3) ACT_PAYEE_NAME : VARCHAR2(255) REMITTANCE_METHOD : NUMBER(9, 0) ACT_PAYEE_PHONE_NUMBER : VARCHAR2(32) ACT_NAME_ON_ACCOUNT : VARCHAR2(255) ACT_BILLING_ACCOUNT : VARCHAR2(255) ACT_PAYMENT_DESTINATION_TYPE : NUMBER(9, 0) ACT_ADDRESS1 : VARCHAR2(64) ACT_ADDRESS2 : VARCHAR2(64) ACT_ADDRESS3 : VARCHAR2(64) ACT_ADDRESS4 : VARCHAR2(64) ACT_CITY : VARCHAR2(32) ACT_STATE_PROV : VARCHAR2(32) ACT_POSTAL_CODE : VARCHAR2(11) ACT_COUNTRY_CODE : CHAR(3) CHECK_NUMBER : VARCHAR2(40) ACT_REMITTANCE_METHOD : NUMBER(9, 0) SERVICE_CENTER_SEQ_ID : NUMBER(9, 0) MERCHANT_SEQ_ID : NUMBER(9, 0) DEFAULT_ROUTING_REASON : NUMBER(9, 0) DAYS_TO_PROCESS : NUMBER(9, 0) AUDIT_VERSION : NUMBER(9, 0) AUDIT_GENERATION : NUMBER(9, 0) AUDIT_DATE : DATE FINANCIAL_TRANSACTIONS AUDIT_ID : NUMBER(9, 0) ACTION_CODE : NUMBER(9, 0) FI_TRANSACTION_SEQ_ID : NUMBER(9, 0) LAST_MODIFIED_BY : NUMBER(9, 0) CONSUMER_SEQ_ID : NUMBER(9, 0) TRANSACTION_TYPE : NUMBER(9, 0) MODEL_INSTANCE_NUMBER : NUMBER(9, 0) RECURRING_MODEL_SEQ_ID : NUMBER(9, 0) SOURCE_ACCOUNT_SEQ_ID : NUMBER(9, 0) SOURCE_ACCOUNT_TYPE_CODE : NUMBER(9, 0) SOURCE_ACCOUNT_NUMBER : VARCHAR2(32) SOURCE_ROUTING_NUMBER : VARCHAR2(9) SOURCE_ACCOUNT_HOLDER : VARCHAR2(255) REQUESTED_DATE : DATE REQUESTED_SCHEDULE_TYPE : NUMBER(9, 0) CREDIT_DATE : DATE PROCESS_DATE : DATE DISPLAY_STATUS_CODE : NUMBER(9, 0) CURRENCY_CODE : CHAR(3) AMOUNT : NUMBER(17, 2) CONSUMER_MEMO : VARCHAR2(255) DISPLAY_STATUS_MODIFIED_DATE : DATE DISPLAY_STATUS_MODIFIED_BY : NUMBER(9, 0) DISPLAY_STATUS_NOTE : VARCHAR2(255) PROCESSING_FLOW_TYPE : NUMBER(9, 0) PROCESSING_TIME : DATE RETRY_COUNT : NUMBER(9, 0) DESTINATION_PROVIDER_SEQ_ID : NUMBER(9, 0) PROCESS_STATUS_CODE : NUMBER(9, 0) AUTHORIZATION_PROVIDER_SEQ_ID : NUMBER(9, 0) DAYS_TO_CREDIT : NUMBER(9, 0) SOURCE_PROVIDER_SEQ_ID : NUMBER(9, 0) VALIDATE_STATUS_CODE : NUMBER(9, 0) PROCESS_STATUS_PROVIDER_SEQ_ID : NUMBER(9, 0) PROCESS_STATUS_MODIFIED_BY : NUMBER(9, 0) PROCESS_STATUS_MODIFIED_DATE : DATE PROCESS_STATUS_NOTE : VARCHAR2(255) VALIDATE_STATUS_MODIFIED_BY : NUMBER(9, 0) VALIDATE_STATUS_MODIFIED_DATE : DATE AUDIT_DATE : DATE AUDIT_VERSION : NUMBER(9, 0) VALIDATE_STATUS_NOTE : VARCHAR2(255) AUDIT_GENERATION : NUMBER(9, 0) 25 Copyright © 2004 InteliData
  26. 26. Conclusions • MDA has value, even without automated transformation. • Advantages of manual transformation – No need to purchase and learn transformation tools. – No need to develop and maintain formal, executable transformation definitions. – Ability to quickly adapt as circumstances dictate. • Disadvantages of manual transformation – Requires continuing effort and process discipline. – Unintentional inconsistencies are inevitable. – Compromises most be made to keep transformations simple enough to be manually tractable. – Care must be given to maintaining clear traceability. 26 Copyright © 2004 InteliData

×