1 / 21

Adopting MDA in a large IT consultancy organization – opportunities, challenges and lessons learnt

Adopting MDA in a large IT consultancy organization – opportunities, challenges and lessons learnt. Vinay Kulkarni* and Sreedhar Reddy, Tata Research Development and Design Centre, Pune, INDIA vinay.vkulkarni@tcs.com. Ground situation Crack design team Functional Architectural

tarak
Download Presentation

Adopting MDA in a large IT consultancy organization – opportunities, challenges and lessons learnt

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. Adopting MDA in a large IT consultancy organization – opportunities, challenges and lessons learnt Vinay Kulkarni* and Sreedhar Reddy, Tata Research Development and Design Centre, Pune, INDIA vinay.vkulkarni@tcs.com

  2. Ground situation Crack design team Functional Architectural Shortage of experienced OO programmers Lack of proven industrial-scale OO development methods Lack of robust development tools A core banking product To be delivered on state-of-the-art technologies i.e. OO, 3-tier client-server architecture with OLTP monitor, rich GUI etc. Customizable offering catering to purpose-specific choice of Business functionality Business process Technology platforms like RDBMSs, OLTP monitors and GUI platforms Long life Off the shelf product or bespoke solution It all began in 1994

  3. A small team of experienced architects manually implemented a sample functionality covering all the layers of implementation architecture Objectives Firm up broad architectural decisions as regards scalability, throughout, response time etc Familiarization with finer nuances of technology platforms Lead to coding guidelines and best practices Revelations Typical business logic has low algorithmic complexity Several reusable design and architectural patterns Architecture can be neatly separated from business logic Architectural prototype

  4. Business logic Solution architecture Intuition Complete implementation Snippet1 Snippet2 Snippetk Specification Specification1 Specification2 Specification3 Generate solution architecture specific code from its declarative specifications

  5. Our MDA approach - overview • A meta model captures a recurring code pattern • All meta models defined in terms of a meta meta model • A model based code generator is an interpreter of meta meta model • Application structure captured in extended UML models • Business logic specified using a DSL • Application specifications (i.e. PIM) are translated into a PSI using PSM-specific code-generators that encode choice of design strategies, architecture decisions and technology platforms • Integrate independently generated code snippets in a consistent manner through an architecture • Component-based development process to manage size and facilitate independent development

  6. Unified meta model View of GUI layer meta model App layer meta model Db layer meta model Instance of Application specification Decomposes into GUI layer model App layer model Db layer model Model to code transformation GUI layer code App layer code Db layer code Composed from Application implementation Example – a client/server application

  7. Our MDA approach - architecture as the integrating glue • MVC paradigm • Well-defined interfaces • Universal interface in the form of services • Object façade over relational database • Transactional integrity, distribution transparency and scale-up courtesy middleware GUI UI manager Universal Interface Application Services DM Database Application Server

  8. Our MDA approach - component based development Component workspace Model workspace Code workspace Workspace for sharing Application release

  9. Class definition Attribute handling logic Getter/Setter Default constructor and copy constructor Persistence Primary- and Alternate-key based CRUDE methods Primary- and foreign-key based association handling Design strategies Soft locking, Soft delete, Auditing, Error handling, Trace logs Object-wrapper for non primary-key based data accesses Component deployment Bean class, Remote interface and Deployment descriptor Screen definition Layout Server-side interface Placeholder for Event logic Testing support Look-n-feel Interaction with server-side Testing support Unit test harness for a service, Test data generation Build support Makefiles Model based code generation

  10. Representative usage data

  11. Product-lines and large projects adopted the approach Technology-proofing Increased productivity Uniformly high code quality Consistent implementation of design strategies, best practices, guidelines etc. Prevention and early detection of errors More complete testing of application Enhanced reusability Small and medium sized projects didn’t find the approach attractive enough to adopt High learning curve Perceived loss of control Customizing code generators takes time Less agile development process Tight coupling with repository Unidirectional synchronization from model to code No debugging support at model level Complex versioning and configuration management In our experience

  12. D T A Selection Repository of building blocks Modification d a t Composition Model d’ a’ t’ Generates Code Addressing customizability of code generators Model-based code generator Generic code generator generator Intuition - meta tools delivering tools

  13. Customizable code generators • A code generator is a hierarchical composition of building blocks • Building block is an unifying abstraction to specify • [Aspect] Model • Model transformation • Model translation • Code generation is a three-step walk over the composition tree • Model creation • Model transformation • Code weaving • Uses OMG QVT and OMG MTT standards Base model Aspect model Model to model transformation Model to text transformation Text artefacts

  14. Code generation steps • Instantiation step • Models are stamped out (leaf level) • Models are merged (non-leaf level) • Transformation step • Code fragments are generated (leaf level) • Weaving specifications are generated (non-leaf level) • Composition step • Code fragments are weaved as per the weaving specifications Model2Java Functionality Persistence Object model Attribute handling OR map Audit

  15. In our experience Building-block based restructuring of code generators led to • Product-line of code generators • Refined organization of development team as platform-experts, architecture-experts etc. • Smaller development team • Reuse across product-lines Thus • Enabling definition of a software factory • Removing the tools team as a bottleneck as the factory can be instantiated elsewhere too

  16. Business logic Solution architecture Addressing high learning curve Complete implementation Snippet1 Snippet2 Snippetk Java Tag1 Tag2 Tag3 Generate solution architecture specific code from its declarative specification encapsulated in tags using a code-centric development approach

  17. Tag definitions Code fragments Metadata-driven aspect-oriented development Class model Architect Tag processor Business logic with metadata Developer Weaver The toolset is realized as a set of Eclipse plug-ins

  18. Easy adoption by small to medium sized projects No / low learning curve Agile loosely coupled development process Quick turn-around time for a change Quick development of purpose-specific tools Adherence to industry-standard technologies Leads to a repository of reusable software artefacts Generated application can be effectively maintained simply with JDK However, A small project grows into a large project A small offering acquires product-line nature over time Large-sized projects are better managed with higher-level abstractions Therefore, A hybrid approach capable of supporting code-centric, model-centric and easy switching between the two seems called for. In our experience

  19. Code fragments Code fragments Merged approach Annotated class models Model to model transformation MDD models Building block1 (for Tag1) Building block2 (for Tag2) Skeleton building block Business logic with metadata Class definition Weaver Metadata-driven aspect-oriented approach Model-driven development approach

  20. Summary • MDA delivers increased productivity, better code quality, platform independence and easier change management • Excellent for large projects and product-lines • Metadata-driven aspect-oriented approach seems to suit small and medium-sized projects better • Need to evolve suitable development methods that allow MDA to be adopted in a more flexible and incremental manner than all-or-nothing top-down manner • Proposed an approach to address this pertinent need

  21. Questions?

More Related