Discussions

News: Taylor MDA 1.1.0, model-driven architecture on rails, released

  1. The Taylor team is pleased to announce the release of Taylor MDA 1.1.0. Taylor MDA is an Eclipse based UML modeling and code generation tool, described as "model-driven architecture on rails." It leverages a convention-based code generation approach and stereotypes so that the maximum amount of code can be generated from streamlined UML models. A screencast showing basic capabilities is available. In the screencast, a simple JPA entity is generated by creating the entity, attaching properties to it, specifying attributes of those properties, and then adding annotations to fulfill the requirements from the JPA side. Entities are not the only thing Taylor MDA is capable of. It can generate session beans, manage resource injection via Java EE 5, maintain web services and junit tests, handle use cases, requirements, and state machines, and much more - see the features page for a more comprehensive list. Changes include:
    • Refactored Generation menus and added Preferences page
    • Refactored generated Maven projects and added master project
    • Richfaces Tree and more leveraged in generated CRUD screens
    • JPA Annotation utilities menu
    • JSFUnit generation
    • JIRA integration
    • A new default portal theme
    • Plus lots of tweaks and fixes
    Taylor is licensed under the LGPL.

    Threaded Messages (16)

  2. What about this alternative: A UML roundtrip tool (as the old TogetherJ) + a Model Driven Framework (as OpenXava3, Romaframework, NakedObject, JMatter, Trails, etc). In this way we can: - Avoid code generation. - Change from UML to code, and vice versa. Because UML is only a view of the code, but not the code. What about of an evolution of Taylor to 2 products ?: 1. A UML roundtrip tool for POJOs + JPA. 2. An application generator from POJOs + JPA. Cheers Javier Paniza
  3. Change from UML to code, and vice versa. Because UML is only a view of the code, but not the code.
    Which means no level of abstraction between your model and your code. This not the way to go in my opinion. The whole idea of model driven development (in ny view) is to create models at different levels of abstraction and generate implementations of the model(s) against (possibly different) target languages/frameworks. So the model is not just another view of the code since it exists at a higher level of abstraction. Hence, some way of code generation will be necessary, with all the challenges it implies. This is also exactly why UML roundtrip tools (like TogetherJ) are insufficent as MDD tools. As for Taylor, I have not read about it yet. Will do! :-) /Ragnar
  4. Hi Ragnar,
    > the model is not just another view ... it exists at a higher level of abstraction. ... some way of code generation will be necessary... Ragnar
    But you can use Java + annotations as a design notation with the same level of abstraction of UML, and with code generation (if you wish). Remember that Meyer talks about its Eiffel as an 'analysis and design notation' and not as mere programming language. Cheers
  5. But you can use Java + annotations as a design notation with the same level of abstraction of UML, and with code generation (if you wish).
    I do not doubt this is technically possible, but I cannot see that it is a good choice as a general solution for MDD. While UML is not perfect, I think it beats Java + annotations as a generic modeling tool/language. And in case you suggest this as a "UML tool -> Java + annotation -> generated Java code" chain, I still cannot see that the UML tool supports separation of levels, since the code generation must be handeled by the Java annotation mechanism and not the UML (roundtrip) tool. I assume here that the annotations are hand coded into the Java code and that the UML tool cannot relate to this and generate the final Java code. If this is not the case, please let me know! :-) Anyway, I would prefer to use pure UML for the modelling, and keep the meta-information there. It would be much easier to maintain and would support generation to other languages/platforms than Java much better. Cheers, Javier! /Ragnar
  6. Hi Ragnar,

    > the model is not just another view ... it exists at a higher level of abstraction. ... some way of code generation will be necessary... Ragnar


    But you can use Java + annotations as a design notation with the same level of abstraction of UML, and with code generation (if you wish).
    Remember that Meyer talks about its Eiffel as an 'analysis and design notation' and not as mere programming language.

    Cheers
    I can think of several reasons why you should use UML. *Try to show your Java code to a non developer and see if he/she understands anything. *Try yourself to understand the relations of 20 java classes from a bunch of source code files. Then compare that to a class diagram with 20 objects. *In a UML tool you can configure it to show a subset of the features that are important just for this diagram. A java source code is always the same. *How to you express a sequence diagram in Java? *When you model in UML you can start topside down. The first version of an object is just a box and a name. No need to get the Java syntax right. *Relations in Java is not expressed very well. A relation has to be expressed with two fields in two classes. Java code could be compared to XMI that most UML tools can read and write. You are free to skip the graphical tool and write XMI by hand, but that would be crazy. I Agree with Ragnar that a UML model should be at a higher level. Using a round trip tool where every uml object maps 1 to 1 to a java object is not very helpful. I also think that the MDA concept of generating a PSM UML model adds more problems than it solves. /Björn
  7. How do you...[ Go to top ]

    *Try yourself to understand the relations of 20 java classes from a bunch of source code files. Then compare that to a class diagram with 20 objects.
    With 20 Java Classes (given coding is type safe), it is fairly easy to spot the relationships. Anything > 10 UML Classes in a non trivial view is unreadable. A diagram has its purpose precisely when you cannot see the relationsships between classes from the code, in particular when using loosely typed languages.
    *How to you express a sequence diagram in Java
    But then, how do you translate a sequence diagram in code but for the most trivial cases where no branching is required? And when branching is required, are you really prepared to draw 20 sequence diagrams for 50 lines of code?
  8. Re: How do you...[ Go to top ]

    *Try yourself to understand the relations of 20 java classes from a bunch of source code files. Then compare that to a class diagram with 20 objects.

    With 20 Java Classes (given coding is type safe), it is fairly easy to spot the relationships. Anything > 10 UML Classes in a non trivial view is unreadable. A diagram has its purpose precisely when you cannot see the relationsships between classes from the code, in particular when using loosely typed languages.
    I don't think a UML diagram with > 10 UML classes is unreadable but even if we have 10 classes that is much easier than reading code. I am not saying that you can't extract the same info from the UML and the Java code (with the aid of som annotations), only that it is easier. Using Java code you have to load each file into your editor and scroll through several lines of code and make a mental image of the relations. I am surprised that anyone can say that it is easier (or at least as easy) to read code compared to looking at a diagram. To make travesty of a known expression: A UML diagram says more than a thousand lines of code.

    *How to you express a sequence diagram in Java

    But then, how do you translate a sequence diagram in code but for the most trivial cases where no branching is required? And when branching is required, are you really prepared to draw 20 sequence diagrams for 50 lines of code?

    Sometimes it is possible to generate code from sequence diagrams but generally it is not.
    Sequence diagrams is most powerful if they are used in the modeling phase to find out what methods you need on the different classes. /Björn
  9. Re: How do you...[ Go to top ]

    Using Java code you have to load each file into your editor and scroll through several lines of code and make a mental image of the relations. I am surprised that anyone can say that it is easier (or at least as easy) to read code compared to looking at a diagram. To make travesty of a known expression: A UML diagram says more than a thousand lines of code.
    Well this depends very much on the size of the classes, the view options that your UML tool gives you and the like. But even then UML generally says what you want to do, not what really happens on the coding level. Technically the cardinality on relationships like 1->n or 1->(1..4) are hardly ever captured in code to avoid the implemetation overhead. This leads to the interesting situation that information like this is actually informal and only formal if this is enforced by code generation.
  10. Re: How do you...[ Go to top ]

    But even then UML generally says what you want to do, not what really happens on the coding level. Technically the cardinality on relationships like 1->n or 1->(1..4) are hardly ever captured in code to avoid the implementation overhead. This leads to the interesting situation that information like this is actually informal and only formal if this is enforced by code generation.
    Well it is here that code generation comes in. They can generate the cardinality check for you
    Actually I have been thinking for at time now that Java needs a standardized business object annotations that describes things like cardinality. That makes it possible for containers to implement it. Then you would get what you want.
    Even if we get those annotations I would not want to write them by hand in a java source file.
  11. Re: How do you...[ Go to top ]

    With 20 Java Classes (given coding is type safe), it is fairly easy to spot the relationships. Anything > 10 UML Classes in a non trivial view is unreadable. A diagram has its purpose precisely when you cannot see the relationsships between classes from the code, in particular when using loosely typed languages.
    In my experience UML scales much better than Java in this respect. For one thing, it is impossible to spot a unidirectional reference in Java from the class in the far end. This is easy in UML. That does not mean that UML diagrams are always easy to understand as size grows. But in my opinion, showing relationships between classes is probably the one thing they definetly do better than source code.
    But then, how do you translate a sequence diagram in code but for the most trivial cases where no branching is required?
    It's not hard to agree to this point. UML behaviour diagrams are not a good basis for code generation. Of the 2-3 MDD/MDA tools I have experience with, none supported generation of sequence diagrams (at least at the time I used them). /Ragnar
  12. Re: How do you...[ Go to top ]

    That does not mean that UML diagrams are always easy to understand as size grows. But in my opinion, showing relationships between classes is probably the one thing they definetly do better than source code.
    More exactly, the unidirectional relationship simply does not exist in the far end. That's why it's unidirectional, right!? The only thing that would need to be enforced is cardinality, which generally is not enforced on the coding level anyway, which in turn means that it's only informational. There UML has it's value. On the other hand, I've seen a several UML tools that treated a relationship only as such if you actually declared it a relationship, which meant that you could have thousands of fields in your code that actually are relationships without ever seeing them in the UML diagram.
  13. Re: How do you...[ Go to top ]

    More exactly, the unidirectional relationship simply does not exist in the far end. That's why it's unidirectional, right!?
    Not quite, I think. Given a unidirectional relationship from class A to B, the reason you don't see it in B is not because it does not exist there, per se. It is because the designers of the Java language (given that this is the language we discuss) chose not to store that information in class B. They could have done, since for a given code base it is present statically. Instead, modern IDE's like Eclipse and NetBeans gives us the oportunity to search for these references (unidirectional or not) and list them (Eclipse: Select class -> Right click and choose "References". I am actually not sure if UML stores it in class B either, but my point was that in a UML diagram it is clearly visible also in the far end. You can look at the class B and see an incoming line from class A.
    On the other hand, I've seen a several UML tools that treated a relationship only as such if you actually declared it a relationship, which meant that you could have thousands of fields in your code that actually are relationships without ever seeing them in the UML diagram.
    This is quite sensible, or else fields with simple types like "private String name;" for a domain object "Person" would always be shown as a relationship, which is not always desirable. This information may also be used by a code generation tool to decide for example which elements to convert to database tables for persistent storage. And the name field probably shouldn't be in its own table, right? :-) Actually your example shows a small but important part of UML's strength over source code. You have more choice both as modeling concepts and what to show and not show on a class/model/diagram basis.
  14. Re: How do you...[ Go to top ]

    Not quite, I think. Given a unidirectional relationship from class A to B, the reason you don't see it in B is not because it does not exist there, per se. It is because the designers of the Java language (given that this is the language we discuss) chose not to store that information in class B.

    They could have done, since for a given code base it is present statically. Instead, modern IDE's like Eclipse and NetBeans gives us the oportunity to search for these references (unidirectional or not) and list them (Eclipse: Select class -> Right click and choose "References".

    I am actually not sure if UML stores it in class B either, but my point was that in a UML diagram it is clearly visible also in the far end. You can look at the class B and see an incoming line from class A.

    Well the "show me references" only works in statically typed languages and only if the type is used and not some supertype. I can see the relationship in the model but usually only, if the particular diagram was modeled that way (see your statement below) or if you switch your UML tool correctly. That can be quite insightful. I usually do that when analysing code bases to get a feeling about the quality, interdependencies etc. However to come to a solid statement about such things, I would always use metrics reports rather than UML.

    This is quite sensible, or else fields with simple types like "private String name;" for a domain object "Person" would always be shown as a relationship, which is not always desirable. This information may also be used by a code generation tool to decide for example which elements to convert to database tables for persistent storage. And the name field probably shouldn't be in its own table, right?
    Absolutely, but for that to work properly you will need to attach tons of metadata to the relationships (transient, persistent, types of mapping ...), for example using stereotypes. And once you do that the diagram slowly morphs into a diagram with a *lot* of text inside. And quite often, the really important stuff ends up in some fields that are not even visible in the diagram. As long as the diagram itself is not executable I have my doubts that it is worth the effort.
  15. What's the purpose?[ Go to top ]

    In a convention driven environment, what is the purpose of drawing pictures (pardon me: diagrams) in order to model the problem domain. The amount of code needed to code domain is so slim, that UML just seems to be overhead.
  16. It is not easily visible whether access is provided to the templates. It would be great for someone to write a page navigation diagram for Wicket.
  17. Taylor templates are deployed as eclipse plug-ins. Templates can be created for any target architecture. To date we have only created templates for the ejb3/seam target architecture that we use. I know there are folks working on templates for spring and ruby target architectures.