Category Archives: Java

Slide deck on Pragmatic model driven development at J-Spring

Posted on by
1

Model driven development has a promise of high productivity. However, many approaches fail to deliver. Sander Hoogendoorn (Capgemini) and Rody Middelkoop (Avisi) will present a very pragmatic approach to model driven development, based on modeling smart use cases and domain models in UML. The speakers elaborate enthusiastically on this approach and the techniques used, and they will model and generate a fully deployable Java applications live on stage!

Rody Middelkoop and I will deliver the following talk on the J-Spring Conference, April 15, 2009 in ‘t Spant in Bussum.

More information: www.smartusecase.com.

Talk at J-Spring conference. Pragmatic model driven development using smart use cases and domain driven design

Posted on by
Reply

Today Rody Middelkoop, senior technology consultant at Avisi and lecturer at the HAN and I will do an amusing talk at the J-Spring Conference in Bussum on model driven development, using a highly pragmatic approach. Talk includes a live demo where we will build a Java web application on stage in a few minutes (the build process will likely take most of that time. A good moment to tell some jokes I suppose). In projects we execute using the Accelerated Delivery Platform, either with .Net or Java, we generate code from our standardized smart use cases and the domain model, using our Tobago MDA tool set. See www.accelerateddeliveryplatform.com for more details.

In our daily practice we generate for a variety of architectures in the .Net space. For instance, we apply our own frameworks, or combine these with open source frameworks such as nHibernate, and blocks from Microsoft.

image

Rody however used our created a set of templates to also facilitate that, resulting in the generation of large parts of Java applications. In short: model driven development has a promise of high productivity. However, many approaches fail to deliver. Rody and I will present a very pragmatic approach to model driven development, based on modeling smart use cases and domain models in UML. The speakers elaborate enthusiastically on this approach and the techniques used, and they will model and generate a fully deployable Java applications live on stage!

We will share our very pragmatic approach to delivering software using model driven development. First, I will elaborate on the modeling and code generation approach, that relies on smart use cases, smart use case stereotype, a solid software architecture and domain driven design. Next, Rody will take the stage and demonstrate how this approach effects in building Java web applications, generating a fully deployable Java EAR live on stage! Although other architectures and frameworks can be applied, Rody will use open source Java frameworks such as Ant, FreeMarker, Struts2, Spring and JPA/Hibernate3.

Cool isn’t it?

For more information: www.accelerateddeliveryplatform.com
J-Spring: www.nljug.org

Digg This

Pragmatic model driven development in Java with smart use cases and domain driven design

Posted on by
Reply

In our Accelerated Delivery Platform we generate code from our standardized smart use cases and the domain model, using our Tobago MDA tooling. See www.accelerateddeliveryplatform.com for more details.

In our daily practice we generate for a variety of architectures in the .Net space. For instance, we apply our own frameworks, or combine these with open source frameworks such as nHibernate, and blocks from Microsoft.

image

Until recently, we did not have templates to generate Java. However, Rody Middelkoop from Avisi in Arnhem. He created a set of templates to also facilitate that, resulting in the generation of large parts of Java applications. Rody and I decided to send in a proposal for the upcoming J-Spring Conference. Here it is:

Model driven development has a promise of high productivity. However, many approaches fail to deliver. Sander Hoogendoorn (Capgemini) and Rody Middelkoop (Avisi) will present a very pragmatic approach to model driven development, based on modeling smart use cases and domain models in UML. The speakers elaborate enthusiastically on this approach and the techniques used, and they will model and generate a fully deployable Java applications live on stage!

In this unstable economy, organizations target software development at shorter time-to-market and high productivity. Model driven development has a promise of raising productivity in projects. However, many approach fail to deliver this promise. During this high-paced, interactive talk speakers Sander Hoogendoorn (Principal Technology Officer and agile thought leader at Capgemini) and Rody Middelkoop (Technical evangelist at Avisi, and lecturer at the Hogeschool Arnhem Nijmegen) share their very pragmatic approach to delivering software using model driven development. First, Sander will elaborate on the modeling and code generation approach, that relies on smart use cases and smart use case stereotype, a solid software architecture and domain driven design. Next, Rody will take the stage and demonstrate how this approach effects building Java web applications, generating a fully deployable Java EAR live on stage! Although other architectures and frameworks can be applied, Rody will use open source Java frameworks such as Ant, FreeMarker, Struts2, Spring and JPA/Hibernate3.

Reblog this post [with Zemanta]

Single point of truth. Domain driven development in the distributed era. Episode III

