1 / 26

A Real-World Example of MDA without Automation

A Real-World Example of MDA without Automation. Ed Seidewitz 26 August 2004. Agenda. Background Model-driven architecture Case study Conclusions. Background. Consumer bill payment InteliWorks architecture InteliWorks development. Background: Consumer bill payment.

rusty
Download Presentation

A Real-World Example of MDA without Automation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  5. Background: InteliWorks architecture

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

  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. hand modeled hand modeled traces xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx hand modeled hand coded Dependency Model (class diagrams) Architectural Realizations (sequence diagrams) Logical Data Model (class diagrams) Schema Definition (Torque XML) hand coded hand modeled hand coded generated xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx xxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx xxxxxxxxxx xxxxxxx ]xxxx reverse engineered generated generated Interface Code (EJB) Web Services Code (WSDL/SOAP) Value Object Code (Java) Schema Code (SQL) Database Design Model (class diagram) Case study: Overview CIM • Implementation platform • J2EE (WebLogic app server) • Relational DB (Oracle DBMS) • Web services (Apache Axis) Requirements Model (use case and activity diagrams) PIM/PSM PIM PSM

  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

  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

  22. Payment entity model

  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 tables

  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.

More Related