Discussions

News: MDA code generator framework XCoder is now open source

  1. XCoder is an extensible model transformation and code generation framework. The framework is itself modelled with UML and generated using the standard UML to Java model transformation included in the distribution.

    Currently supported input meta models: UML via XMI
    Currently supported output meta models: Java, C# and C++

    The distribution also includes a standard transformation from the UML to an EJB meta model.

    The source is available open source under http://sourceforge.net/projects/xcoder/ , whitepapers are available under http://www.liantis.com/Downloads/index.html

    Threaded Messages (19)

  2. Its great to know that XCoder is now Open Source. Wont this bring down Rational's product??? Also I dont understand why in the world is everything going OPEN SOURCE?? Isnt there any value to the work put up by these developers?? Is software development now a charity service where you give away everything for free??
  3. Open Source[ Go to top ]

    George,

    you can generate real money by doing open source development(for free) and then by doing consulting(for money) for those fellows, that decided to use your open source project and want to get some help.

    Hope that clarifies a bit.
  4. Open Source[ Go to top ]

    George,

    >
    > you can generate real money by doing open source development(for free) and then by doing consulting(for money) for those fellows, that decided to use your open source project and want to get some help.
    >
    > Hope that clarifies a bit.

    To add to that point...

    I, personally, have never heard of this software before. But as a J2EE developer whose been intrigued by the idea behind MDA, I'm going to try it out now. I think they're many others out there too that will do the same.

    It's hard to build a successful brand from scratch when going up against the big vendors. Going open-source it a great way to build the brand. A sophisticated MDA tool will still leave plenty of consulting work for good app. architects.

    Mike
  5. Open Source[ Go to top ]

    I understand the "Consulting" power of open source products. But when I think about the scary situation- First of all MDA will take away my job as a developer. Secondly it wont cost a penny to buy the software which will take away my job. Whats the world come to???
  6. Open Source[ Go to top ]

    I understand the "Consulting" power of open source products. But when I think about the scary situation- First of all MDA will take away my job as a developer. Secondly it wont cost a penny to buy the software which will take away my job. Whats the world come to???


    "Won't new-tech-X take away my job?" is a cry I've been hearing for the last couple of decades (fortunately not quarter of a century, yet). The necessary and sufficient answer is, of course, "yes, if you let it".

    Giving OSS away? That is a rational response when the *marginal* cost of production is zero, and when there is competing technology. It has to be lived with, and worked around
  7. Open Source[ Go to top ]

    If you think that MDA tools will take away (some) aspects of a developers job, yes this may be true. But by not using the tools will only put you further behind.(increasing your chances of being replaced by the tool) These tools are becoming much better at helping with Rapid development.

    These tools will not replace the need for Good Developers & Architects, only help them work smarter (and concentrate on the real business problems).

    I am very glad to see such tools go open source.. because most of us can't afford Rational or TogetherSoft on our own.

    just my 2 cents
    -j
  8. What XCoder is[ Go to top ]

    You still need a modelling tool. XCoder is not a modelling tool, only a code generator framework. XCoder comes with a Rose Addin which exports the model into a file and launches the XCoder generator.

    So you still need some modelling tool (with XMI output)

    Greetings
    Con
  9. Open Source[ Go to top ]

    "I understand the "Consulting" power of open source products. But when I think about the scary situation- First of all MDA will take away my job as a developer. Secondly it wont cost a penny to buy the software which will take away my job. Whats the world come to???"

    Survival of the fittest mate. Those that can adapt and embrace new forms of competition will thrive and grow stronger, while those that try to hold back progress will get trampled and extinct. Its capitalism and the evolutionary spirit at its best.
    I am sure the smart guys will find new ways of adding value and make money (not just consulting, use your imagination), it has always been like that throughout history: once one type of work becomes a "commodity", it gets a lot cheaper. But new "even higher qualified" jobs pop up above the old "high level".

    Its just a matter of recognizing that you dont have a God given right to do the same thing for 40 years without having to learn anything new while still getting paid a lot of money.

    Oh well, thats all philosophy. But the point is: the competitive landscape is always getting tougher and forever changing, thats no different now or 20 years ago.
  10. The Architect, Open Source[ Go to top ]

    A sophisticated MDA tool will still leave plenty of consulting work for good app. architects.

    But what matters are the analyst roles that the tool creates. Business analysis is where the passion is. It's where customer and developer meet, and knowledge tranfer occurs. That's very dynamic. Whereas the architect is the geek who applies the same stale tricks over and over again to make hidden machinery that most folks hope never to see. It's easy not to appreciate the architect, and indeed it's his job that's being mercifully factored away by MDA.
  11. MDA complement - does not replace[ Go to top ]

    It might prove a useful tool to automate (like xdoclet) some repetitive task which are unproductively coded by hand right now but to say it will replace architects or coders is a big mistake (euphemism here)
    First as for architects :
    mastering a distributed architecture and finding the best solution is a complex task (synchronous, asynchronous, security fmwk, component model best suited,...) that can not be done by "analyst" which are by definition focused on business.
    As for coders :
    generating maintenable (readable) and efficient code is a craft that can not be so easily replaced by MDA as the technical details at low level are still very important for the success or the failure of a project (a project is very unlikely to be successful if you have bad coders even if the architect is good). Maybe when AI will be as good as human mind...

    Funny to see this sea snake (replacing these bad bad developers) every 10 years or so : it failed last time and still fail right now but I agree it improves and let us focus on what's important.
  12. MDA complement - does not replace[ Go to top ]

    It might prove a useful tool to automate (like xdoclet) some repetitive task which are unproductively coded by hand right now but to say it will replace architects or coders is a big mistake...

    Either you haven't read OMG's MDA Guide or you didn't believe it. It claims:

    "There are contexts in which a PIM can provide all the information needed for
    implementation, and there is no need to add marks or use data from additional profiles, in order to be able to generate code. One such is that of mature component-based development, where middleware provides a full set of services, and where the necessary architectural decisions are made once for a number of projects, all building similar systems (for example, there is a component based product line architecture in place). These decisions are implemented in tools, development processes, templates, program libraries, and code generators."

    Of special importance in the above is the phrase: "the necessary architectural decisions are made once for a number of projects". This means the role of the on site architect is potentially eliminated. With action semantics the generative automation approaches totality: programing and design are also potentially eliminated as mental chores. Ideally only business analysis remains.

    Section 2.3.5 of the OMG's MDA Technical Perspective mentions four ways to translate a model, enumerated in order of increasing automation. Presumably your comments refer to the third way, in which a programer must add hand code to an automaticly generated skeleton. This is the approach taken by the AndroMDA tool. Indeed it's useless without an on site code monkey. The fourth way includes the notion of an executable model, for which there's no need of programing by hand in the implementation language. BridgePoint and PathMATE are such tools.
  13. reading OMG's MDA Guide[ Go to top ]

    do you relly think its the dreams and visions produced my the OMG that matter? I for my part have seen too much questionable stuff being promoted. I rather stick with reality. And to me, reality says that full generation of a system is only possible if you can fully and unambigously specify it. That latter task will remain as complex as it ever was, no matter what tools you throw at it. And the specification language (certainly not UML) will be about as complex to learn and handle as any programming language.

    christian
  14. Hi Brian,

    <quote>

    "the necessary architectural decisions are made once for a number of projects". This means the role of the on site architect is potentially eliminated. With action semantics the generative automation approaches totality: programing and design are also potentially eliminated as mental chores. Ideally only business analysis remains.

    </quote>

    I disagree with this. Look at what the OMG says:

    > "There are contexts in which a PIM can provide all the information
    > needed for implementation...

    This is the key phrase: "there are...". It is certainly possible to find a context that can be fully described by a PIM. However, from my experience in many projects, I question the next sentence in the OMG document:

    "One such [context] is that of mature component-based development, where middleware provides a full set of services, and where the necessary architectural decisions are made once for a number of projects..."

    I say: mature CBD is *not* such a context. There are architectural decisions that can be made for a number of projects, OK. But those decisions concern only the repetitive and boring part of the architecture. Tools, development processes, templates, program libraries, and code generators will take over this part of the work, pretty sure. However:

    The more interesting architectural decisions have to be made in a project-specific way. The basic architecture will tell you how transactions are handled, for example. But: In project X, the on-site architect will still have to decide about how many components there will be, where a component has its border and how many interfaces it has. The on-site architect's job will *not* be eliminated - it will only become more specific. The architect can focus on what's really challenging and: he/she can act smarter and more creatively. Let a business analyst do this job and the resulting product will not perform as expected - I assure you!

    <quote>

    Section 2.3.5 of the OMG's MDA Technical Perspective mentions four ways to translate a model, enumerated in order of increasing automation. Presumably your comments refer to the third way, in which a programer must add hand code to an automaticly generated skeleton. This is the approach taken by the AndroMDA tool. Indeed it's useless without an on site code monkey.

    </quote>

    Folks, where does the notion "code monkey" come from? Writing beautiful, maintainable code that fulfills its requirements is still one of the highest challenges in the SW development world. This is much more than a monkey can do!

    > The fourth way includes the notion of an executable model,
    > for which there's no need of programing by hand in the
    > implementation language. BridgePoint and PathMATE are such tools.

    About BridgePoint: Look at their success story: Which context or problem domain does it address? Embedded systems! A telco switch in this case! This is one of the contexts that can fully be described by a PIM (see OMG's dream above). No wonder that this did not require any hand coding for the target processor. The same with PathMATE: the main stories are about embedded systems development, too!

    Look at modern component-based enterprise information systems instead: I fully agree with Martin Fowler who said that the business rules of such systems are absolutely crazy. It is this craziness that still requires hand coding of the system's business rules. It is this craziness that still requires handcrafting most of the architecture and careful elaboration of design decisions.

    So, step back and relax: MDA will eliminate neither architects nor developers, just as high level language compilers (C++, Java, etc.) did not do that. They only eleminated the need for assembly language programming. Programmers simply moved up one step on the ladder of abstraction.

    You say, you want to remain an assembly language programmer for your whole life? Well, yes, then I guess you have a problem! :-)

    Cheers,
    Matthias Bohlen
    founder of the AndroMDA project
  15. OMG's MDA Guide says: One such [context] is that of mature component-based development, where middleware provides a full set of services, and where the necessary architectural decisions are made once for a number of projects...

    Matthias: I say: mature CBD is *not* such a context.

    Maybe you consider Sun's Ace Project too audacious. Ace hopes to abstract away J2EE:

    "Applications are specified in the Ace language, DASL, which is a higher level architectural programming language (xGL). This language is the gem at the heart of Ace. The DASL language abstracts out complexities, such as persistence and distribution. Using DASL, the application writer concentrates on domain details specific to the application's purpose, instead of worrying about the application's deployment architecture, middleware APIs, remote object invocations, and other details of the implementation stack."

    Matthais: The more interesting architectural decisions have to be made in a project-specific way. ... In project X, the on-site architect will still have to decide about how many components there will be, where a component has its border and how many interfaces it has.

    The first two you mention are structural choices, which are the easiest aspects of design to automate. Interfaces are more difficut, since they imply behavior, but still within the realm of today's generative automation. There are plenty of undisputed cases where the design decisions you mention don't need human attention. Eg, generating entity beans from a relational schema or automaticly aggregating use cases into a session facade. I suspect generally that it's common to have a one-to-one mapping of objects identified during business analysis to implementation components. Such direct projection encourages automatic design.

    About BridgePoint: Look at their success story: Which context or problem domain does it address? Embedded systems! A telco switch in this case! This is one of the contexts that can fully be described by a PIM (see OMG's dream above). No wonder that this did not require any hand coding for the target processor. The same with PathMATE: the main stories are about embedded systems development, too!

    It's innapropriate to dismiss embedded development as trivial. Quite the opposite: of all software systems, firmware has the most painful edit/debug cycle. So firmware has the greatest mandate to automate pain away. That's why model compilation has shone on the embedded scene; not because firmware is somehow trivial. Every firmware application I've heard of using model compilation has involved heterogeneous distributed processing. As such the complexity is akin to EAI, which TheServerSide audience appreciates.

    Look at modern component-based enterprise information systems instead: I fully agree with Martin Fowler who said that the business rules of such systems are absolutely crazy. It is this craziness that still requires hand coding of the system's business rules. It is this craziness that still requires handcrafting most of the architecture and careful elaboration of design decisions.

    Can you give an example?
  16. The Architect, Open Source[ Go to top ]

    But what matters are the analyst roles that the tool creates. Business

    >analysis is where the passion is. It's where customer and developer meet, and
    >knowledge tranfer occurs. That's very dynamic. Whereas the architect is the
    >geek who applies the same stale tricks over and over again to make hidden
    >machinery that most folks hope never to see. It's easy not to appreciate the
    >architect, and indeed it's his job that's being mercifully factored away by
    >MDA.

    You make some interesting observations. Business analysis, however, has always been with us. It's nothing new. To claim to have discovered it as something previously abandoned would be stretching it.

    What is new, though, is the recognition that high technology fundamentally failed so far to deliver on its promise. That's why we're seeing so many desperate efforts to salvage hi tech, to make an attempt to finally deliver on the promise.

    MDA is one such attempt (the latest one). What is it saying is that it's high time we abandon our fascination with software code, and start focusing on the results. Who cares if the operation of the high tech equipment is governed by this or that technology? Let vendors fight it among themselves. We, the users, are only interested in what the technology can bring in terms of making our jobs and our lives easier.

    Yes, there will be casualities. That's the way the cookie crumbles. We're definitelly approaching the stage where no one would want to hear anymore whether something is Java, or PHP, or J2EE, or .Net, or C++, or C#, and so on. What does matter, however, is whether the damned thing is delivering the goods. How was it built, whether it uses patterns or not, is a moot point.

    Whether we use those frameworks to crank the implementation code, or whether we use cheaper labor overseas to crank the code, doesn't really matter in the final analysis. What matters is that we get pass the fascination with the code production, and move on to demanding the goods. Where's the beef? I really don't care if you've used Ant to produce this piece of software. And so on, why should I care whether you've used Struts or Turbine etc.? If the final result sucks, the --- (insert your favorite technology du jour here, such as Struts) is not gonna help one bit.

    Alex
  17. The Architect, Open Source[ Go to top ]

    Brian: But what matters are the analyst roles that the tool creates. ...

    Alex: ... Business analysis, however, has always been with us. It's nothing new. To claim to have discovered it as something previously abandoned would be stretching it.

    Surely you agree that MDA promises to create more analyst positions than there are now -- and that MDA promises a structural shift in labor demand from hand implementors to analysts. That *is* something new.
  18. The Architect, Open Source[ Go to top ]

    Surely you agree that MDA promises to create more analyst positions than there

    >are now

    Sorry Brian, but I must say that I don't necessarily agree with that. I'd say that business analyst positions are created outside of the IT departments, and that there are various reasons why these positions may be needed. Just because something may change inside the IT department does not automatically mean that the business will jump on hiring more analysts.

    > -- and that MDA promises a structural shift in labor demand from hand
    >implementors to analysts. That *is* something new.

    Now, with this I must agree. And yes, that *is* something new, previously unheard of. So, you have a good point. However, these analysts may not necessarily be business analysts. I see more demand opening up in the future for the interaction analysts and product designers. These people should ideally be recruited from the by that time redundant code jockeys.

    Even today I see less and less need for code jockeys. I'd rather see us spend extra time in determining the best way to cover customers' expectations. THe coding itself can alway be outsourced. This sentiment will only grow in the future, until it hits the mainstream, by which time coders will suffer the same fate as DB and network administrators, who are being demoted into 'data janitors' as we speak.

    Alex
  19. Open Source[ Go to top ]

    you can generate real money by doing open source development(for free) and

    >then by doing consulting(for money) for those fellows, that decided to use
    >your open source project and want to get some help.

    This is exactly why open source products tend to suck big time. Yeah, give us something half-baked for free, just to get your foot in the door, and then charge us an arm and a leg for making it actually work.

    I'd rather go with something that's fully functional, pay the market price for it, and not have to depend on the 'aftermarket'.

    However, some (many?) people are masochistic, and enjoy being tortured by the consultants.

    Alex
  20. For a start Open Source doesn't necessarily mean free.

    Secondly, there is another *free* and open source “product” called AndroMDA that is doing something very similar. I’ve only been using it for a week or so and I’m impressed. You can check it out at http://sourceforge.net/projects/andromda/.

    Cheers,
    Dan