Home

News: Improving Developer Productivity with Sculptor

  1. Sculptor is a simple and powerful code generation platform, which provides a quick start to Model Driven Software Development (MDSD). When using Sculptor you can focus on the business domain, instead of technical details, to create applications for Java EE. This article by Patrik Nordwall walks through a simple sample application to show how Sculptor can be used to implement domain-driven design through a domain-specific language.

    Threaded Messages (35)

  2. bad link in article[ Go to top ]

    Parik, In the article, there is a sentence - The full DSL model for the Library example looks like this. - where the final word "this" is a link. I has a local drive reference to it and thus is broken for us internet users. Cary
  3. Opinion about sculptor[ Go to top ]

    Hi, I love MDSD and I think that it improves productivity a lot. Even though I find this flaws in Sculptor: - Code generation: Code generation makes the cycle from touch code to see the result more large. - If 'Application Library' model is in only one file this is a problem when you work in a team with several member touching the same application code with CVS. Moreover entity definition tends to grows. - An DSL is a new propietary language to learn by developers. My question is, why instead of: Entity Library { String name key reference Set<@Movie> movies Repository LibraryRepository { save; @Library findLibraryByName(String name) throws LibraryNotFoundException; protected findByCriteria; } } this alternative: @Entity public class Library { @Id public String name; @ManyToOne public Set movies; } That is, an standard EJB3 entity And, BTW, what do you think about model driven frameworks without code generations, as RomaFramework, NakedObject or Trails ? What do you think about a DSL using XML, as OpenXava ? Cheers Javier Paniza
  4. Re: Opinion about sculptor[ Go to top ]

    If 'Application Library' model is in only one file this is a problem when you work in a team with several member touching the same application code with CVS.
    Yes, that might be a problem, even though merging works fine. I hope this will be solved by new features in oAW XText.
    An DSL is a new propietary language to learn by developers.
    Fowler writes this in http://www.martinfowler.com/articles/languageWorkbench.html
    A particularly common objection to external DSLs is the language cacophony problem. This concern is that languages are hard to learn, so using many languages will be much more complicated than using a single language. To some extent this concern is based on a misconception about DSLs. Those having the concern often imagine multiple general purpose languages, which indeed could easily result in cacophony. But DSLs tend to be limited and simple which makes them easier to learn. This is reinforced by their closeness to the domain. DSLs don't look like regular programming languages.
    Your comparison is irrelevant. You are comparing different things. Sculptor provides a lot more than your EJB3 entity definition.
    And, BTW,
    what do you think about model driven frameworks without code generations
    For some problem domains it is great, for example a state machine or page flow. For application structure, like the thing Sculptor focus on I prefer code generation (today, with Java). Otherwise I would have to invent an advanced runtime framework instead of utilizing existing frameworks such as Spring and Hibernate.
    What do you think about a DSL using XML
    I depends on what is described by the DSL. If it is is simple configuration it is alright, but if it is more advanced DSL that is used often I think it is a bad idea. XML is too noisy for humans.
  5. Re: Opinion about sculptor[ Go to top ]

    Hi Patrick,
    Your comparison is irrelevant. You are comparing different things. Sculptor provides a lot more than your EJB3 entity definition.
    The idea was creating a DSL using Java + annotations.
    XML is too noisy for humans
    My experience is good using XML as DSL (the OpenXava 2 case). In fact the learning curve is very low for new developers and the flexibility is high. XML is just for humans, what is easier, HTML or Swing ? Your model using OpenXava can be: It's not soo noisy. And you have for free tools for parsing and the developers has editors with autocompletion, error detection, etc. In spite of my comments I agree with you. Using DSL + code generation improves greatly the productivity. Cheers Javier Paniza
  6. Re: bad link in article[ Go to top ]

    While we are waiting for TSS editor to fix the broken links you can use the following URLs: Test Driven Development with Sculptor: http://www.theserverside.com/tt/articles/content/ProductivityWithSculptor/appendix_tdd.html Full DSL model: http://www.theserverside.com/tt/articles/content/ProductivityWithSculptor/library_model_design.html Sculptor Metrics: http://www.theserverside.com/tt/articles/content/ProductivityWithSculptor/appendix_metrics.html Figure: http://www.theserverside.com/tt/articles/content/ProductivityWithSculptor/metrics.gif
  7. I'm skeptical but interested. Has anyone used this tool and could they give some independent analysis?
  8. AndroMDA[ Go to top ]

    Personally, I have found AndroMDA very useful on several projects. Sculptor appears to have a lot of similar functionality. But a big part of code generation is the quality of the generated code. What are the significant advantages?
  9. Compuware OptimalJ[ Go to top ]

    Disclaimer: I am a Compuware employee and use OptimalJ daily. It also uses MDA and I can honestly say it is much more advanced than the tool mentioned here. Evaluate for yourself: http://www.compuware.com/products/optimalj/
  10. Yes, it is more advanced, and that might be an advantage to Sculptor. :) I tried to use OptimalJ some time ago but the learning curve was too steap and I gave up. It is rather general purpose and therefore also complex. Sculptor is rather specific and hopefully a lot easier to use, if you have a problem domain that fits.
  11. Disclaimer: I am the lead developer for Javelin! Javelin has been providing light weight, low intrusion, model driven software development for Java via live class diagrams since 1995 although it's adoption for server side Java development has, until a few years ago, been frustrated by the lack of viable object persistence solutions - but that's all changed now. Now Javelin has inbuilt support for JDO (JPOX, KDO etc,) and Hibernate so it's possible to focus on development of domain models using POJOs generated and maintained via Javelin's live, visual modeling paradigm which allows changes to method bodies from outside Javelin (eg., your favourite IDE) without requiring a reverse engineering step to resync the code. Classes, attributes and method signatures are automatically updated (while preserving method body code) whenever a change is made to the model via the class diagrams - no separate export/import phase is required. The meta data for JDO or Hibernate (depending on your selection for a particular project) is constantly updated to reflect changes to your classes and the relationships between them so you never have to create or update XML meta data files by hand again nor litter your otherwise pure POJOs with vendor specific annotations. What Javelin does not do Javelin does not support the full range of UML diagrams - at this stage it only supports the most important one, the one that supports a direct 1 to 1 relationship between model and code: the class diagram - if you want a full UML tool with diagrams other than class diagrams and the learning curve that goes with that then Javelin isn't for you. Javelin is available in a free Modeler only version (no automatic code or ORM meta data management) but the full Modeler+Coder+Meta data version is priced so that it's barely more expensive than free software. http://stepaheadsoftware.com/products/javelin/javelin.htm
  12. Re: Compuware OptimalJ[ Go to top ]

    I wonder, in what way would OptimalJ be more advanced then? With Fornax/oAW I have a (rather large) choice of modelling tools (MagicDraw, RSM, Omondo, EA) and I have the opportunity to overload (and/or change) the Fornax templates with ease in order to address the technology/architecture being targeted. I my (limited, I admit) knowledge this is now what I get from OptimalJ. But I love to hear otherwise... \Ron
  13. Re: Compuware OptimalJ[ Go to top ]

    A variety of things. First of all, it forces you to program to a particular pattern or technology implementation. The generated code is partially guarded, i.e. there are some sections you can modify, some you cannot as they get re-generated all the time. This forces any new programmer that joins the project throughout its lifetime to follow the same standards as everyone and not go off on a tangent and pollute the source code with something different than what the rest of the system is doing. Most of the products described here seem to focus on code generation. OptimalJ does all of that AND then focuses on code maintenance as well throughout the years that a system is maintained (with potentially many different developers touching the code). The code generation itself handles everything from creating entities, EJBs, MDBs, data acces layer objects (implements the Fast Lane Reader pattern) to maintaining the Struts output (including automatic generation of Struts validators, etc). Basically it allows you to create top-notch J2EE apps even if your team does not consist of senior J2EE developers. Not to mention it automatically maintains ejb-jar.xml, generates Jboss/BEA descriptors automatically, etc. To be fair, there is a fair learning curve. It took me probably a good 2-3 months to get comfortable in it, but after that you're off running.
  14. Re: Compuware OptimalJ[ Go to top ]

    Well, how should I bring this to you gently...? Everything (and I really mean everything) you describe, oAW -and some other MDSD tools I could mention- can do with a suitable set of mappings (of which the Fornax project is just an example). Guarding modified code from subsequent generation cycles is there of course (that's a code generation 101) and with a mapping I wrote (in just a few weeks, not the "2-3 months to get comfortable" you quote) I generate domain POJO's, DAO's, Hibernate mappings, Service layer, Spring WebFlow front-end, and the kitchen sink. I can feed oAW with models described with a TDSL like Sculptor, with UML2, or really with any EMF-based metamodel. Having the opportunity to work with a modelling language that works best for the intended audience is a big. big plus. As far as I understand, OptimalJ will not provide that to me. And if I'm provided with a mapping that generates to a pattern that I don't like (say, Fast Lane Reader), I can easily rip that out and replace it with something more to my liking. Again, I understand that OptimalJ will not provide that to me _easily_. To recap my understanding of this all: OptimalJ is a CASE tool; oAW is a flexible generator framework and Sculptor is just one of many generators based on that framework. Big difference to me... \Ron
  15. Re: Compuware OptimalJ[ Go to top ]

    Your notions are somewhat incorrect. With the Architecture Edition you can plug in/enhance/replace/write from scratch any of the code generation templates. You can even "attach" yourself to the existing ones and inject additional customized code at the many join points that are available. It's not a hard-coded code generator by any stretch of imagination, it's actually extremely extensible (by design).
  16. Re: Compuware OptimalJ[ Go to top ]

    Your notions are somewhat incorrect.

    With the Architecture Edition you can plug in/enhance/replace/write from scratch any of the code generation templates. You can even "attach" yourself to the existing ones and inject additional customized code at the many join points that are available. It's not a hard-coded code generator by any stretch of imagination, it's actually extremely extensible (by design).
    Again, that's nothing oAW (or to inject a bit of objectivity, Acceleo too) can't do as well. This lill' thread started out with your remark that OptimalJ is much more advanced. And that's something I just can't agree to. \Ron
  17. How many of these tools is no one using? Everybody's pushing them but no one can say how well they work? Does any of this stuff work like Together before Borland gutted it?
  18. Does any of this stuff work like Together before Borland gutted it?
    Javelin's sister product Visual Classworks for C++ was in use well before Together was released (actually was initially called C++ Creator - wow now that's going back some!). I've never used Together but I've read about it. Javelin is a lot more light weight and so has a much smaller learning curve. It's designed to give developers the classic 80%/20% trade off - covers 80% of the things you need right now to create and manage high quality, Java software products with automatic persistence generation using Hib/JDO. It leaves out the 20% which are the things you don't *really* need to produce your code - object diagrams, sequence diagrams, use-case diagrams etc., - although these are useful in coming up with the design that you end up putting in your class diagrams. These other diagrams don't possess the same 1 to 1 relationship to the underlying code that class diagrams do and so Javelin just focusses on class diagrams and the management of the underlying .java files that implements the designs represented by those diagrams.
    How many of these tools is no one using? Everybody's pushing them but no one can say how well they work?
    The visual development paradigm supported by Javelin might sound radical and seem like 'the software development paradigm of the distant future' but trust me - the smart developers of today are already using it! Is it in their interest to promote it and spread it to other developers when it's a key way they can remain so much more productive than their counterparts? Probably not!
  19. The visual development paradigm supported by Javelin might sound radical and seem like 'the software development paradigm of the distant future' but trust me - the smart developers of today are already using it! Is it in their interest to promote it and spread it to other developers when it's a key way they can remain so much more productive than their counterparts? Probably not!
    Don't you think you push the plug a bit too far? Come down on earth, there are some nice things going on.
  20. Javelin is a lot more light weight and so has a much smaller learning curve. It's designed to give developers the classic 80%/20% trade off - covers 80% of the things you need right now to create and manage high quality, Java software products with automatic persistence generation using Hib/JDO.
    Yeah, I don't need that. Together allowed me to write code in Java or by drawing class diagrams seamlessly. They were two sides of the same coin. One changed the other instantaneously. When I did a refresh from source control, I'd see if someone added new classes or messed with my perfect ;^) designs by looking at the class diagrams. It didn't force me to write code in little shitty dialog boxes (yeah I'm talking about you Rational). If it was easier to write Java one part I did it in Java. If it were easier/quicker to draw stuff in class diagrams I did it there. What I don't need is another tool that assumes what it is that I am trying to do. I know it's hard to conceptualize, but I often need to do things that software vendors haven't already thought of.
  21. Just to clarify, Sculptor differ a lot from general purpose UML tools that are based on a one-to-one relationship between code and visual class diagram. The intention is to raise the level of abstraction beyond that and therefore gain real benifits in productivity and quality. James, I'm also very skeptical to general purpose tools, which are hard to adopt to the specific problems. Sculptor is intended to be customized to fit your requirements. It is easy to customize or in the high end spectrum develop your own code generators based on Sculptor.
  22. Just to clarify, Sculptor differ a lot from general purpose UML tools that are based on a one-to-one relationship between code and visual class diagram.

    The intention is to raise the level of abstraction beyond that and therefore gain real benifits in productivity and quality.
    OK but here's my problem. If the code and the UML are not automatically kept in sync, the UML either becomes useless quickly or the cost of keeping the UML up to date erases the benefits gained by writing it. There are also a lot of things that are a lot harder and time consuming to do in UML. For example, I've sworn of sequence diagrams. It's the most asinine way to write a process around. You can create the same thing in code in a small fraction of the time required to do it in a UML tool. But some people seem to think that it's better to write sequence diagrams because 'code is bad' even though it's completely unproductive. I think that Sculptor addresses this by generating certain classes that are to be modified by hand and others that are not. I think this is a better solution than generating everything but I still have some issues with it. For one, I don't want my code to be tied inextricably to one tool. No more lock-in. I refuse to go into the tar-pit no matter how tasty that mastodon looks.
  23. I'm not sure how the generated code is "tied inextricably to one tool". There's no reason why you couldn't stop generating the code at some point and develop manually from there on forward. Or alternatively, modify/overload the templates to address patterns to your liking. \Ron
  24. I'm not sure how the generated code is "tied inextricably to one tool". There's no reason why you couldn't stop generating the code at some point and develop manually from there on forward. Or alternatively, modify/overload the templates to address patterns to your liking.

    \Ron
    It all depends on the quality of the generated code. The other thing is that code generation is often a stand-in for dynamic designs. Often code generation is used in cases where it's completely unnecessary. I'm working on some code right now that uses code generation for things that could be completely data driven. Aside from the problems this causes from a maintenance perspective, it means that in order to extract the tool from the equation, we either need to rewrite the code entirely or we must manually edit and create the source files that the tool was generating. Often, code generation represents a failure of a language to have the features to create an application properly. But more often I find that it represents a lack of imagination. Basically, it becomes a way to automate hard-coding. If I can write a script to generate the code, then that code generation script is, in effect, my program and the code generation is compilation. Saying that you can just drop this at anytime is like saying you can drop javac at any time an manually edit the bytecodes.
  25. One of the corner stones in MDSD, according to the book, is that you start with a reference architecture, i.e. you manually implement a typical use case that spans the important parts of the system design. From this reference you extract the parts that are suitable for code generation and implement them in the code generator. This is the way Sculptor has evolved. Usage of good design and frameworks is a critical success factor for this approach. Code generation should never be a substitute for good design. I agree that when there is a simple alternative without code generation it is often better to select that solution. My goal is always to generate as good code as I would have written by hand. However, the quality of the generated code is often a lot better, since it consistent and it is lacking mistakes. It is also a lot more fun to get rid of the tedious repetitive parts of programming :)
  26. My goal is always to generate as good code as I would have written by hand. However, the quality of the generated code is often a lot better, since it consistent and it is lacking mistakes. It is also a lot more fun to get rid of the tedious repetitive parts of programming :)
    I want to be clear that I am not saying that Sculptor is making these kinds of mistakes. It's actually piqued my interest because it seems that it might not. I'm merely pointing out my concerns. Along the lines of what you say here, this is what I liked about Together. It seemed less like a code generator than a tool that allowed multiple perspectives of the code. I wasn't writing UML to generate code. I was writing code with UML. That probably sounds like a meaningless distinction but it's not, at least to me.
  27. Often, code generation represents a failure of a language to have the features to create an application properly. But more often I find that it represents a lack of imagination. Basically, it becomes a way to automate hard-coding. If I can write a script to generate the code, then that code generation script is, in effect, my program and the code generation is compilation. Saying that you can just drop this at anytime is like saying you can drop javac at any time an manually edit the bytecodes.
    Of course this represents a failure of the target language having the appropriate features! Isn’t that what we’ve been doing all along, right from the very first programmable computers? Tackling programming complexity with caked layers of abstractions, each a simplified (and hopefully, clarified) description of the layer beneath it? Sculptor seems to be a nicely compact way of defining the traits of my system’s components, their configurations and their interrelations, based on a certain architectural style and a given technology stack. That’s the tedious and menial (and error prone) stuff I happily automate away. The semantic gap between a Sculptor program and the code it generates is really not that hard to comprehend, so the Java-to-bytecode metaphor is not really applicable here IMO. \Ron
  28. Often, code generation represents a failure of a language to have the features to create an application properly. But more often I find that it represents a lack of imagination. Basically, it becomes a way to automate hard-coding. If I can write a script to generate the code, then that code generation script is, in effect, my program and the code generation is compilation. Saying that you can just drop this at anytime is like saying you can drop javac at any time an manually edit the bytecodes.


    Of course this represents a failure of the target language having the appropriate features! Isn’t that what we’ve been doing all along, right from the very first programmable computers? Tackling programming complexity with caked layers of abstractions, each a simplified (and hopefully, clarified) description of the layer beneath it?
    Yes. But why should I use a code generator instead of a language with the desired features?
    The semantic gap between a Sculptor program and the code it generates is really not that hard to comprehend, so the Java-to-bytecode metaphor is not really applicable here IMO.
    What does the semantic gap have to do with the validity of the comparison? The analogy made no reference to any semantic gap. It doesn't seem to be relevant at all to my point.
  29. How does it compare to Roo?[ Go to top ]

    Ben Alex (Interface21) of Acegi Security fame has written a DDD architecture and code generation tool called Roo that on the face of it seems very similar in aims to Sculptor. I saw a pre-release demo of it at the Sydney Spring User Group, where he said he would release it as an open source project in Q3 this year. Here's an article about it: http://raibledesigns.com/rd/entry/tse_hop_into_real_object It would be interesting for you two guys to compare and contrast your respective frameworks for the benefit of prospective users.
  30. Yes, it would be interesting to learn more about ROO, but I can't find much information about it. I don't how to contact Ben, maybe someone of you can notify him.
  31. Web Interface[ Go to top ]

    What about web interface generation? In the "Sculptor Java EE Tutorial" there is a reference to a "Web application consisting of a jsp, which invokes the EJB service." but is not clear to me if you have to manually create the web app upon the generated business code, or if at least a basic web interface is generated automatically (and if is based on SpringMvc , Jsf or whatever else)
  32. Web Interface[ Go to top ]

    What about web interface generation? In the "Sculptor Java EE Tutorial" there is a reference to a "Web application consisting of a jsp, which invokes the EJB service." but is not clear to me if you have to manually create the web app upon the generated business code, or if at least a basic web interface is generated automatically (and if is based on SpringMvc , Jsf or whatever else)
  33. Re: Web Interface[ Go to top ]

    I agree, without a UI layer, the value is limited. In my own experience I found that, once you're already using Spring and Hibernate and not writing SQL yourself, 90% of the remaining mindless crank-turning in webapp development is in the UI layer, and integrating the UI with the business/persistence tier. Especially if you're using Struts and have to touch four different files to do something simple like create a new CRUD form with validations. I also agree that annotations on domain objects may be preferable to a 4GL/DSL. Arguably the domain objects are the classes that you *should* write, since they should include behaviors as well as data fields. One project I've worked on that took this approach all the way to the UI layer (along the lines of Trails, and which may now be obsoleted by Grails): http://sourceforge.net/projects/easel
  34. Re: Web Interface[ Go to top ]

    Well, the plan is to include support for a web gui in the next release of sculptor, i.e. 1.1. It still is in an alpha stage, so the scope isn't decided yet, but at least some sort of CRUD functionality is to be expected. About the tech part regarding framework the gui is going to be based on (still alpha), we are leaning towards spring webflow.
  35. why not try andromda[ Go to top ]

    it's great for java guys ,I think.
  36. The idea of creating a new DSL for Business Applications is not good, IMO. Check out my opinion about this matter in my blog below: ... My questions here is: why using a new text-based DSL for implementing business applications? For this purpose UML is the way to go. Why? Because: http://lofidewanto.blogspot.com/2007/06/mdsdmda-frameworks-andromda-cartridges.html Wish all the best to Sculptor creators. Cheers, Lofi.