Posted on by
Reply

Go to episode two
Go to episode one

Client / server could have been a much more successful era in software development, if it wasn’t for this copy-and-paste programming, leading to applications that slowly became unmanageable. I have seen this anti-pattern occur in any of the popular client / server technologies. Without exception, whether it was Visual Basic, PowerBuilder or SQL:Windows and even the older web technologies, such as ASP and even early Java applications.

Splashed business logic

We still bare the fruit from the client / server era. Many of the projects we currently undertake are application migration projects, or re-engineering projects. Although tools exist that claim to do fully automated migration of client / server apps, I find that hard to believe. Having done many code reviews on these poorly constructed applications, these all seem to have one thing in common: the business logic is splashed all over the place, and hardly ever consistent.

Single point of truth

And the nasty thing is: we could have prevented most of this problem, if we would have known then what is now much more common, although less widespread as it should be. But I’ll come back to this in later episodes.

We should have introduced a single point of truth in our client / server applications. We should have constructed a domain layer – or business layer – that contains our business rules and validations, as in the figure below. Separating concerns is a popular catch phrase. In this case separating the presentation logic of the user interface from the domain logic in the domain layer.

image

Now we only have one location of our simple business rule. For now, I’ll leave it in the middle where in the domain the business rule sits. There are a few options. If the customer changes his mind in this situation not much harm is done. We simply modify the one business rule in the domain layer and we’re back on the road. All presentation logic simply refers to this location, so we’re good.

For as long as they both shall live

Of course, this refactoring comes with a couple of consequences. For starters, you could reason about the fact whether a copy of the business logic should also be present in the database underneath. There are a couple of thoughts to consider here:

  • How and by whom is the is the database approach. If our application is the only party to talk to the database, and if this situation remains in tact, you’re quite safe, and you could consider not implementing the rules in the database.
  • If you’re not sure who else approaches the database, you will need to implement the rules at least in the database too, otherwise there is no way of guaranteeing continuity and consistency.
  • If you decide to have the business rules implemented double, make absolutely sure that the two versions of the truth are in sync, and will remain in sync for as long as they both shall live.

This taking into consideration, applications and database should have been much easier to extend and to maintain. Of course, back in the nineties of the previous  century, more and more people started to realize this. That’s when multi-layered architectures became in fashion, which they still are.

The merits of two-tier architecture. Domain driven development in the distributed era. Episode II

Posted on by
Reply

Go to episode one.

So now you’re stuck with this two-tier architecture. Is this a problem. Well, not yet. However, it can become a huge problem, and it has become a huge problem in many, many client / server applications, in a vide variety of technologies, including several types of (legacy) web application technologies.

The truth is out there

The problem with this architecture again is fairly simple. There is no single point of truth. Business logic is scattered. Consider this simple piece of business logic below.

if (StartDate < EndDate)
{
   ...
}






This code is now in the database, to keep the database from getting harmed. But it is also copied into one of the forms in the application, preferably on an event that is fired when the user tabs out of the field StartDate from, let’s say a Contract.


Eventually, there will be someone on the team of developers who is going to build another form that involves manipulating a Contract. It could be yourself, or any of the other well-educated developers, but there’s always someone how will copy-and-paste the business logic from the other form to the new one. And from that time on the truth is out there. Somewhere. After a while, you will end up with an application that looks like this.


image


And you might not even see that, because it happens over time. For instance, much of this copy-and-paste activity will take place after the application is deployed and it enters maintenance mode. Especially when the boys and girls doing the maintenance were not on the team that built the software.


Customers changing their minds


Still, this doesn’t have to be bad. It will become bad when something peculiar happens: the customer changes his mind on the business rule. Now, I know, that never happens on your projects, but on mine it did and it does. On average, requirements will change about 20% to 25% during the project. And there you go. Let’s say the customer just thought of the fact that the previous rule must be altered. Just a very small change, isn’t






if (StartDate <= EndDate)


{


...


}






So the boys and girls in the development or maintenance team start looking for the locations this business rule applies to. Of course, there is hardly any documentation, so they start searching the code. And you know what, they will find occurrences of the business rule and fix them. But, that’s Murphy for you, they will likely not find all the occurrences. The applications will now look like this.


image


And that’s where client / server fails. Miserably.

					

		
		
	


				
					
	

		

						
Back in the days of client/server. Domain driven development in the distributed era. Episode I

			
						

				Posted on   by  			

			
						

				2			

					


				

			

