A Real-World Example of MDA without Automation
description
Transcript of A Real-World Example of MDA without Automation
Copyright © 2004 InteliData
A Real-World Example ofMDA without Automation
Ed Seidewitz26 August 2004
Copyright © 2004 InteliData
2
Agenda
• Background
• Model-driven architecture
• Case study
• Conclusions
Copyright © 2004 InteliData
3
Background
• Consumer bill payment
• InteliWorks architecture
• InteliWorks development
Copyright © 2004 InteliData
4
Background: Consumer bill payment
Consumer ComputerConsumer Consumer ComputerComputer
Web Banking/ Bill Pay UI
Web Banking/ Web Banking/ Bill Pay UIBill Pay UI
Bill Payment Warehouse
Bill Payment Bill Payment WarehouseWarehouse
Funding SystemFunding Funding SystemSystem
Remittance Provider
Remittance Remittance ProviderProvider
Internet
Bank-owned systems
Batch files
(Bank system / ACH / …)
MerchantsMerchantsMerchants
Copyright © 2004 InteliData
5
Background: InteliWorks architecture
Application TierApplication TierApplication Tier
Data TierData TierData Tier
Presentation TierPresentation TierPresentation Tier
Financial WarehouseFinancial WarehouseFinancial Warehouse
Gateway ServicesGateway Gateway ServicesServices
Adapter Data
Adapter Adapter DataData
Gateway ServicesGateway Gateway ServicesServices
Adapter Data
Adapter Adapter DataData
Back-End Data
BackBack--End End DataData
Back-End Data
BackBack--End End DataData
Consumer Services
Consumer Consumer ServicesServices
Consumer Front EndConsumer Consumer Front EndFront End
CSR/ Admin Front EndsCSR/ Admin CSR/ Admin Front EndsFront Ends
Consumer Data
Consumer Consumer DataData
Consumer Services
Consumer Consumer ServicesServices
Consumer Front EndConsumer Consumer Front EndFront End
CSR/ Admin Front EndsCSR/ Admin CSR/ Admin Front EndsFront Ends
Consumer Data
Consumer Consumer DataData
Event notificationEvent notification
RequestsRequests
ResponsesResponses
Web ServicesWeb Services
RMIRMI
Copyright © 2004 InteliData
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.
Copyright © 2004 InteliData
7
Model-driven architecture
• What is it?
• What is a platform?
• CIM, PIM, PSM and all that…
• Transformations
• Why “manual transformation”?
Copyright © 2004 InteliData
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.”
Copyright © 2004 InteliData
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.”
Copyright © 2004 InteliData
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.”
Copyright © 2004 InteliData
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
Copyright © 2004 InteliData
12
Case study
• Overview
• Architecture
• Data
Copyright © 2004 InteliData
13
Case study: OverviewConsumer: Payment - View
PaymentsConsumer
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>>
PAYMENTFUNDS_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)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxx xxxxxxx ]xxxx
Interface Code(EJB)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxx xxxxxxx ]xxxx
Web Services Code(WSDL/SOAP)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxx xxxxxxx ]xxxx
Value Object Code(Java)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 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 : DATEREQUESTED_SCHEDULE_TYPE : NUMBER(9, 0)CREDIT_DATE : DATEPROCESS_DATE : DATEDISPLAY_STATUS_CODE : NUMBER(9, 0)CURRENCY_CODE : CHAR(3)AMOUNT : NUMBER(17, 2)CONSUMER_MEMO : VARCHAR2(255)DISPLAY_STATUS_MODIFIED_DATE : DATEDISPLAY_STATUS_MODIFIED_BY : NUMBER(9, 0)DISPLAY_STATUS_NOTE : VARCHAR2(255)PROCESSING_FLOW_TYPE : NUMBER(9, 0)PROCESSING_TIME : DATERETRY_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 : DATEPROCESS_STATUS_NOTE : VARCHAR2(255)VALIDATE_STATUS_MODIFIED_BY : NUMBER(9, 0)VALIDATE_STATUS_MODIFIED_DATE : DATEAUDIT_DATE : DATEAUDIT_VERSION : NUMBER(9, 0)VALIDATE_STATUS_NOTE : VARCHAR2(255)AUDIT_GENERATION : NUMBER(9, 0)
Database Design Model(class diagram)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxx xxxxxxx ]xxxx
Schema Definition(Torque XML)
CIM
PIM
PSM
PIM/PSM
hand coded hand coded
hand
cod
ed
genera
ted
genera
ted
generated
reverse
eng
ineere
d
hand modeled hand modeled
hand
mod
ele
d
traceshand modeled
Implementation platform•J2EE (WebLogic app server)•Relational DB (Oracle DBMS)•Web services (Apache Axis)
Implementation platform•J2EE (WebLogic app server)•Relational DB (Oracle DBMS)•Web services (Apache Axis)
Copyright © 2004 InteliData
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.
Copyright © 2004 InteliData
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
Copyright © 2004 InteliData
16
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()
Copyright © 2004 InteliData
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 { … }}
Copyright © 2004 InteliData
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; }}
Copyright © 2004 InteliData
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>
Copyright © 2004 InteliData
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
Copyright © 2004 InteliData
21
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>>
PAYMENTFUNDS_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
Copyright © 2004 InteliData
22
Payment entity model
PaymentExtended
PaymentRemittanceDetail DestinationRoutingData
FiAccountSpecification
Payment
FinancialTransactionConsumerData FinancialTransactionSpecification FinancialTransactionExtended
PaymentSpecification
PaymentDestinationRoutedPaymentSpecification
0..1
1
0..1
+paymentSpecification1
0..1
0..1
0..1
+remittanceDetail0..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..10..1
0..1+actualDestination0..1
+destination
0..1 0..10..1 0..1
Copyright © 2004 InteliData
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 …}
Copyright © 2004 InteliData
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>
Copyright © 2004 InteliData
25
Payment tablesPAYMENTS
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 : DATEREQUESTED_SCHEDULE_TYPE : NUMBER(9, 0)CREDIT_DATE : DATEPROCESS_DATE : DATEDISPLAY_STATUS_CODE : NUMBER(9, 0)CURRENCY_CODE : CHAR(3)AMOUNT : NUMBER(17, 2)CONSUMER_MEMO : VARCHAR2(255)DISPLAY_STATUS_MODIFIED_DATE : DATEDISPLAY_STATUS_MODIFIED_BY : NUMBER(9, 0)DISPLAY_STATUS_NOTE : VARCHAR2(255)PROCESSING_FLOW_TYPE : NUMBER(9, 0)PROCESSING_TIME : DATERETRY_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 : DATEPROCESS_STATUS_NOTE : VARCHAR2(255)VALIDATE_STATUS_MODIFIED_BY : NUMBER(9, 0)VALIDATE_STATUS_MODIFIED_DATE : DATEAUDIT_DATE : DATEAUDIT_VERSION : NUMBER(9, 0)VALIDATE_STATUS_NOTE : VARCHAR2(255)AUDIT_GENERATION : NUMBER(9, 0)
Copyright © 2004 InteliData
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.