Success Story - Using my Own Tool

I’m the founder and lead developer of Sculptor. Why would I write a success story? They should be written by users. Right, I’m a user of my own tool. This is maybe the key to why the tool is working as good as it does.

Since May 2009 I have been working with a customer in the logistics business. I’m involved in several projects but in my “main” project we develop a Track & Trace system. We receive events with parcel state information from several production systems in different countries. Volumes around 500 million tracking events during 6 months, which is the period we need to support track&trace searching.

In this department JEE was greenfield development. They have been using Java before, but not with application servers and modern frameworks. We established guidelines and tools for the new platform.

The introduction of Sculptor started with a technical prototype of the domain model. About 20 entities were developed in 2 days. Test driven. Of course this was only an initial draft, but it was important to quickly be able to try our ideas in practice. We have done a lot of refactoring of the domain model since then and Sculptor doesn’t sit in the way for doing changes. It simplifies change.

When evaluating Sculptor for the prototype my team developers stressed the importance of being able to remove the tool and continue without starting from scratch. It was good to see that the developers were able to quickly grasp the concepts and be able to use the tool immediately without any lengthy education.

When I and the other developers in my team had used Sculptor for a while another team wanted to try it also. I helped with converting existing code. The conversion and initial learning was smooth.

We listed the following benefits of using Sculptor for all new projects at the department:

• Improved productivity. Generate code from high level description. Less manual mistakes. Relieved the developers from repeating and tedious programming tasks.
• High quality of generated code. As if written manually, but better. We actually found several flaws in the hand written code when converting it to Sculptor.
• Consistent design and structure. The department was running several projects in parallel, with different developers, and varying experience of JEE. Consistency between solutions was considered very important from a maintenance perspective.
• Easy to learn. The developers that tried Sculptor found it intuitive to use. “It’s nothing magic”.
• Great possibilities for customization. We did some adjustments to fit the database naming conventions.
• Good design. The design of the generated code match our guidelines, JEE, JPA, DDD.
• Easy to remove the tool. No dynamic runtime magic.

We have continued to use Sculptor successfully. We use Sculptor for all new projects. Several new developers have joined the teams and quickly learnt how to use Sculptor. We are 11 developers in 4 projects right now.

Two Success Stories from Factory4Solutions

Introduction
I work as architect at company Factory4Solutions (www.f4s.sk). Our
primary customers are banks, insurance companies, telecommunication
sector. We was using MDA approach long before. We started around 1997
with our own home made solution based on RationalRose, XML and custom
generator. Than we switched to AndroMDA. Tool was nice but stalled in
development around 2007. Then I start investigate another MDA tools.
We were looking for tool based on open technologies, universal and able
to generate JEE code. After playing little bit with proof of concept
projects we got first real project in which we could apply it.

Insurance company
Decision was not easy. We have to migrate existing portal with huge
amount of existing data to new portal. Persistent layer was hand
written in Oracle TopLink and front-end was in JSPs. I expected many
problems because hand written persistent layer is usually full of
nonstandard approaches which are hard to achieve in generic MDA tool.

However for me as an architect it was important to achieve
standardization because we had complicated deployment mode. Because of
security, portal was split to two. First was 3 tier extranet deployed
on WebLogic cluster and internal part which had similar functionality
but was running only on single server. Both portals were using same
database. For easier development I decided go with only one code base.
At build time we split the application and created more WAR files (Full
intranet, Extranet service tier, Extranet web tier).

I was really afraid about MDA approach. I started with SQL DDL and
created first version of model design file for Sculptor. Then I started
to tweak model file to fit existing database. After 2 days I was ready

with our model and first version of important services.

Thanks to strict Domain Driven Design which Sculptor follow I moved
code to developers to finish services and develop web frontend. Thanks
to Spring Remoting it took just 1 day to develop build procedure for 3
different WAR files. Except some small problems when developer used
some utility methods from frontend on backend. The architecture is stable,
system is maintainable and extendable. Today we still use one code
base also for demo system, batch processing system and Web Service
layer. Flexibility of Sculptor is endless. When you reach the border
with what Sculptor allow, you are still free to override parts of
generated code thanks to Xpand language.

Project facts:

• 6 developers + 0.5 architect + 1 project manager + 0.5 auality assurance + 0.5 analyst for 9 month
• 108.000 lines of java code, 34.000 lines of JSP code
• Processing big reports from customers take 5-6 minutes (10 MB XML)
• 20.000 reports a day are send in peaks

Investment company
We had advantage that we should start from scratch. Now project
consist of 40 entities and 26 services. Very complex security and
entity processing by complicated business processes involving bank,
customers, internal users, stock exchange, e-mail processing and
advisor networks. It was developed fully with Sculptor for entity and
service tier.

This is our first project where we used Sculptor also for generating
web frontend. We used smartclient (Sculptor allow to generate different
frontends). We are satisfied with speed of development and nice GUI
which users appreciate.

We also used very unique concept of waving rule engine - Drools

in front of service tier. This way we validate objects, sending

announcement, sending business alerts and also for complex price

list processing which consist of 8 different payment tables applied

at complex conditions. Result is very robust system which allow at

one side dynamic change but on other side very stable.

We are now running User Acceptance Tests at client side.

Project facts:

• 2 developers + 0.5 architect + 0.5 quality assurance during 6 month
• 9.000 lines of hand written code, 3.600 lines of test code, 49.000 lines of generated code

Conclusion
Today we are using Sculptor for all our projects. We master it to nice
extend and we now participate in development of new versions. I'm very
happy with new 1.7 release. This brings some nice features.
Specifically it's Smartclient frontend, hints for custom generation of
code and condition criteria builder with nice Java DSL (type and name
checking and IDE autocompletion).

This story was written by Pavel Tavoda, Factory4Solutions

An Old Success Story

It was a completely new project started from scratch. The main goal of a project was processing of a big files and then generates reports. Despite the fact that installation of a product includes configuration for personal and network use, we choose choose architecture of app that includes Tomcat and Hibernate. After some investigation I found Sculptor. It uses well known (by me) technologies and best practices for that moment. When main functionality was implemented in a draft state Sculptor helped to start with a simple domain model. It was not really big model. This model includes about 50 entities and services (Users, Reports, Settings, Schedule, Directory objects, ...). It was implemented by a team with a different experience in JEE technologies. And almost all of them started to use Sculptor model very quickly.

Our team used SCRUM as a development process. So, it was really exciting "Agile" process implementation. Even Domain Model was agile! There were several serious refactorings that includes changes in Domain Model and Sculptor framework supported this in several ways. First, It requires tests implementation, so our changes was tested just after applying. Second, the way Sculptor uses to separate generated and hand-written code doesn't prevent refactorings. Sure, there were some minor problems, e.g. with using "lazy" initialization. But they were successfully solved and now product is on the market.

Regards,

Vladimir

December 2008