At this point in time, where we slowly shift from service orientation to cloud computing, building business software is more complicated then it has ever been. There are many platform that your software needs to target, and there are even more ways of writing the software.


Beyond choosing technology


Choosing a technology goes way beyond stating that you are doing Java, .Net or Adobe, and can be quite complicated. A vast amount of architectures, patterns, frameworks – open source and vendor specific – is available to make life easier, but choosing more complex. With this paper – in episodes – I will try to make a point for building software around its domain, also in applications that consume services in a distributed environment. Especially in such a service oriented environment, since there is a wide variety of sources your domain can be fed from, including database, ERP, web services and the cloud – where ever that leads us to. In the sequential episodes of this paper, I aim at presenting a collection of patterns that will help you leverage your domain driven design independent of the back ends this domain needs to interact with.


Back in the good old days


But first things first. Back in the old days of client/server life was fairly simple. You could find the a way to get the data you needed from the database, usually using ODBC, and splash that data to a form, usually a Windows form. You could build applications in a jiffy. Didn’t we all love PowerBuilder, SQL:Windows and Visual Basic?


Then life got a little more complicated at the time the customer wanted some validation in the application. Let’s say hew wanted to make sure that the end date of a contract was either blank or later in time than the starting date. Here’s where the discussion started. The developers that previously worked with Clipper or DBase would insist to put this validation in the database. And they did. Nice and safe. The younger developers, including me, however would mention that if validation was delayed until the data reached the database, it was fairly late. Couldn’t we just build the validation into the form? Well, yes we could. And we did. So we ended up with a simple architecture, as shown below.


Client / server softwar architecture


The nasty thing about this architecture is that both arguments hold. Yes, validations in the database is fairly safe. And yes, validating until the data is in the database is fairly late. So now we keep two versions of our little validation rule. One in the database, and one in our form. It’s the same rule. For now.

					

		
		
	


				
					
	

		

						
Application migration using smart use cases and a model driven development approach

			
						

				Posted on   by  			

			
						

				Reply			

					


				

			

Application migration is the process of migrating older applications (often referred to as legacy) to application that have more of less similar functionality, but are developed in newer technology. Application migration has proven to be a crucial but very hard part of software development over the years. Key to such projects is:


    

  • Automated migration is hardly ever possible. It is hard for tools to migrate towards new development models, such as from Windows to web, because underlying different platforms have totally different programming models. 
    • 

  • Business logic is scattered. In most legacy applications, the business logic is scattered all over the place, from user interface to the database. New architectures and platforms often serve best when applying domain driven design and development to centralize such logic. Migrating business logic is often hard. 
    • 

  • Process logic is in the user interface‘. While current platforms and architectures offer to build software around business processes, this wasn’t always the case. Previously, lots of software was built around maintaining the database. Process logic is therefore either not present, or entwined in the user interface, which makes it hard to unlock.
    • 



    Using our Accelerated Delivery Platform (ADP) we have done some successful application migration projects. The ADP holds a number of accelerators that contribute in lowering your workload in such projects to a great extend.For instance, we model requirements using smart use cases and domain models. Smart use cases are an excellent unit of work to estimate, plan, and reuse functionality. See the example model below. Moreover, we generate a lot of code from both models using our generator Tobago MDA, but instead you might use other code generators, such as Velocity or CodeSmith. 


    Task 


    This code runs under (our) proven .Net frameworks. But, smart use cases also serve as a great unit of requirements when remodeling existing applications.


Strategy for application migration


Using these accelerators a clear strategy for solving re-engineering assignments such as yours is defined as follows:


    

  • Re-model in smart use cases. Examine the existing applications and model smart use cases from that. 
    • 

  • Model the domain. Create a model the domain, for instance from existing data models. 
    • 

  • Generate the new application. Generate the larger part of the new application using our model driven approach and Tobago MDA. 
    • 

  • Examine business logic. Examine the old code for business logic and extend the generated application with this logic (in the domain layer). 
    • 

  • Round up user interface. Finish of the newly generated user interface by examining the old user interface.
    • 



Of course, this approach does not solve all of your problems, and still leaves manual work discovering the business and user interface logic. But this approach reduces a lot of work. Even better, since the new application was modeled and generated, it is possible to migrate the model to several different platforms, such as mobile and web, or to migrate to a new platform much more easily in the future.


We have applied the accelerators in this platform in many projects and at many customers. Currently we support generating both Windows applications and ASP.NET web applications, and we have started to support Silverlight front ends and (even) Java applications. 


