1 / 32

Model-Driven Architecture & Software Factories

Model-Driven Architecture & Software Factories. April 24, 2006 Radhika Pasumarthi Bhavesh Thakker. Agenda. Model Driven Development (MDD) Model Driven Architecture (MDA) Eclipse Modeling Framework (EMF) Software Factories (SF) Discussion – MDA vs. SF Conclusion. MDD – Why?.

ruthdennis
Télécharger la présentation

Model-Driven Architecture & Software Factories

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. Model-Driven Architecture & Software Factories April 24, 2006 Radhika Pasumarthi Bhavesh Thakker

  2. Agenda • Model Driven Development (MDD) • Model Driven Architecture (MDA) • Eclipse Modeling Framework (EMF) • Software Factories (SF) • Discussion – MDA vs. SF • Conclusion

  3. MDD – Why? • move from documentation to automation • language-based abstractions - numerical encoding > assembly > structured > object-oriented languages > byte coded languages and design patterns • In each generation, language designers produce constructs for lessons learned in the previous generation, and then architects use them to build more complex and powerful abstractions. • seek to increase productivity and predictability in software development using methodologies

  4. MDD – Concerns • visualize the domain and generation of implementation artifacts • graphically represent code syntax and code concepts or domain concepts and structures • clear distinction between domain engineering and application engineering. • domain - application platform • application – application implementation. • model portability, to be able to bridge a model between different meta-modeling languages • creating usable models that ease knowing code assets make it easy to inventory and visualize them

  5. MDA - Introduction • requirement for cross-platform development arises from the fast-pacing technology scene and the resulting uncertainty – EJB 2 today, EJB 3 tomorrow, or is it .NET? • An approach to system specification that separates the two specifications of system functionality and its implementation on a certain technology platform. • Models: representation of a part of function, structure and/or behavior of a system • designed “bottom-up” (starting from the target platform)

  6. MDA continued…

  7. MDA Process

  8. MDA continued… • Developing software as a DAG (directed acyclic graph) of platform-independent and platform-specific models (PIM, PSM) with transformations in-between. • CIM – Compuation Independent Model • high-level overview of the software system • PIM – Platform Independent Model • provides formal specifications of the structure and function of the system that abstract away technical details • PSM – Platform Specific Model • expressed in terms of the specification model of the target platform

  9. Eclipse • an extensible development platform and application frameworks for building software. • a framework for program development into which programs can be added • plug-in based framework • Tool builders contribute to the Eclipse platform by wrapping their tools in pluggable components • EMF Plug-in • following MDA* example built and executed based on the EMF plug-in

  10. EMF - Introduction • Eclipse Modeling Framework (EMF) • Java framework and code generation facility for building tools and other applications based on a structured model • Exploits the facilities offered in Eclipse to... • Generate code without losing user customizations (merge) • Consistent and Efficient • Improve extensibility • Provide a UI layer • What is an EMF "model"? • Specification of your application's data • Object attributes • Relationships (associations) between objects • Operations available on each object • Simple constraints (eg. cardinality) on objects and relationships • Essentially it represents the class diagram of the application

  11. EMF - Models • Not exactly MDA • focus on structured data models • positioned in the middle between MDA and manual programming. • does not currently support all of the UML specification • lacks the ability to generate source code for behavioral models such as UML state charts, it does provide support for extension points (e.g., plug-ins) that allow developers to add missing MDA capabilities. • Three EMF Framework models: • ECore models - UML modeling • Code models - specially annotated Java code. • XMI – XML Metadata Interchange, XML based modeling • all mapped to a representation that allows for translation between models.

  12. EMF – Code Generation Code Generation Highlights: • Model - provides Java interfaces and implementation classes for all the classes in the model, plus a factory and package (meta data) implementation class. • Adapters - generates implementation classes that adapt the model classes for editing and display. • XML Schema for the model. • Characteristics: • Generated files are intended to be a combination of generated and hand-written pieces

  13. EMF – Example Model

  14. EMF – Annotated Java Model package org.eclipse.example.library; import java.util.List; /** * @model */ public interfaceLibrary { /** * @model */ String getName(); /** * @model type="Writer" containment="true" */ List getWriters(); /** * @model type="Book" containment="true" */ List getBooks(); }

  15. Model Interfaces and Classes Type-safe enumerations Package (metadata) Factor Switch utility Adapter factory base Validator Custom resource XML Processor Edit (UI independent) Item Providers Item provider adapter factory Editor Model Wizard Editor Action bar contributor Advisor (RCP) Tests Test cases Test suite Stand-alone example EMF – Generated Artifacts

  16. EMF – Generated Artifacts (cont…) • Interface and implementation for each modeled class • Includes get/set accessors for attributes and references • EMF generates two more interfaces and implementation classes: • Factory • create instance of model objects • Eg: Library aLib = LibraryFactory.eINSTANCE.createLibrary(); • Package • class provides access to model metadata

  17. Software Factories • a development environment configured to support the rapid development of a specific type of application • less concerned with portability and platform independence than MDA, and more concerned with productivity • apply select patterns of automation to existing manual development tasks • UML not an actual software development artifact

  18. Software Factories (cont…) • A software factory contains three key ideas: a software factory schema, a software factory template and an extensible development environment • Instead of having to build a whole application from scratch, developers using a software factory build only the parts where the application differs from other members of the family. The rest is provided by the software factory.

  19. Software Factory Definition A software factory is a software product line that configures extensible tools, processes, and content using a software factory template based on a software factory schema to automate the development and maintenance of variants of an archetypical product by adapting, assembling, and configuring framework-based components.

  20. Software Factory Schema • A directed graph whose nodes are viewpoints and whose edges are computable relationships between viewpoints called mappings. • Describes the artifacts that must be developed to produce a software product • Recipe for building a family of software products

  21. Software Factory Schema

  22. Software Factory Templates • Describes Domain Specific Languages, Tools, Patterns and Frameworks • Consist of Code(DSLs) and Metadata that can be loaded in extensible tools • Tools produce specific type of software from the code and metadata Software Factory Template (Code + Metadata) Software Product Extensible Tools

  23. Software Product Line • Software Product Line produces a Family Software Products • A Software Product Family is a set of products whose members vary, while sharing ,any common features • Microsoft Office (Word, PowerPoint, Excel, InfoPath, Access etc.) • Accounting Software Suite for different Industries • Problems common to family members can be solved collectively • Thus Software Product Line can produce a family of products more quickly, more cheaply, and with higher quality than producing them individually

  24. Why Domain Specific Languages? • UML is good for documentation but insufficient for generating code or software automation • Failure of CASE Tools • Did not Exploit Platform Features and produced naïve, inefficient and LCD code • DSLs are designed to express model by targeting a narrow domain • Captures concepts used by people who work for a domain

  25. Building a Software Factory

  26. Building a Software Factory • Product Line Analysis • What products will be developed? • Product Line Design • How the products will be developed? • Design DSLs • Product Line Implementation • Build Software Factory Template

  27. Building a Software Product • Problem Analysis • Product Specification • Product Design • Product Implementation • Product Deployment • Product Testing

  28. MDA pure MDD approach focus on platform independence UML - modeling language Requires UML experts for model comprehension Greater learning curve due to complexity and individuality of using MDA based tools SF development methodology focus on product line development UML – documentation No misinterpretation as DSLs comprise the problem domain High expense of DSL and Code Generator development MDA vs. Software Factory

  29. MDA - Issues • MDA marks a significant step forward, but then model-driven development is still just a form of software development and has to answer all the well-known questions: • How to bridge the gap between business specification and technology? • How to enforce architectural and design guidelines while maintaining agility? • How to collaborate in a software development effort?

  30. Conclusion • Improved quality and reliability • Generated code less error-prone • Which method to use? • Depends on the problem domain, skill set, development tools and the idea of the intended solution • SA recommended for developing product lines • One-off development expensive in terms of time, budget and resources • MDA can be used for one-off development or product line development

  31. Thank You! Questions…

More Related