copyright © 2004 intelidata a real-world example of mda without automation ed seidewitz 26 august...

Copyright © 2004 InteliData

A Real-World Example ofMDA without Automation

Ed Seidewitz26 August 2004


2

Agenda

• Background

• Model-driven architecture

• Case study

• Conclusions


3

Background

• Consumer bill payment

• InteliWorks architecture

• InteliWorks development


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


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


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.


7

Model-driven architecture

• What is it?

• What is a platform?

• CIM, PIM, PSM and all that…

• Transformations

• Why “manual transformation”?


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


9

MDA: What is a platform?


“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

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


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


12

Case study

• Overview

• Architecture

• Data


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)


Web Services Code(WSDL/SOAP)


Value Object Code(Java)


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)


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)


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.


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


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()


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 { … }}


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; }}


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>


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


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


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


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 …}


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>


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)


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.

copyright © 2004 intelidata a real-world example of mda without automation ed seidewitz 26 august...

Documents