Generated code is plain C# (or VB.NET or Java) and can be read and extended at any time. As the platform is shared with our customers in a open source-like manner, all accelerators in our platform come free of cost (also for our customers). There are 8 different training courses available to come up to speed with the platform.


This presentation will explain this approach to application migration into more detail.



					

		
		
	


				
					
	

		

						
So much to write, so little time

			
						

				Posted on   by  			

			
						

				3			

					


				

			

It’s too bad there’s only 24 hours in a day. There are so many ideas in my head that I still have to write down, that I have to make a (short) list now to keep my head from exploding.


So here it is:


    

  • White paper on how to do agile SAP projects using smart use cases.
    • 

  • Article on applying smart use cases in BI project (started).
    • 

  • White paper on agile accounting models (80% done).
    • 

  • White paper on my agile methodology Smart.
    • 

  • Book on agile / Smart in everyday practice (lay-out done). Have to find publisher.
    • 

  • Book on software architecture and patterns for .Net projects (started). Need to find publisher.
    • 

  • White paper on pragmatic model driven development.
    • 

  • Wiki page on how to use Tobago MDA.
    • 

  • Article on pragmatic model driven development in Java (with Rody).
    • 

  • Article on Descriptor pattern
    • 

  • Article on Smart Reference pattern (80% done).
    • 

  • Blog on agile mediocrity.
    • 

  • Article on application migration using smart use cases and the Accelerated Delivery Platform (started).
    • 

  • Ugly blog on the hype of cloud computing, following and extending the hypes around service orientation and component based development.
    • 

  • White paper on distributed agile software development.
    • 

  • Book on project anti-patterns (lay-out done).
    • 

  • White paper on our three references architectures, identifying all types in the layers, and their responsibilities.
    • 

  • Update the wiki with Smart 3.0 (30% done).
    • 

  • White paper on level of ceremony in agile methodologies (30% done)
    • 

  • Wiki page on mixing Scrum and Smart.
    • 

  • Wiki page on splitting smart use cases to work items.
    • 

  • Wiki page / article on testing smart use cases (80% done).
    • 

  • Newsletter item on visit of .NET PAC in Redmond.
    • 

  • Book on smart use cases.
    • 



And moreover (added February 6):


    

  • White paper on agile for software product development.
    • 

  • White paper about implementing agile smart.
    • 

  • Blog on questions raised during recent discussion on implementing agile at a large international bank.
    • 

  • Blog post(s) on going from Twitter API to service oriented software.
    • 



So help! Any votes or assistance offered?


For more information around these subjects see: www.accelerateddeliveryplatform.com

					

		
		
	


				
					
	

		

						
Talk at Javapolis 2007. Popular project anti-patterns

			
						

				Posted on   by  			

			
						

				2			

					


				

			

This is the video from Parlays.com that presents the talk I gave at the last JavaPolis conference in Antwerp, Belgium. During the talk I ask myself the question how everybody in their own role can attribute to making our project fail, as it is far too complicated to make your projects succeed.


The talk presents popular anti-patterns I’ve gathered over the years, such as Titanic Projects, the Bob-the-Builder Syndrome, PowerPoint Architecture. Enjoy.



					

		
		
	


				
					
	

		

						
Javapolis 2008

			
						

				Posted on   by  			

			
						

				2			

					


				

			

Did a talk at Javapolis 2008 in Antwerp in December. As I stood in last minute for Andy Mulholland, group CTO at Capgemini, who was ill, I had little time to prepare a sound talk. That’s why I used a golden oldie, but still very valid!


Project anti-patterns. How to make your projects fail

Software development is hard. Many software development projects fail to meet their goals. Although nobody deliberately thrives to make our projects fail, being successful in software development projects is just plain tough. However, making a project fail is easy. In his ironic and entertaining style the speaker Sander Hoogendoorn demonstrates how each of us can contribute in making our projects fail.


Presenting a collection of patterns, Sander zooms in on all roles in projects, such as project managers, architects, designers, developers and even testers (the poor guys who get to slash the work of other people at the end of projects). For each of you he has tips & tricks that will help you make your project fail miserably. Low cost, high impact!


This talk presents you with patterns such as: Titanic projects, Dead fish projects, the new kid on the block, Death by planning, Architects-don’t-code, Powerpoint Architecture, use case worst case, the Truck Factor, and the Bob the Builder Syndrome.


I had a talk with Stephan Janssen, chief organiser of Javapolis, and still a geek for gadgets, who told me my talk was taped and will be made available soon. I’m very curious to what it (and I) looks like on film. More on Javapolis shortly – met a lot of interesting people and gained some new insights as well.