Model Driven Architecture - PowerPoint by BhFk7Br8

VIEWS: 0 PAGES: 17

									Model Driven Architecture
        (MDA)
    Partha Kuchana
Agenda
•   What is MDA
•   Modeling Approaches
•   MDA in a NutShell
•   MDA Models
•   SDLC
•   MDA Models (an Example)
•   MDA - Advantages
•   MDA - Reality Check
What is MDA ?
• Model Driven Architecture
• What is Model
   • abstraction of something that exists in reality
   • description of a (business) system in a [formal way]
What is MDA ?
• Software Modeling Approaches
• OMG framework for software development, which is top-down and
  driven by the business

      Code Only         Code
      [No Model]




   Code Visualization
  [Code is the Model]   Code   Model



       RoundTrip
      Engineering
  [Code and Model Co-   Code   Model
         Exist]




    Model Centric
  [Model is the Code]   Code   Model




      Model Only
      [No Code]                Model
Modeling Approaches
• Code Only
   • No formal model exists
   • Modeling is done in the form of programming
     abstractions e.g., packages and modules
   • Might work for small scale efforts
   • Makes maintenance difficult

• Code is Model
   • Pictorial representation of the code base
   • No real high level model
   • Developers can alter model elements through code
Modeling Approaches
• Code and Model Co-exist (RTE)
   • High level model exists
   • Transformation from model to code is manual
      • Automated tools could be used to generate stubs
   • Code and model evolve through iterations
   • Code or model may be changed for error-correction
      • If not controlled through an effective process, gets
        code and model out of sync

• Model-centric
  • Model exists with sufficient details
     • Business Rules
     • Integration Requirements
Modeling Approaches
      • Business Requirements
      • UI Representation Details
      • Business Logic
   • Transformation from model to code is automated

• Model only
  • Corresponding code transformation may not occur
    (solution architecture in proposals and software
    architecture documents)
  • Model and code are disconnected (O/N/R* shoring)
MDA in a Nutshell




          MDA
MDA Models
• MDA is a way to organize and manage enterprise
  architectures supported by automated tools and services for
  both defining the models and facilitating transformations
  between different model types. (OMG Definition)

• Platform Independent Model (PIM)
    • Fundamental Business Function and Behavior
    • Created using UML

• Platform Specific Model (PSM)
    • Specification of the Application in terms of the
      Implementation Constructs
    • Specific to a Given Target Platform
    • Based on the PIM
MDA Models
• Code Model
   • Based on PSM
   • Implementation in a Specific Language

• MDD
       • Model is used as a primary artifact to generate an
         efficient implementation through transformations
       • Work carried out by developers in an MDA based
         implementation
       • MDA - MDD made formal (by OMG)

• Example:
   • Functionality around an insurance policy and a
     customer
   SDLC
                                                                 Traditional


 Requirements                                                                Build/Coding          Testing   Deployment
 Gathering/An                              Design
    alysis




          Analysis and Requirements
                Specification                       Detailed System Design                  Code




                     Usecases/ PIM
                                                                PSM                           Code




       Req                            Design                          Build/Coding                 Testing    deployment
Gathering/Analysis




                                                                        MDA
             MDA Models (an Example)
 Platform Independent Model                                                                         Platform Specific Model
             Policy                               Customer                                               (EJB Component)
                                 1                                                             <<EJBEntityComponent>>
          effDate: Date      *                 firstName: String                                       Policy               <<EJBDataSchema>>
         expDate: Date                         lastName: String                                                                    and
         Premium: Real                         Address: Address                                                              <<EJBKeyClass>>
       policyType: Integer
                                                                                               <<EJBEntityComponent>>
                                                                                                     Customer
         getPremium()




                                                                                  Platform Specific Model
Platform Specific Model (Relational)
                                                                                      (Web Component)
                                                                                <<WebComponent>>        <<WebDataSchema>>
        Policy                                Customer                               Policy


     effDate: DATE                     firstName: VARCHAR(30)
     expDate: DATE                     lastName: VARCHAR(30)                    <<WebComponent>>
    Premium: REAL                       Address: VARCHAR(30)                        Customer
 policyType: INTEGER




                                                                   Code Model
       Oracle DDL                        JSP Code                                                                                  EJB Code
                                                                            Infrastructure/Deployment/Plumbing Code
Advantages
• MN language suitable for automated interpretation
   • Increased Productivity
       • Automated code generation (not just stubs)
       • Higher level of abstraction to the SD process
       • High quality, Standards Based, Consistent Code base

• Helps preserve development investment
   • Insulates business from technology evolution

• Requires strong collaboration between IT and
  Business
   • Top down development
       • More in alignment with the real-world
       • empowering business users
Advantages
• Model (in action) validation
     • capture requirements more effectively
• Suitable for modern day development approaches
• Portability
   • Focus on PIMs, transform to multiple PSMs (platforms)
     • Enables transition to newer technologies seamless to gain
       business value (java, xml, web services)
• Interoperability
   • Bridges, for communication between PSMs
• Documentation
   • Low and high level
   • Useful/meaningful documentation
   • Automated
• Automated Integration
•   support for automated testing *
MDA – Reality Check
• MDA <> Math
• UML is not sufficient to describe complex business
  interactions
   • leads to proprietary extensions
       • Affects portability
   • Cannot produce fully functional application
• One-size fits all approach
   • Potential for inefficient code
• Domain experts with business knowledge may need
  to learn UML
• Built in transformations
   • Needs customizations
   • Complex template merging may be required
   • Can be minimized with rich set of templates
MDA – Reality Check
• Provides a higher level of abstraction to the SD process

• Before you start using MDA
    • Support for powerful frameworks for robust system design
    • Limit on the number of business entities that can be modeled
    • Support for automated testing
        • Plug-play with testing tools
    • Support for integration
    • Estimate the amount of customization needed
         • DB related customizations, not just code
    • Estimate the template merging effort
         • Continued vendor support for template merging for new releases
    • Consider the efficiency of the generated code
    • Have a process to ensure top-down development
       • requirements must always flow from top down
       • Eliminates the scope for technology defining business
         requirements
Questions

								
To top