Do you still code everything by hand? Isn’t it tedious and error prone? It’s time to start using Sculptor to jump start Model Driven Software Development. Concepts and patterns from Domain-Driven Design are used in the Domain Specific Language, which is the model for the generated Hibernate and Spring implementation. Have you had frustrating experiences with code generators? Have you become disillusioned with code generators? Was the generated code not entirely satisfactory, and you couldn’t control the result? Sculptor is different!
Overview 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. You can use the concepts from Domain-Driven Design (DDD) in the textual Domain Specific Language (DSL). Sculptor uses openArchitectureWare (oAW) to parse the DSL and generate high quality Java code and configuration. The generated code is based on well-known frameworks, such as Spring, Hibernate and Java EE.
“Overview” illustrates how the developer specifies the application design in the DSL, generates code and configuration with Maven 2. Generated code and hand written code is well separated. Hand written code, such as JUnit tests and business logic, is added in subclasses or other well defined places.
The DSL and the code generation drives the development and is not a one time shot. It is an iterative process, which can be combined with Test Driven Development (TDD) and evolutionary design, as explained in the appendix Test Driven Development with Sculptor.
High level features of Sculptor:
Possibility to use the concepts from Domain-Driven Design (DDD) directly in the program language (the textual DSL). E.g. Module, Service, Entity, Value Object, Repository, …
- It provides a “best practice design” for Hibernate and Spring. The target environment is real enterprise systems. It is easy to make CRUD-services, but the design is based on the assumption that more than simple CRUDs are needed (flexibility, business logic, …).
- The design and the generated code is better and more complete than existing code generation tools (e.g. Hibernate synchronizer, Hibernate reveng) can achieve out of the box. Maybe the biggest advantage is that a complete application can be generated from a single model, not only fragments that are hard to fit in to the overall design.
- Quick start. The initial investment for getting started with MDSD can be big and this platform reduces that a lot.
- Sculptor is not a one-size-fits-all product. Even though it is a good start for many systems, sooner or later customization is always needed. Sculptor is designed and documented with this in mind. The generated result can easily be modified to meet your needs.
To illustrate how Sculptor can be used in practice we will use an example.
The example is a simple system for a library of movies and books. The core of the system is a Domain Model, see figure 2 below A Library consists of PhysicalMedia. Books and Movies are different types of Media, which are stored on a PhysicalMedia, e.g. DVD, VHS, paper books, eBooks on CD. A Media has Characters, e.g. James Bond, which can be played by a Person, e.g. Pierce Brosnan. A person can be involved (Engagement) in different Media, actually a Person can have several Engagements in the same Media. E.g. Quentin Tarantino is both actor and director in the movie ‘Reservoir Dogs’.
With a few simple Maven commands you will be able to create the Maven and Eclipse projects for your application. Sculptor provides Maven Archetype artifacts to facilitate this.
Domain Specific Language
A Sculptor application is defined in a textual DSL. Since it is text it has all the benefits of ordinary text source code, such as searching, copy-paste, merging and so on. Sculptor provides an Eclipse editor for the DSL. It supports error highlight, code completion and outline view.
Sculptor doesn’t mandate any specific development methodology, but personally I prefer Test Driven Development with evolutionary design and refactoring. Using that approach the DSL model is not a big design up front. This is described in more detail in the appendix Test Driven Development with Sculptor.
- Flash Remoting for J2EE
- J2EE Checklists
- AWT vs Swings
- What is Beehive
- CGI Tutorials
- CORBA tutorials
- J2EE Application server
- J2EE History
- J2EE Design Patterns
- J2EE Interview Questions
- Application Server
- What is Manifest
- What is Maven
- Maven 2
- POJO Application Frameworks
- Web 2.0
- AWT vs Swings
- J2ME- Java2,Micro Edition
- iBatis DAO
- Working with eclipse and CVS
- XDoclet tutorial
- Cross-site scripting
- Cross-site scripting – part 2
- Workflow Component
- How to check performance in J2EE applications
- Sun VirtualBox
- Secure Coding Guidelines
- Eclipse Shortcuts
- Applications on Eclipse
- Extension Points
- Best place in the internet where you will get Java J2ee pdf tutorials
- DISTRIBUTED MULTI-TIERED APPLICATION
- J2EE Containers
- Adaptive vs Responsive design
- Creating an Eclipse RCP application
- ElasticSearch – Storage Architecture using Inverted Indexes
- Architectural Considerations for using Elasticsearch
- How to use Elasticsearch with SQL Server