Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Model Driven Architecture without Automation

119 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.

NOTE: This presentation used to be on my Slideshare, but it seems to have gotten deleted, so I have uploaded it again.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Model Driven Architecture without Automation

  1. 1. Copyright © 2004 InteliData A Real-World Example of MDA without Automation Ed Seidewitz 26 August 2004
  2. 2. Copyright © 2004 InteliData2 Agenda • Background • Model-driven architecture • Case study • Conclusions
  3. 3. Copyright © 2004 InteliData3 Background • Consumer bill payment • InteliWorks architecture • InteliWorks development
  4. 4. Copyright © 2004 InteliData4 Background: Consumer bill payment Consumer Computer ConsumerConsumer ComputerComputer Web Banking/ Bill Pay UI Web Banking/Web Banking/ Bill Pay UIBill Pay UI Bill Payment Warehouse Bill PaymentBill Payment WarehouseWarehouse Funding System FundingFunding SystemSystem Remittance Provider RemittanceRemittance ProviderProvider Internet Bank-owned systems Batch files (Bank system /ACH / …) MerchantsMerchantsMerchants
  5. 5. Copyright © 2004 InteliData5 Background: InteliWorks architecture
  6. 6. Copyright © 2004 InteliData6 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.
  7. 7. Copyright © 2004 InteliData7 Model-driven architecture • What is it? • What is a platform? • CIM, PIM, PSM and all that… • Transformations • Why “manual transformation”?
  8. 8. Copyright © 2004 InteliData8 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.”
  9. 9. Copyright © 2004 InteliData9 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.”
  10. 10. Copyright © 2004 InteliData10 MDA: CIM, PIM, PSM and all that… • “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.” From the MDA Guide Version 1.0.1 (omg/2003-06-01)
  11. 11. Copyright © 2004 InteliData11 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
  12. 12. Copyright © 2004 InteliData12 Case study • Overview • Architecture • Data
  13. 13. Copyright © 2004 InteliData13 Case study: Overview Consumer: Payment - View Payments Consumer Consumer: Payment - Cancel Consumer: Payment - Create (without Bill) Consumer: Payment - Modify Consumer: Payment - View Activity <<extend>> Consumer: Payment - Validate <<extend>> <<include>> <<extend>> <<include>> Consumer: Payment - Route <<include>> <<include>> <<extend>> Requirements Model (use case and activity diagrams) PaymentService PaymentFe <<Interface>> addPayment() cancelPayment() getPayments() getPaymentActivity() updatePayment() PaymentRead PaymentEvent <<Interface>> processPayments() PaymentFeExtended <<Interface>> addPaymentNoteExtended() completePaymentExtended() failPaymentExtended() getPaymentsExtended() pendPaymentExtended() resubmitPaymentExtended() reversePaymentExtended() Notification (from eMessenger) FinancialTransactionCommon (from Financial Transaction Service) PayeeUtility AccountUtility FinancialTransactionWrite OperationalDirectory (from Operational Directory Service) FinancialTransactionUtility (from Financial Transaction Service) FinancialTransaction (from Financial Transaction Service) SchedulingEvent (from Scheduler) Payment <<Interface>> handlePayeeChange() FinancialTransactionRead PaymentUtility <<Interface>> prepare() getRouting() checkForDuplicate() Dependency Model (class diagrams) : Consumer : ConsumerFrontEnd : XmlConnector : PaymentService : FinancialTransactionService Sequence Diagram: InteliWorks Consumer: Payment Realizations / Consumer: Payment - View Payments 1. Create payment 2.1. addPaymentRq 2.1.2. addPaymentRs 1.2. Display confirmation 2. Ok 3. Close view 3.1. View payments 2.1.1. addPayment( ) 2.1.1.2. payment 1.1. Enter payment Sequence Diagram: InteliWorks Consumer: Payment Realizations / Consumer: Payment - Enter 2.1.1.1. addFinancialTransaction( ) 2.1.1.1.1. financialTransaction Sequence Diagram: InteliWorks Consumer: Financial Transaction Realizations / Consumer: Financial Transaction - Add Architectural Realizations (sequence diagrams) FinancialTransactionBase DisplayStatus CreationData FinancialTransactionConsumerData 1 11 +displayStatus 1 +creationData 11 FinancialTransactionData FinancialTransaction Note FinancialTransactionExtended 0..1 * 0..1 +note* CurrencyAmount FinancialTransactionTypeCode <<enumeration>> PAYMENT FUNDS_TRANSFER FinancialTransactionSpecification 0..1 1 0..1 +specification1 0..11 0..1 +amount 1 +transactionType 11 ProcessingData 1 11 +processingData 1 ProcessingStatus 0..1 1 0..1 +status 1 ProcessingStep 0..1 * 0..1 +previousStep {ordered} * +status 0..1 1 0..1 1 Logical Data Model (class diagrams) xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx Interface Code (EJB) xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx Web Services Code (WSDL/SOAP) xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx Value Object Code (Java) xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx Schema Code (SQL) 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) Database Design Model (class diagram) xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx Schema Definition (Torque XML) CIM PIM PSM PIM/PSM hand coded hand coded handcoded generated generated generated reverse engineered hand modeled hand modeled handmodeled traceshand modeled Implementation platform • J2EE (WebLogic app server) • Relational DB (Oracle DBMS) • Web services (Apache Axis)
  14. 14. Copyright © 2004 InteliData14 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.
  15. 15. Copyright © 2004 InteliData15 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
  16. 16. Copyright © 2004 InteliData16 Payment Service dependencies PaymentService PaymentFe <<Interface>> addPayment() cancelPayment() getPayments() getPaymentActivity() updatePayment() PaymentRead PaymentEvent <<Interface>> processPayments() PaymentFeExtended <<Interface>> addPaymentNoteExtended() completePaymentExtended() failPaymentExtended() getPaymentsExtended() pendPaymentExtended() resubmitPaymentExtended() reversePaymentExtended() Notification (from eMessenger) FinancialTransactionCommon (from Financial Transaction Service) PayeeUtility AccountUtility FinancialTransactionWrite OperationalDirectory (from Operational Directory Service) FinancialTransactionUtility (from Financial Transaction Service) FinancialTransaction (from Financial Transaction Service) SchedulingEvent (from Scheduler) Payment <<Interface>> handlePayeeChange() FinancialTransactionRead PaymentUtility <<Interface>> prepare() getRouting() checkForDuplicate()
  17. 17. Copyright © 2004 InteliData17 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 { … } }
  18. 18. Copyright © 2004 InteliData18 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; } }
  19. 19. Copyright © 2004 InteliData19 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>
  20. 20. Copyright © 2004 InteliData20 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
  21. 21. Copyright © 2004 InteliData21 Financial transaction entity model FinancialTransactionBase DisplayStatus CreationData FinancialTransactionConsumerData 1 11 +displayStatus 1 +creationData 11 FinancialTransactionData FinancialTransaction Note FinancialTransactionExtended 0..1 * 0..1 +note* CurrencyAmount FinancialTransactionTypeCode <<enumeration>> PAYMENT FUNDS_TRANSFER FinancialTransactionSpecification 0..1 1 0..1 +specification1 0..11 0..1 +amount 1 +transactionType 11 ProcessingData 1 11 +processingData 1 ProcessingStatus 0..1 1 0..1 +status 1 ProcessingStep 0..1 * 0..1 +previousStep {ordered} * +status 0..1 1 0..1 1
  22. 22. Copyright © 2004 InteliData22 Payment entity model PaymentExtended PaymentRemittanceDetail DestinationRoutingData FiAccountSpecification Payment FinancialTransactionConsumerData FinancialTransactionSpecification FinancialTransactionExtended PaymentSpecification PaymentDestinationRoutedPaymentSpecification 0..1 1 0..1 +paymentSpecification 1 0..1 0..1 0..1 +remittanceDetail 0..1 0..1 0..1 0..1 +destinationRoutingData0..1 0..10..1 0..1 +source 0..1 0..1 1 0..1 1 +paymentSpecification 0..1 0..1 0..1 +actualDestination0..1 +destination 0..1 0..10..1 0..1
  23. 23. Copyright © 2004 InteliData23 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 … }
  24. 24. Copyright © 2004 InteliData24 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>
  25. 25. Copyright © 2004 InteliData25 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)
  26. 26. Copyright © 2004 InteliData26 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.

×